Re: Question abut CometProcessor EventSubType.TIMEOUT semantics
Filip Hanik - Dev Lists wrote: are you able to submit a simple example, and we shall get it taken care of Yes...but only in the parallel universe where I have loads of spare time ;) Realistically it'd be quicker for me to debug the problem in situ and fix it than to create an isolate reproduction case (since that involves creating a client too). One more question before I dive in : what's the 'correct' way for the application to terminate a live Comet request ? That is, suppose the client connects, sends an http request, which we process, then the client does exactly nothing, forever. Unless the server closes the TCP connection, this connection will stay open until the end of time (and that's what I observe practically). How should the application force the closure of the connection ? (possibly the answer is 'send a response to the client which causes it to close', but given the fact that Tomcat never sends anything to the client, that doesn't work). I've tried calling event.close(), and close() on the response stream. Neither seems to have the desired effect. It'd be useful to know the intended behavior of the CometProcessor interface, so I can determine if it's behaving as intended. Right now I don't have a clear definition in my mind of either the intended interface behavior, nor the actual implementation behavior, nor if the two are the same or different. Thanks again for your help. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question abut CometProcessor EventSubType.TIMEOUT semantics
David Boreham wrote: Filip Hanik - Dev Lists wrote: are you able to submit a simple example, and we shall get it taken care of Yes...but only in the parallel universe where I have loads of spare time ;) 0.18 like the people helping you for free on the mailing lists? :) Realistically it'd be quicker for me to debug the problem in situ and fix it than to create an isolate reproduction case (since that involves creating a client too). One more question before I dive in : what's the 'correct' way for the application to terminate a live Comet request ? That is, suppose the client connects, sends an http request, which we process, then the client does exactly nothing, forever. Unless the server closes the TCP connection, this connection will stay open until the end of time (and that's what I observe practically). How should the application force the closure of the connection ? (possibly the answer is 'send a response to the client which causes it to close', but given the fact that Tomcat never sends anything to the client, that doesn't work). I've tried calling event.close(), and close() on the response stream. Neither seems to have the desired effect. event.close() during an event is the correct way, that will terminate it. In 6.0.19 you will also be able to call event.close() asynchronously, on a non worker thread It'd be useful to know the intended behavior of the CometProcessor interface, so I can determine if it's behaving as intended. Right now I don't have a clear definition in my mind of either the intended interface behavior, nor the actual implementation behavior, nor if the two are the same or different. before you debug 6.0.18, there are fixes in 6.0.x/trunk that you may want to try out before you dig into the older code base Filip Thanks again for your help. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question abut CometProcessor EventSubType.TIMEOUT semantics
Filip Hanik - Dev Lists wrote: David Boreham wrote: Filip Hanik - Dev Lists wrote: are you able to submit a simple example, and we shall get it taken care of Yes...but only in the parallel universe where I have loads of spare time ;) 0.18 like the people helping you for free on the mailing lists? :) Pretty much. But as I said, I'm willing to debug and fix the code myself. If I wasn't familiar with this kind of code I'd consider making a repro case, but since I am, It's more efficient overall to just fix it in place. event.close() during an event is the correct way, that will terminate it. In 6.0.19 you will also be able to call event.close() asynchronously, on a non worker thread Hmm...I didn't appreciate there were rules about which thread could do what. Obviously I don't have an event, so I'm not in a worker thread. before you debug 6.0.18, there are fixes in 6.0.x/trunk that you may want to try out before you dig into the older code base Ok I'll do that. JBoss folk seem to have made some fixes in this area. Did they fork the code, or are their fixes in the trunk, I wonder ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question abut CometProcessor EventSubType.TIMEOUT semantics
Filip Hanik - Dev Lists wrote: are you calling response.flushBuffer() to flush your data? No, I was calling response.getOutputStream().flush(). I'll try your suggestion and report back, thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question abut CometProcessor EventSubType.TIMEOUT semantics
David Boreham wrote: Filip Hanik - Dev Lists wrote: are you calling response.flushBuffer() to flush your data? No, I was calling response.getOutputStream().flush(). I'll try your suggestion and report back, thanks. This made no difference, btw. It's broken in the same way as before. Do you want me to call flush() on the stream AND on the response ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question abut CometProcessor EventSubType.TIMEOUT semantics
are you able to submit a simple example, and we shall get it taken care of Filip David Boreham wrote: David Boreham wrote: Filip Hanik - Dev Lists wrote: are you calling response.flushBuffer() to flush your data? No, I was calling response.getOutputStream().flush(). I'll try your suggestion and report back, thanks. This made no difference, btw. It's broken in the same way as before. Do you want me to call flush() on the stream AND on the response ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question abut CometProcessor EventSubType.TIMEOUT semantics
are you calling response.flushBuffer() to flush your data? that is probably what you are missing David Boreham wrote: I'm re-writing an application to use the CometProcessor interface. Generally things are working but despite several late evenings single-stepping through the connector code, I'm still unclear on one issue and would appreciate some education: In my debugging I'm using NIO (production deployment is intended to use Linux and APR but for now my question pertains to my experiences with NIO on the Windows desktop). My application receives a BEGIN event and stores the event object, response and so on for later use to respond to the client, much like the example code. Until that time, which may be many minutes in the future, it sends nothing back to the client. I see EventSubType.TIMEOUT events delivered during the time after BEGIN event, one TIMEOUT ever soTimeout interval. This matches the documentation's description of timeout semantics. However, I have observed empirically that if an attempt is made to send data back to the client (via Response.outputStream.write/flush), no data is actually sent on the wire IF the write is done AFTER one of these timeout events has arrived. That is, if I change the timeout such that it is longer than the time at which the application responds to the client, the client receives the data. If I make the timeout shorted, the client does not receive the data. There is no exception thrown, and in fact I've single stepped into the NIO code all the way to the socket write and flush calls. Everything looks ok, but no data makes it to the wire (confirmed in a packet trace). So, I'm wondering: is this expected behavior ? If so then the documentation is incorrect. Also, if this is the intended behavior it would appear to make it hard to build a working application for APR because the timeout can't be set after connection establishment (the same timeout, it appears applies to all socket reads, and hence setting it to a very long time will cause thread pool starvation trouble with new connections that stall with the client never sending any data). Any thoughts on this are most welcome. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Question abut CometProcessor EventSubType.TIMEOUT semantics
I'm re-writing an application to use the CometProcessor interface. Generally things are working but despite several late evenings single-stepping through the connector code, I'm still unclear on one issue and would appreciate some education: In my debugging I'm using NIO (production deployment is intended to use Linux and APR but for now my question pertains to my experiences with NIO on the Windows desktop). My application receives a BEGIN event and stores the event object, response and so on for later use to respond to the client, much like the example code. Until that time, which may be many minutes in the future, it sends nothing back to the client. I see EventSubType.TIMEOUT events delivered during the time after BEGIN event, one TIMEOUT ever soTimeout interval. This matches the documentation's description of timeout semantics. However, I have observed empirically that if an attempt is made to send data back to the client (via Response.outputStream.write/flush), no data is actually sent on the wire IF the write is done AFTER one of these timeout events has arrived. That is, if I change the timeout such that it is longer than the time at which the application responds to the client, the client receives the data. If I make the timeout shorted, the client does not receive the data. There is no exception thrown, and in fact I've single stepped into the NIO code all the way to the socket write and flush calls. Everything looks ok, but no data makes it to the wire (confirmed in a packet trace). So, I'm wondering: is this expected behavior ? If so then the documentation is incorrect. Also, if this is the intended behavior it would appear to make it hard to build a working application for APR because the timeout can't be set after connection establishment (the same timeout, it appears applies to all socket reads, and hence setting it to a very long time will cause thread pool starvation trouble with new connections that stall with the client never sending any data). Any thoughts on this are most welcome. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
