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

Re: [xmlblaster-devel] Perl XMLRPC callbacks



I used the following qos in 1.4, and it didn't work (same as the behavior in 1.3)

<qos>
<session timeout='364000000' clearSessions='true' reconnectSameClientOnly='false' />
<queue maxEntries='15000' relating='callback'>
<callback retries='2' delay='5000' type='XMLRPC'>
<attribute name='__initialCallbackPing'>false</attribute>
http://127.0.0.1:3130/RPC2</callback>
</queue>
<local>false</local>
</qos>


Tim


Marcel Ruff wrote:
Tim,

i have added in the current xmlBlaster svn an experimental switch to inhibit the initial callback ping
during connect().


Here is how i have tested it from my C client with the SOCKET protocol:

...
"<queue relating='callback' maxEntries='50000' maxEntriesCache='10000'>"
" <callback type='SOCKET' sessionId='%s'>"
" socket://%.120s:%d"
" <attribute name='__initialCallbackPing'>false</attribute>"
" </callback>"
"</queue>"
...


Could you pls try this similar in your Perl client if it addresses your problem?

thanx

Marcel

Tim Heilig wrote:
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