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. 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. 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. 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). Thanks, Peter On Jan 20, 2008 8:15 PM, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > >>> 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: [EMAIL PROTECTED] > >>>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> --------------------------------------------------------------------- > >>>> To start a new topic, e-mail: users@tomcat.apache.org > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>>> > >>>> > >>> --------------------------------------------------------------------- > >>> To start a new topic, e-mail: users@tomcat.apache.org > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >>> > >> --------------------------------------------------------------------- > >> To start a new topic, e-mail: users@tomcat.apache.org > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > --------------------------------------------------------------------- > > To start a new topic, e-mail: users@tomcat.apache.org > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
