tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: comet end event
Date Mon, 21 Jan 2008 19:53:11 GMT
answers inline

Peter Warren wrote:
> First off, thanks for your responses.  The contributors to this list
> are extremely responsive, patient, and helpful, and I really
> appreciate it!
>
> Hmm, in your test case did you set the HttpURLConnection to use
> chunked transfers (setChunkedStreamingMode(...))?  I find if I use
> chunked transfers, the HttpURLConnection sends a "last chunk" message
> upon reading input from the server, which generates a comet END event
> on the server.  If I don't use chunked transfers, no END event is
> generated because no "last chunk" is sent by the client.
>   
as I  mentioned, the "last chunk" doesn't generate an END event, I tried 
it locally. of course against 6.0.x trunk.
> Which brings up an option I never considered: will a comet servlet
> function properly with non-chunked transfer (i.e. no transfer-coding
> header)?  It seems to.
>   
yes, it can, just send a very large content-length header
> Lastly, I'm still a little confused about requiring the comet event to
> be closed on an END event.  Doesn't this mean that tomcat comet can't
> handle pipelined requests?  If a client sends 2 pipelined requests, it
> will send a "last chunk" to indicate the end of the first request.
> This "last chunk" will generate an END event on the server, which then
> requires the connection to be closed.  After the comet event is closed
> the server cannot send a response to the client.
>   
pipelined requests are not defined by the HTTP spec for POST methods, 
only for GET
assuming the pipelining you are talking about is true pipelining :)
if you just mean, next request, then yes, tomcat handles that just fine, 
and that is why you have to call event.close()
> The END event docs indicate that pipelined request will generate an
> END event: ...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).
>   
depends on what you mean by pipeline, see above
> Thanks,
> Peter
>
> On Jan 20, 2008 8:15 PM, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
>   
>> 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 <devlists@hanik.com> 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 <devlists@hanik.com>
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
>>
>>
>>     
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message