[undertow-dev] Handling termination of WebSocket connection

[Vladimir Tsukur]

>
> How long did you wait? the close listener should still be torn down, but
> it may take a while for Undertow to be aware of the underlying network
> failure.


I did not wait long but I guess it was more than a couple of minutes. What
is the anticipated timeout value that are referring to?

AFAIU problem boils down to the need to write to a socket to actually find
out if it s still there or was [abruptly] disconnected. Using ping message
in a ping / pong flow seems to be a solution in this case.


On Tue, Oct 21, 2014 at 11:32 PM, Stuart Douglas <sdouglas at redhat.com>
wrote:

> How long did you wait? the close listener should still be torn down, but
> it may take a while for Undertow to be aware of the underlying network
> failure. If you try and send a ping message intermittently that will force
> the issue, as sending will fail, which will result in the connection being
> town down.
>
> Another option is to set an idle timeout.
>
> Stuart
>
> ----- Original Message -----
> > From: "Vladimir Tsukur" <flushdia at gmail.com>
> > To: "Stuart Douglas" <sdouglas at redhat.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Wednesday, 22 October, 2014 2:07:10 AM
> > Subject: Re: [undertow-dev] Handling termination of WebSocket connection
> >
> > One more observation - in case network connection is completely lost in
> > between client and server, "close" notifiers are not invoked at all
> (tried
> > by shutting down network connection on the client machine keeping browser
> > tab opened). In this case there is no opportunity for a client to send a
> > close frame to the server. Is it a bug then? Using Undertow 1.2.0.Beta1
> >
> > On Tue, Oct 21, 2014 at 4:10 PM, Vladimir Tsukur <flushdia at gmail.com>
> wrote:
> >
> > > Thanks Stuart,
> > >
> > > Did not see this method in 1.0.x since it was added at a later release
> -
> > > tried with latest version and it works well.
> > >
> > > However, I figured out that connection termination works well iif
> receive
> > > setter is set:
> > >
> > >     WebSocketChannel channel = ...;
> > >     channel.getReceiveSetter().set(new AbstractReceiveListener() {});
> > >     channel.addCloseTask(new ChannelListener<WebSocketChannel>() {
> > >         @Override
> > >         public void handleEvent(WebSocketChannel channel) {
> > >             ...
> > >         }
> > >     });
> > >
> > > If receive setter is not set, then close task will not be called. In my
> > > case there was no intent to receive messages from the client and just
> push
> > > them from the server. Receive setter was not set => connection was not
> > > closed.
> > >
> > > It seems obligatory to set receive setter all the time to make the
> thing
> > > work. Is it intended? While it is not a big deal really, I would
> imagine
> > > that Undertow should handle connection termination without explicit
> receive
> > > setter call made by the API client.
> > >
> > >
> > > On Tue, Oct 21, 2014 at 2:08 AM, Stuart Douglas <sdouglas at redhat.com>
> > > wrote:
> > >
> > >> WebsocketChannel.addCloseTask() should do what you are after (this is
> > >> actually provided by the base AbstractFramedChannel class).
> > >>
> > >> Stuart
> > >>
> > >> ----- Original Message -----
> > >> > From: "Vladimir Tsukur" <flushdia at gmail.com>
> > >> > To: undertow-dev at lists.jboss.org
> > >> > Sent: Tuesday, 21 October, 2014 7:20:54 AM
> > >> > Subject: [undertow-dev] Handling termination of WebSocket connection
> > >> >
> > >> > Let's imagine user closed browser tab and thus terminated WebSocket
> > >> > connection. Is there any way to run a callback method on the
> > >> server-side to
> > >> > handle this case?
> > >> >
> > >> > The requirement is to perform necessary cleanup actions when
> connection
> > >> is
> > >> > closed, regardless of the type of disconnect (normal, forced
> > >> termination,
> > >> > etc.).
> > >> >
> > >> > (Ideally using lower level API, and not JSR 356)
> > >> >
> > >> > --
> > >> > Vladimir Tsukur
> > >> > Software Architect, Design Engineer
> > >> >
> > >> > _______________________________________________
> > >> > undertow-dev mailing list
> > >> > undertow-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > >>
> > >
> > >
> > >
> > > --
> > > Vladimir Tsukur
> > > Software Architect, Design Engineer
> > >
> >
> >
> >
> > --
> > Vladimir Tsukur
> > Software Architect, Design Engineer
> >
>



-- 
Vladimir Tsukur
Software Architect, Design Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141022/395206c6/attachment-0001.html