[ grinder-Bugs-3202566 ] Premature EOF encountered

Bugs item #3202566, was opened at 2011-03-08 04:31
Message generated for change (Comment added) made by philipa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=118598&aid=3202566&group_id=18598

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Plugin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: James Farrier (jamesfarrier)
Assigned to: Philip Aston (philipa)
Summary: Premature EOF encountered

Initial Comment:
I realize there are atleast two other of these issues detailed here.  My one however follows a different parttern.  I don't receive the following:HTTPClient.StreamDemultiplexor.retry_requests(StreamDemultiplexor.java:5 
26) 

Instead my stack trace looks like this:
8/03/11 3:03:29 AM (thread 6 run 0 test 302): Aborted run due to Java exception calling TestRunner
Java exception calling TestRunner
	File "C:\grinder\.\WorkbookS2.py", line 477, in page3
	File "C:\grinder\.\WorkbookS2.py", line 894, in __call__
	File "c:\grinder\grinder.py", line 27, in __call__
Caused by: java.io.EOFException: Premature EOF encountered
	at HTTPClient.StreamDemultiplexor.read(StreamDemultiplexor.java:300)
	at HTTPClient.RespInputStream.read(RespInputStream.java:155)
	at HTTPClient.HTTPResponse.readResponseData(HTTPResponse.java:1011)
	at HTTPClient.HTTPResponse.getData(HTTPResponse.java:515)

Does anyone know what might have cause this exception to be thrown?

----------------------------------------------------------------------

>Comment By: Philip Aston (philipa)
Date: 2011-06-04 17:25

Message:
[Discussion from grinder-development list].

Steven,

The stack traces in your attachment indicate a "Premature EOF" during a
different part of the HTTP protocol to your original report. Consequently,
the diagnostic patch does not add any useful information.

However, together with the low level of similar reports, this second
symptom makes me confident that the problem is not due to a bug in the
HTTPClient library used by The Grinder. Rather, there is something
"upstream" from The Grinder that is occasionally terminating HTTP
connections. This might be anything, e.g. the server process, something in
the network, the client or server O/S, firewall, ...

Interestingly, HTTP allows for two different ways to specify the number of
bytes in a response body. The first is for the server to provide the length
up-front in the response header. This was happening in your original
scenario, and the error was occurring because the server said it was going
to deliver X bytes, but the connection was closed before The Grinder had
received that many. To support scenarios where the server doesn't know how
many bytes its going to send (useful because it avoids the need to buffer
large responses, for example) HTTP 1.1 added another way: "chunked
transfer". In this case, the response is made up of several parts, with the
server saying "Here's a chunk of X bytes, [data follows], here's a chunk of
Y bytes, [data], ..., we're done". In your second scenario, the connection
is closed when The Grinder is expecting a new chunk.

I know this doesn't help too much with your testing.

I'll add this discussion, and your attachment to the bug. Please continue
discussion there. (To add an attachment, first log in, then use the "Add a
file" link. Its a little hard to see, but its there).

- Phil




On 30/05/11 18:32, Steven Swart wrote:
> Hi Philip!
>
> With reference to the following bug:
>
>
https://sourceforge.net/tracker/?func=detail&atid=118598&aid=3202566&group_id=18598
>
> I have encountered a similar problem on my test run
> today. I was running one agent with a hundred worker
> threads against my application. I hit the 'Premature
> EOF encountered' error again. My test did not complete,
> I aborted it as soon as I encountered the errors. Please
> see attached file for details. It contains the std err output
> from that patch you uploaded, my Grinder test script,
> and the complete output logs etc from my agent.
>
> Here is the id string for my webserver:
>
> Apache/2.0.63 (Unix) DAV/2 mod_perl/2.0.0 Perl/v5.8.4 Server at
> www.test.lan Port 80
>
> We are also using FastCGI.
>
> Sorry for posting this here, but I was unable to figure
> out how to upload an attachment to this bug.
>
> I hope this helps...
>
> Regards,
> S.


----------------------------------------------------------------------

Comment By: Steven Swart (stevenswart)
Date: 2011-05-03 16:38

Message:
Hi Philip!

I have spent most of the day trying to reproduce this error. Unfortunately
the server against which my tests were originally triggering this error has
been decommissioned, and I don't have access to software version
information. I have run the distributed version of grinder.jar against our
software on all of our servers which run Apache, which include a FreeBSD 8
box, a Centos 5 box and a Solaris 10 box. None of these tests reproduced
the exception. I didn't even get a chance to try the patch, there was no
point. I will keep an eye out and if I ever encounter this error again, I
will apply the patch and attach the resultant logs to this issue. Sorry I
couldn't be more help!

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2011-03-21 21:17

Message:
Patch attached - please use it to diagnose in conjunction with an HTTP
trace (perhaps taken using the tcpproxy) to determine whether the server is
sending the correct content length.

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2011-03-21 19:33

Message:
This code path occurs if the server has returned a response with a
Content-Length header, and then proceeded to close the response stream
before fully transmitting a body of the specified number of bytes.

I suspect that this is a server issue, rather than a problem with The
Grinder or the HTTPClient library. I'll produce a debug patch to allow us
to diagnose this a little further.

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2011-03-21 19:29

Message:
Bug 3206627 has duplicate symptoms.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=118598&aid=3202566&group_id=18598

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2