ODP: [Spread-users] Problem with Java client

[Jarosław Nozderko]

[*** Sorry - I accidentally posted unfinished message a moment ago]

Hi Ryan, Theo,

 thanks a lot for your responses.
I can't access CVS through SSH at the moment, so I've added manually
setTcpNoDelay(true) in connect() and listener.join() in 
stopListener() to version from 3.17.3. 
 
It's OK now - message is delivered, and LEAVE is reported.

However, it didn't fix another problem - when I kill Spread 
dameon, User (java test client) is not notified (spuser correctly
exits) and obviously crashes after any further attempt to communicate
(SocketException: Broken pipe).

Then I removed setTcpNoDelay(true) and replaced it with 
setSoLinger(true, x), for several x (1,10,100,1000).
It seems to be unpredictable a bit - it happened once to work 
for x=1000, in general it does not. Seriously, since this is 
timeout in seconds, it shouldn't really matter here (and, 
according to man setsockopt() on HP, value may be ignored).

I will try to reproduce this on Linux using more tools.
 
Regards,
Jarek 

> > Od: Ryan Caudy [mailto:rcaudy at gmail.com] 
> > Wysłano: 18 sierpnia 2005 02:32
> > Do: Theo Schlossnagle
> > DW: Jarosław Nozderko; spread-users at lists.spread.org
> > Temat: Re: [Spread-users] Problem with Java client
> > 
> > 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#setSoLing
> > > er(boolean,%20int)
> > > 
> > > Best regards,
> > > 
> > > Theo
> > >
> > 
>