tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach>
Subject Re: Comet: problem with request.getParameter() in Comet POST requests
Date Wed, 02 May 2007 18:59:01 GMT

Am 02.05.2007 um 17:26 schrieb Sebastiaan van Erk:

> Hi,
>> How about not arguing about everything ? It is your fault when
>> parameters are not processed. Tomcat will process parameters with
>> comet.
> No, Comet will not process parameters in POST requests if you call  
> getParameter() in the BEGIN event and the request body has not yet  
> arrived. getParameter() will return null even if the parameter is  
> set in the request body. How is this my fault? How do I know when  
> to call getParameter()? How exactly am I supposed to process the  
> POST parameters in a Comet request?

I have no problem to get POST parameter with NIO Connector at my  
begin.event.  With APR connector I also have POST parameter problems.  
Strange! A my first request I get the POST parameter. The POST  
message close the event and I got an exception after  the end event.

== This two messages are only exists at my patch tomcat trunk, but it  
show that POST read the 12 byte post body.
02.05.2007 20:24:00 org.apache.catalina.connector.Request  
FEIN: before readPostBody 12
02.05.2007 20:24:00 org.apache.catalina.connector.Request  
FEIN: post is suuccessfull[B@69ba97 12
Asynch close of the event command=close
Asynch close of the event
Closing transport
Asynch close of the event command=close
Asynch close of the event
Event received END
Closing transport
Leaving handle end
02.05.2007 20:24:04 org.apache.catalina.connector.CoyoteAdapter event
SCHWERWIEGEND: The servlet did not read all available bytes during  
the processing of the read event
Event received BEGIN
Leaving handle begin
Sending message Message0
Sending message Message1
Sending message Message2
Sending message Message3
Sending message Message4
Closing transport
Event received END
Closing transport
Leaving handle end

As I use the NIO connector I have no problems...

Here my POST request:
POST /tcniotest/comet HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv: Gecko/20070309 Firefox/
Accept: text/xml,application/xml,application/xhtml+xml,text/ 
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: close
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Referer: http://localhost:8080/tcniotest/
Content-Length: 12
Cookie: JSESSIONID=17451AD30A176E1B7E7292CD9E1A0987.tomcat6
Pragma: no-cache
Cache-Control: no-cache


Testet with current tomcat6 main trunk, java 6, mac osx 10.4.9 and  
firefox , apr 1.2.8 tcnative 1.1.10

>>> You need the IO event to free up more than just the memory. The file
>>> descriptor also needs to be freed; this was causing problems for  
>>> me earlier.
>> Then set a shorter timeout, allow an appropriate amount of file
>> descriptors, or produce an IO event. It is possible that a notify
>> method (or something like that) could be added on the event to  
>> make it
>> a bit more straightforward.
> The first two are workarounds which start failing quite quickly  
> when there is a high number of requests. As for the last option,  
> how do "produce and IO event" on the input stream on the server  
> side? It's the client that produces IO events on the input stream,  
> and I have no control over the client.
> By the way, in RFC 2616 it says: HTTP/1.1 defines the "close"  
> connection option for the sender to signal that the connection will  
> be closed after completion of the response.
It seems a good option that connection really close with the header  
"Connection: close" is set.
For normal Htttp11Processor it is easy, but NIO and APR processor are  
more complex.
Currently set a short timeout is the only option, but most programmes  
want to set Connection:close.

> So as far as I can tell it's not even required for the client to  
> close the input stream after reading Content-Length bytes. It could  
> very well wait for the server to close the request, which means  
> that Comet receives no IO event and we end up having to wait for a  
> TIMEOUT event.
> So please tell me how to "produce an IO event".
Currently we have no IO Event, but Remy has wrote a proposal to dev  
list :-)

I thing we need this feature.  +1

>> The way to sync is according to what your application does. The chat
>> mini example has a very simple sync structure. The sync depends on
>> what the application is doing. The only official stance is that none
>> of the structures that the Servlet API provides are synced.
> I don't see how this is enough information. Obviously I need to  
> synchronize access to the output stream of the repsonse object. But  
> internally, Tomcat uses this object too. For example, it closes the  
> output stream in the event.close() method. Without me knowing when  
> and how Tomcat uses this object, how am I supposed to know how to  
> do the synchronization?

> For example, there is no explanation in the chat example why there  
> is a synchronized (connections) block in the READ event. It looks  
> like it's in there to syncrhonize access to the list, which could  
> possibly be avoided with a CopyOnWriteArrayList. However, using a  
> concurrent list and using synchronization on the output stream  
> would break the chat program (because event.close() seems to  
> internally access the output stream).
Yes, the event coordination with read is complicated.

>> Rémy
> Regards,
> Sebastiaan
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message