[
https://jira.jboss.org/jira/browse/JBSEAM-4480?page=com.atlassian.jira.pl...
]
Ross Mills commented on JBSEAM-4480:
------------------------------------
Our successful run was a fluke. We continued hitting concurrent conversation errors the
next time we ran it.
But it looks like we're getting to the bottom of this. Here's an update.
For some reason, from time to time, a JBoss thread would hang for about 25 seconds or so.
We're don't know why the thread would hang. But the way we had Apache/mod_jk
configured caused Apache to timeout before the JBoss thread could complete. Apache would
timeout and return an error message to the browser. However, the automated test would go
ahead and continue onto the next page. When the next request was received by JBoss, the
previous request thread was still hung and the conversation was still locked. This caused
the concurrent conversation error.
We were able to resolve this by fixing the workers.properties file in Apache. The socket
timeout was removed and keepalive was turned back on. This made Apache wait for the JBoss
thread to become unhung and complete its lifecycle and unlock the conversation.
The reason we started making changes to Apache in the first place was that we were getting
503 errors when we load tested the app. The reason for that turned out to be a typo in
the Tomcat server.xml file. I had spelled "maxThreads" as
"maxthreads". That was enough to cause Tomcat to become overwhelmed and start
refusing connections. When the typo was fixed, the 503 errors went away.
Sometimes JSF lifecycle not completing which leaves conversation in
locked state causing concurrent conversation error
----------------------------------------------------------------------------------------------------------------------
Key: JBSEAM-4480
URL:
https://jira.jboss.org/jira/browse/JBSEAM-4480
Project: Seam
Issue Type: Bug
Components: Core, JSF Integration
Affects Versions: 2.2.0.GA
Environment: Linux
Reporter: Ross Mills
Attachments: concurrent-conv-err.log, concurrent-conv-error-2.log
I have an Seam app that has a left menu on every page. When the user selects an item
from the menu, it ends the current conversation and starts a new one. However, once in a
while, I get a concurrent conversation exception. I have an automated test that does the
following:
(1) Logs the user in.
(2) 10 seconds later, the user selects an item from the left hand menu (which ends the
current conversation and begins a new one). This causes a seach form to appear.
(3) 10 seconds later, the user fills in the form and submits. The search results are
displayed.
(4) 10 seconds later, the user navigates through the search results and drills down.
(5) 10 seconds later, the user returns to step (2) by selecting the same item from the
left hand menu and repeats the above steps.
The user is able to cycle through these steps anywhere from a few seconds to several
minutes until the concurrent conversation error occurs. When the error occurs, it is when
the user attempts to submit the search form.
The logs indicate that when the search form is displayed, the JSF lifecycle is not
progressing beyond the RESTORE_VIEW phase. This causes the conversation to remain locked.
Then when the user attempts to submit the form, the new thread finds the conversation
locked and generated the concurrent conversation exception.
My company policy may not allow me to provide you with code that you can use to duplicate
the problem. But snippets of the logs can be found in the JBoss forum reference I am
including.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira