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 <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: [xmlblaster] Adminstrative get and filtering >Reply-To: [EMAIL PROTECTED] > > >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
