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

[xmlblaster] minor socket ping/refreshSession method inconsistency?


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.


Balázs Póka