Skip to main content

GF4 / JMS 2.0 - How to read from JMS Temporary Queue? (Regression from GF3.1)

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
7 replies [Last post]
lprimak
Offline
Joined: 2006-08-22

Hi,

I am in the process of upgrading to GF4 and I decided to try JMS 2.0.
I have a MDB that listens to a topic and then replies to a temporary queue via getJMSReplyTo()
This is all done in a @Singleton EJB.

Question becomes, how do I listen to temporary queue replies?
I can't seem to do it in MDB because it requires a non-temporary predefined queue to listen to,
and MessageConsumer.setMessageListener doesn't work in JMS 2.0 with JMXContext @Injected.

I even tried the new concurrent context API to try to start another thread, and manually receive() the messages to no avail.

Does anyone have experience with this or am I missing something?

Thank you

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
nigeldeakin
Offline
Joined: 2007-10-12

The JMS 2.0 specification contains examples of how to do request-reply messaging using a temporary queue. Section 15.11.1 shows how this can be done using the classic API, and section 15.11.2 shows how this can be done using the simplified API.

You can download the spec from http://jcp.org/aboutJava/communityprocess/final/jsr343/index.html

As you observe, Java EE does not allow the use of the setMessageListener method, so you need to receive messages synchronously using one of the receive methods. This is not a new restriction.

lprimak
Offline
Joined: 2006-08-22

Thanks for the reply,

The examples show how to use request / reply pattern synchronously.
What I need is a way to read the temporary queue asynchronously in a separate thread.

Basically, the usage is a singleton - @Startup bean that runs for the life of the application. Basically, it's listening for modules on the cluster and periodically gathers their status.

So, the temporary queue listener should be in a separate thread.

But, no matter what I do, I can't seem to access the connection / temporary queue in a separate thread using the new API.

nigeldeakin
Offline
Joined: 2007-10-12

By "asynchronously in a separate thread" do you mean you want to create a separate thread which calls receive(timeout) repeatedly?

I'm not sure exactly what the spec allows here. But are you saying this works with a MessageConsumer but not with a JMSConsumer? In GlassFish there's not much difference under the covers.

lprimak
Offline
Joined: 2006-08-22

Yes, exactly.

Right now, (in GF 3.1) I just call setMessageListener() and it works (I know it breaks the spec) but it does work, and right now I can't figure out the "right" way of doing this.

nigeldeakin
Offline
Joined: 2007-10-12

OK. So what you were exploiting previously is that GlassFish MQ allows you to call MessageConsumer.setMessageListener in a Java EE application, even though the Java EE spec states that applications must not do this.

This has not changed in GlassFish 4 (even though it was forbidden in the spec) because we didn't want to disrupt existing GlassFish applications.

However JMSConsumer.setMessageListener, which is a new method in in GlassFish 4, does enforce this restriction.

From a spec perspective, there isn't a "legal" way to create an async consumer on a temporary destination in a Java EE application (and there has never been). I'll log this as a possible issue for the next version of the JMS spec.

lprimak
Offline
Joined: 2006-08-22

Thank you. Appreciate putting this in the spec in the near future. I believe this is a pretty general use case in clustered applications.

nigeldeakin
Offline
Joined: 2007-10-12

Logged in the JMS specification issue tracker as https://java.net/jira/browse/JMS_SPEC-141