https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #22 from Mark Thomas ---
Thanks for confirming the fix.
Generally, if applications simulate blocking using non-blocking I/O that will
be problematic.
If there is a way to reduce the locking in Tomcat (and hence reduce the chances
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #21 from Venkata Manda ---
Excuse me for the delayed response.
I tested the fix by simulating the GC pause by pausing the JVM (running in
debug mode) and it worked.
My team is working on running this at a higher load with actual
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEEDINFO
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
Boris Petrov changed:
What|Removed |Added
CC||boris_pet...@live.com
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
Matafagafo changed:
What|Removed |Added
CC||matafag...@yahoo.com
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #19 from Mark Thomas ---
I've applied a further fix for this.
I've also updated the dev build at:
https://people.apache.org/~markt/dev/v9.0.74-dev/
Same caveats apply:
- this is not an official release
- use it at your own risk
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #18 from Mark Thomas ---
Thanks for the Connector settings. The stack traces will definitely be useful
as it looks as if you are using useAsyncIO="true". If correct, I definitely
want to see how this is being triggered.
As an
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #17 from Venkata Manda ---
Excuse me for the delayed response. Please find below our connector
configuration:
protocol=org.apache.coyote.http11.Http11Nio2Protocol
tomcat.connector.all.enableLookups=false
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #16 from Mark Thomas ---
Short term, any combination of NIO/NIO2 and useAsyncIO that is NOT NIO2 +
useAsyncIO="false" should work. Performance differences should be minimal
between all of those combinations.
Medium term, this
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
Mark Thomas changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #15 from Mark
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #14 from Venkata Manda ---
Hi Mark Thomas,
I am still able to reproduce the issue with the latest changes.
My understanding is the recent changes help only when the
writeCompletionHandler failed method in Nio2Endpoint fires the
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #13 from Mark Thomas ---
I fixed the other code path that could trigger this issue and have uploaded
8.5.x and 9.0.x builds for testing:
https://people.apache.org/~markt/dev/
--
You are receiving this mail because:
You are the
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
Mark Thomas changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #12 from Mark Thomas
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
Remy Maucherat changed:
What|Removed |Added
Status|REOPENED|NEEDINFO
--- Comment #11 from Remy
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #10 from Remy Maucherat ---
There's some bad analysis in the comment: processSocket is not supposed to
return false (it does only when the executor refuses to run the task), the
close() is simply there to handle this unlikely (and
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #9 from Venkata Manda ---
When a nonblocking write is failing, the writeCompletionHandler.failed inside
Nio2Endpointis getting called, but it is unable to trigger a code path to clear
the handler on WsRemoteEndpointImplServer.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
Venkata Manda changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #7 from Mark Thomas ---
If it helps, dev build with the fix is available from:
https://people.apache.org/~markt/dev/v9.0.74-dev/
Note:
- this is not an official release
- use it at your own risk
--
You are receiving this mail
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #6 from Venkata Manda ---
(In reply to Mark Thomas from comment #4)
> Fixed in:
> - 11.0.x for 11.0.0-M5 onwards
> - 10.1.x for 10.1.8 onwards
> - 9.0.x for 9.0.74 onwards
> - 8.5.x for 8.5.88 onwards
>
> If you'd like to test
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #5 from Venkata Manda ---
(In reply to Mark Thomas from comment #3)
> Thanks for the steps to reproduce.
>
> I'll note for the record that you also need to be using the NIO2 connector.
>
> I can see what the root cause is. The
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #3 from Mark Thomas ---
Thanks for the steps to reproduce.
I'll note for the record that you also need to be using the NIO2 connector.
I can see what the root cause is. The write in "Event 3" fails and isn't
cleaned up properly
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
Mark Thomas changed:
What|Removed |Added
Version|Tomcat 8.5.84 |8.5.72
--- Comment #2 from Mark Thomas
https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
--- Comment #1 from Venkata Manda ---
In my below issue description, I mentioned the test environment java version is
1.8. The issue is reproducible with Java 11.
Based on my reading and analysis of the issue, any time a socket is closed at
24 matches
Mail list logo
