Re: [xmlblaster] dynamically changing a persistent subscription

[Michele Laghi <laghi at swissinfo.org>]

Hi Joanne,

Joanne wrote:
> I have written a client that creates an exact subscription using the Sql92 client property filter. I've also turned off the async dispatcher for this specific session by setting ?dispatcherActive=false. This session & subscription was also setup as persistent with a failsafe callback queue. I have two questions related to my implementation:
>
> 1. By disabling this session's async dispatching, I only intend to process messages for this client (joe/1) using synchronous admin gets from another client (say, john/1). Before publishing any messages, I ensure that the callback queue for joe/1 exists. If not, I launch a thread that logs in as joe/1 and creates an exact subscription based on a Sql92 filter. Since I ensure that session joe/1 never unsubscribes or explicitly disconnects, I never really have to log in as joe/1 again unless I intend to create/modify/delete its existing subscriptions. Remember, my get client (john/1) is doing all the message processing for joe/1's callback queue using admin gets. But if I want to modify joe/1's subcription or add a new one, I find that I would have to log in as joe/1 again and do unsubscribe, subscribe, etc. to get my changes done. But I'm running into a problem when I do this, because on calling connect() as joe/1 the second time, async updates are automatically triggered (li
k!
>  e it turned on the dispatcher for this session automatically) for any messages still remaining in its callback queue. If I initially set the dispatherActive property for this session to false, how can I ensure it remains disabled even if I reconnect using the same session name?
Yes, I am well aware of the problem. We need to implement a ConnectQos 
flag of the kind "callbackInitiallyDisabled='true'". The same problem 
exists if the server crashes and the client is still logged in with a 
persistent subscription.

I am kind of busy right so I don't want to promise you anything when it 
will be implemented. If you don't have the time to wait you could invoke

I_XmlBlasterAccess.leaveServer(null);

on your client/joe/1 session.
This has the effect of shutting down its callback server (on the server 
side the callback dispatcher would be active but no messages would be 
sent since the client would be unavailable).


> 2. If I wanted to change an existing subscription (i.e. change the Sql92 filter clauses), do I have to unsubscribe to the first one I created then recreate a new one? Or is there a way to modify a subscription on the fly?
As far as I know there in no way of changing the subscription on the fly 
(Marcel correct me if I am wrong).

1) If the amount of combinations is limited you could have one client 
(or one session) per such subscription.

2) Another alternative would be to have a less restrective filter, get 
all messages and filter them on the client side

3) Write an own mime plugin based on the existing one (it's pretty 
easy). The plugin could be a native client. Your client joe/1 could then 
send to this plugin a PtP message which tells him how to change the 
filtering criteria on the fly.

Hope that helped you
Michele

--
Michele Laghi
mailto:laghi at swissinfo.org
tel. +46 8 7492952 / mob. +46 70 4103964
http://eclettic.tripod.com
http://www.xmlBlaster.org