[Spread-users] Problem with Java client

[Ryan Caudy]

I would investigate using both TCP_NODELAY *and* SO_LINGER in connect.

TCP_NODELAY is set in connect by the C API.  Although there is a
potential performance penalty if you're using small messages, the
expected scenario is that network traffic between a client and its
connected daemon is the cheapest communication in the entire system. 
Considering that a lot of Spread client applications depend on timely
delivery of small messages, this setting is often very appropriate. 
Although this option won't have any affect on the correctness of the
causal ordering provided by the daemons, leaving it off will
potentially increase the likeliness that messages sent at observably
different times are received out of order.

My understanding of SO_LINGER is that it possibly prevents a bit of
data loss at the end of your connection's life cycle.  I don't think
that it additionally flushes the outgoing buffer, however.

For these reasons, I would encourage you to set TCP_NODELAY to true
and SO_LINGER to some reasonable timeout in the connect method.

Cheers,
Ryan

On 8/22/05, Jarosław Nozderko <jaroslaw.nozderko at polkomtel.com.pl> wrote:
> Hi Ryan,
> 
> > My reason for considering TCP_NODELAY is to avoid holding
> > onto data longer than necessary, hopefully leaving the buffer
> > empty when the socket is closed.  Regardless, I think it's an
> > appropriate setting for the Java API to use, the same as the C API.
> >
> > From the description of SO_LINGER read after reading Theo's
> > response, we should be using it in both the Java and C APIs.
> > It seems like a more correct way to solve Jaroslaw's problem,
> > as well as a generally good thing to use regardless,
> > considering the kind of guarantees we're trying to preserve.
> 
> Definitely. However, using setSoLinger() in connect() and/or
> calling shutdownInput() and shutdownOutput() on the socket
> (which presumably call shutdown() with SHUT_RD and SHUT_WR,
> respectively) before socket.close() in disconnect() didn't solve
> the problem. Since it's probably not a good idea to
> hardcode enabling TCP_NODELAY in connect(), I put it
> in disconnect() as a workaround, just before sending final
> KILL_MESS (together with your listener.join() in
> stopListener()) - everything seems to work correctly
> now (HP-UX, Linux, WinXP).
> 
> 
> Regards,
> Jarek
>