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 ------- Additional Comments From [EMAIL PROTECTED] 2007-04-23 12:26 ------- Ok, I have read (it was a bit hidden) that you have tested with the current svn code. I had forgotten that close was immediately closing the response. As the thing is designed, this is a bit wrong, I think, so I will make an update. I don't understand how your problem can happen at this time (it would imply that the internal objects have been recycled, however), since I don't see anything occuring on your connections. Maybe you could use the system property org.apache.catalina.connector.RECYCLE_FACADES set to true (you can put it in catalina.properties). It protects from crashes from funky async accesses (like Java2D, or here, bad Comet access). You appear to be storing connections in a queue for some async processing. In the design, it is up to you to synchronize accesses as needed (as with the rest of the Servlet API, nothing is thread safe): in the example ChatServlet - not functional, but is meant to be an IO test - all async writes are done inside a sync on an object which is also used to manipulate the list of connections. This way, you cannot have a close occurring at the same time as another write (or close). The more I think about it, the less I think there's a bug to fix. -- 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]
