Bug 51918 - GZIP compressed traffic produces errors, when multiple connections allowed
Summary: GZIP compressed traffic produces errors, when multiple connections allowed
Status: RESOLVED FIXED
Alias: None
Product: JMeter - Now in Github
Classification: Unclassified
Component: Main (show other bugs)
Version: 2.5
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks: 51919
  Show dependency tree
 
Reported: 2011-09-29 15:48 UTC by Kai Mattern
Modified: 2011-10-02 05:53 UTC (History)
0 users



Attachments
Fix to issue (1.02 KB, patch)
2011-09-29 21:32 UTC, Philippe Mouawad
Details | Diff
readBuffer local in readResponse() (1.75 KB, patch)
2011-10-01 07:23 UTC, Milamber
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kai Mattern 2011-09-29 15:48:35 UTC
We are testing against a Glassfish App connected to an Apache Server via mod_jk. SSL is in place.

Tests against the server are as expected until we enable mod_deflate on the server. Afterwards we completely randomly get error response when collecting the page fragments.

It seems that the gzipper is not able to decompress the http response. We just see the error (in the http response window in the "View Result Tree" report):

java.io.IOException: Corrupt GZIP trailer
	at java.util.zip.GZIPInputStream.readTrailer(GZIPInputStream.java:203)
	at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:94)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
	at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
	at java.io.FilterInputStream.read(FilterInputStream.java:90)
	at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1541)
	at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:236)
	at org.apache.jmeter.protocol.http.sampler.HTTPJavaImpl.readResponse(HTTPJavaImpl.java:286)
	at org.apache.jmeter.protocol.http.sampler.HTTPJavaImpl.sample(HTTPJavaImpl.java:518)
	at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
	at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:1674)
	at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase$ASyncSample.call(HTTPSamplerBase.java:1659)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)

No further notice in the jmeter.log.

Original setting:
- 10 Threads with the option to open 5 sub connections
- 3-4 sec think time
- 50 repeats
- Client HTTP 3.1

We tried to play with the settings until we knew that the only thing that stops the error is to deny the sub connections.

It kind of seems that something connected to the gzip decompression of the resonse stumbles from time to time. The error seems to be completely random. Somtimes neatly distributed, sometimes packed at so time in the test - sometimes a lot - sometimes only one error. But never in the main request - always in a sub request.

I can provide the test-script if needed and give out some further details about the apache config, if needed.
Comment 1 Kai Mattern 2011-09-29 15:50:34 UTC
One quick remark: When manually querying the page in question via Firefox, there never is a broken response.
Comment 2 Philippe Mouawad 2011-09-29 21:32:33 UTC
Created attachment 27637 [details]
Fix to issue

Hello,
Patch synchronizes methods that modify CookieManager content.


Regards
Philippe
Comment 3 Sebb 2011-09-30 23:05:19 UTC
Isn't this the same as Bug 51919?

If so, the workround is to disable concurrent downloads.
Comment 4 Milamber 2011-10-01 07:23:51 UTC
Created attachment 27653 [details]
readBuffer local in readResponse()

the readResponse() in HTTPSampleBase isn't thread safe because there iss this line:
byte[] readBuffer = getThreadContext().getReadBuffer();

The getReadBuffer() (from JMeterContext) is:
A temporary buffer that can be shared between samplers in a thread.

I thinks that it isn't necessary to have a temp share buffer?

I purpose to use a local readBuffer at each call method (patch)
Comment 5 Sebb 2011-10-01 09:42:55 UTC
(In reply to comment #4)
> Created attachment 27653 [details]
> readBuffer local in readResponse()
> 
> the readResponse() in HTTPSampleBase isn't thread safe because there iss this
> line:
> byte[] readBuffer = getThreadContext().getReadBuffer();
> 
> The getReadBuffer() (from JMeterContext) is:
> A temporary buffer that can be shared between samplers in a thread.
> 
> I thinks that it isn't necessary to have a temp share buffer?

It was only there to save recreating it for each sample.

> I purpose to use a local readBuffer at each call method (patch)

Agreed.

In the meantime, the work-round is to avoid using concurrent downloads entirely.

As far as I can tell, all such downloads are potentially affected.
Comment 6 Philippe Mouawad 2011-10-01 13:07:35 UTC
(In reply to comment #3)
> Isn't this the same as Bug 51919?
> 
> If so, the workround is to disable concurrent downloads.

It was a manipulation error
Comment 7 Philippe Mouawad 2011-10-01 13:18:44 UTC
Also agree with Milamber patch
Comment 8 Milamber 2011-10-02 05:53:29 UTC
Fixed. 

URL: http://svn.apache.org/viewvc?rev=1178129&view=rev
Log:
Bug 51918 - GZIP compressed traffic produces errors, when multiple connections allowed

Modified:
    jakarta/jmeter/trunk/src/core/org/apache/jmeter/threads/JMeterContext.java
    jakarta/jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
    jakarta/jmeter/trunk/xdocs/changes.xml
Comment 9 The ASF infrastructure team 2022-09-24 20:37:47 UTC
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2569