#172 Premature EOF encountered

[James Farrier]

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?

[Philip Aston]

Bug 3206627 has duplicate symptoms.

[Philip Aston]

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.

[Philip Aston]

Here's a debug patch against 3.4. Please add it to the start of the classpath used to start the agent. It will print out length data for each response to stderr.

[Philip Aston]

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.

[Steven Swart]

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!

[Philip Aston]

Steven's second scenario

[Philip Aston]

[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.

[Ravi Joshi]

I too found "Premature EOF encountered" once but it was human mistake. I forgot to close all the brackets in one of a header section.