Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 49620 invoked from network); 21 Jan 2008 04:16:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Jan 2008 04:16:20 -0000 Received: (qmail 71162 invoked by uid 500); 21 Jan 2008 04:15:56 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 71137 invoked by uid 500); 21 Jan 2008 04:15:56 -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 71126 invoked by uid 99); 21 Jan 2008 04:15:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 Jan 2008 20:15:56 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.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; Mon, 21 Jan 2008 04:15:42 +0000 Received: (qmail 18194 invoked from network); 20 Jan 2008 22:07:53 -0600 Received: from 72-19-171-38.static.mesanetworks.net (HELO ?192.168.1.4?) (72.19.171.38) by halosg.com with SMTP; 20 Jan 2008 22:07:53 -0600 Message-ID: <47941C6D.4050809@hanik.com> Date: Sun, 20 Jan 2008 21:15:41 -0700 From: Filip Hanik - Dev Lists User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Tomcat Users List Subject: Re: comet end event References: <176a7eb80801181340v43ae0f2bnce4188ddb2953707@mail.gmail.com> <479188D3.5080408@hanik.com> <176a7eb80801191632x60fc192eqc3bad1a89b040280@mail.gmail.com> <4792AB7B.3050605@hanik.com> <176a7eb80801192322n62f25378gff58a8813612c39a@mail.gmail.com> In-Reply-To: <176a7eb80801192322n62f25378gff58a8813612c39a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org now I get it. I just ran through a test case, and an END event was not thrown just because there was an end chunk. the response is very much still open at that point Filip Peter Warren wrote: > What java.net.HttpURLConnection has to do with Tomcat and comet is > that HttpURLConnection is Java's implementation of an http client and > will likely be used by people developing comet apps for Tomcat. In my > case, I want to use it because I can't use raw sockets on my applet > client due to permission problems when trying to use sockets behind a > proxy. > > I understand that asynchronous writes are possible, but they're not > when using HttpURLConnection because HttpURLConnection sends a "last > chunk" message when it's done with its request. "Last chunk" > generates a comet end event, which then requires that the connection > to the client be closed. > > I guess I don't understand why tomcat needs to close the connection > after an END event. It seems to me that the "last chunk" message from > the client simply indicates that the client is done sending its > request. Why does the server need to close the connection when the > client finishes its request? > > Peter > > On Jan 19, 2008 6:01 PM, Filip Hanik - Dev Lists wrote: > >> I'm not sure what HttpURLConnection has to do with Tomcat or comet. >> and yes, asynchronous writes are possible, just not after the END or >> ERROR events have been issued >> >> Filip >> >> >> Peter Warren wrote: >> >>> Does that mean that HttpURLConnection cannot be used for comet >>> requests with asynchronous (i.e. delayed) responses? >>> >>> It would seem so to me since HttpURLConnection always sends an END >>> message before reading from the server and since the server can no >>> longer write to the client after closing the comet event. Am I >>> missing something? Is there a way to write to the client after the >>> comet event is closed? >>> >>> Would you consider it a bug that HttpURLConnection is implemented that way? >>> >>> Peter >>> >>> On Jan 18, 2008 9:21 PM, Filip Hanik - Dev Lists wrote: >>> >>> >>>> during end and error, you MUST close the Comet event >>>> >>>> Filip >>>> >>>> >>>> Peter Warren wrote: >>>> >>>> >>>>> What do I do to make the END event stop repeating? I don't want to >>>>> close the CometEvent yet because the server is waiting for data to >>>>> send to the client. If I don't close the comet event, the END event >>>>> repeats incessantly. >>>>> >>>>> I'm using an unsigned applet as a comet client. To accommodate >>>>> proxies, I've had to change my comet client to use HttpURLConnection >>>>> instead of Sockets. (Accessing ProxySelector from an applet to create >>>>> a socket with a proxy generates an AccessControlException.) >>>>> >>>>> HttpURLConnection unfortunately sends a 0crlf when its input stream is >>>>> retrieved for reading. This generates a Comet END event. Short of >>>>> closing the comet event, how can I make the server stop notifying me >>>>> of END events? I can't close the comet event because I want to hold >>>>> onto the comet output stream for use later to send data to the client. >>>>> >>>>> >From the comet docs: >>>>> EventType.END: End may be called to end the processing of the request. >>>>> Fields that have been initialized in the begin method should be reset. >>>>> After this event has been processed, the request and response objects, >>>>> as well as all their dependent objects will be recycled and used to >>>>> process other requests. End will also be called when data is available >>>>> and the end of file is reached on the request input (this usually >>>>> indicates the client has pipelined a request). >>>>> >>>>> This seems to indicate that even if I could get the END event to go >>>>> away quietly, the comet event's output stream might no longer be >>>>> usable anyway. >>>>> >>>>> It seems to me I have 3 options: >>>>> 1) figure out how to make the comet END event stop repeating and hope >>>>> it's output stream still works >>>>> 2) figure out how to keep HttpURLConnection from sending 0crlf (don't >>>>> know if that can be done) >>>>> 2) use sockets with ProxySelector (which requires signing my applet >>>>> and getting users to grant it privileges) >>>>> >>>>> Thanks, >>>>> Peter >>>>> >>>>> --------------------------------------------------------------------- >>>>> To start a new topic, e-mail: users@tomcat.apache.org >>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org >>>>> For additional commands, e-mail: users-help@tomcat.apache.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To start a new topic, e-mail: users@tomcat.apache.org >>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org >>>> For additional commands, e-mail: users-help@tomcat.apache.org >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To start a new topic, e-mail: users@tomcat.apache.org >>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org >>> For additional commands, e-mail: users-help@tomcat.apache.org >>> >>> >>> >>> >>> >> --------------------------------------------------------------------- >> To start a new topic, e-mail: users@tomcat.apache.org >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org >> For additional commands, e-mail: users-help@tomcat.apache.org >> >> >> > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > > > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org