I encountered a degenerate EJB QL call that timed out after 5 minutes with the following message to the JBoss 4.2.2 console:
During the time of the failed SQL call, the CPU is running hot 50-80% "user". When I hit the server again, it pegs the CPU as "system".
Subsequently I killed Eclipse, JBoss, and the browser I was running the client in. The CPU is still running 50% "system" hot, caused by the mysqld - actually ~ 130% on my two core system.
Is there a good way to soft-reset this process? Is this a flaw in the JConnector for JBoss/mysql? Is this expected behavior?!
Bill Shirley - bshirley - frazerbilt.com
if (Posts < 30) you.read( JavaRanchFAQ);
hari haran sethu raman
Joined: Nov 10, 2008
Did you get the solution for this problem?
I am struggling to a similar issue.
Joined: Sep 12, 2009
I am also facing the same issue, can anyone help me out..
Joined: Mar 05, 2008
Well you are seeing several things happening here. Though first of all, it's unlikely there are problems with MySQLs JConnector and JBoss. It's invariably closer to home you need to start looking.
I always find the JBoss Transactions team KnowledgeBase Wiki a good start. Then the JBoss Transactions User forum as the next port of call. Finally the JIRA bugs database.
Your EJB is invoking EJB QL that is creating a very large result set. Possbily a http://en.wikipedia.org/wiki/Cartesian_product. This will typically cause the database to pin the CPU which you are seeing.
If your really want to prove to yourself there isn't a problem with JBoss/JConnector/MySQL then try running the statement manually. Do this by changing Entity Manager configuration in persistence.xml to show SQL statements. Run the EJB to display the SQL statement. Take the statement and run it using the command line mysql application and look at the CPU usage graph.
The message you are seeing indicates the duration for processing the sql query is too long. The transaction manager monitors the duration of EJB calls and time's out the transaction allocated to the EJB. This is expected and normal behaviour of the Transaction Manager.
What isn't normal behaviour is the duration of the EJB QL.
Can you explain what you EJB is doing ?
Also, include the EJB QL in you explanation.