|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Issue with temporary queue pooling - Illegal State Exception |
« View previous topic :: View next topic » |
Author |
Message
|
anandsourabh |
Posted: Fri Mar 14, 2008 5:54 am Post subject: Issue with temporary queue pooling - Illegal State Exception |
|
|
Newbie
Joined: 14 Mar 2008 Posts: 3
|
Hello Friends,
I was working on a requirment where an application performs repetitive request-response operations all the time. The requestor sends messages to a static mq queue, but the response is always written to a temporary queue. This information is set into the JMSReplyTo header of the outgoing text message.
Now a requirement cropped up where it was stated that temporary queue creation/destruction process for every request is an expensive process and we should get rid of it by pooling these temporary queues. This in turn means that the connection,session,temporaryqueue all needs to be added to a pool, bearing in mind that these will be used bya single requesting service all the time.( a single thread)
Summing up, the flow is as follows :
For first request
==================
Create Connection
Create Session
Create Temp Queue
Create Sender
Send Message
Add (Connection+Session+Temp Queue) to POOL
Receive Message
For next request,
==================
Get Session From Pool
Get Temp Queue instance
Send Message
Get session object retrieved above
Create Receiver
Receive Message
Problem is that this approach works for the first time and for the second attempt, I get an IllegalStateException: Connection already Closed
This happens when I am trying to send messages to the MQ Queue.
When I run this peice of code as a standalone java program, outside websphere, just looking up the JMS objects in websphere jndi tree, it all works perfectly fine !
The application is deployed as an EAR in Websphere Application Server 6.1 and Uses Websphere MQ 6.0.
I uses non-XA connection factories and there are no transaction boudaries explicitely defined by me in EAR.
The scenario involves data being entered by a end user from a webpage, uses Spring MVC, and then in the business layer, a call to the backend is made, where we send these messages via MQ and expect a response back.The results have to be displayed to the user on the webpage.
Will be great if you guys could provide me some help on this.
Thanks in Advance ! |
|
Back to top |
|
 |
JLRowe |
Posted: Fri Mar 14, 2008 8:39 am Post subject: |
|
|
 Yatiri
Joined: 25 May 2002 Posts: 664 Location: South East London
|
Are you writing you own pool implementation then? why are you using a pool if there will only be a single request at a time? have you considered late responses?
I would think about doing it differently by using stateless session beans, the ssb can open the request queue and create a response queue during the ejbCreate() method. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Mar 14, 2008 2:34 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Remember as well that the JMS implementation of IBM already contains some pooling of temporary queues.
This is why the model queue is set on the connection factory.
The overhead for this is minimal.
Now if you are outside of a J2EE appserver and dealing with a standalone JMS program you might create the session as some type of pool repository for unused temp queues.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
anandsourabh |
Posted: Mon Mar 17, 2008 1:22 pm Post subject: |
|
|
Newbie
Joined: 14 Mar 2008 Posts: 3
|
Thanks for the replies. it really did help me think more.
However, let me clarify my requirement once more.
Say from the end, user clicks on a button for checking order status.
An XML message is generated and is supposed to be sent to services behind an ESB. I have adaptors which will perform these request-response services. So, for the above example I have a service called SVC-GET-ORDER-STATUS which will read messages from a queue ORDER.STATUS.QUEUE and always write messages back to a temporary queue, which ofcourse has been set by the adaptor in the JMSReplyToQueue header of the message being sent.
I might be having another service for similar operation say SVC-GET-ORDER-DETAILS, doing the same stuff.
Each of these services will be invoked by different clients.
I could have used static reply to queues, but seems that using temporary queues is the way the requirements have been placed.
There is a peak load of 2000 users, hence it was required that we do not continously create-destroy queues, as it takes a lot of time.
I do the following the first time,
Queue outQueue=qSession.createTemporaryQueue(); |
|
Back to top |
|
 |
anandsourabh |
Posted: Mon Mar 17, 2008 1:24 pm Post subject: |
|
|
Newbie
Joined: 14 Mar 2008 Posts: 3
|
Also, the proposed architecture does not use EJBs,hence using enterprise beans is not a solution for me.  |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Mar 17, 2008 3:00 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
anandsourabh wrote: |
Also, the proposed architecture does not use EJBs,hence using enterprise beans is not a solution for me.  |
You live in a J2EE world so you should take advantage of the design.
Obviously your problem is that the session, your request is using, is different from the one that created the temp queue and as such the handle is not valid.
You need to conform to J2EE spec and let the app server do the pooling. We do truly not see that much of an impact on creating and releasing temp queues in the app as they are pooled through the JMS connection at the appserver level, and most of our req/reply flows are under 1 sec.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
JLRowe |
Posted: Tue Mar 18, 2008 3:37 am Post subject: |
|
|
 Yatiri
Joined: 25 May 2002 Posts: 664 Location: South East London
|
anandsourabh wrote: |
Also, the proposed architecture does not use EJBs,hence using enterprise beans is not a solution for me.  |
Well, what you are doing, asynchrnous to synchronous invocation is quite difficult to do well. Again, what happens about late replies? Have you thought through all the 'edge cases'?
Why make it more difficult by writing your own pooling implementation (which will have to be threadsafe by the way), when doing this with stateless session beans is a lot easier? An EJB is also remoteable so you could locate them on your MQ server.
I also notice you are using Spring, spring helps a lot with EJB invocation and implementation. Your web code need not be aware of what is actually going on in the background: be it an EJB or some other implementation. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|