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

Re: [xmlblaster] default response timout

Hi Jonathan,

I have just tried this:

java javaclients.HelloWorldPublish -session.name Publisher/1 -numPublish 10000 -dispatch/callback/retries -1 -plugin/socket/responseTimeout 6000

and blocked the xmlBlaster server in the publish call (in my debugger), after 6 seconds i got the
expected timeout:

2007-11-02 00:41:57.134 WARNING 10-main org.xmlBlaster.util.dispatch.DispatchConnection handleTransition: DispatchConnection-connection:client/Publisher/1 Connection transition ALIVE -> POLLING: socket://192.168.1.20:7607 is unaccessible, we poll for it every 5000 msec: errorCode=communication.responseTimeout message=#1.6.1 Timeout of 6000 milliseconds occured when waiting on publish(Publisher:1193960511113000000) response. You can change it with -plugin/socket/responseTimeout <millis>

If the option does not work for your please check on how your plugin configuration is called,
if it is named e.g. "socket_ssl" (in you xmlBlaster.properties on client side) you need to set

 -plugin/socket_ssl/responseTimeout 6000

Details:
http://www.xmlblaster.org/xmlBlaster/doc/requirements/protocol.socket.html#client

regards
Marcel

PS: We had once (2006-12-05) this discussion on the mailing list, how did everything end up last time?:

"
David R Robison wrote:
Should this function be synchronized since it sets and then resets the system properties javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword? Also, should SocketUrl.createServerSocketSSL be synchronized for the same reason? David

Could you please comment out the resetting of the properties
(and also probably add your 'synchronized' suggestion) and
report back if it solves the issue?
"

Jonathan Clark wrote:
Marcel,
Unfortunately, I have not been able to reproduce this in our lab environment. We are getting periodic reports from
the field and the client does block using the max int timeout. What property should I be using to change the timeout
to 1 minute? The one that I'm using below does not affect the timeout value.
Thanks,
Jonathan
Jonathan Clark wrote:

I've tried to set the timeout value for the client side to correct
the problem detailed below, but have not found the correct entry.I
am using
"dispatch/connection/plugin/socket/responseTimeout=60000", but
this does not seem to affect the client side. Any suggestions on
what property I should be setting? Thanks, 

Do you have blocking clients when the server disappears?
If yes, can you reproduce this issue?

Thanks,
Marcel

    David Robison wrote:
    I am not sure why the xmlBlaster does not respond. Here is the
    stack trace when the client gets hung waiting for a response.

    "DomainCheckTimer" prio=6 tid=0x033a29b0 nid=0x182c in
    Object.wait() [0x03ebf000..0x03ebfbec]
    at java.lang.Object.wait(Native Method)
    at EDU.oswego.cs.dl.util.concurrent.Latch.attempt(Latch.java)
    - locked <0x198226e0> (a EDU.oswego.cs.dl.util.concurrent.Latch)
    at
    org.xmlBlaster.util.protocol.RequestReplyExecutor.requestAndBlockForReply(RequestReplyExecutor.java:629)
    at
    org.xmlBlaster.client.protocol.socket.SocketConnection.subscribe(SocketConnection.java:469)
    at
    org.xmlBlaster.client.dispatch.ClientDispatchConnection.subscribe(ClientDispatchConnection.java:282)
    at
    org.xmlBlaster.client.dispatch.ClientDispatchConnection.doSend(ClientDispatchConnection.java:150)
    at
    org.xmlBlaster.util.dispatch.DispatchConnection.send(DispatchConnection.java:231)
    at
    org.xmlBlaster.util.dispatch.DispatchConnectionsHandler.send(DispatchConnectionsHandler.java:435)
    at
    org.xmlBlaster.util.dispatch.DispatchWorker.run(DispatchWorker.java:70)
    at
    org.xmlBlaster.util.dispatch.DispatchManager.putPre(DispatchManager.java:561)
    at
    org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:476)
    at
    org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:456)
    at
    org.xmlBlaster.client.XmlBlasterAccess.queueMessage(XmlBlasterAccess.java:820)
    at
    org.xmlBlaster.client.XmlBlasterAccess.subscribe(XmlBlasterAccess.java:862)
    at
    com.orci.datagateway.ClientKit.DGDomain.subscribe(DGDomain.java:327)
    at
    com.orci.datagateway.ClientKit.DGConnection.addDomain(DGConnection.java:146)
    - locked <0x17feb2c0> (a com.orci.datagateway.ClientKit.DGConnection)
    at com.orci.datagateway.ClientKit.DGDomain.connect(DGDomain.java:195)
    at
    com.orci.datagateway.ClientKit.DGDomain.updateCurrentState(DGDomain.java:264)
    at
    com.orci.datagateway.ClientKit.DGDomain.checkState(DGDomain.java:216)
    at
    com.orci.datagateway.ClientKit.DGDomain$CheckDomainsTask.run(DGDomain.java:404)
    at java.util.TimerThread.mainLoop(Timer.java:512)
    at java.util.TimerThread.run(Timer.java:462)

    The problem seems to occur when using SocketSSL protocol and the
    server dies and comes back up. The client tries to reconnect and
    resubscribe to the blaster. This situation does not happen all the
    time, but only occasionally and unfortunately we have not been
    able to isolate the exact string of events that cause this
    problem. We are hoping that a timeout will fix the problem.
    David
    Jonathan Clark
    Open Roads Consulting, Inc.
    757-546-3401



--
Marcel Ruff
http://www.xmlBlaster.org <http://www.xmlblaster.org/>
Jonathan Clark
Open Roads Consulting, Inc.
757-546-3401


--
Marcel Ruff
http://www.xmlBlaster.org