Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 53142 invoked from network); 9 May 2007 17:43:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 May 2007 17:43:25 -0000 Received: (qmail 82081 invoked by uid 500); 9 May 2007 17:43:28 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 81808 invoked by uid 500); 9 May 2007 17:43:27 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 81797 invoked by uid 99); 9 May 2007 17:43:27 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 May 2007 10:43:27 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [212.27.42.36] (HELO smtp6-g19.free.fr) (212.27.42.36) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 May 2007 10:43:19 -0700 Received: from [192.168.0.1] (gou06-1-82-224-99-120.fbx.proxad.net [82.224.99.120]) by smtp6-g19.free.fr (Postfix) with ESMTP id 2D6578EE4E for ; Wed, 9 May 2007 19:42:58 +0200 (CEST) Message-ID: <46420823.1000704@apache.org> Date: Wed, 09 May 2007 19:42:59 +0200 From: Remy Maucherat User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Tomcat Developers List Subject: Re: Comet changes References: <463E04B3.8060903@apache.org> <463F3563.6030909@hanik.com> <463F4199.6030706@apache.org> <463F4871.8030601@hanik.com> <463F4ACC.5040402@apache.org> <464038D2.5080609@hanik.com> <46404F00.8080900@apache.org> <4640566F.9080808@hanik.com> <46408633.4010909@apache.org> <4640D06D.3070404@hanik.com> <4640FBE2.9050204@apache.org> <464124E0.50205@hanik.com> <4641AB1D.3030001@apache.org> <4641CE66.4080400@hanik.com> <4641D3FE.4010205@apache.org> <4641DBD4.7030301@hanik.com> <4641F55A.9090201@apache.org> <4642013C.3040802@hanik.com> In-Reply-To: <4642013C.3040802@hanik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Filip Hanik - Dev Lists wrote: > oh crap, we are thinking way different :), I was thinking the other way > around > > Here is one event chain > 1. CometProcessor.event(CometEvent.BEGIN/null) > 2. Servlet calls CometEvent.setBlocking(false); > 3. Servlet calls CometEvent.notify(READ) - the servlet wants to be > notified when data is available > 4. Data arrives on the socket > 5. CometProcessor.event(CometEvent.NOTIFY/READ) > 6. Servlet calls a CometEvent.getHttpServletRequest().read() > 7. Servlet calls CometEvent.notify(READ|WRITE); - this servlet wants to > be notified when it can write or read data > 8. CometProcessor.event(CometEvent.NOTIFY/WRITE); > 9. Servlet calls a CometEvent.getHttpServletResponse().write(bbuf) > 10. Under the hood, write is being done when it can write until the > buffer is empty > 11. CometProcessor.event(CometEvent.NOTIFY/WRITE_COMPLETE) > 12. Servlet calls CometEvent.notify(WRITE); - notify me when I can write > again > 13. Data arrives on the socket again > 14. CometProcessor.event(CometEvent.NOTIFY/READ); > > so this whole time I thought the notify() method is a call from the > servlet to the container. > The Comet servlet "register" actions it wants to be notified of. > And basically, this way, we disallow any writes or reads from a "user" > thread when the Poller is in use. Ok, I am running away screaming in horror (and begging for mercy). It's not acceptable to generate one event, along with plenty of API interactions, for every write operation. The benefit I wanted to provide is easy asynchronous writes. For example, let's say you want to send something on all your connections (which is IMO quite common), and let's say you have 10000. Having to generate 10000 events and process each of them using one thread is extremely bad. To summarize, I don't want to hear about sending write events until one write is incomplete, and async writes should be allowed. At this point, I think I will veto any change beyond tweaks to my earlier proposal (which did not do non blocking IO). It would avoid a lot of complexity, at least. > Is this too convuluted? > do you feel like we are spinning circles, starting over or simply making > it too complex? Yes, I think it got a little bit out of hand, thanks for noticing it ;) R�my --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org