Re: [xmlblaster] Callback queues

[Marcel Ruff <mr at marcelruff.info>]

Jason Martin wrote:
> I've been trying to get perl Callbacks to work correctly, and I
> finally got it up and running. One question I had was if the
> following construct was possible:
>
> 1. Callback server on port X, subscribed to several XPATH and
> exact topics.
> 2. Callback server dies for three days.
> 3. Callback server comes back up on port X+Y
>
> Is there any way to tell xmlBlaster to send all pending messages
> for the subscriptions in step 1 to the new callback server
> (assuming it was configured properly for that length of
> durability)? My reading of the manual leads me to believe that
> there is no way to 'switch over' to a new callback server.
Hi,

try this:

1. Start server in a console

  java -jar lib/xmlBlaster.jar

2. Start a publisher in another

  java javaclients.HelloWorldPublish -numPublish 100

3. Start a failsafe subscriber in another console

  java javaclients.HelloWorldSubscribe -session.name joe/1 -dispatch/callback/retries -1 
-dispatch/callback/delay 2000 -dispatch/callback/pingInterval 2000 -protocol XMLRPC 
-dispatch/callback/plugin/xmlrpc/port 9011


Hit enter until the subscriber has subscribed and hit a
few enters in the publisher console to publish some messages;
they should arrive at the subscriber.

Now kill the subscriber (with Ctrl-C) and publish some
more messages, they are queued.

Restart the subscriber with the same or another callback port (say 8012)
and it will receive all missing messages.

> I'm also curious why xmlBlaster continues to ping a callback
> server after it has killed the login session that created the
> subscriptions for it.  I killed /restarted the callback server
> and am still getting PING's but no messages relating to the
> subscriptions.

This is strange, can you provide some code to reproduce it?

> On a side note, there are a few issues with the example XMLRPC
> perl callback servers:
>
> The self-contained callback server scripts invoke the
> subscription before they create the listening daemon, so
> xmlBlaster gets a connection refused if it happens to respond
> quickly. Unfortunately Frontier::Daemon does not fork so there'd
> have to be some added complexity to get it into one script. 
>
> That same script doesn't set "ReuseAddr => 1" in the invocation
> of the daemon, so if the user ctrl-C's the script and attempts
> to restart it it will fail silently. Testing the return code of
> the daemon invocation gives a "Address already in use" error,
> which has to do with outstanding TIME_WAIT connections. 

Perl contributions are welcome!

> Finally, the link on 
> http://www.xmlblaster.org/xmlBlaster/doc/requirements/requirement.html
> to
> http://www.xmlblaster.org/xmlBlaster/doc/requirements/msgDistributor.plugin.consumableQueue.html
> is broken.

We will fix this.

regards

Marcel
> Thanks,
> -Jason Martin


--
http://www.xmlBlaster.org