[Spread-users] Problem with Java client

[Ryan Caudy]

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.

Cheers,
Ryan

On 8/17/05, Theo Schlossnagle <jesus at omniti.com> wrote:
> Ryan Caudy wrote:
> 
> >It sounds to me like there's some sort of buffering going on in the
> >Java client at the socket level.
> >
> >If I had to guess, I would say that this is because the Spread Java
> >API isn't using TCP_NODELAY.  The C API is, and hence wouldn't be
> >subject to the same problem, assuming that my hypothesis is correct.
> >
> >Attached to this message is a patch to SpreadConnection.java
> >(generated against the latest CSV version) which should set this
> >socket option.
> >
> >Please let me know if this helps.
> >
> >
> TCP_NODELAY effect how the socket reacts when you send data on it.  Not
> how it reacts when you close it.
> 
> Look at setsockopt(.... SO_LINGER).  and in C make sure you shutdown()
> the socket before you call close. (read the shutdown man page).
> 
> If you just call close() on a socket, you can certainly loose data
> you've written to it that has yet to be transmitted.
> 
> http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#setSoLinger(boolean,%20int)
> 
> Best regards,
> 
> Theo
>