[undertow-dev] Handling termination of WebSocket connection

Stuart Douglas sdouglas at redhat.com
Tue Oct 21 16:32:30 EDT 2014


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
> 


More information about the undertow-dev mailing list