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

[xmlblaster] Re: Can't Get Rid of Timeouts

P. Michael Hutchins wrote:
I'm debugging an app. that uses xmlBlaster (hereinafter, "XB").

I'm stopping execution  at  breakpoints..

..& so was getting ...

well, :

* inexplicable behavior in my app.s (like I know I publishged a msg,
but the subscriber never got it)
* (once I decided to investigate:) WARNs in XB's log - like this:

[Aug 24, 2004 3:03:37 PM WARN RequestBroker-/node/xmlBlaster_140_102_82_36_3412]
Generating dead message 'callback:/node/xmlBlaster_140_102_82_36_3412/client/pmh0232/-2/NORM/1093374157792000003/clientpmh02321093374144198-1093374157730000001'

from publisher=/node/xmlBlaster_140_102_82_36_3412/client/pmh0232/-3
because delivery with queue 'callback:/node/xmlBlaster_140_102_82_36_3412/client/pmh0232/-2'
failed: XmlBlasterException errorCode=[user.update.error] serverSideException=true
message=[SOCKET callback of 1 messages failed : errorCode=resource.exhaust
message=Timeout of 60000 milliseconds occured when waiting on update(pmh0232:2) response.
You can change it with -dispatch/callback/plugin/socket/responseTimeout <millis>]
[See URL http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#user.update.error]

...so I followed the nice handy URL..
..which didn't help - so I tried search, which remains busted - so I did a site search w/ Google..

..and finally found at least some discussion on
-dispatch/callback/plugin/socket/responseTimeout <millis>

(not, unfortunately, info on whether such can be done from w/in an app. -- but...)
(nor what the max. is)


Currently the server needs to be started with this setting,
you can't reconfigure it from client side (only as an administrative
task like using our telnet access which will set it for future client connects).

You could however start two different SOCKET plugins in the server
with different timeouts configured and listening on different ports,
like this a client can choose the SOCKET driver it likes (current xmlBlaster from cvs)
(see SOCKET_UDP example in http://www.xmlblaster.org/xmlBlaster/config/xmlBlasterPlugins.xml.template).

..so I added that to my cmd line
java -Xms10m -Xmx220m org.xmlBlaster.Main -protocol SOCKET -dispatch/callback/plugin/socket/responseTimeout 9999000

When you do a java org.xmlBlaster.Main -help it shows you the correct option, here it is:

java -Xms10m -Xmx220m org.xmlBlaster.Main -plugin/socket/responseTimeout 100000 -trace[socket] true

and see the setting in the trace output.
The documentation is not correct on all places, sorry, but i have fixed this now.

You can play with this setting and force the timeout like this:

  java -Xms10m -Xmx220m org.xmlBlaster.Main -plugin/socket/responseTimeout 100 -trace[socket] true

  java javaclients.HelloWorldSubscribe -protocol SOCKET -updateSleep 0
  (and type enter to subscribe)

  java javaclients.HelloWorldPublish -protocol SOCKET -numPublish 100
  (type enter to publish)

if you now set the subscribers "-updateSleep 200" you will see your error,

i hope this helps,


...then it happened again.
I again went through a painful search process like the one above..
..and found:
-socket.responseTimeout <millis>
..aso I added that to the cmd line:
java -Xms10m -Xmx220m org.xmlBlaster.Main -protocol SOCKET -dispatch/callback/plugin/socket/responseTimeout 9999000 -socket.responseTimeout 9999000

..then it happened again.(!)

Now I'm tired of that:  What do I need to do?

-- M.