https://issues.apache.org/bugzilla/show_bug.cgi?id=50184

           Summary: RpcChannel sends the answer without requesting an ACK
           Product: Tomcat 7
           Version: trunk
          Platform: PC
        OS/Version: Solaris
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Cluster
        AssignedTo: dev@tomcat.apache.org
        ReportedBy: arieland...@hotmail.com


Created an attachment (id=26229)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26229)
proposed patch

Hi,

I'm using apache tribes outside of Tomcat.
Although my version is not the latest one, this also applies to trunk.

I have a customer that was using Bio senders (a version before to the
excecutors refactor see bug 50183), and there were experiencing some weird
behavior. (I couldn't reproduce it, but I guess it is related with the platform
since they are using solaris)

My application uses tribes to create an RPC channel. They also had some network
issues.
So, in certain occasions, the application invoked a remote method, the remote
node processed the invocation and send the answer back (but it is not received
in the first node).
So, the timeout occurs and eventually a new RPC invocation occurs. But this
time, the second node realized that there is a socket issue when trying to send
the answer back (it gets a broken pipe exception). Them the connection is
re-established and the message is received without any issues.

My customer is complaining about the timeout that occurred the first time.

To send the message we do the following:
BioSender.pushMessage(.....) {
    ...
    soOut.write(data);
    soOut.flush();
    ...
}
But the flush operation does not warranty that the message was successfully
sent to the network. It just warranty that the information was passed to the
S.O. 
http://download.oracle.com/javase/6/docs/api/java/io/OutputStream.html#flush()

So, in order to avoid this issue I thought that we can modify the RpcChannel to
send the reply message using SEND_OPTIONS_USE_ACK option.
Setting this, the remote node will be able to detect situations like the one I
commented, and recreate the connection.

I'm attaching a patch with my proposal.


Thanks for your time.

Regards,
Ariel

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to