Re: websockets holding on to threads.

[Mark Thomas]

On 08/04/2013 15:32, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chuck,

On 4/8/13 8:30 AM, Caldarale, Charles R wrote:

From: Anton Piatek1 [mailto:anton.pia...@uk.ibm.com] Subject: Re:
websockets holding on to threads.



My thinking about it being a bug is that to support N clients
with websockets, you need N threads available on tomcat, even
though they are only getting updates every x seconds.


I don't know if this will have any effect, but try using the NIO
 instead of the BIO one.  Set the protocol attribute to
org.apache.coyote.http11.Http11NioProtocol and see what happens.


+1

I think there was a recent discussion about using Websocket under BIO:
basically, you go back to sucking again.


Short version:

BIO = 1 thread per connection (doesn't scale)

NIO/APR = 1 thread per currently processed frame

i.e. NIO/APR allocate a thread to process an incoming frame and that 
thread stays allocated until the frame has been completely read. Putting 
it another way NIO and APR are non-blocking between frames and blocking 
within frames. Writes always block.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: websockets holding on to threads.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chuck,

On 4/8/13 8:30 AM, Caldarale, Charles R wrote:
>> From: Anton Piatek1 [mailto:anton.pia...@uk.ibm.com] Subject: Re:
>> websockets holding on to threads.
> 
>> My thinking about it being a bug is that to support N clients
>> with websockets, you need N threads available on tomcat, even
>> though they are only getting updates every x seconds.
> 
> I don't know if this will have any effect, but try using the NIO 
>  instead of the BIO one.  Set the protocol attribute to 
> org.apache.coyote.http11.Http11NioProtocol and see what happens.

+1

I think there was a recent discussion about using Websocket under BIO:
basically, you go back to sucking again.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRYxtCAAoJEBzwKT+lPKRYktEP/3sZVejpzAngSi+Zjy3Ln8lx
BS00kfRuShtGGN10OVbaGqyFdVQqnxhoENW/6Bjvc4joUsS2pX2ygVKFYqElKaNw
t0leP+m5uEncILJti25o/X11VlxBbFJBkYZtpNvusGrEcQnCR7dODOQT2EYKn9pR
dER7RSgN9TjzQVUL7IBM8pixkSVvsnFGaJ/mGN+gs6W6Tg9PYHoRLjTc2c3JhoSD
B5FITbIufSWo/5P66+wnXmO6i06PuoKmHDOGhghIbo0cynu8ayFbzgY7Dt2GzB6f
1RzxwR9sosgFpC3JLGoN7O8B7qZB1M8ZGL8SLhuvGunKzev6zBZxw6Dpuvtk70LX
6xsl7nOcfgz0n+BqrnIxCzJzXyJUBSz6xfo8HdRGMrYK7BjdIJDyQGgG9kSgOFT2
gDq66v3yimJYkt+iFntKUQah4aItv4KVQJqOXlQa8IS8wqhjHzB9/nbpPGAe9BBn
Aals6RsV5Xoh1rJG9fw/VS2Wvjo+yB8gAxuM/HLrMLPu42c31sEZsimrr9ARxBfM
A+PKbuGwJ+hMN+rEppHDbm/Hd1sRe8Uj/FJkg5WoMEXfz8WkEhts2+BrGLwa1lFK
6CR3UXMHoBhZhWnpqYgYiIMdFNqojeco84vwVbuobN4S2u3R6p1TuhRvCeMHKRm4
MTJDbBSt3v6k7ONTXvwK
=4iXj
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: websockets holding on to threads.

[Anton Piatek1]

"Caldarale, Charles R"  wrote on 08/04/2013 
13:30:00:

> From: "Caldarale, Charles R" 
> > From: Anton Piatek1 [mailto:anton.pia...@uk.ibm.com] 
> > My thinking about it being a bug is that to support N clients with 
> > websockets, you need N threads available on tomcat, even though they 
are 
> > only getting updates every x seconds. 
> 
> I don't know if this will have any effect, but try using the NIO 
>  instead of the BIO one.  Set the protocol attribute to 
> org.apache.coyote.http11.Http11NioProtocol and see what happens.

Thanks, had just noticed that myself. Will give it a try

Anton





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: websockets holding on to threads.

[Howard W. Smith, Jr.]

On Mon, Apr 8, 2013 at 8:30 AM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Anton Piatek1 [mailto:anton.pia...@uk.ibm.com]
> > Subject: Re: websockets holding on to threads.
>
> > My thinking about it being a bug is that to support N clients with
> > websockets, you need N threads available on tomcat, even though they are
> > only getting updates every x seconds.
>
> I don't know if this will have any effect, but try using the NIO
>  instead of the BIO one.  Set the protocol attribute to
> org.apache.coyote.http11.Http11NioProtocol and see what happens.
>
>
Good recommendation, Chuck.

I have been using NIO connector for several months now and websockets have
been working as designed/expected. Also, my websocket implementation was
working-as-designed prior to using NIO connector; I think I was using APR,
as my tomcat install-or-configuration seemed to default to APR.

Re: websockets holding on to threads.

[Howard W. Smith, Jr.]

On Mon, Apr 8, 2013 at 4:05 AM, Anton Piatek1 wrote:

> >
>
Multiple tabs/windows is one thing, but multiple clients are just as big a
> problem.
>

Not a problem or a concern in my web app. Endusers are trained to use the
web app in 'one' browser tab/window 'per device'; every now and then, I can
tell when they have accidentally opened more than one browser tab/window
while using the web app. Still, not a 'big' problem or concern to 'me'.

Hmmm interesting, a thought just came to me on some code I can write/add to
possibly prevent user from opening multiple browser tab/windows per device
(or ip address). Thanks for the motivation. :)


>
> Have you looked at how many tomcat threads you have running and what
> happens to each of them as you open more websockets? What if you open more
> websockets than you have threads...
>

I open one websocket per client (client = user-login-per-device), and the
app pushes messages to the logged-in users. Currently, my web app is used
by a small number of users on the different devices that they use/own, and
I have no need to limit the # of threads to the # of potential users;
accepting the default # of threads has allowed my web app to work well on
Windows Server 2003 32bit server (initial/previous production server), and
now, on windows 2008 64bit server (current production server).

I understand that you want to test/prepare for worst-case-scenario.

RE: websockets holding on to threads.

[Caldarale, Charles R]

> From: Anton Piatek1 [mailto:anton.pia...@uk.ibm.com] 
> Subject: Re: websockets holding on to threads.

> My thinking about it being a bug is that to support N clients with 
> websockets, you need N threads available on tomcat, even though they are 
> only getting updates every x seconds. 

I don't know if this will have any effect, but try using the NIO  
instead of the BIO one.  Set the protocol attribute to 
org.apache.coyote.http11.Http11NioProtocol and see what happens.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: websockets holding on to threads.

[Anton Piatek1]

"Howard W. Smith, Jr."  wrote on 05/04/2013 
21:22:33:
> On Fri, Apr 5, 2013 at 9:07 AM, Anton Piatek1 
wrote:
> 
> > I am seeing what at first appears to be a bug, but given the lack of 
other
> > reports I can't believe I am the only person seeing this, so maybe it 
is
> > user-error.
> >
> > I have tomcat (was 7.0.30, but I just tried with 7.0.39) running a 
website
> > which uses websockets. The websockets code in tomcat isn't that
> > complicated - My servlet returns a new subclass of StreamInbound which 
has
> > overridden the onTextData() and onBinaryData() methods. This seems to
> > generally work fine, and I can send and receive data happily.
> >
> > However when I load up several browser windows I find that tomcat 
hangs. I
> > used jconsole to check the tomcat threads and found that as I open 
each
> > new websocket, the tomcat worker threads go from idle threads waiting 
for
> > work to the following busy, blocking threads waiting for websocket 
data.
> >
> >
> I have not written low-level websocket code as you are doing, but I 
think I
> have seen this behavior even in/with my app, and others have reported 
and
> discussed this issue in more ways than one.
> 
> I am using Atmosphere Framework via PrimeFaces Push to implement 
websockets
> in my app, and it does work well with one browser tab/window, but it is
> commonly reported that websockets do not work when one client (machine) 
has
> multiple simultaneous websocket connections to the server.
> 
> Since I use Atmosphere Framework, I searched their google groups for the
> following:
> 
> browser windows
> 
> and found the following (URL and quote from page at URL below):
> 
> https://github.com/Atmosphere/atmosphere/issues/493
> 
> According to HTTP RFC<
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html>
> :
> 
> Clients that use persistent connections SHOULD limit the number of
> simultaneous connections that they maintain to a given server. A
> single-user client SHOULD NOT maintain more than 2 connections with any
> server or proxy.
> 
> This can cause problems if you have multiple tabs/window open, which all
> maintain a persistent connection. It would be great if persistent
> connections should be shared (as GWT or Bayeux
> Protocol does
> it).

Multiple tabs/windows is one thing, but multiple clients are just as big a 
problem.

Have you looked at how many tomcat threads you have running and what 
happens to each of them as you open more websockets? What if you open more 
websockets than you have threads... 

> > Name: http-bio-4415-exec-5
> > State: RUNNABLE
> > Total blocked: 50  Total waited: 112
> >
> > Stack trace:
> > java.net.SocketInputStream.socketRead0(Native Method)
> > java.net.SocketInputStream.read(SocketInputStream.java:161)
> > java.net.SocketInputStream.read(SocketInputStream.java:132)
> >
> > org.apache.coyote.http11.upgrade.UpgradeBioProcessor.read
> (UpgradeBioProcessor.java:81)
> > org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:214)
> >
> > 
org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java:68)
> > 
org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:149)
> >
> > org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch
> (UpgradeProcessor.java:83)
> >
> > org.apache.coyote.AbstractProtocol
> $AbstractConnectionHandler.process(AbstractProtocol.java:587)
> >
> > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run
> (JIoEndpoint.java:310)
> >- locked org.apache.tomcat.util.net.SocketWrapper@ddb0d168
> >
> > java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1156)
> >
> > java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:626)
> > java.lang.Thread.run(Thread.java:780)
> >
> > I am trying to figure out what I am missing. I didn't think I needed 
to
> > override StreamInbound.onData() in my class, but as that seems to be 
what
> > is keeping the thread busy, presumably waiting for data looking at 
that
> > stack.
> >
> > Am I misunderstanding something, or is this possibly a tomcat bug?
> >
> 
> I don't think this is a tomcat bug, but I could be mistaking.

My thinking about it being a bug is that to support N clients with 
websockets, you need N threads available on tomcat, even though they are 
only getting updates every x seconds. 

It becomes trivial to denial-of-service a tomcat running websockets with 
this sort of behaviour, as all you have to do is open 10 websockets which 
lock up all 10 tomcat worker threads. Now nobody can connect to tomcat.
Sure, I can increase the number of tomcat threads, but if I want to 
support 1000 concurrent users, I need well over 1000 tomcat threads to 
achieve this!

Anton





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: websockets holding on to threads.

[Howard W. Smith, Jr.]

On Fri, Apr 5, 2013 at 9:07 AM, Anton Piatek1 wrote:

> I am seeing what at first appears to be a bug, but given the lack of other
> reports I can't believe I am the only person seeing this, so maybe it is
> user-error.
>
> I have tomcat (was 7.0.30, but I just tried with 7.0.39) running a website
> which uses websockets. The websockets code in tomcat isn't that
> complicated - My servlet returns a new subclass of StreamInbound which has
> overridden the onTextData() and onBinaryData() methods. This seems to
> generally work fine, and I can send and receive data happily.
>
> However when I load up several browser windows I find that tomcat hangs. I
> used jconsole to check the tomcat threads and found that as I open each
> new websocket, the tomcat worker threads go from idle threads waiting for
> work to the following busy, blocking threads waiting for websocket data.
>
>
I have not written low-level websocket code as you are doing, but I think I
have seen this behavior even in/with my app, and others have reported and
discussed this issue in more ways than one.

I am using Atmosphere Framework via PrimeFaces Push to implement websockets
in my app, and it does work well with one browser tab/window, but it is
commonly reported that websockets do not work when one client (machine) has
multiple simultaneous websocket connections to the server.

Since I use Atmosphere Framework, I searched their google groups for the
following:

browser windows

and found the following (URL and quote from page at URL below):

https://github.com/Atmosphere/atmosphere/issues/493

According to HTTP RFC
:

Clients that use persistent connections SHOULD limit the number of
simultaneous connections that they maintain to a given server. A
single-user client SHOULD NOT maintain more than 2 connections with any
server or proxy.

This can cause problems if you have multiple tabs/window open, which all
maintain a persistent connection. It would be great if persistent
connections should be shared (as GWT or Bayeux
Protocol does
it).





> Name: http-bio-4415-exec-5
> State: RUNNABLE
> Total blocked: 50  Total waited: 112
>
> Stack trace:
> java.net.SocketInputStream.socketRead0(Native Method)
> java.net.SocketInputStream.read(SocketInputStream.java:161)
> java.net.SocketInputStream.read(SocketInputStream.java:132)
>
> org.apache.coyote.http11.upgrade.UpgradeBioProcessor.read(UpgradeBioProcessor.java:81)
> org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:214)
>
> org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java:68)
> org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:149)
>
> org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch(UpgradeProcessor.java:83)
>
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:587)
>
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
>- locked org.apache.tomcat.util.net.SocketWrapper@ddb0d168
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626)
> java.lang.Thread.run(Thread.java:780)
>
> I am trying to figure out what I am missing. I didn't think I needed to
> override StreamInbound.onData() in my class, but as that seems to be what
> is keeping the thread busy, presumably waiting for data looking at that
> stack.
>
> Am I misunderstanding something, or is this possibly a tomcat bug?
>

I don't think this is a tomcat bug, but I could be mistaking.



> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>