tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Goupil <goupilpie...@gmail.com>
Subject Re: websockets questions
Date Thu, 04 Jul 2013 17:43:34 GMT
Regarding browser support, a framework like Atmosphere handles pretty well
having WebSockets when they are available and falling-back to another Comet
implementation (such as long-polling or http-streaming) when they are not.
Le 4 juil. 2013 17:12, "Mark Thomas" <markt@apache.org> a écrit :

> On 04/07/2013 15:52, André Warnier wrote:
> > Mark Thomas wrote:
> >> On 04/07/2013 10:17, André Warnier wrote:
> >>> To me that means that at some point, there must be on the server side a
> >>> process or thread which is dedicated to this websocket client for as
> >>> long as it takes, and this process/thread in the meantime is no longer
> >>> available to process other HTTP requests.
> >>> (That's because the basic idea is that the "websocket application" on
> >>> the server side can keep sending messages asynchronously to the client
> -
> >>> and vice-versa - so I don't see how this can work with different
> >>> threads/processes on the server; but I'm not that smart, so it may be
> >>> that the implementation is smarter).
> >>> For that same reason, it would seem that the very concept of
> >>> "load-balancing" must be suspended once the websocket connection is
> >>> established.
> >>
> >> The connection has to be kept open but you can use non-blocking IO to
> >> only allocate a thread to process data when there is data to process.
> >>
> >> The exact behaviour varies between Tomcat 7 and Tomcat 8.
> >>
> >> BIO 7 & 8 - 1 thread per connections, blocking IO, doesn't scale
> >>
> >> NIO / APR 7 - 1 thread per currently processed frame, non-blocking
> >> between frames, scales better
> >>
> >> NIO / APR 8 - threads only allocated where there is data to process,
> >> scales best
> >
> > "data to process" meaning an entire websocket "message" I suppose ?
>
> No. Data means bytes on the wire. It doesn't matter if those bytes are
> an entire message (multiple frames), a single frame, part of a frame of
> even the last few bytes of one frame and the first few bytes of the
> next. Tomcat will read what is available, process it as far as possible
> given that data it has to hand (for example if the application indicates
> it will except it, partial data can be passed to the application if it
> is available) and then release the thread and wait for the next set of
> bytes to turn up.
>
> > Another question while we're at it :
> > As I understand from the specs/docs, there are 2 kinds of messages :
> > text or "blob".
> > And I found that there are 2 ways of reading that data, corresponding to
> > these 2 types of messages.
> > However, I do not find anywhere a function or method or call which would
> > allow for example the server-side application to find out in advance if
> > the data currently available for reading is one or the other type.  Did
> > I miss that somewhere, or do I misunderstand the specs/docs ?
>
> Actually, there are three types exposed to applications: Text, Binary,
> Pong.
> The application only finds out what type the message is when the
> container calls the appropriate message handler. Note if an application
> doesn't have a handler for a particular message type then the message is
> ignored.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

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