[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] Callback queues

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.

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
is broken.

We will fix this.



Thanks, -Jason Martin