The trace suggests that JMeter is trying to download embedded resources within the SSL page - perhaps try switching this off, in case this nested sample is causing the problem?
S. On 21 Oct 2004 18:00:39 -0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > <http://issues.apache.org/bugzilla/show_bug.cgi?id=31832>. > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND > INSERTED IN THE BUG DATABASE. > > http://issues.apache.org/bugzilla/show_bug.cgi?id=31832 > > HTTPS seems to randomly lock during handshake > > Summary: HTTPS seems to randomly lock during handshake > Product: JMeter > Version: 2.0.1 > Platform: Sun > OS/Version: Windows NT/2K > Status: NEW > Severity: Normal > Priority: Other > Component: Main > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > Hello, > > I am trying to put some load on an HTTPS server, but jmeter threads keep > blocking during the HTTPS handshake. If i launch eg ten threads, they will all > start issuing requests successfully but after a while they all (one by one) get > stuck. > > A thread dump of one blocked thread: > > "Thread Group1-14" prio=7 tid=0x02ea1b68 nid=0x566c runnable > [0x2dd9f000..0x2dd9f9e4] > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.read(SocketInputStream.java:129) > at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:284) > at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:319) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:720) > - locked <0x1f38a930> (a java.lang.Object) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:102 > 5) > - locked <0x1f38a938> (a java.lang.Object) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1038) > at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:405) > at > sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHtt > psURLConnection.java:170) > at > com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl.connect(HttpsURLCon > nectionOldImpl.java:122) > at > org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:467) > at > org.apache.jmeter.protocol.http.sampler.HTTPSampler.downloadPageResources(HTTPSampler.jav > a:736) > at > org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:580) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:585) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:573) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) > at java.lang.Thread.run(Thread.java:595) > > These blocked threads also eat up resources (https connections) at the server > side. They are only released if jmeter is stopped. > > I have seen this behavior with both JDK 1.4 and 1.5. I realise this might be a > JDK (SSL) bug, but i wonder if anybody else working with jmeter has seen this > problem. Is using a different SSL provider the way to go ? > > Regards, > Koen. > > Jmeter: 2.1 > JDK 1.5/1.4 > Server: jboss 3.2.3 (tomcat) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
