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
