It has been almost 6 weeks since we reverted our JBoss to version
4.0.3sp1 and on that server the problem hasn't returned. That seems conclusive that the problem doesn't exist in 4.0.3sp1.
We upgraded a different JBoss server from 4.2.1 to 4.2.2 about 2 weeks ago and it still has the same problems.
We also upgraded Java to 1.6.0_04 on both servers.
One other thing to add: We thought maybe load might be a cause, but the new JBoss server has very light load and still has the problem.
Anybody have any suggestions?
That looks like a mod_jk problem more than a JBossAS one.
I don't follow the logic. We have the same version of mod_jk, but it works with JBoss 4.0.3sp1, but not 4.2.2?
Or are you saying it is a mod_jk problem on the JBoss side with the AJP?
According to your problem description it seems there could be 2 problems the JVMRoute is of the sessionid is not handled by mod_jk or the sessions are not distributed between the nodes of the cluster.
Additionaly the JBossWeb used by 4.2.2-GA is affected by http://jira.jboss.com/jira/browse/JBPAPP-366.
We don't have a clustered environment. We used to have 2 JBoss servers that were load balanced, but not distributed (we don't need session replication), but like I said, we removed all that to simplify the configuration.
Most of the time, we have no problem. Then, for no observable reason, weird stuff happens. Then it is stops.
I looked at the JIRA issue, which deals with CLOSE_WAIT. Wouldn't that be more of a memory leak? I can see how over time all those connections could stack up.
If this is our problem, it would need an event that causes it. And then something that fixes it without intervention.
Lots of AJP connections stack up over time. Then they get garbage collected or cleaned up, or a JBoss service restarts to clean up the problem?
Is that what we are talking about here?
So according to your configuration and applications a user session can start in one server and go on in the other, correct?
How do you recognize session created in one server or the other? Do you use JVMRoute?
The problems caused by the CLOSE_WAIT issue don't get fixed without intervention.
Incorrect. We currently have just ONE JBoss server. When we had two, we used JvmRoute. But like I said, we don't use a second server anymore because we thought that might be the problem.
The problem is that a user session can be transfered to a different user session.
1. User logs in.
2. Adds stuff to cart.
3. Goes to checkout.
4. User becomes a different user with that person's sessionId.
5. Order is logged under wrong person.
By monitoring every single request that comes to our site, we have been able to see exactly what the users are doing.
One time, while the problem was happening, I went to our website and it gave me another users sessionId. I didn't have to log in. Somehow it got me confused and assigned me their sessionId.
Since we have gone back to 4.0.3sp1, we haven't seen it. But it appears to exist in all the 4.2.x versions.
Did you evr find a resolution for this?
No, we went back to JBoss 4.0.3sp1. Best guess, there is a problem with Tomcat 6. The JBoss versions that uses Tomcat 5.5 don't have the problem.
We might try it again if we can get management to go along now that we have upgraded to Apache 2.0.63 and mod_jk 1.2.26.
We can't stay on 4.0.3sp1 forever, but 4.2.2 is still the latest version.