DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42198>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42198 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #20017|0 |1 is obsolete| | ------- Additional Comments From [EMAIL PROTECTED] 2007-04-23 14:52 ------- Created an attachment (id=20025) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20025&action=view) Corrected version of comettest.war You are right - it is not a bug! I synchronized access to the output stream by synchronizing on the event object, and the synchronization problem is solved - Thank you for your quick comment. Synchronization on the CometEvent object works fine with the current implementation which reuses the same CometEventImpl instance throughout the lifetime of a request, but is this part of the contract between container and the Servlet? I would not like the idea of synchronizing write operations on lots of connections with the help of a single synchronizer object like the example ChatServlet does. An alternative would be to synchronize on the HttpServletResponse object. What do you recommend? As I understood your comment, event.close and outputStream.close are not intended to be coupled as close as they are in the current implementation. Thus, would it be the recommended use of the Comet interface if the response provider thread closes only the stream but not the event, so that the Servlet's event method will be triggered with an END event, and the event method can close the event? Will a close of the event be required in case of an END event (e.g. to enable recycling of request and response) or is it optional? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
