[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] Adminstrative get and filtering

Robert Leftwich wrote:
Marcel Ruff wrote:

I assume you are doing some sort of load balancing for the consuming clients.

That's one of the reasons I'm using it. I'm basing the implementation on the discussion with Joanne on the ConsumableQueuePlugin and administrative get, starting at http://xmlblaster.org/mhonarc-xmlBlaster/msg01833.html, as my requirements are very similar.

The consuming administrative get() queries the sessions callback queue. The callback queue is filled by PtP or subscriptions.

If we assume that only subscriptions are used (no PtP for this session)
you can apply the query filter plugin on the subscription.
The administrative get() will then only get the already filtered
messages from the callback queue.

If you have individual filtering per admin-get() you need
to login and subscribe separately for each filter rule to
have specific callback queues (each login session has its own callback queue).

My current plan is to have a specific oid that all the responses from a request/response pair are published to, regardless of source. Each client that initiates a request/response will subscribe to that oid with a filter based on the correlation id and when it receives the response it will unsubscribe (i.e. a one shot subscription). No clients will subscribe without a filter, so each client should only receive the relevant response without the overhead of creating a queue for every request/response pair (esp. since I'm using persistent messages).

Does that sound like a reasonable approach or will the overhead of a subscribe/unsubscribe for every request/response be too high?

You could subscribe for exactly one responseTopic for each client, for example:

 oid='response_client:joe'  (subscription from client joe)

 oid='response_client:jack' (subscription from client jack)


and the resonses are published to this topic.

Another, probably easier way is that the receiver sends a PtP message back the the sender, as done in

  see: pq.addDestination(new Destination(updateQos.getSender()));