https://bz.apache.org/bugzilla/show_bug.cgi?id=57779
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=57779
--- Comment #8 from bock.mich...@telekom.de ---
This is custom async code written on top of servlet 2.5.
We're now switched the http-connector to Http11NioProtocol. In a first try the
lock didn't occur anymore.
--
You are receiving this mail
https://bz.apache.org/bugzilla/show_bug.cgi?id=57779
--- Comment #7 from Mark Thomas ---
Are you using Servlet 3 async processing at all? Or is this all custom async
code written on top of - effectively - servlet 2.5?
--
You are receiving this mail because:
You are the assignee for the bug.
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=57779
--- Comment #6 from bock.mich...@telekom.de ---
We lock the servlet thread with our own lock, which is normally released by the
worker thread as soon as the output is processed.
But this case the worker thread has no chance to release the lock,
https://bz.apache.org/bugzilla/show_bug.cgi?id=57779
--- Comment #5 from Remy Maucherat ---
In your trace the deadlock is caused by the lock on <0xc3b273b8> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) but it
only appears once in your stack, we don't see where
https://bz.apache.org/bugzilla/show_bug.cgi?id=57779
--- Comment #4 from bock.mich...@telekom.de ---
We must block the servlet thread to wait for the output from the other thread
to be completed.
In consequence to the changes in 7.0.54 it is generally not possible anymore to
use a separate thread
https://bz.apache.org/bugzilla/show_bug.cgi?id=57779
--- Comment #3 from Remy Maucherat ---
Ok, but your: parking to wait for <0xc3b273b8> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
does not seem to be related to Tomcat.
The lock on the socket is unavoidab
https://bz.apache.org/bugzilla/show_bug.cgi?id=57779
--- Comment #2 from bock.mich...@telekom.de ---
We are not using the tomcat non blocking io. We simply hand over the
ServletOutputStream to another thread. Here are the complete stacktraces:
"http-bio-25030-exec-10" daemon prio=10 tid=0x00
https://bz.apache.org/bugzilla/show_bug.cgi?id=57779
--- Comment #1 from Mark Thomas ---
Full stack traces of both threads please.
As an aside, using the blocking IO connector with the non-blocking API is
pointless. Depending on what the stack traces show, this may end up as WONTFIX.
--
You ar
