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" <ma...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
