I try to receive a JMS message in an EJB2 (legacy sucks ;-) stateless session bean, in weblogic 10.0.1, with bean managed transactions. Queue definition from jms folder looks like
<uniform-distributed-queue name="ReqQueue">
<default-targeting-enabled>true</default-targeting-enabled>
<delivery-params-overrides>
<delivery-mode>Non-Persistent</delivery-mode>
</delivery-params-overrides>
<quota>QuotaCrc</quota>
<jndi-name>xxx.ReqQueue</jndi-name>
<load-balancing-policy>Round-Robin</load-balancing-policy>
</uniform-distributed-queue>
<uniform-distributed-queue name="RespQueue">
<default-targeting-enabled>true</default-targeting-enabled>
<delivery-params-overrides>
<delivery-mode>Non-Persistent</delivery-mode>
</delivery-params-overrides>
<quota>QuotaCrc</quota>
<jndi-name>xxx.RespQueue</jndi-name>
<load-balancing-policy>Round-Robin</load-balancing-policy>
</uniform-distributed-queue>
The business method in the bean does not start a transaction, so the JMS operations are not transactional. The executed code is
InitialContext ictx = new InitialContext();
QueueConnectionFactory cf = (QueueConnectionFactory)
ictx.lookup("weblogic.jms.ConnectionFactory");
Queue responseQueue = (Queue) ictx.lookup("RespQueue");
conn = cf.createConnection();
session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageConsumer receiver = session.createConsumer(responseQueue);
ObjectMessage response = (ObjectMessage) receiver.receive(30000);
The problem is that receiver.receive
returns null immediately without any blocking, regardless of the contents of the queue. According to the JMS API doc., receiver.receive
with a timeout returns null after the timeout or immediately if the destination is closed. The problem is the same if I use bean managed transactions, container managed transactions or no transactions at all. Posting a JMS message to another queue works. Receive returns null immediately regardless if I do a send before in the same method or not.
Why is the queue closed, or why does it seem so?
Unfortunately MDB is not an option because we have to tunnel a synchronous call through JMS (and I don't want to fool around too much in the Ball of Mud ;-)