Are you using temporary queues in an interesting application? Discuss it here.
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 17 of 17.

• performance
  2007-07-26 05:33:41  gastonscapusio [Reply | View]
  
  
  I like your article and I agree with you that in some cases it's a good idea to use temporary queues.
  
  My question is about if it's a good idea to use temporary queues to send messages within the server and a rich client, where there are about 5000 clients (5000 temporary queues). In this scenario the server is sending messages to a especific user due to an event in the server side.
  In this scenario we couldn't use 1 static filtered queue because the messages couldn't be readed by other clients that has access to it (security).
  I don't know if queues is the best approach in this scenario.
  
  regards
  Gastón
• performance
  2007-07-26 18:03:07  ThribhuvanThakur [Reply | View]
  
  
  Let me see if I understood your question(s) correctly.
  
  (1) You have a client server application where in the client is fat (rich).
  
  (2) You have to support 5000 clients and you don’t want the clients to peek at each other.
  
  (3) Server has to reach out to an individual client.
  
  When it comes to the applicability of JMS with Dynamic Queues, it should matter whether the client is thin or rich, what matters is that you need a static queue for the handshake. You can then process the request and reach out to a client individually using JMSReplyTo header, as discussed in the article.
  
  Regarding you question as to how many Dynamic Queues we can create, it depends on the JMS infrastructure that is available to you. For instance, I have used Tibco in the past and have used other Business Integration/JMS vendors like Vitria and have not seen any issues, as far the number of temporary queues are concerned. I was able to create 50 thousand!! Keep in mind that these queues only exist as long as the session is alive, and hence you should take all the necessary action to close the session gracefully, as soon as you are done.
  
  As far as performance is concerned, in the past I have used Swing clients in lieu with WebSphere and WebLogic and was able to guarantee 2 seconds response SLA. Again, it largely depends upon the complexity of the server side processing.
  
  From the monitoring perspective, Dynamic queues don’t pose any treat, since they are cleaned up as soon as the session is closed.
  
  Hope this helps.
  
• performance
  2007-07-29 17:16:19  gastonscapusio [Reply | View]
  
  
  Thanks for your answer.
  
  What I'm trying to do is to communicate events to the client. The server push data (events) to the client.
  The client could be connected to the server 1 day (session duration).
  
  Maybe I could use RMI callback (p.e.) or raw socket.
  
  
  Regards
  Gaston

• Check out Spring JMS Remoting - A very clean way to do this
  2007-04-27 20:20:28  tkjc [Reply | View]
  
  
  Spring 2.0 introduces a set of JMS remoting classes which makes the proposed system much simpler to program and use.
  
  http://www.springframework.org/docs/reference/remoting.html
  
  Basically the client and server share the same service interface. The client codes to the interface and the server code implements it.
  
  In your spring config file on the client you create a factory bean of JmsInvokerProxyFactoryBean, you give this bean the service interface, the well named queue and connection factory to the JMS Server. Spring creates a dynamic proxy which translates your code into JMS messages with reply-to and temp queues created properly.
  
  On the server side you create a JmsInvokerServiceExporter bean which has a reference to your bean which actually implements the service interface. You then set up a message listener container which has a reference to the JmsInvokerServiceExporter. The service exporter handles converting the message into an api call on your interface and responding back to the caller on the reply-to queue.
  
  This approach is really beneficial because the code you write NEVER interacts with the actual JMS api. This allows you to easily test the system, change the underlying transport layer (spring offers similar services for RMI/Hessian/Burlap/WebServices), and so on. You can also use this to break apart a useful service from a singular process and expose it remotely to the entire system.
  
  Personally I think the temp queue request-reply approach is a great alternative to an RMI/stateless session bean approach. The layer of indirection afforded by the JMS server is huge. You can easily move the server process to different hosts without worrying about client configurations. If your service is truely stateless you can bring up several server processes consuming off the same queue and distribute your work seemlessly.
  
  
  

• Code on the client side
  2007-04-23 17:30:27  chun chikwong [Reply | View]
  
  
  Hi Thakur, I would like to see the source code on the client side if it is available. I understand 90% of what you said in the article, the 5% lies on the client side (other than create the JMSReplyTo header field) how it gets back the message and proceeds.
  
  Another 5% is on the section "Some Considerations for the Client Side When Using Temporary Queues", in which you were talking about concurrency and JMS sessions. Sorry I am pretty new on this JMS stuffs.
  
  A very nice article indeed.
  Matthew
  
  
• Code on the client side
  2007-04-26 10:20:57  chun chikwong [Reply | View]
  
  
  Hi folks,
  
  If anyone has the same question with the "Close the Connection as soon as you are done with all the threads" like I did, Thakur suggested we can use workerThread.join() to wait till the thread dies, then we close the connection afterward.
  
  Thanks for Thakur pointing it out.
  Matthew
• Code on the client side
  2007-04-24 17:44:09  ThribhuvanThakur [Reply | View]
  
  
  Here is the protoype.
  We start off be initiating a JNDI look up for Queue Connection Factory
  
  Access the resources by looking up the JNDI tree
  
  Get the Connection Factory reference
  
  Get the connection to JMS Server
  
  Get the reference to the static destination that MDB is listening on
  
  
  Create a Session using Connection Object
  
  Create the Temporary Destinations using Session Object
  
  Create the Message - in our example a text message
  
  Set the temporary queue name as a message header - JMSReplyTo
  
  
  Create Receiver - We are now ready to listen on the temporary Queue
  
  
  Create worker thread pass in Session, Receiver and the Connection so that it makes the blocking call
  
  
  Start the thread.
  
  At this point a new thread is spawned and waiting for the reply
  
  Create a sender to the static queue using the session
  
  send the message to the static destination
  
  Assuming MDB is active and accepting requests, depending upon the vendor, you could accept the message in a second or couple of seconds - depends upon the complexity of the workflow you are dealing with on the Facade side
  
  
  Clean up
  
  Worker thread will close the session and the receiver passes in, but not the connection
  
  Close the Connection as soon as you are done with all the threads
  
  
  IMPORTANT NOTE: YOU CAN'T PASS IN THE SAME SESSION TO MORE THAN ONE THREAD, EVEN THOUGH YOU CAN PASS IN THE SAME CONNECTION OBJECT, OTHERWISE, YOU GET javax.jms.IllegalStateException SINCE JMS SESSIONS ARE NOT MULTITHREADED AS DESCRIBED IN THE ARTICLE
  
  
/** We start off be initiating a JNDI look up for Queue Connection Factory*/
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, VendorSpecificContextFactory);
env.put(Context.PROVIDER_URL, JMS_URL);
env.put(Context.SECURITY_PRINCIPAL, USERNAME );
env.put(Context.SECURITY_CREDENTIALS, PASSWORD);
Context context = new InitialContext(env);
System.out.println("Go the Initial Context");
/** Access the resources by looking up the JNDI tree */
/** Get the Connection Factory reference*/
QueueConnectionFactory qcf = (QueueConnectionFactory)context.lookup(QCFNAME);
System.out.println("Go the QCF");

/** Get the connection to JMS Server */
javax.jms.QueueConnection qConnection = (javax.jms.QueueConnection)qcf.createQueueConnection(USERNAME, PASSWORD);

/** Get the reference to the static destination that MDB is listening on */
javax.jms.Queue staticQueue = (javax.jms.Queue)context.lookup(STATIC_QUEUE_NAME);

/** Create a Session using Connection Object */
javax.jms.Session qSession = (QueueSession)qConnection.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);

/** Create the Temporary Destinations using Session Object */
javax.jms.Queue replyTempQueue = qSession.createTemporaryQueue();
System.out.println("Temporary Queue Name:" + replyTempQueue);

/** Create a Message - in our example a text message */
TextMessage message= qSession.createTextMessage();
message.setText("sampletext"); // in most cases it is an xml

/**Optional - set message properties - if any for example user, department*/
message.setStringProperty(USER, USER);
message.setStringProperty(DEPT, DEPT);

/** Set the temporary queue name as a message header - JMSReplyTo*/
message.setJMSReplyTo(replyTempQueue); //mandatory in the context of temporary destinations

/** Optional - vendor specific - set the message expiration*/
message.setJMSExpiration(30000); //message will expire after 30 seconds

/**Assuming MDB is active and accepting requests, depending upon the vendor,
* you could accept the message in a second or couple of seconds - depends upon
* the complexity of the workflow you are dealing with on the Facade side*/

/** Create Receiver - We are now ready to listen on the temporary Queue*/
QueueReceiver receiver= ((QueueSession)qSession).createReceiver(replyTempQueue);

/** Create worker thread that makes the blocking call*/
RequestHelper worker = new RequestHelper(qSession, qConnection,replyTempQueue,receiver );
worker.start();
/** At this point a new thread is spawned and waiting for the reply*/

/** Create a sender to the static queue using the session*/
QueueSender sender= ((QueueSession)qSession).createSender(staticQueue);
/** send the message*/
sender.send(message);
System.out.println("Message Send to Static Queue:" + staticQueue.getQueueName());


public class RequestHelper extends Thread
{
private Connection conn;
private MessageConsumer receiver;
private Session qSession;
private Queue tempQueue; /** Used only for logging purposes*/
private String threadId; /** Used only for logging purposes*/

public RequestHelper(Session session, Connection conn, Queue tmpQue, QueueReceiver queueReceiver) throws JMSException
{
this.receiver = queueReceiver;
this.conn = conn;
this.qSession = session;
this.threadId = getName();
this.tempQueue = tmpQue;
System.out.println("Temporay QueueName:" + threadId + ":" + tmpQue.getQueueName());
}

public void run()
{
try
{
System.out.println(threadId + ":Calling Connection.start");
conn.start();
System.out.println(threadId + ":Connection.Start Called");
System.out.println(threadId + ":Delivery of Messages Started");

String receivedText = null;
System.out.println(threadId + ":Waiting for Messages on Receiver");
Message messageM = receiver.receive();
System.out.println(threadId + ":Processing of Response started, Unpacking TextMessage");

TextMessage textMessage = (TextMessage)messageM;
receivedText = textMessage.getText();
System.out.println (threadId + ":Successfully Completed Processing of Response" + threadId + ":" + receivedText );

receiver.close();
qSession.close();
}catch ( JMSException exp)
{
exp.printStackTrace();
}
}
}

• Code on the client side
  2007-04-23 18:40:40  ThribhuvanThakur [Reply | View]
  
  
  Thank you for taking time to read the article. I will post the code tomorrow as soon as I have some slack. Keep in mind that JMS Session doesn't support concurrency and hence you are required to coordinate individual sessions to implement concurrent processing. I will walk you through step-by-step to accomplish just that, on the client side.

• Lifetime of Temporary Destination
  2007-04-23 13:14:05  VenugopalJ [Reply | View]
  
  
  
  
  

  
  The session should be closed as soon as processing is completed so that TemporaryQueues will be deleted on the server side
  
  

  
  
  As per my understanding of the JMS Specification closing a connection closes all the TemporaryQueues created on that connection. The lifetime of the TemporaryQueues does not depend on the Session in which they were created. Right?
  
  
• Lifetime of Temporary Destination
  2007-04-23 18:28:41  ThribhuvanThakur [Reply | View]
  
  
  JMS Session is the factory for creating Topics and Queues (temporary as well as static resources). I was trying to stress on the point that the JMS resources should be closed as soon as you done using them and not rely on garbage collection.
  
  You are right in that, as soon as the connection is closed, all the constituents of the closed connection and session are closed, like I outlined in the article
  
  >There is no need to close the consumers (QueueReceiver) of a closed session. As soon as the connection that created the temporary queue is closed, all the constituents of the closed connection and session are closed. Relying on garbage collection to eventually reclaim these resources may not be timely enough, especially in the case of JMS resources that are created outside of JVM.
  
  Thank for your time.
  

• Interesting, but why messaging?
  2007-04-23 05:36:52  zanfolim [Reply | View]
  
  
  I might have missed the point here, but why would someone use messaging for handling a synchronous request? Wouldn´t it be better to just handle it in a synchronous call (xml over http, rmi, or some other remote protocol)?
  
  Thanks for the information,
  
  Tedi
• Interesting, but why messaging?
  2007-04-23 07:53:28  ThribhuvanThakur [Reply | View]
  
  
  JMS has proven to be successful for both asynchronous (pub/sub) and synchronous (Point-to-Point) calls. As you mentioned, you could use xml/http, RPC or SOAP or RMI (for java clients) for synchronous calls. In some sense, this is a matter of choice and would depend upon the dependability and the availability of the framework you choose.
  
  If you already using JMS and wanted to support synchronous calls, then JMS is the way to go. JMS promotes building loosely coupled systems and persistence messages (dependability). If your application does not have strict response requirements, JMS will queue the request(either syn or asyn) when the service is temporarily unavailable and the message will persist until the service is ready -- after which your application would continue normally.
  
  Thanks, I should have added more along these lines. I agree.
  
  

• Nice
  2007-04-22 07:08:18  paragshah72 [Reply | View]
  
  
  Hey Tribhuvan,
  
  That was a nice article on temporary queues. When you say that static queues do not scale up well, is it because one queue may have to handle many messages and it will take greater time for the server to process each message?
  
  Regards
  Parag
• Nice
  2007-04-22 07:54:18  ThribhuvanThakur [Reply | View]
  
  
  Scalability is very subjective in this context. What I meant was, it requires an admin to create static queues/topics well in advance and maintain them administratively, before you can actually use them. This is in contrast to dynamic destinations, which could be created on the fly at runtime, enabling you to add or remove JMS resources dynamically, thus achieving better scalability. Hence it is not so much about load factor (number of messages a resource can handle) or taxing the system's performance due to the usage of static destinations.
  
  Thank you for your time and I hope I answered you question.
  

• NIce article
  2007-04-22 02:05:18  iguane18 [Reply | View]
  
  
  Very interesting. If I did understand clearly, it is an elegant way to create asynchroneous req/resp. in a distributed architecture.
  It lakes the client receiving the response but that's ok.
• NIce article
  2007-04-22 07:15:19  ThribhuvanThakur [Reply | View]
  
  
  Thank you for your time and feedback. Temporary destinations are a better communication mechanism in a distributed architecture to create 'synchronous' request/reply, as I mentioned in the introduction.
  
  Client receives the response synchronously-make a request and wait for the reply. The way you accomplish it is by passing in the name of the temporary destination as a header field (JMSReplyTo), as part of a message. The value of this header field is later used by the receiving party to send the reply as explained in the ‘Temporary Destinations: An Overview’ section.
  
  Please let me know if I answered your questions.
  

• Temporary queues always preferred ?
  2007-04-21 19:03:22  Koya [Reply | View]
  
  
  Author goes a long way trying to justify the usage of temporary destinations as opposed to static destinations. This justifies the architectural aspects of using temporary destinations. More Case studies and Code samples would be been better. Well written article, good illustrations!