[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
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.
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
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
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
We will fix this.