Re: Comet problem when writing a lot of data to the OutputStream
Rémy Maucherat wrote: On 4/26/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: Sebastiaan van Erk wrote: > Hi, > > The fixes seem to work well, thanks again! :-) Excellent, thanks for bringing it to my attention And it was committed before tagging, not 5 minutes after as usually happens. I feel lucky today. he he, I broke my own pattern :) Filip Rémy - 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]
Re: Comet problem when writing a lot of data to the OutputStream
On 4/26/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: Sebastiaan van Erk wrote: > Hi, > > The fixes seem to work well, thanks again! :-) Excellent, thanks for bringing it to my attention And it was committed before tagging, not 5 minutes after as usually happens. I feel lucky today. Rémy - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comet problem when writing a lot of data to the OutputStream
Sebastiaan van Erk wrote: Hi, The fixes seem to work well, thanks again! :-) Excellent, thanks for bringing it to my attention Filip Regards, Sebastiaan Sebastiaan van Erk wrote: Hi, Thanks for the quick action. I'll test the new version right away. :-) Regards, Sebastiaan Filip Hanik - Dev Lists wrote: Sebastian, I have checked in a fix to SVN. You can also work around the problem by not using the shared selector by adding -Dorg.apache.tomcat.util.net.NioSelectorShared=false to your command line Filip Filip Hanik - Dev Lists wrote: definitely a bug, I will work on a fix right away. Filip Sebastiaan van Erk wrote: Hi, I have the following problem with Comet. I have a long request, and I asynchronously write data to the output stream of the response while the request is between the BEGIN and END/ERROR events. However, the writes do NOT occur while IN a READ request, but are triggered by other events on the server side. When I send a lot of data, the send buffer fills up, and the channel needs to be registered with the poller for the OP_WRITE event. However, this does not happen. In NioBlockingSelector line 69, there is the following code that is supposed to register the channel for OP_WRITE: if ( att.getLatch()==null || att.getLatch().getCount()==0) att.startLatch(1); if ( att.interestOps() == 0) socket.getPoller().add(socket,SelectionKey.OP_WRITE); att.getLatch().await(writeTimeout,TimeUnit.MILLISECONDS); However, since I'm not in a comet READ event, att.interestOps() == 1 (and not 0), therefore the event is never registered. 60 seconds later I get a SocketTimeoutException. I figure this is probably a bug, but I thought I'd ask here just to be sure. Regards, Sebastiaan - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comet problem when writing a lot of data to the OutputStream
Hi, The fixes seem to work well, thanks again! :-) Regards, Sebastiaan Sebastiaan van Erk wrote: Hi, Thanks for the quick action. I'll test the new version right away. :-) Regards, Sebastiaan Filip Hanik - Dev Lists wrote: Sebastian, I have checked in a fix to SVN. You can also work around the problem by not using the shared selector by adding -Dorg.apache.tomcat.util.net.NioSelectorShared=false to your command line Filip Filip Hanik - Dev Lists wrote: definitely a bug, I will work on a fix right away. Filip Sebastiaan van Erk wrote: Hi, I have the following problem with Comet. I have a long request, and I asynchronously write data to the output stream of the response while the request is between the BEGIN and END/ERROR events. However, the writes do NOT occur while IN a READ request, but are triggered by other events on the server side. When I send a lot of data, the send buffer fills up, and the channel needs to be registered with the poller for the OP_WRITE event. However, this does not happen. In NioBlockingSelector line 69, there is the following code that is supposed to register the channel for OP_WRITE: if ( att.getLatch()==null || att.getLatch().getCount()==0) att.startLatch(1); if ( att.interestOps() == 0) socket.getPoller().add(socket,SelectionKey.OP_WRITE); att.getLatch().await(writeTimeout,TimeUnit.MILLISECONDS); However, since I'm not in a comet READ event, att.interestOps() == 1 (and not 0), therefore the event is never registered. 60 seconds later I get a SocketTimeoutException. I figure this is probably a bug, but I thought I'd ask here just to be sure. Regards, Sebastiaan - 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]
Re: Comet problem when writing a lot of data to the OutputStream
Hi, Thanks for the quick action. I'll test the new version right away. :-) Regards, Sebastiaan Filip Hanik - Dev Lists wrote: Sebastian, I have checked in a fix to SVN. You can also work around the problem by not using the shared selector by adding -Dorg.apache.tomcat.util.net.NioSelectorShared=false to your command line Filip Filip Hanik - Dev Lists wrote: definitely a bug, I will work on a fix right away. Filip Sebastiaan van Erk wrote: Hi, I have the following problem with Comet. I have a long request, and I asynchronously write data to the output stream of the response while the request is between the BEGIN and END/ERROR events. However, the writes do NOT occur while IN a READ request, but are triggered by other events on the server side. When I send a lot of data, the send buffer fills up, and the channel needs to be registered with the poller for the OP_WRITE event. However, this does not happen. In NioBlockingSelector line 69, there is the following code that is supposed to register the channel for OP_WRITE: if ( att.getLatch()==null || att.getLatch().getCount()==0) att.startLatch(1); if ( att.interestOps() == 0) socket.getPoller().add(socket,SelectionKey.OP_WRITE); att.getLatch().await(writeTimeout,TimeUnit.MILLISECONDS); However, since I'm not in a comet READ event, att.interestOps() == 1 (and not 0), therefore the event is never registered. 60 seconds later I get a SocketTimeoutException. I figure this is probably a bug, but I thought I'd ask here just to be sure. Regards, Sebastiaan - 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]
Re: Comet problem when writing a lot of data to the OutputStream
Sebastian, I have checked in a fix to SVN. You can also work around the problem by not using the shared selector by adding -Dorg.apache.tomcat.util.net.NioSelectorShared=false to your command line Filip Filip Hanik - Dev Lists wrote: definitely a bug, I will work on a fix right away. Filip Sebastiaan van Erk wrote: Hi, I have the following problem with Comet. I have a long request, and I asynchronously write data to the output stream of the response while the request is between the BEGIN and END/ERROR events. However, the writes do NOT occur while IN a READ request, but are triggered by other events on the server side. When I send a lot of data, the send buffer fills up, and the channel needs to be registered with the poller for the OP_WRITE event. However, this does not happen. In NioBlockingSelector line 69, there is the following code that is supposed to register the channel for OP_WRITE: if ( att.getLatch()==null || att.getLatch().getCount()==0) att.startLatch(1); if ( att.interestOps() == 0) socket.getPoller().add(socket,SelectionKey.OP_WRITE); att.getLatch().await(writeTimeout,TimeUnit.MILLISECONDS); However, since I'm not in a comet READ event, att.interestOps() == 1 (and not 0), therefore the event is never registered. 60 seconds later I get a SocketTimeoutException. I figure this is probably a bug, but I thought I'd ask here just to be sure. Regards, Sebastiaan - 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]
Re: Comet problem when writing a lot of data to the OutputStream
definitely a bug, I will work on a fix right away. Filip Sebastiaan van Erk wrote: Hi, I have the following problem with Comet. I have a long request, and I asynchronously write data to the output stream of the response while the request is between the BEGIN and END/ERROR events. However, the writes do NOT occur while IN a READ request, but are triggered by other events on the server side. When I send a lot of data, the send buffer fills up, and the channel needs to be registered with the poller for the OP_WRITE event. However, this does not happen. In NioBlockingSelector line 69, there is the following code that is supposed to register the channel for OP_WRITE: if ( att.getLatch()==null || att.getLatch().getCount()==0) att.startLatch(1); if ( att.interestOps() == 0) socket.getPoller().add(socket,SelectionKey.OP_WRITE); att.getLatch().await(writeTimeout,TimeUnit.MILLISECONDS); However, since I'm not in a comet READ event, att.interestOps() == 1 (and not 0), therefore the event is never registered. 60 seconds later I get a SocketTimeoutException. I figure this is probably a bug, but I thought I'd ask here just to be sure. Regards, Sebastiaan - 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]
