0

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 ;-)

Peter Kofler
  • 9,252
  • 8
  • 51
  • 79
  • I don't get why MDB is not an option. – Pascal Thivent Oct 07 '09 at 03:46
  • because we want to get rid of EJB – Peter Kofler Oct 07 '09 at 08:11
  • The standard way to consume JMS message in a J2EE container is to use a MDB, which is known to be the simplest EJB 2.x. So I still don't understand why you prefer using a Stateless Session Beans (SLSB) which **is** more complicated. I'd get rid of SLSB, but MDB are ok IMO. – Pascal Thivent Oct 07 '09 at 19:04
  • Sorry for my first comment. Of course you are right. The problem is the legacy: We offer a Tuxedo service which is provided by WL10 as SLSB. To get rid of all EJBs in our app, we want to extract this (last remaining) SLSB into a standalone app and tunnel it's calls from our app through JMS. Or sort of. It sucks. – Peter Kofler Oct 08 '09 at 07:45

2 Answers2

0

Before MessageConsumer receiver = session.createConsumer(responseQueue); put conn.start();

Costin Arsene
  • 58
  • 6
  • Unfortunately I am not able to verify this, as the whole story was done differently and the problem did not arise. When checking the API doc it says `A JMS client typically creates a connection, one or more sessions, and a number of message producers and consumers. When a connection is created, it is in stopped mode. That means that no messages are being delivered.` So I would say you are right and that would have been the solution. – Peter Kofler Dec 17 '09 at 09:34
0

After you create the connection, it needs to be started to get into the receiver mode. Try this

 ......
 conn = cf.createConnection(); 
 conn.start();
 session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE); 
 ......
Vikdor
  • 23,934
  • 10
  • 61
  • 84
Steven Ye
  • 1