https://bz.apache.org/bugzilla/show_bug.cgi?id=64007
Remy Maucherat changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEEDINFO
https://bz.apache.org/bugzilla/show_bug.cgi?id=64007
--- Comment #9 from echo ---
with your fixed code i package a new jar and then replace tomcat-embed-core.jar
in 9.0.26.and then i pressure my application 3 hours and all is fine. But with
the tomcat 9.0.26 press 1 hour the deadlock appear.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=64007
--- Comment #8 from Remy Maucherat ---
The issue would have been introduced in 9.0.20, and it's not surprising it's
hard to reproduce.
It's interesting that with the new Java dev model they actually do this sort of
refactorings, cleanups and i
https://bz.apache.org/bugzilla/show_bug.cgi?id=64007
--- Comment #7 from echo ---
yes. thank you for your patient answer.I don't have a correct way to test. Just
pressure test and it's hard to reproduce the bug fixed or not.
--
You are receiving this mail because:
You are the assignee for the b
https://bz.apache.org/bugzilla/show_bug.cgi?id=64007
--- Comment #6 from Remy Maucherat ---
Looking at the most recent JDK sources, the root issue likely has been fixed by
these commits which remove all the unwanted internal NIO syncing:
https://github.com/openjdk/jdk/commit/33b921f25d8b5e6a50003
https://bz.apache.org/bugzilla/show_bug.cgi?id=64007
--- Comment #5 from Remy Maucherat ---
Ok. If you run again into a deadlock, please add the updated deadlock traces as
an attachment to the BZ (otherwise it's harder to read).
--
You are receiving this mail because:
You are the assignee for t
https://bz.apache.org/bugzilla/show_bug.cgi?id=64007
--- Comment #4 from echo ---
I will test first. If there is progress i will recommend agin
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsu
https://bz.apache.org/bugzilla/show_bug.cgi?id=64007
--- Comment #3 from Remy Maucherat ---
Ok, so then cancelledKey should cancel the key first, and this would resolve
the "problem" as the channel close locks everything before cancelling that key
itself. This is what was done like that in 8.5 bu
https://bz.apache.org/bugzilla/show_bug.cgi?id=64007
--- Comment #2 from echo ---
but, in my opinion. just the NioEndpoint$Poller.cancelledKey and
NioEndpoint$Poller.run may cause the deadlock. Poller.run finally call
AbstractSelector.cancel and Poller.cancelledKey finally call
AbstractSelector.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64007
Remy Maucherat changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Remy Mau
10 matches
Mail list logo
