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.
One quick remark: When manually querying the page in question via Firefox, there never is a broken response.
Created attachment 27637 [details] Fix to issue Hello, Patch synchronizes methods that modify CookieManager content. Regards Philippe
Isn't this the same as Bug 51919? If so, the workround is to disable concurrent downloads.
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)
(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.
(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
Also agree with Milamber patch
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
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2569