Re: [xmlblaster-devel] Perl XMLRPC callbacks

[Tim Heilig <blaster at heilig.com>]

Once you start the xmlrpc server on the client side, you lose the flow 
of control to Frontier::Daemon, so you have to subscribe before you are 
able to handle callback calls.
This doesn't seem like a problem that would be specifically perl 
related, any xmlrpc (or multiple socket) protocol would seem to have the 
same timing issue.

If you are trying to run in a single thread, like the perl xmlrpc demo, 
the sequence looks like this:

-----> connect
<----  connectReturn

<----- ping (refused)

-----> subscribe
<----  subscribeReturn

< XMLRPC Server starts on client side>

<----- ping
-----> pong


I've seen others put the subscribe in the ping handler, this was also 
viable in 1.0.7, but doesn't appear to work in 1.3

-----> connect
<----  connectReturn

<----- ping (refused)


< XMLRPC Server starts on client side>

<----- ping
-----> subscribe
<----  subscribeReturn
-----> pong


If you wait until after a ping return to do it, things are ok, this 
still works as a single threaded perl client:

-----> connect
<----  connectReturn

<----- ping (refused)


< XMLRPC Server starts on client side>

<----- ping
-----> pong

<----- ping
-----> subscribe
<----  subscribeReturn
-----> pong



I fixed the problem by creating a separate thread for the subscribes, 
basically kicking it off in the ping handler, and having it sleep 
(hopefully) long enough for the ping return, of course if the ping 
return is fouled up, then the subscribe will die.

Multi-threaded timing:
-----> connect
<----  connectReturn

<----- ping (refused)


< XMLRPC Server starts on client side>

<----- ping
  <Kick off subscribe thread>
-----> pong

<some time later>
-----> subscribe
<----  subscribeReturn


Marcel Ruff wrote:
> Hi Tim,
>
> i don't understand the setup/problem.
>
> Is this your scenario?
> Left is client, right is server:
>
> -----> connect
> <----  connectReturn
>
> <----- ping
> -----> pong
>
> -----> subscribe
> <----  subscribeReturn
>
> Which perl modules do you use, can you send
> your demo client to show the problem?
>
> thanks
> Marcel
>
>
>
>
> Tim Heilig wrote:
> > I'm finally attempting to switch up from 1.0.7 to 1.3, every previous 
> > version switch has run into problems, but I'm hopeful this time.  My 
> > biggest issue right now is the single threaded perl callback problem 
> > when you want to subscribe.  The server pings before the subscribe 
> > call returns, so the callback server isn't set up yet.  This is a 
> > problem that's been around as long as I've used blaster, and was no 
> > big deal in 1.0.7, you would get a connection refused, then the 
> > server would reping, connect, and send the messages.
> > In 1.3 the server instead shoots out an error saying that a 
> > subscriber needs a callback server.  The server gets tied up so long 
> > generating those errors, that it eventually drops the client connection.
> > If I subscribe on the first ping, it doesn't work either, I'm 
> > assuming in 1.3 a message won't get routed to a client until a 
> > successful ping has occurred.
> >
> > Subscribing on the second ping seems to work, but I don't want to 
> > wait that long before I can subscribe, nor do I want the ping time to 
> > get shortened just for that one subscribe.
> >
> > I'm going to try and fork off a procces which sleeps long enough for 
> > the connection to be established (hopefully) then sends the 
> > subscribe, but I was curious if anyone had a better method for 
> > dealing with this in v1.3
> >
> > Tim