From dev-return-80966-apmail-tomcat-dev-archive=tomcat.apache.org@tomcat.apache.org Thu May 10 11:43:52 2007 Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 44784 invoked from network); 10 May 2007 11:43:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 May 2007 11:43:50 -0000 Received: (qmail 11703 invoked by uid 500); 10 May 2007 11:43:51 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 11654 invoked by uid 500); 10 May 2007 11:43:51 -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 11642 invoked by uid 99); 10 May 2007 11:43:51 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 May 2007 04:43:51 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [72.22.94.67] (HELO virtual.halosg.com) (72.22.94.67) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 May 2007 04:43:44 -0700 Received: (qmail 16236 invoked from network); 10 May 2007 06:41:18 -0500 Received: from unknown (HELO ?192.168.2.3?) (195.216.52.112) by halosg.com with SMTP; 10 May 2007 06:41:18 -0500 Message-ID: <4643053A.6030800@hanik.com> Date: Thu, 10 May 2007 13:42:50 +0200 From: Filip Hanik - Dev Lists User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) 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> <46420823.1000704@apache.org> <4642217B.60705@hanik.com> <46423D5E.8040504@apache.org> <4642EDAA.1080002@hanik.com> In-Reply-To: <4642EDAA.1080002@hanik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org ok, changes are in, there is one inconsistency, currently READ is a main type, while WRITE is a subtype of NOTIFY thoughts on consolidate these? ie NOTIFY/READ or make WRITE a main type by no means is this set in stone, and as we go along and discover problems or semantics issues, we can make any adjustments that are needed. Filip Filip Hanik - Dev Lists wrote: > Remy Maucherat wrote: >> Filip Hanik - Dev Lists wrote: >>> 1. CometEvent.notify is a servlet calling container method,not a >>> callback from the container >> >> The servlet calls the "notify" method, right ? >> >>> 2. Introduce a new EventType -> NOTIFY >>> 3. Keep the sub event type -> WRITE_COMPLETE, instead of having to >>> busy poll CometEvent.canWrite() >> >> I'd like to know where this "busy poll" for CometEvent.canWrite() >> comes from ;) That flag would be used like available is, such as: > we're thinking along the same lines. > I was more thinking > if ( event.isWriteable() ) { > os.write(data); > } else { > event.register(WRITE); > } > > so instead of WRITE_COMPLETE event, your idea of letting the servlet > know when it can receive more data NOTIFY/WRITE, is essentially the > same message. > so I'm happy to do it this way. > "while" or "if" depends on the app of course. > > The "busy poll" thoughts came up because I thought you were against > any event notification. >> >> while (event.canWrite()) { { >> os.write(randomData); >> } >> _notify(WRITE); >> >> I am not ok to have to wait for an event following each write, since >> it has a huge cost (the canWrite flag is there to be able to do it >> only when it is needed). > agreed. >> >>> 4. Introduce CometEvent.setBlocking(true|false) >>> 5. CometEvent.notify(NOW) to spawn an instant thread, for example, >>> changing blocking -> non blocking and the other way around should be >>> done on a Tomcat worker thread, too many race condition can occur >>> from doing it async with a background thread. Also useful for >>> blocking writes when that is desired >> >> Changing blocking mode in the middle is a bit extreme, I think. > it is. For rev 1, lets only allow it during the "BEGIN" event, and > throw an exception if it is done anytime outside of that. >> >>> and third scenario, useful when you want to end the request, but >>> don't want to wait for an IO event or a timeout.(event.close() -> >>> event.notify(NOW) or the other way around) >>> EventType-> NOTIFY SubEventType->NOW >> >> "notify" is not possible as a method name, any ideas ? I am ok with >> using the proposed notify subtypes. > I suggest these methods > > event.configure - instead of setBlocking - as I'd like to set a flag > to not register with poller as well, so we can use int options > event.register - instead of notify > event.isWriteable - instead of canWrite > > >> >> Overall, I would be happier to not be doing non blocking IO. There >> will be a lot of ifs in the code, and it will be pretty complex to test. > welcome to my world :) NIO implementing non blocking for a blocking API. > > I'll have the API changes in in another 2 hours > > Filip > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org > For additional commands, e-mail: dev-help@tomcat.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org