Re: [xmlblaster] Adminstrative get and filtering

[Marcel Ruff <mr at marcelruff.info>]

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

  xmlBlaster/demo/HelloWorld5.java
  see: pq.addDestination(new Destination(updateQos.getSender()));



> Robert


--
http://www.xmlBlaster.org