How can I avoid asynchronous message deadlocks?
Submitted by: AdministratorDue to a limitation in the JMS 1.0.2 specification, asynchronous messages can become deadlocked if the close() method of a session is inside a user-synchronized block. To resolve this, you must move the close() method outside the user-synchronized block. For example:
public class CloseTest() {
private void xxx() {
synchronized (this) {
create connection/session/consumer
initialize and set a listener for this consumer;
wait();
connection.close();
}
}
private void onMessage(Message message) {
synchronized (this) {
notify();
}
}
}
Before the connection.close() method is closed, another message can be delivered to the onMessage routine by the JMSProvider. The main() method thread owns the monitor lock for the CloseTest method. Before the onMessage() method of the CloseTest class fires, JMS sets INLISTENER as the state for the session in JMSSession (the JMS specification says that the close() method must wait for the onMessage routine), so that the main() method thread can wait for the onMessage routine to complete.
Now when the onMessage routine tries to acquire the monitor lock, it blocks waiting for the main() method thread to give up, and the main() method thread is waiting for the onMessage to be completed.
JMS also blocks when the close() method of a consumer is done from an onMessage routine and the allowCloseInOnMessage attribute is set to false in the config.xml file.
Submitted by: Administrator
public class CloseTest() {
private void xxx() {
synchronized (this) {
create connection/session/consumer
initialize and set a listener for this consumer;
wait();
connection.close();
}
}
private void onMessage(Message message) {
synchronized (this) {
notify();
}
}
}
Before the connection.close() method is closed, another message can be delivered to the onMessage routine by the JMSProvider. The main() method thread owns the monitor lock for the CloseTest method. Before the onMessage() method of the CloseTest class fires, JMS sets INLISTENER as the state for the session in JMSSession (the JMS specification says that the close() method must wait for the onMessage routine), so that the main() method thread can wait for the onMessage routine to complete.
Now when the onMessage routine tries to acquire the monitor lock, it blocks waiting for the main() method thread to give up, and the main() method thread is waiting for the onMessage to be completed.
JMS also blocks when the close() method of a consumer is done from an onMessage routine and the allowCloseInOnMessage attribute is set to false in the config.xml file.
Submitted by: Administrator
Read Online BEA Weblogic Job Interview Questions And Answers
Top BEA Weblogic Questions
☺ | Can I use the getAttribute() and setAttribute() methods of Version 2.2 of the Java Servlet API to parse XML documents? |
☺ | Which of the following are the benefits of MDB (Message Driven Beans) over standard JMS consumers? |
☺ | Why do I get an error while trying to retrieve the text for ORA-12705? |
☺ | Why am I getting an ORA-01000: maximum open cursors exceeded error, even though I closed all ResultSet, Statement, and Connection objects? |
☺ | Can WebLogic Server start with a UNIX boot? |
Top Application Program Categories
☺ | AutoCAD Interview Questions. |
☺ | Microsoft Office Interview Questions. |
☺ | Microsoft Outlook Interview Questions. |
☺ | Microsoft Excel Interview Questions. |
☺ | MATLAB Interview Questions. |