https://bz.apache.org/bugzilla/show_bug.cgi?id=58506
Bug ID: 58506
Summary: Timeout property on the JMS Point-to-point sampler
does get applied - results in tests running forever
Product: JMeter
Version: 2.13
Hardware: PC
Status: NEW
Severity: enhancement
Priority: P2
Component: Main
Assignee: [email protected]
Reporter: [email protected]
Component: JMS Point-to-Point sampler
Observed from the JMeter GUI on Windows 7 and when run via jmeter-maven-plugin
on Redhat 6.6. Observed in JMeter v2.13 most recently and have also noticed it
in version 2.6 in the past.
Problematic behavior:
When run in "Request Response" mode and a value is not set for "JNDI name
Receive queue" there is no effective way to deal with timeouts. If a reply
message never arrives the test thread hangs forever. Per the Stackoverflow
article linked below this sampler uses a JMS Temporary Queue to handle the
replies and does not set any timeout when waiting for those replies.
http://stackoverflow.com/questions/28609859/timeout-of-jms-point-to-point-requests-in-jmeter-does-not-result-in-an-error
https://github.com/apache/jmeter/blob/dd30d6171d031d3288c7d31da303823dccee03c2/src/protocol/jms/org/apache/jmeter/protocol/jms/sampler/JMSSampler.java#L373
Excerpt from the source linked immediately above:
if (useTemporyQueue()) {
executor = new TemporaryQueueExecutor(session, sendQueue); // Timeout
setting isn't applied!
} else {
producer = session.createSender(sendQueue);
executor = new FixedQueueExecutor(producer, getTimeoutAsInt(),
isUseReqMsgIdAsCorrelId());
}
Also, the TemporaryQueueExecutor's sendAndReceive method is given a timeout
value by the JMSSampler class BUT it doesn't use it per the source linked and
excerpted immediately below:
https://github.com/apache/jmeter/blob/5512162ec752b35378275711a9a03f4d003a664a/src/protocol/jms/org/apache/jmeter/protocol/jms/sampler/TemporaryQueueExecutor.java
@Override
public Message sendAndReceive(Message request,
int deliveryMode,
int priority,
long expiration) throws JMSException {
return requestor.request(request);
}
How to reproduce the behavior:
Create a JMS service that replies to any input message by sending a reply
message to the destination found in the request message at
"javax.jms.Message.getJMSReplyTo()". Then configure a JMeter job to use the
"JMS Point-to-Point" sampler to send messages to the request queue for that
"dummy service". Do not set the "JNDI name Receive queue" property on the
sampler. Set the timeout to 5 seconds and observe that the test works. Now
modify the service provider to not send any responses. Run the test again and
observe that it never completes.
Desired behavior:
When a reply message does not arrive within the specified timeout window that
sample should be marked as failed and the test should proceed to the next
sample. It is acceptable for this to continue to work in a blocking manner
where the next request doesn't go out until the reply arrives or (after this
fix/enhancement is applied) the timeout is hit.
The implementation of "TemporaryQueueExecutor" reuses the same temporary queue
for all requests issued by the thread and doesn't use any form of secondary
reply message correlation technique to verify that the received message is a
response to the request message. As such, when a timeout occurs the executor
needs to handle it by marking this sample as a failure, deleting the temporary
queue, creating a new temporary queue, and then allowing the next request to
proceed. Deleting the temporary queue is necessary in case the provider sends a
reply message after the timeout period; we don't want the next sample to
receive that late reply as if it were the reply to some other issued-later
request.
To implement this change you'll have to abandon the usage of JMS's
QueueRequestor since it doesn't appear to let you set a timeout.
--
You are receiving this mail because:
You are the assignee for the bug.
