Samplers such as HTTP can take a long time to return all the date. There are timeout settings, but these apply to each network message, not the overall sample. Once the sampler has completed, the duration assertion can be used to flag overlong samples, but this could take a very long time. Rather than update every sampler and its GUI to support an extra timeout option, it is possible to use the Interruptible.interrupt() method in a Timer. Timers run before the sampler to which they apply, so they can schedule a future task to invoke the interrupt() method on the sampler. The following is a very basic BeanShell Timer implementation: ==== cut here ===== import java.util.concurrent.Executors; sampler=ctx.getCurrentSampler(); run=new Runnable() { public void run() { sampler.interrupt(); } }; tpool = Executors.newScheduledThreadPool(1); // schedule the interrupt to occur in 5 seconds from now tpool.schedule(run, 5L, java.util.concurrent.TimeUnit.SECONDS); return 0; // don't actually wait ===== cut here ===== It would be useful to have a built-in Timer to perform the same function.
URL: http://svn.apache.org/r1698393 Log: Add interrupt Timer Bugzilla Id: 58299 Added: jmeter/trunk/src/components/org/apache/jmeter/timers/InterruptTimer.java (with props) jmeter/trunk/src/components/org/apache/jmeter/timers/gui/InterruptTimerGui.java (with props) jmeter/trunk/xdocs/images/screenshots/timers/interrupt_timer.png (with props) Modified: jmeter/trunk/bin/saveservice.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties jmeter/trunk/xdocs/changes.xml jmeter/trunk/xdocs/usermanual/component_reference.xml
URL: http://svn.apache.org/r1698403 Log: Add French localization for the new Interrupt timer (and littel alphabetical ordering in the keys) Bugzilla Id: 58299 Modified: jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
When I test the new Interrupt timer, I have the message on stdout: MEvent. CASE! and this on the sampler response: java.net.SocketException: Socket closed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at sun.security.ssl.InputRecord.readFully(InputRecord.java:442) at sun.security.ssl.InputRecord.read(InputRecord.java:480) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:436) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.open(MeasuringConnectionManager.java:107) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:643) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:521) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:329) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.followRedirects(HTTPSamplerBase.java:1518) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.resultProcessing(HTTPSamplerBase.java:1599) at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.resultProcessing(HTTPAbstractImpl.java:463) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:408) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1147) at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1136) at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:434) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:261) at java.lang.Thread.run(Thread.java:745) None to think that is the Interrupt timer in action? Normal?
I do not see the same problem. However running as non-GUI did show that the executor threads need to be daemon URL: http://svn.apache.org/r1698462 Log: Add interrupt Timer Ensure threads are created as daemons Add some extra debug info Bugzilla Id: 58299 Modified: jmeter/trunk/src/components/org/apache/jmeter/timers/InterruptTimer.java Can you provide a sample JMX that shows the issue?
Created attachment 33053 [details] Sample Test case Here the sample test
I see what you mean now; the response does contain the stack trace. Yes, that is expected when the request is aborted. The same would happen when stopping the test. BTW OpenJDK reports "MEvent. CASE!" sometimes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679036 There is a minor problem with the implementation: if the timeout is set too short, it may fail to cancel the first HTTP sample. That is because the sampler can take a while to initialise itself. The timer can expire before the sample itself is started, so interrupt() does nothing. A work-round is to add a dummy HTTP request (without timeout) in a setUp group to do the init. Handling one-off init is probably best addressed in a separate issue, as it would be better if the first sample time were more accurate.
Work on this was moved to a separate branch. The code was reworked to use a Pre-Processor instead. See Bug 58736
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/3659