https://bz.apache.org/bugzilla/show_bug.cgi?id=58506
Philippe Mouawad <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |om --- Comment #3 from Philippe Mouawad <[email protected]> --- (In reply to Gordon Daugherty from comment #1) > Here's an alternative solution that preserves the configuration interface > but significantly changes the test's behavior: > > When no "JNDI name Receive queue" is provided create a single temporary > queue and internally use that queue name for that field. > > This way the execution behavior would always be asynchronous with requests > going out at a consistent rate regardless of how fast the replies are coming > back. This has the advantage of avoiding the "Coordinated Omission" problem > (search "Gil Tene Coordinated Omission" if you're not familiar with that > concept). This solution keeps the configuration interface simple. The > downside is that people that were using the TemporaryQueueExecutor approach > would see new behavior when they upgrade; these more-accurate results are > likely to show worse peformance numbers so we'd get some questions when > people do that upgrade. (In reply to Gordon Daugherty from comment #0) > 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); > } Just to be sure there is no confusion, expiration here is not a timeout in processing of message. It's an expiration of the message. > > > 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.
