tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niki Dokovski <nick...@gmail.com>
Subject Re: 8.0.x / 7.0.x progress
Date Sat, 05 Oct 2013 05:46:51 GMT
On Sat, Oct 5, 2013 at 2:18 AM, Konstantin Preißer <kpreisser@apache.org>wrote:

> Hi Mark,
>
> > -----Original Message-----
> > From: Mark Thomas [mailto:markt@apache.org]
> > Sent: Friday, October 4, 2013 11:58 PM
> > To: Tomcat Developers List
> > Subject: Re: 8.0.x / 7.0.x progress
> >
> > On 04/10/2013 22:49, Konstantin Preißer wrote:
> > > Hi Mark,
> > >
> > > while I was developing and experimenting with a WebSocket application
> > (that I think could be added to Tomcat 8's WebSocket examples), I think I
> > found some more possible issues with the Websocket handling. One of
> > these can be seen with the Snake example.
> > >
> > >
> > > A) For NIO and APR connector:
> > > It seems that when a client establishes a Websocket connection and then
> > stops to read data from it (but doesn't close the connection, so that
> writing
> > data to the underlying TCP connection will be blocked), and then after
> some
> > time continues to read data from the Websocket connection, then Tomcat
> > seems not to be able to read data from that client any more (and doesn't
> > notice when the connection has been closed), but it can still read from
> it.
> >
> > I think you have written read when you meant write somewhere in the
> > previous sentence.
>
> Sorry, yes. I'll try again:
>
> It seems that when a client establishes a Websocket connection and then
> stops to read data from it (but doesn't close the connection, so that at
> Tomcat's side writing data to the underlying TCP connection will be
> blocked), and then after some time the client continues to read data from
> the Websocket connection, then Tomcat seems not to be able to read data
> from that client any more (and doesn't notice when the connection has been
> closed), but it can still write data to the client.
>
>
> > > To reproduce:
> > > 1) Start Tomcat (current trunk) on Windows 64-bit with Java7 64-bit and
> > either NIO or APR connector.
> > > 2) Open two instances of Firefox (that may or may not be on the same
> > machine) and open the snake example. On both instances, press up or down
> > key so that both snakes begin moving.
> > > 3) Suspend one of the two Firefox processes (say Firefox B). This can
> be
> > done with "Process Explorer" [1] tool by right-clicking on the
> firefox.exe
> > entry and select "Suspend". You can see that Firefox B does not respond
> any
> > more, but on Firefox A the snakes continue to move.
> > > 4) After some time, you can see that on Firefox A the snakes suddenly
> stop
> > moving. This is correct because the current code uses
> RemoteEndpoint.Basic
> > that may block on write() methods.
> > > 5) Now resume Firefox B with Process Explorer. You can see that on both
> > Firefoxes the snakes will continue to move. This means that both
> Firefoxes
> > are able to receive data from the Websocket connection.
> > > 6) When you try to change the direction of the snake in Firefox A,
> > everything works. However on Firefox B, the snake will not change its
> > direction. This means that while Tomcat continues to send data to this
> > Websocket connection, it cannot receive from it any more.
> > > 7) If you close Firefox B, then the corresponding snake will not
> disappear
> > (so it seems Tomcat doesn't notice that the connection closed).
> >
> > It would be worth taking a look with something like Wireshark to see if
> > the data is being sent to Tomcat.
>
> I have installed Wireshark now and can confirm that Firefox (after it is
> resumed) still sends data over the TCP connection which Tomcat seems not to
> be able to read.
>

Are there ACKs for the TCP packets?
I'll try to reproduce the case.

>
>
> > > B) For BIO connector:
> > > I noticed that on Tomcat with BIO connector, when using a
> > RemoteEndpoint.Async to asynchronously send data over the WebSocket
> > connection, sendText(String, SendHandler) (or similar methods) will
> block if
> > the Remote endpoint does not read data from the connection, whereas for
> > NIO and APR connector this method will always return immediately.
> > > Is it intended that for the BIO connector those methods are blocking?
> As
> > the javadoc says, "Initiates the asynchronous transmission of a text
> message.
> > This method returns before the message is transmitted.", I would have
> > expected that e.g. another Thread is used to write in blocking mode, so
> that
> > the sendText() method can return immediately.
> >
> > You can't do non-blocking IO with the BIO connector. All communication
> > with BIO is blocking. This is working as designed.
>
> OK, but my understanding was that there is a difference between the terms
> "synchronous/asynchronous" and "blocking/non-blocking" (but maybe the
> meaning differs from programming language to programming language).
>

An excellent and detailed explanation on this topic can be found in  "UNIX
Network Programing"  R. Stevens Vol 1 3td ed. p154-p160


>
> For example, in .Net applications (C#) you can do Stream operations (read,
> write) in a synchronous and asynchronous mode, regardless of whether the
> underlying I/O supports NIO or only BIO. For asynchronous operations, you
> can specify a callback that is called (from another thread) when the
> operation has finished.
>
> When the underlying I/O supports NIO, an async operation will use NIO so
> that an additional thread is not required (only when the operation has
> completed, it will take an additional thread for the callback) .
> However, when the underlying I/O doesn't support NIO, then you can still
> do an asynchronous operation. E.g. if you do an async write(), then this
> seems to be done by using an additional thread (from a thread pool) that
> will use a blocking write(), and after that method returns, it calls your
> callback to inform you that the write operation has completed.
>
> (Of course, this has at least the same costs (Thread usage) as using
> synchronous writes if the I/O does not support NIO, but it will be
> transparent to the application if the underlying I/O uses BIO or NIO.)
>
> This is why I was excepting that RemoteEndpoint.Async#sendText(...)
> returns immediately, regardless of whether BIO or NIO is used.
>
>
> Regards,
> Konstantin Preißer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message