I have a centralized server, the functionality of this server is to create big PDF files on request basis. becasue of PDFs are big in size it will take some time to create. Then I have three more servers which will send requests to main server continuesly for generating PDFs. I have two Queues , one is requeswt Queue and one response Queue. All requests from these three servers will be in request Q and generated PDF respnses from Central server are in response Q.
Now my question is from response Q how can I identify which response should go for which server.Technologies I am using is EJB, JMS .
Please let me know any one have good design stratagy.
Thanks in advance
Why don't you try to use Topic instead of queues, so that you can rely on publish subscribe mechanism..
In general, you should choose a Topic if one of the following conditions applies:
1. The same message must be replicated to multiple consumers.
2. A message should be dropped if there are no active consumers that would select it.
3. There are many subscribers, each with a unique selector.
It is interesting to note that a topic with a single durable subscriber is semantically similar to a queue. The differences are as follows:
a.) If you change a topic selector for a durable subscriber, all previous messages in the subscription are deleted, while if you change a queue selector for consumer, no messages in the queue are deleted.
b.) A queue may have multiple consumers, and will distribute its messages in a round-robin fashion, whereas a topic subscriber is limited to only one consumer.
Hope this gives clarity for your decision
Use Queue for writing concurrent input messages from various JMS clients.
User topic to allow multiple clients listen concurrently.
U can have custom header fields added to the message. When u are creating the message for the pdf doc request, u can set a header attribute called server-name. The response message that gets put into the response q also can contain the same attribute. (The pdf response message prog can just read this attribute and put it back on the response). U can have message selectors on the front end servers (3 servers) that listen on the same q with these selectors. That will solve the prob without changing ur queue infrastructure.
Multiple subscribers (MDB's or listeners) listening to same queue will run into a race condition.
The efficient way is publish and subscribe, all other things carry overhead.
Wow never come across such a situation. If we have a queue and 3 MDBs listen on these with 3 different message selectors we have a race condition?? Why? Any reference?
When you run the message selector it will use "read and skip", the queue is not indexed like a DB table.
It will start at the first message in the queue and check each individually to see whether it matches the selector. It has to do this for every receive()
If few (or even worse none) match the selector, it will have to check lots (all) of messages. This will be especially bad when messages towards the bottom of the queue are not in memory, meaning it has to load the message into memory to look at the properties.
"Race" I define it as every MDB shall recieve and put back into queue in case it doesn't have the right selector as a result it is a hard choice to have Message selectors which bring down the MPS (the throughput measurement).
Nevertheless I do agree with you, in case if we decide not to change the infrastructure it is quick and easy way to go with message selector.
Durability is to go with ideal way which mentioned above..