https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
--- Comment #13 from Volker Kleinschmidt ---
Well, this actually WAS a valid bug - it got re-filed and fixed as
https://issues.apache.org/bugzilla/show_bug.cgi?id=55267
I'm just wondering why they're not linked together.
--
You are receiv
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
--- Comment #12 from Mark Thomas ---
Something is setting the timeout to 30 minutes and that something isn't Tomcat.
If Tomcat was using the wrong / old timeout then that would be a Tomcat bug but
I don't see any evidence of that here.
-
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
--- Comment #11 from Pavel ---
I've discovered a strange behavior - even though I set a timeout of 20 sec on
the connector (in server.xml), sometimes it gets here:
att.awaitWriteLatch(writeTimeout,TimeUnit.MILLISECONDS);
With the timeout
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
Mark Thomas changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
--- Comment #9 from Pavel ---
I did a heap dump - and discovered 2 things:
1. timeout is normal (setting to 30 minutes in atmosphere and it's the same in
the locked thread)
2. the nio connection is an HTTPS
I haven't tested https in my l
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
--- Comment #8 from Mark Thomas ---
If you can take a thread dump then you should be able to take a heap dump as
well. You can then load the heap dump into a profiler and take a look at the
current value of the timeout. Knowing the timeout
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
--- Comment #7 from Pavel ---
See this new dump - I'm also seeing gzip in the stacktrace - maybe it's
contributing to the problem.
"CleanResourceTask" id=81 idx=0x154 tid=220556 prio=5 alive, interrupted,
blocked, native_blocked, daemon
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
--- Comment #6 from Pavel ---
Missed that question :)
I'm not sure how can I check the timeout for one of the locked threads... (I
can't reproduce it locally)
I did check the timeout for atmosphere threads and it looks normal (uses the
ti
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
--- Comment #5 from Mark Thomas ---
It is good to know that Atmosphere doesn't appear to change the timeout but the
question I asked was for one of these blocked threads can you see what the
timeout has actually been set to? If the timeout
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
--- Comment #4 from Pavel ---
I debugged and I don't see that Atmosphere rewrites the timeout.
As to the client going away - how do I check this? That's what I was suspecting
at the beginning but I'm not sure how to reproduce.
The whole
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
--- Comment #3 from Mark Thomas ---
Any way you can debug the instance to see that the timeout has been set to?
I'll have another look at the code and see if I can spot any possible code
paths that could lead to a much longer delay.
Is it
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
--- Comment #2 from Pavel ---
here is my connection config:
As you can see it has a timeout of 20 sec - so I'm not sure how it can lock for
hours.
--
You are receiving this mail because:
You are the assignee for the bug.
-
https://issues.apache.org/bugzilla/show_bug.cgi?id=55144
Mark Thomas changed:
What|Removed |Added
Status|NEW |NEEDINFO
OS|
13 matches
Mail list logo