Responses without requests to a temporary queue

[ynusis]

Hi everybody,

I run into several questions implementing a request / response system where the response is not send immediately after the request or responses are send without a request. So I can't use the JMSReplyTo() because sometime there is no request but i habe to send a response.

It is very important that the answer is only send to the client who made the request, so I can't use a public destination for all responses.

I figured out, that I can use the following code to "persist" the clients temporary queue on the server side although the Queue itself is not serializable:

The very first message send by the client contains a JMSReplyTo() pointing to a temporary queue created by the client.

{code}

// [...]

HornetQTemporaryQueue q = (HornetQTemporaryQueue) message.getJMSReplyTo();

String persistedQueue = q.getAddress();

persist(user, persistedQueue); // pseudo code

// [...]

{code}

All the following responses are send using this snippet:

{code}

// […]

String persistedQueue  = getPersistedQueue(user); // pseudo code

MessageProducer producer = session.createProducer(HornetQTemporaryQueue.fromAddress(persistedQueue));

producer.send(...);

// [...]

{code}

My questions are:

1.) Is this a good idea at all?

2.) Is there a standard JMS way doing this? My solution is HornetQ specific.

3.) Is the scenario described above an issue that should be solved with JMS? Maybe I am just trying to abuse JMS?

A completely other idea:

Is it possible to have server-side selectors for each client based on JAAS? So I could use a public topic for the answers while clients are separated by there automatically generated selectors?

Regards,

Michael

[andreas_back]

Hello Michael,

you can have a look at "Designing Messaging Applications with Temporary Queues" by Thakur Thribhuvan, see http://onjava.com/pub/a/onjava/2007/04/10/designing-messaging-applications-with-temporary-queues.html

The second page contains an example of temporary queues with JMS but there are doubts that temporary queues are adaequate for you.

If you want to use the "Single static queue for multiple clients model" you shall be aware of the status of https://jira.jboss.org/browse/HORNETQ-469. You then can also have a look at the Thread http://community.jboss.org/thread/154438?start=15&tstart=0

If you decide for a variant of the "static queues per client model" and the number of clients is not fixed, then you can dynamically (programatically) create and delete (JMS) queues. If you have a unique identifier for the client you can make it a part of the queue name of the dynamically created queue, that may simplify the propagation of the address infos. But the destruction of the dynamically created queues in the case of a server crash might be something that needs to be solved.

With best regards,

Andreas

[andreas_back]

Hello Michael,

you of course may look at the example hornetq-2.1.1.Final\examples\jms\temp-queue for

temporary queues and JMS and HornetQ!

And a full code example of the replier with clear explanation of the Request/Reply
pattern is given under http://www.eaipatterns.com/RequestReplyJmsExample.html.

The HornetQ documentation clarifies the usage of temporary queues under 46.6.

For our application for example it is seems not to be senseful to use temporary

queues, see the question https://community.jboss.org/message/557537#557537,

because

*     the request of the servlet not performed by a JMS-message

*     and the request of the servlet is to a stateless (!) session bean

*     and the response to the servlet is issued by a MDB via a queue.

So we have not a JMS-based Request/Reply pair and are not able to identify

a single replier.

With best regards,

Andreas

[ynusis]

Hi Andreas,

thank you very much for your reply. I also found the example you gave me by Thakur Thribhuvan. The "problem" with this example is, that the response is send immediately after the receive. But I need a way to send a response to the client without an request.

So my solution is to wait for the first message of the user (lets call him UserA) with a filled jmsReplyTo() property and to "persist" this jmsRplyTo() value. So if later an event occurs that must be send to UserA I can look into the database and have the temporary queue destination for this special user.

I will try to implement the communication as described. If I fail I will post my solution here.

Regards,

Michael

[timfox]

I would probably just use a single non temporary topic, and each requestor would receive a replies via a subscription with a selector. This would be 100% standard JMS and probably give the best performance too.

[ynusis]

But there is no guarantee that users can not select messages from other users? Or is it possible to set selectors on server side like i suggested in my first posting?

[timfox]

Selectors are always evaluated on the server side.

If you choose your selector appropriately, e.g. based on some kind of user id which you pass in a header you can ensure the consume only receives messages for that "user"

[andreas_back]

Hello Michael,

further hints to estimate if a topic instead of queue can be used can be found here:

     http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jms/design_best_practices.html#1061024

With best regards,

Andreas

[ynusis]

I will try to demonstrate my question with some code:

In the example I am userid := 1you are userid := 2

Client side:

Queue queue = ...;

MessageConsumer consumer = session.createConsumer(queue, "userid=1");

// Ok, this is fine as long as I do not insert a "wrong" userid...

MessageConsumer consumer = session.createConsumer(queue, "userid=2");

// Not so fine, now i steal your messages...

What my question was about: I will set a selector based on JAAS on the server side. So every connection made by a special ConnectionFactory is automatically completed with a selector based on JAAS data. So no user can "steal" data any longer. There must be a guarentee that userA can only receive messages for userA.

[timfox]

Michael Wittig wrote:

I will try to demonstrate my question with some code:

In the example I am userid := 1you are userid := 2

Client side:

Queue queue = ...;

MessageConsumer consumer = session.createConsumer(queue, "userid=1");

// Ok, this is fine as long as I do not insert a "wrong" userid...

MessageConsumer consumer = session.createConsumer(queue, "userid=2");

// Not so fine, now i steal your messages...

I don't understand what you are trying to to explain in the above example. Who is "stealing" what?

[ynusis]

On a topic everybody sees every message.

I can not force the clients to use a selector. So I can not guarantee that messages are just send to the adressed user.

[timfox]

I don't understand why your clientd can't specify a selector.

I am lacking information on what you are trying to achieve here.

[ynusis]

My client can specify a selector but he also can not do it. That's the problem.

I can't rely on client side selectors. otherwise I have to pray that all programmers who are using the topic will use the selectors. And this is in my opinion not a good idea because it is not guarenteed by the server.

What I am trying to achive is a system where the server sends messages to indivudially clients over jms without having a request for every response.

For example a perdiodically generated report for a certain user.

[timfox]

I'm not following you. If you have no control over what clients do, then how's that going to work with a queue? You won't have control over how clients create consumers on the queue either...

Still not understanding your use case, perhaps you should describe it in more detail?

[andreas_back]

Hello Michael,

one question that comes into my mind is the lifetime and the number of your clients.

What you are seeking for seems to be a point-to-point connection between one client and the server, and this for each client. This sounds like you may favour a queue.

The next point is whether you know the number and identity of your clients at design-time. If yes, you can use a fixed number of queues.

If no, things become more interesting.

With best regards,

Andreas