Hi! I may have found a small problem regarding socket protocol ping invocations. Let's suppose that a client logged in successfully using the socket protocol. Pinging is enabled, ping timeout 60s. Then I pull the network cable (or remove the default route of the client in a similar way). This has the effect that there are no default routes anymore and any new TCP connection attempt is immediately answered by the kernel with a "No route to host" or similar message. Though SocketImpl.read(...) does not return (so no IOException or anything else to signal the event that no packets may reach the destination host), I would expect the PingTimer (thread) to notice this after pingTimeout time elapsed and to cause my connection to go into polling mode. However, nothing happens after that time elapsed.
This is the stack trace of the PingTimer thread at that time: Thread [XmlBlaster.PingTimer] (Suspended) Object.wait(long) line: not available [native method] Latch.attempt(long) line: 79 SocketCallbackImpl(RequestReplyExecutor).requestAndBlockForReply(MsgInfo, boolean, boolean) line: 629 SocketConnection.get(String, String) line: 617 ClientDispatchConnection.get(MsgQueueEntry) line: 368 ClientDispatchConnection.doSend(MsgQueueEntry[]) line: 145 ClientDispatchConnection(DispatchConnection).send(MsgQueueEntry[]) line: 231 ClientDispatchConnectionsHandler(DispatchConnectionsHandler).send(MsgQueueEntry[]) line: 435 DispatchWorker.run(ArrayList) line: 75 DispatchManager.putPre(I_QueueEntry[]) line: 561 DispatchManager.putPre(I_QueueEntry) line: 535 RamQueuePlugin.put(I_QueueEntry, boolean) line: 712 XmlBlasterAccess.queueMessage(MsgQueueEntry) line: 792 XmlBlasterAccess.get(GetKey, GetQos) line: 918 XmlBlasterAccess.refreshSession() line: 444 XmlBlasterAccess$1.timeout(Object) line: 412 Timeout.run() line: 189 SocketCallbackImpl(RequestReplyExecutor).requestAndBlockForReply(MsgInfo, boolean, boolean) line: 629 contains the following: awakened = startSignal.latch.attempt(getResponseTimeout( msgInfo.getMethodName())); // block max. milliseconds So I'd expect it to time out after 60s (which is my ping timeout). It did not; instead it turned out that msgInfo.getMethodName() is not a PING, but a GET invocation, so getResponseTimeout returns the wrong timeout. My question is whether this msgInfo should contain a PING MethodName instead of GET. I realize that in XmlBlasterAccess.refreshSession() line: 444, you call get(GetKey, GetQos), but maybe there should be a separate method for pings, or an additional parameter. As a temporary workaround, I'm setting responseTimeout to 60sec, too. regards, Balázs Póka
