[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] default response timout
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
Jonathan Clark
Open Roads Consulting, Inc.
757-546-3401