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 > > -- > > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > > > > -----Message d'origine----- > > De : Paul J. Lucas [mailto:[EMAIL PROTECTED] > > Envoye : mercredi 13 aout 2008 20:57 > > A : [email protected] > > Objet : Re: Knowing if a client disconnected? > > > > On Aug 13, 2008, at 10:26 AM, Jerome Louvel wrote: > > > > > The closest you'll find in the Restlet API is the > > > org.restlet.service.ConnectorService class that has two callback > > > methods: > > > - beforeSend(Representation entity) > > > - afterSend(Representation entity) > > > > > > Maybe we could introduce a new call-back method "onSendError(...)" > > > that > > > would inform you about the failed response and the reason for failure. > > > > So you're saying there's no way to know *now* with the API as it > > currently is? It would be nice to know *now*. > > > > - Paul > > > > >
