Designing Messaging Applications with Temporary Queues
Subject:   performance
Date:   2007-07-26 05:33:41
From:   gastonscapusio
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.


Full Threads Newest First

Showing messages 1 through 2 of 2.

  • performance
    2007-07-26 18:03:07  ThribhuvanThakur [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 [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.