You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Sergio Boso <se...@bosoconsulting.it> on 2013/03/25 14:08:34 UTC

Jmeter stuck with bad application error management

Hi I'm experiencing a weird behaviour  in Jmeter.

As the application has its own burden of problems, it returns sockets error fro time to time.
The point is that Jmeter, instead of recording the error and going on the next sample, gets stuck there forever (no time out is 
applied).
I can stop it manually, reset it and restart it.

Here is the error stack after manually stopping.
have you ever experienced such a behaviour?
Is this already known?

Java the error stack follows

Thank you in advance

Sergio

Java.net.SocketException: socket closed
     at java.net.SocketInputStream.socketRead0(Native Method)
     at java.net.SocketInputStream.read(Unknown Source)
     at java.net.SocketInputStream.read(Unknown Source)
     at sun.security.ssl.InputRecord.readFully(Unknown Source)
     at sun.security.ssl.InputRecord.read(Unknown Source)
     at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
     at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
     at sun.security.ssl.AppInputStream.read(Unknown Source)
     at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
     at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
     at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
     at org.apache.http.impl.io.ChunkedInputStream.getChunkSize(ChunkedInputStream.java:251)
     at org.apache.http.impl.io.ChunkedInputStream.nextChunk(ChunkedInputStream.java:209)
     at org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:171)
     at org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:201)
     at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:155)
     at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1649)
     at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:235)
     at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:300)
     at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
     at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.downloadPageResources(HTTPSamplerBase.java:1207)
     at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.resultProcessing(HTTPSamplerBase.java:1500)
     at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.resultProcessing(HTTPAbstractImpl.java:251)
     at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:358)
     at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
     at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1088)
     at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1077)
     at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:428)
     at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:256)
     at java.lang.Thread.run(Unknown Source)

-- 

Ing. Sergio Boso




---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org


Re: Jmeter stuck with bad application error management

Posted by Sergio Boso <se...@bosoconsulting.it>.
Il 25/03/2013 17:06, Adrian Speteanu ha scritto:
> Hi,
>
> My understanding is that this stack trace is applicable to those
> times/situations when you use stop test instead of shutdown. Jmeter cuts
> ongoing connections and this error is logged. This error is also logged if,
> for whatever reasons, the connection is cut on server side or all
> midle-ware components (from routers to firewalls and balancers).
>
> Now, if the problem is that the application doesn't respond for a long
> time, jmeter shouldn't close that connection frankly. Tweak the server
> side. The situations where you want to keep connection up an indefinite
> period of time are very rare.
Yes, in fact it is not uncommon to see the application return a timeout, after some time, especially under heavy load.
I'm quite surprised NOT to see this behaviour here: the application stop without closing the connection.
I will try to set the timeout  (which I thought was buried in the Java low level software, but I was wrong).

My idea is that a disconnection on Jmeter side after 1-2 minutes will report an error and it will let the test go on.

Thank you for you (brilliant) support and best regards

Sergio

>
> But all modern browsers timeout connections after 1-2 min. You can use the
> connect / response timeouts fields from the HTTP Sampler to achieve this in
> JMeter as well.
>
> Log the timeout errors separately from other errors. These will increase in
> frequency as soon as you start using the timeouts on JMeter side. A high
> percentage should be a good motivator for the dev/infrastructure teams to
> start looking for a solution. But I have to say, most of the times
> timeouted connections mean poor configuration, not necessarily poor
> application, so you should look into it ASAP. There is little reason to
> continue testing until these problems are eliminated, one by one, or their
> effect is reduced as much as possible. Your end-users will get this
> behaviour as well. I doubt that 2 min of waiting (and for nothing) is
> desirable for them.
>
>
> Regards,
> Adrian S
>
>
>
> On Mon, Mar 25, 2013 at 3:08 PM, Sergio Boso <se...@bosoconsulting.it>wrote:
>
>> Hi I'm experiencing a weird behaviour  in Jmeter.
>>
>> As the application has its own burden of problems, it returns sockets
>> error fro time to time.
>> The point is that Jmeter, instead of recording the error and going on the
>> next sample, gets stuck there forever (no time out is applied).
>> I can stop it manually, reset it and restart it.
>>
>> Here is the error stack after manually stopping.
>> have you ever experienced such a behaviour?
>> Is this already known?
>>
>> Java the error stack follows
>>
>> Thank you in advance
>>
>> Sergio
>>
>> Java.net.SocketException: socket closed
>>      at java.net.SocketInputStream.**socketRead0(Native Method)
>>      at java.net.SocketInputStream.**read(Unknown Source)
>>      at java.net.SocketInputStream.**read(Unknown Source)
>>      at sun.security.ssl.InputRecord.**readFully(Unknown Source)
>>      at sun.security.ssl.InputRecord.**read(Unknown Source)
>>      at sun.security.ssl.**SSLSocketImpl.readRecord(**Unknown Source)
>>      at sun.security.ssl.**SSLSocketImpl.readDataRecord(**Unknown Source)
>>      at sun.security.ssl.**AppInputStream.read(Unknown Source)
>>      at org.apache.http.impl.io.**AbstractSessionInputBuffer.**fillBuffer(*
>> *AbstractSessionInputBuffer.**java:166)
>>      at org.apache.http.impl.io.**SocketInputBuffer.fillBuffer(**
>> SocketInputBuffer.java:90)
>>      at org.apache.http.impl.io.**AbstractSessionInputBuffer.**readLine(**
>> AbstractSessionInputBuffer.**java:281)
>>      at org.apache.http.impl.io.**ChunkedInputStream.**getChunkSize(**
>> ChunkedInputStream.java:251)
>>      at org.apache.http.impl.io.**ChunkedInputStream.nextChunk(**
>> ChunkedInputStream.java:209)
>>      at org.apache.http.impl.io.**ChunkedInputStream.read(**
>> ChunkedInputStream.java:171)
>>      at org.apache.http.impl.io.**ChunkedInputStream.read(**
>> ChunkedInputStream.java:201)
>>      at org.apache.http.conn.**EofSensorInputStream.read(**
>> EofSensorInputStream.java:155)
>>      at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerBase.**
>> readResponse(HTTPSamplerBase.**java:1649)
>>      at org.apache.jmeter.protocol.**http.sampler.HTTPAbstractImpl.**
>> readResponse(HTTPAbstractImpl.**java:235)
>>      at org.apache.jmeter.protocol.**http.sampler.HTTPHC4Impl.**
>> sample(HTTPHC4Impl.java:300)
>>      at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerProxy.**
>> sample(HTTPSamplerProxy.java:**62)
>>      at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerBase.**
>> downloadPageResources(**HTTPSamplerBase.java:1207)
>>      at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerBase.**
>> resultProcessing(**HTTPSamplerBase.java:1500)
>>      at org.apache.jmeter.protocol.**http.sampler.HTTPAbstractImpl.**
>> resultProcessing(**HTTPAbstractImpl.java:251)
>>      at org.apache.jmeter.protocol.**http.sampler.HTTPHC4Impl.**
>> sample(HTTPHC4Impl.java:358)
>>      at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerProxy.**
>> sample(HTTPSamplerProxy.java:**62)
>>      at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerBase.**
>> sample(HTTPSamplerBase.java:**1088)
>>      at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerBase.**
>> sample(HTTPSamplerBase.java:**1077)
>>      at org.apache.jmeter.threads.**JMeterThread.process_sampler(**
>> JMeterThread.java:428)
>>      at org.apache.jmeter.threads.**JMeterThread.run(JMeterThread.**
>> java:256)
>>      at java.lang.Thread.run(Unknown Source)
>>
>> --
>>
>> Ing. Sergio Boso
>>
>>
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.**apache.org<us...@jmeter.apache.org>
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>


-- 

Ing. Sergio Boso

Mail:
Cell:
Web:
Linkedin:
Skype:

	

sergio@bosoconsulting.it <ma...@bosoconsulting.it>
+39 335 7243 445
www.bosoconsulting.it <http://www.bosoconsulting.it>
http://it.linkedin.com/in/sergioboso <http://www.linkedin.com/pub/sergio-boso/1/29b/255>
sbos61




---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org


Re: Jmeter stuck with bad application error management

Posted by Adrian Speteanu <as...@gmail.com>.
Hi,

My understanding is that this stack trace is applicable to those
times/situations when you use stop test instead of shutdown. Jmeter cuts
ongoing connections and this error is logged. This error is also logged if,
for whatever reasons, the connection is cut on server side or all
midle-ware components (from routers to firewalls and balancers).

Now, if the problem is that the application doesn't respond for a long
time, jmeter shouldn't close that connection frankly. Tweak the server
side. The situations where you want to keep connection up an indefinite
period of time are very rare.

But all modern browsers timeout connections after 1-2 min. You can use the
connect / response timeouts fields from the HTTP Sampler to achieve this in
JMeter as well.

Log the timeout errors separately from other errors. These will increase in
frequency as soon as you start using the timeouts on JMeter side. A high
percentage should be a good motivator for the dev/infrastructure teams to
start looking for a solution. But I have to say, most of the times
timeouted connections mean poor configuration, not necessarily poor
application, so you should look into it ASAP. There is little reason to
continue testing until these problems are eliminated, one by one, or their
effect is reduced as much as possible. Your end-users will get this
behaviour as well. I doubt that 2 min of waiting (and for nothing) is
desirable for them.


Regards,
Adrian S



On Mon, Mar 25, 2013 at 3:08 PM, Sergio Boso <se...@bosoconsulting.it>wrote:

> Hi I'm experiencing a weird behaviour  in Jmeter.
>
> As the application has its own burden of problems, it returns sockets
> error fro time to time.
> The point is that Jmeter, instead of recording the error and going on the
> next sample, gets stuck there forever (no time out is applied).
> I can stop it manually, reset it and restart it.
>
> Here is the error stack after manually stopping.
> have you ever experienced such a behaviour?
> Is this already known?
>
> Java the error stack follows
>
> Thank you in advance
>
> Sergio
>
> Java.net.SocketException: socket closed
>     at java.net.SocketInputStream.**socketRead0(Native Method)
>     at java.net.SocketInputStream.**read(Unknown Source)
>     at java.net.SocketInputStream.**read(Unknown Source)
>     at sun.security.ssl.InputRecord.**readFully(Unknown Source)
>     at sun.security.ssl.InputRecord.**read(Unknown Source)
>     at sun.security.ssl.**SSLSocketImpl.readRecord(**Unknown Source)
>     at sun.security.ssl.**SSLSocketImpl.readDataRecord(**Unknown Source)
>     at sun.security.ssl.**AppInputStream.read(Unknown Source)
>     at org.apache.http.impl.io.**AbstractSessionInputBuffer.**fillBuffer(*
> *AbstractSessionInputBuffer.**java:166)
>     at org.apache.http.impl.io.**SocketInputBuffer.fillBuffer(**
> SocketInputBuffer.java:90)
>     at org.apache.http.impl.io.**AbstractSessionInputBuffer.**readLine(**
> AbstractSessionInputBuffer.**java:281)
>     at org.apache.http.impl.io.**ChunkedInputStream.**getChunkSize(**
> ChunkedInputStream.java:251)
>     at org.apache.http.impl.io.**ChunkedInputStream.nextChunk(**
> ChunkedInputStream.java:209)
>     at org.apache.http.impl.io.**ChunkedInputStream.read(**
> ChunkedInputStream.java:171)
>     at org.apache.http.impl.io.**ChunkedInputStream.read(**
> ChunkedInputStream.java:201)
>     at org.apache.http.conn.**EofSensorInputStream.read(**
> EofSensorInputStream.java:155)
>     at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerBase.**
> readResponse(HTTPSamplerBase.**java:1649)
>     at org.apache.jmeter.protocol.**http.sampler.HTTPAbstractImpl.**
> readResponse(HTTPAbstractImpl.**java:235)
>     at org.apache.jmeter.protocol.**http.sampler.HTTPHC4Impl.**
> sample(HTTPHC4Impl.java:300)
>     at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerProxy.**
> sample(HTTPSamplerProxy.java:**62)
>     at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerBase.**
> downloadPageResources(**HTTPSamplerBase.java:1207)
>     at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerBase.**
> resultProcessing(**HTTPSamplerBase.java:1500)
>     at org.apache.jmeter.protocol.**http.sampler.HTTPAbstractImpl.**
> resultProcessing(**HTTPAbstractImpl.java:251)
>     at org.apache.jmeter.protocol.**http.sampler.HTTPHC4Impl.**
> sample(HTTPHC4Impl.java:358)
>     at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerProxy.**
> sample(HTTPSamplerProxy.java:**62)
>     at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerBase.**
> sample(HTTPSamplerBase.java:**1088)
>     at org.apache.jmeter.protocol.**http.sampler.HTTPSamplerBase.**
> sample(HTTPSamplerBase.java:**1077)
>     at org.apache.jmeter.threads.**JMeterThread.process_sampler(**
> JMeterThread.java:428)
>     at org.apache.jmeter.threads.**JMeterThread.run(JMeterThread.**
> java:256)
>     at java.lang.Thread.run(Unknown Source)
>
> --
>
> Ing. Sergio Boso
>
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.**apache.org<us...@jmeter.apache.org>
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>