I was doing some load testing against a WebSocket to measure the message latency between a publisher (presenter) and subscriber (participant). Below is the structure of my test plan. The "Setup" TG is a setUp thread group to make sure that both publisher and subscriber are connected to the WebSocket before starting the communication to measure the latency.
I had a JSR223 PostProcessor to cache the connection for publisher and subscriber accordingly so that they can pick up the same connection in the following thread groups. 3 messages were sent out from the publisher correctly. However, not sure why the read sampler in the subscriber (ParticipantA) Thread Group did not capture any message even after I increased the timeout to 20s.
Here is the JSR223 PostProcessor for caching the connection:
def participantAConnection = sampler.threadLocalCachedConnection
props.put('participantAConnection' + ctx.getThreadNum(), participantAConnection.get())
Here is the JSR223 PreProcessor for restoring the connection in the Participant Thread Group.
def participantAConnection = props.get('participantAConnection' + ctx.getThreadNum())
sampler.threadLocalCachedConnection.set(participantAConnection)
I can see the properties for the cached connection for the presenter and participant in the debug sampler.
participantAConnection0=eu.luminis.websocket.WebSocketClient#1b510239
presenterConnection0=eu.luminis.websocket.WebSocketClient#755f44c9
The debug log was enabled below:
2022-07-13 01:06:49,666 DEBUG e.l.j.w.SingleReadWebSocketSampler: I/O Error in sampler 'participantACommandsRead'.
java.net.SocketTimeoutException: Read timed out
at sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:280) ~[?:?]
at sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:306) ~[?:?]
at sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:347) ~[?:?]
at sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:800) ~[?:?]
at java.net.Socket$SocketInputStream.read(Socket.java:966) ~[?:?]
at sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478) ~[?:?]
at sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472) ~[?:?]
at sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70) ~[?:?]
at sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455) ~[?:?]
at sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059) ~[?:?]
at java.io.BufferedInputStream.fill(BufferedInputStream.java:244) ~[?:?]
at java.io.BufferedInputStream.read(BufferedInputStream.java:263) ~[?:?]
at eu.luminis.websocket.Frame.parseFrame(Frame.java:61) ~[jmeter-websocket-samplers-1.2.8.jar:?]
at eu.luminis.websocket.WebSocketClient.receiveFrame(WebSocketClient.java:420) ~[jmeter-websocket-samplers-1.2.8.jar:?]
at eu.luminis.jmeter.wssampler.WebsocketSampler.readFrame(WebsocketSampler.java:306) ~[jmeter-websocket-samplers-1.2.8.jar:?]
at eu.luminis.jmeter.wssampler.SingleReadWebSocketSampler.readFrame(SingleReadWebSocketSampler.java:83) ~[jmeter-websocket-samplers-1.2.8.jar:?]
at eu.luminis.jmeter.wssampler.SingleReadWebSocketSampler.doSample(SingleReadWebSocketSampler.java:71) ~[jmeter-websocket-samplers-1.2.8.jar:?]
at eu.luminis.jmeter.wssampler.WebsocketSampler.sample(WebsocketSampler.java:169) ~[jmeter-websocket-samplers-1.2.8.jar:?]
at org.apache.jmeter.threads.JMeterThread.doSampling(JMeterThread.java:651) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:570) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:501) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:268) ~[ApacheJMeter_core.jar:5.5]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
Your approach seems to be okayish, the question why you're getting timeouts is different.
Try to put publisher and subscriber samplers into a single Thread Group and see if this works for you
If it does most probably there is an errors somewhere, but we cannot state where without seeing your full test plan, full code or at least jmeter.log file with debug logging enabled for (at least) WebSocket Samplers. This line needs to be added to log4j2.xml file:
<Logger name="eu.luminis" level="debug" />
Related
After the response time is set too small, check the result tree and display read time out,But not all fail, some don't show read time out.
There is no problem with the server returning the result. It should be the problem of jmeter, please help me analyze.
jmeter log:
2022-03-01 15:25:22,959 DEBUG o.a.j.p.h.s.HTTPHC4Impl: Sent 314 bytes
2022-03-01 15:25:23,011 DEBUG o.a.j.p.h.s.HTTPHC4Impl: IOException
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method) ~[?:1.8.0_131]
at java.net.SocketInputStream.socketRead(Unknown Source) ~[?:1.8.0_131]
at java.net.SocketInputStream.read(Unknown Source) ~[?:1.8.0_131]
at java.net.SocketInputStream.read(Unknown Source) ~[?:1.8.0_131]
at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137) ~[httpcore-4.4.13.jar:4.4.13]
at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153) ~[httpcore-4.4.13.jar:4.4.13]
at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:280) ~[httpcore-4.4.13.jar:4.4.13]
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138) ~[httpclient-4.5.13.jar:4.5.13]
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) ~[httpclient-4.5.13.jar:4.5.13]
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) ~[httpcore-4.4.13.jar:4.4.13]
at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163) ~[httpcore-4.4.13.jar:4.4.13]
at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157) ~[httpclient-4.5.13.jar:4.5.13]
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) ~[httpcore-4.4.13.jar:4.4.13]
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) ~[httpcore-4.4.13.jar:4.4.13]
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272) ~[httpclient-4.5.13.jar:4.5.13]
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186) ~[httpclient-4.5.13.jar:4.5.13]
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) ~[httpclient-4.5.13.jar:4.5.13]
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) ~[httpclient-4.5.13.jar:4.5.13]
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) ~[httpclient-4.5.13.jar:4.5.13]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) ~[httpclient-4.5.13.jar:4.5.13]
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:935) ~[ApacheJMeter_http.jar:5.4.3-SNAPSHOT]
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:646) [ApacheJMeter_http.jar:5.4.3-SNAPSHOT]
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:66) [ApacheJMeter_http.jar:5.4.3-SNAPSHOT]
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1296) [ApacheJMeter_http.jar:5.4.3-SNAPSHOT]
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1285) [ApacheJMeter_http.jar:5.4.3-SNAPSHOT]
at org.apache.jmeter.threads.JMeterThread.doSampling(JMeterThread.java:638) [ApacheJMeter_core.jar:5.4.3]
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:558) [ApacheJMeter_core.jar:5.4.3]
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:489) [ApacheJMeter_core.jar:5.4.3]
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:256) [ApacheJMeter_core.jar:5.4.3]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_131]
As per SocketTimeoutException description:
Signals that a timeout has occurred on a socket read or accept.
You're expecting JMeter to get the response in 50 milliseconds or less, if the server fails to respond fully in 50 milliseconds - you will get this error.
If you're absolutely sure that your server responds in less than 50 milliseconds be aware that there are also connect time and latency
As per JMeter Glossary:
Elapsed time. JMeter measures the elapsed time from just before sending the request to just after the last response has been received. JMeter does not include the time needed to render the response, nor does JMeter process any client code, for example Javascript.
So there are following operations involved:
JMeter connects to the server
JMeter sends the request
Server prepares the response
Server sends the response to the server
JMeter receives first byte of the response
JMeter receives last byte of the response
And "Response timeout" means full end-to-end sequence.
If you don't want to see this error either increase the timeout or use Duration Assertion instead, in that case JMeter will wait for the full response to arrive and only then will assert whether the response time exceeds the anticipated value
We are getting the Caused by: java.io.InterruptedIOException: timeout exception in the logs from the server. However, the server is not giving the response code to us.
I am looking for the standard practice for the timeout monitoring to be followed in Splunk or Appdynamics to plot the graph for number of timeouts being received per second.
Shall we add the error code like 408 in the exception at client side or we should plot the graph for on basis of text "timeout" count with over the time.
Exception Logs
java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at lambdainternal.LambdaRTEntry.main(LambdaRTEntry.java:150)
Caused by: java.io.InterruptedIOException: timeout
at okhttp3.internal.connection.Transmitter.timeoutExit(Transmitter.kt:104)
at okhttp3.internal.connection.Transmitter.maybeReleaseConnection(Transmitter.kt:293)
at okhttp3.internal.connection.Transmitter.noMoreExchanges(Transmitter.kt:257)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:192)
at okhttp3.RealCall.execute(RealCall.kt:66)
For AppDynamics the ideal solution would be for a "bad error code" to be returned from the server - this would cause an error to be detected (and mark any associated Business Transaction as being in error) - see https://docs.appdynamics.com/22.2/en/application-monitoring/troubleshooting-applications/errors-and-exceptions#ErrorsandExceptions-BusinessTransactionError
Else you can use Custom Error Configuration to set a logger which signals errors - see https://docs.appdynamics.com/22.2/en/application-monitoring/configure-instrumentation/error-detection#ErrorDetection-ErrorDetectionConfiguration
Else you can capture values using a Data Collector and then use these in Analytics to break out errors - see https://docs.appdynamics.com/22.2/en/application-monitoring/configure-instrumentation/data-collectors + https://docs.appdynamics.com/22.2/en/analytics/configure-analytics/collect-transaction-analytics-data
Here I use Parallel Controller but the Parallel Controller2 and Parallel Controller3 don't run and throw error in logs. The Parallel Controller1 is inside Transaction Controller. The Parallel Controller2 and Parallel Controller3 are inside Simple Controller.
Here is the error log for Controller2
2021-08-24 17:51:48,819 ERROR o.a.j.t.JMeterThread: Error while processing sampler: 'bzm - Parallel Controller2'.
java.lang.RuntimeException: Attempting to reset the thread context
at org.apache.jmeter.testelement.AbstractTestElement.setThreadContext(AbstractTestElement.java:579) ~[ApacheJMeter_core.jar:5.4.1]
at org.apache.jmeter.threads.JMeterThread.doSampling(JMeterThread.java:623) ~[ApacheJMeter_core.jar:5.4.1]
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:558) ~[ApacheJMeter_core.jar:5.4.1]
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:489) [ApacheJMeter_core.jar:5.4.1]
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:256) [ApacheJMeter_core.jar:5.4.1]
at com.blazemeter.jmeter.controller.JMeterThreadParallel.run(JMeterThreadParallel.java:61) [jmeter-parallel-0.11.jar:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) [?:1.8.0_211]
at java.util.concurrent.FutureTask.run(Unknown Source) [?:1.8.0_211]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:1.8.0_211]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:1.8.0_211]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_211]
How is it possible to execute the calls in parallel inside another parallel controller?
I don't think it's supported, moreover it's not clear what you're trying to achieve by this.
As per documentation Parallel Controller executes its children in parallel so instead of going for nested constructions you can just place everything under a single Parallel Controller.
If you need to mimic a parallel call which in its turn triggers another parallel calls, however I don't think the use case is valid, you can reach out to the plugin developers and/or maintainers at jmeter-plugins support forum
In the meantime you can use JSR223 Test Elements to kick off the parallel requests as per your network requests pattern using JSR223 Test Elements and Groovy language like it's described in the How to Load Test AJAX/XHR Enabled Sites With JMeter article
Elastic search server doesn't start on a new node. It fails with the following error :
[2019-06-27T00:16:01,471][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [node-10] fatal error in thread [main], exiting
java.lang.ExceptionInInitializerError: null
at java.lang.Class.forName0(Native Method) ~[?:1.8.0_212]
at java.lang.Class.forName(Class.java:348) ~[?:1.8.0_212]
at org.elasticsearch.painless.Definition.addStruct(Definition.java:753) ~[?:?]
at org.elasticsearch.painless.Definition.<init>(Definition.java:566) ~[?:?]
at org.elasticsearch.painless.PainlessScriptEngine.<init>(PainlessScriptEngine.java:106) ~[?:?]
at org.elasticsearch.painless.PainlessPlugin.getScriptEngine(PainlessPlugin.java:59) ~[?:?]
at org.elasticsearch.script.ScriptModule.<init>(ScriptModule.java:69) ~[elasticsearch-6.2.2.jar:6.2.2]
at org.elasticsearch.node.Node.<init>(Node.java:327) ~[elasticsearch-6.2.2.jar:6.2.2]
at org.elasticsearch.node.Node.<init>(Node.java:246) ~[elasticsearch-6.2.2.jar:6.2.2]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:213) ~[elasticsearch-6.2.2.jar:6.2.2]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:213) ~[elasticsearch-6.2.2.jar:6.2.2]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:323) ~[elasticsearch-6.2.2.jar:6.2.2]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:121) ~[elasticsearch-6.2.2.jar:6.2.2]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:112) ~[elasticsearch-6.2.2.jar:6.2.2]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86) ~[elasticsearch-6.2.2.jar:6.2.2]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:124) ~[elasticsearch-cli-6.2.2.jar:6.2.2]
at org.elasticsearch.cli.Command.main(Command.java:90) ~[elasticsearch-cli-6.2.2.jar:6.2.2]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:92) ~[elasticsearch-6.2.2.jar:6.2.2]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:85) ~[elasticsearch-6.2.2.jar:6.2.2]
Caused by: java.lang.ArrayIndexOutOfBoundsException: 4
at java.time.chrono.JapaneseEra.<clinit>(JapaneseEra.java:179) ~[?:1.8.0_212]
... 19 more
I have a 5-node cluster running in production already in GCP. Since the load has increased, I tried to add few more nodes to that cluster. To create new nodes, I used "Create similar" option provided by GCP. I updated all configurations like node name and deleted the /var/lib/elasticsearch/nodes folder and tried to start the ES server on the new node. But it always fails with the error mentioned above.
This node uses OpenJDK 1.8. I enabled trace log for root logger, but couldn't identify what's wrong with the new node.
Please help in identifying what's the root cause of this problem.
Theory explanation:
public class ArrayIndexOutOfBoundsException extends IndexOutOfBoundsException
Thrown to indicate that an array has been accessed with an illegal index. The index is either negative or greater than or equal to the size of the array.
How to avoid:
Always remember that array is zero-based index, the first element is at 0th index and the last element is at length - 1 index.
So accessing the first element will give you the
java.lang.ArrayIndexOutOfBoundsException : 0 error in Java.
In your case it is a Caused by: java.lang.ArrayIndexOutOfBoundsException: 4
You should always pay to one-off errors while looping over an array in Java. The programmer often makes mistakes which result in either missing first or last element of the array by messing 1st element or finishing just before the last element by incorrectly using the <, >,> >= or <= operator in for loops.
Give special attention to the start and end condition of the loop.
Put some if-else blocks in code.
Here I have reproduced your error:
I am getting the below error.Kindly help
[8/8/14 21:14:56:939 GMT-08:00] 00000005 TimeoutManage I WTRN0006W: Transaction 00000147B92EFAE20000000100000012DF462C9E681BA3670A44A25FE1B0F6182303FB5C00000147B92EFAE20000000100000012DF462C9E681BA3670A44A25FE1B0F6182303FB5C00000001 has timed out after 120 seconds.
[8/8/14 21:14:56:967 GMT-08:00] 00000006 TimeoutManage I WTRN0124I: When the timeout occurred the thread with which the transaction is, or was most recently, associated was Thread[WMQJCAResourceAdapter : 4,5,main]. The stack trace of this thread when the timeout occurred was:
java.net.SocketOutputStream.socketWrite0(Native Method)
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:103)
java.net.SocketOutputStream.write(SocketOutputStream.java:147)
com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection.send(RemoteTCPConnection.java:1212)
com.ibm.mq.jmqi.remote.internal.system.RemoteConnection.sendTSH(RemoteConnection.java:2289)
com.ibm.mq.jmqi.remote.internal.RemoteHconn.sendTSH(RemoteHconn.java:954)
com.ibm.mq.jmqi.remote.internal.RemoteFAP.jmqiPut(RemoteFAP.java:5443)
com.ibm.mq.jmqi.remote.internal.RemoteFAP.MQPUT(RemoteFAP.java:5205)
com.ibm.msg.client.wmq.v6.base.internal.MQSESSION.MQPUT(MQSESSION.java:1252)
com.ibm.msg.client.wmq.v6.base.internal.MQQueue.putMsg2(MQQueue.java:2090)
com.ibm.msg.client.wmq.v6.jms.internal.MQMessageProducer.sendInternal(MQMessageProducer.java:1262)
com.ibm.msg.client.wmq.v6.jms.internal.MQMessageProducer.send(MQMessageProducer.java:768)
com.ibm.msg.client.wmq.v6.jms.internal.MQMessageProducer.send(MQMessageProducer.java:2713)
com.ibm.msg.client.jms.internal.JmsMessageProducerImpl.sendMessage(JmsMessageProducerImpl.java:872)
com.ibm.msg.client.jms.internal.JmsMessageProducerImpl.send_(JmsMessageProducerImpl.java:727)
com.ibm.msg.client.jms.internal.JmsMessageProducerImpl.send(JmsMessageProducerImpl.java:398)
com.ibm.mq.jms.MQMessageProducer.send(MQMessageProducer.java:281)
com.ibm.ejs.jms.JMSQueueSenderHandle.send(JMSQueueSenderHandle.java:204)
com.scb.sts.stsappserver.sender.MessageSender.sendRecords(Unknown Source)
com.scb.sts.services.PCSPPaymentSplitter.doExecute(Unknown Source)
com.scb.sts.stsappserver.eventhandler.SplitterEventHandler.handleEvent(Unknown Source)
com.scb.sts.services.PCSPPaymentReceiver.doProcess(Unknown Source)
com.scb.sts.services.PCSPPaymentReceiver.doExecute(Unknown Source)
com.scb.sts.controllers.OCWSServlet.doPost(Unknown Source)
com.scb.sts.qlcomm.QLCommBean.processXMLFile(Unknown Source)
com.scb.sts.qlcomm.QLCommBean.isDoOutput(Unknown Source)
com.scb.sts.qlcomm.QLCommBean.onMessage(Unknown Source)
com.ibm.ejs.container.MessageEndpointHandler.invokeMdbMethod(MessageEndpointHandler.java:1093)
com.ibm.ejs.container.MessageEndpointHandler.invoke(MessageEndpointHandler.java:778)
$Proxy32.onMessage(Unknown Source)
com.ibm.mq.connector.inbound.MessageEndpointWrapper.onMessage(MessageEndpointWrapper.java:131)
com.ibm.mq.jms.MQSession$FacadeMessageListener.onMessage(MQSession.java:147)
com.ibm.msg.client.jms.internal.JmsSessionImpl.run(JmsSessionImpl.java:2557)
com.ibm.mq.jms.MQSession.run(MQSession.java:860)
com.ibm.mq.connector.inbound.WorkImpl.run(WorkImpl.java:172)
com.ibm.ejs.j2c.work.WorkProxy.run(WorkProxy.java:399)
com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1604)
The transaction timeout simply means that the transaction not was committed before the timeout expired, in this case 120s elapsed without a commit.
The stack shows that you're in the onMessage() function of an MDB named QLCommBean. And that this MDB was sending some messages via MessageSender.sendRecords(), which in turn was called the MQ JMS API:
JMSQueueSenderHandle.send()
The top of the stack is:
java.net.SocketOutputStream.socketWrite0(Native Method)
This means that the active code within the MDB at the time of the transaction timeout, was a socket write (sending data over the network). In this case MQ was sending a message to the queue manager.
The transaction timeout itself is not a bug. You need to review the MDB logic and determine if 120s is an appropriate amount of time to be in the MDB. If it isn't, I suggest you add logging to your MDB to find out what it was doing for 120s. It may be that the MQ code has used up a lot of this time, but it may not be. The stack shown is just where the code happened to be 120s after onMessage() was invoked.
As MQ in the process of sending data over the network to the queue manager, you may want to look at your network to see if its performing adequately, or possibly your queue manager. It might be heavily loaded.
If this occurs regularly, one good option is to take a number of javacores over the course of the 120s. You can then see what the stack was at various points.
Otherwise I suggest:
1) Instrument your MDB, make sure you know which code was executed, and at what time. Only this will rule out your MDB logic.
2) Consider your network
3) Possibly trace your queue manager & the MQ JMS code - you may need IBM's help to determine if the time taken by the IBM code is appropriate
4) If 120s is an acceptable length of time for onMessage(), consider increasing the transaction timeout value to a value greater than the maximum time you consider to be acceptable for onMessage().