[Bug 56518] NIO async servlet limit latch leak

2014-06-16 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 56518] NIO async servlet limit latch leak

2014-06-12 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #16 from Mark Thomas --- I have implemented this for 8.0.x and it will be included in 8.0.9 onwards. I am now looking at back-porting the fix to 7.0.x. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 56518] NIO async servlet limit latch leak

2014-06-11 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #15 from Konstantin Kolinko --- (In reply to Mark Thomas from comment #14) > > I am leaning towards closing the > connection if Tomcat detects an interrupt since that is what would happen if > the thread was allowed to continue

[Bug 56518] NIO async servlet limit latch leak

2014-06-11 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #14 from Mark Thomas --- I've done some testing and it looks like the call to Thread.currentThread().isInterrupted() is nice and quick. I'm going to go ahead and make some changes here. I've been thinking about this some more a

[Bug 56518] NIO async servlet limit latch leak

2014-06-10 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #13 from Mark Thomas --- Thanks for all your work on this. It is much appreciated. Given that it is the application that is triggering the interrupt, shouldn't it be the application's responsibility to clear that interrupt befo

[Bug 56518] NIO async servlet limit latch leak

2014-06-10 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #12 from hanyong --- Created attachment 31703 --> https://issues.apache.org/bugzilla/attachment.cgi?id=31703&action=edit fix bug 56518 on TOMCAT_7_0_54 Clear thread interrupted status before write to NIO socket. i.e. Never in

[Bug 56518] NIO async servlet limit latch leak

2014-06-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #11 from Mark Thomas --- One way around that issue would be to move the Async timeout processing to a separate thread - like it is for the other endpoints. -- You are receiving this mail because: You are the assignee for the b

[Bug 56518] NIO async servlet limit latch leak

2014-06-09 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #10 from hanyong --- Sorry, the patch DOES NOT work well. I found another problem. The aysnc servlet timeout is triggered by the poller thead also, since the SelectionKey was deregistered when the socket be closed, the asyncTi

[Bug 56518] NIO async servlet limit latch leak

2014-06-08 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #9 from hanyong --- Created attachment 31698 --> https://issues.apache.org/bugzilla/attachment.cgi?id=31698&action=edit fix bug 56518 based on https://svn.apache.org/repos/asf/tomcat/trunk@1595293 Here is my Quick and Dirty p

[Bug 56518] NIO async servlet limit latch leak

2014-06-05 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #8 from Mark Thomas --- (In reply to hanyong from comment #7) > It seems the bug does not fixed in tomcat 8, but make > it more difficult to reproduce. I wondered if that might be the case. I've spent quite a bit of time lookin

[Bug 56518] NIO async servlet limit latch leak

2014-06-05 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #7 from hanyong --- we are try to back-porting the fix in tomcat 8 to tomcat 7. After some debugging, It seems the bug does not fixed in tomcat 8, but make it more difficult to reproduce. The root cause is that the SelectionKey

[Bug 56518] NIO async servlet limit latch leak

2014-06-05 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 hanyong changed: What|Removed |Added Attachment #31614|0 |1 is obsolete|

[Bug 56518] NIO async servlet limit latch leak

2014-06-05 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 hanyong changed: What|Removed |Added Attachment #31613|0 |1 is obsolete|

[Bug 56518] NIO async servlet limit latch leak

2014-05-15 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #4 from Mark Thomas --- The fix works on 8.0.x but back-porting the changes to 7.0.x doesn't appear to address the problem on that platform. For reasons I don't yet fully understand, 8.0.x appears not to throw the ClosedByInter

[Bug 56518] NIO async servlet limit latch leak

2014-05-13 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #3 from Mark Thomas --- As luck would have it, the next stage of clean-up / refactoring appears to have fixed this issue. The fix is applied to 8.0.x and the unit tests pass on OSX. I'm just waiting for the results for Linux and

[Bug 56518] NIO async servlet limit latch leak

2014-05-13 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #2 from Mark Thomas --- Thanks for the sample web application. I am able to reproduce this with NIO but not with NIO2 or APR/native so it appears that this issue is specific to NIO. I have started some refactoring that should m

[Bug 56518] NIO async servlet limit latch leak

2014-05-13 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 hanyong changed: What|Removed |Added CC||observer.hany@alibaba-inc.c

[Bug 56518] NIO async servlet limit latch leak

2014-05-13 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=56518 --- Comment #1 from hanyong --- Created attachment 31614 --> https://issues.apache.org/bugzilla/attachment.cgi?id=31614&action=edit source code of the sample webapp -- You are receiving this mail because: You are the assignee for the bu