Re: [xmlblaster] Adminstrative get and filtering

[laghi at swissinfo.org]

Hi Robert,

For the responses a better approach would be to send a PtP back to the sender
as done in the xmlBlaster/demo/HelloWorld5.java

look for the line:

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

The oid of the PtP response could always be the same, for example 'response'.
This way you ensure not to create each time a new topic.

Michele




>-- Original Message --
>Date: Mon, 05 Jul 2004 17:12:24 +1000
>From: Robert Leftwich <robert at leftwich.info>
>To: xmlblaster at server.xmlBlaster.org
>Subject: Re: [xmlblaster] Adminstrative get and filtering
>Reply-To: xmlblaster at server.xmlBlaster.org
>
>
>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?
>
>Robert
>
>


_______________________________________________________________________
Dreaming of a Swiss Account? Get it here: http://freemail.swissinfo.org