Hi Bruno, I think guaranteed delivery is what TCP was designed for and HTTP/1.1 reuses the TCP socket. You do not need to write something to a TCP socket to see if it is writeable, the socket throws an exception if it closes or becomes unwriteable. You will "know if a client disconnected" in real-time.
On the other hand transactionality over HTTP is really an application concern and very easy to solve. Cheers, /marc On Thu, 14 Aug 2008, Bruno Harbulot wrote: > Hi Marc, > > I think what Kevin meant (and was more along my interpretation of the original > question) is that you can know that a socket has been closed before attempting > to write to it, but you cannot know that it's going to be open for writing > until you actually write to it. As Jerome pointed out, guaranteed delivery is > a more subtle problem that has to be handled differently. > > Best wishes, > > Bruno. > > > Marc Larue wrote: > > Hi Paul, > > > > Rupy has this functionallity built in: http://rupy.googlecode.com > > > > You get a Service.session(Session, DISCONNECT) event when all of the TCP > > connections for a session have been forcibly closed. > > > > Unfortunately this doesen't work if you are behind an apache proxy, since it > > caches and reuses TCP connections. > > > > Cheers, > > > > /marc > > > > On Wed, 13 Aug 2008, Kevin Conaway wrote: > > > > > I don't think its possible to check on the state of a Socket without > > > actually writing to it. > > > > > > Why do you need to know if a client is still active? Perhaps you could > > > restructure your problem in a different manner? > > > > > > On Wed, Aug 13, 2008 at 3:30 PM, Jerome Louvel > > > <[EMAIL PROTECTED]>wrote: > > > > > > > Paul, > > > > > > > > Beside intercepting JDK log messages, looking for those IO exceptions, > > > > there > > > > is indeed currently no way to intercept those errors and act on them. > > > > That's > > > > why I suggested a RFE. > > > > > > > > As a more general thought, you will never be 100% sure that a client got > > > > your response and successfully processed it unless the client confirms > > > > it > > > > to > > > > you via a separate request. For example a client crash could occur right > > > > after he read your response... > > > > > > > > But if we can give you more control at Restlet API level, I think this > > > > is > > > > valuable. > > > > > > > > Best regards, > > > > Jerome Louvel > >
