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 <[email protected]>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<[email protected]>
For additional commands, e-mail: [email protected]
--
Ing. Sergio Boso
Mail:
Cell:
Web:
Linkedin:
Skype:
[email protected] <mailto:[email protected]>
+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: [email protected]
For additional commands, e-mail: [email protected]
