Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A8C1810667 for ; Thu, 4 Jul 2013 15:12:21 +0000 (UTC) Received: (qmail 6884 invoked by uid 500); 4 Jul 2013 15:12:16 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 6635 invoked by uid 500); 4 Jul 2013 15:12:16 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 6317 invoked by uid 99); 4 Jul 2013 15:12:15 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Jul 2013 15:12:15 +0000 Received: from localhost (HELO [192.168.23.9]) (127.0.0.1) (smtp-auth username markt, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Jul 2013 15:12:13 +0000 Message-ID: <51D590C5.9050301@apache.org> Date: Thu, 04 Jul 2013 16:12:05 +0100 From: Mark Thomas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tomcat Users List Subject: Re: websockets questions References: <51D453A9.5030708@ice-sa.com> <51D46638.3090003@ptc.com> <51D53DB4.9080903@ice-sa.com> <51D540BF.7030902@apache.org> <51D58C42.4050403@ice-sa.com> In-Reply-To: <51D58C42.4050403@ice-sa.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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