Finding that for normal GET requests (REST API transactions) which don't return any of the relevant cache-control/expires (or Last-Modified) headers, Jmeter seems to cache the request and use it on subsequent transactions. The headers returned with the JSON are: HTTP/1.1 200 Content-Type: application/json;charset=UTF-8 Content-Length: 1321 Date: Tue, 10 Nov 2020 22:03:36 GMT Vary: Accept-Encoding Content-Encoding: gzip Connection: keep-alive Both Firefox and Chrome will go ahead and send the GET transaction to the server, but with JMeter the 2nd and subsequent transaction with the same path is not fired (it does pass control to the pre-processor). This bug does not reproduce with JMeter 3.2 but does with 5.2.1 and 5.3
Yes, it seems, that we are a bit too heavy on the caching side and cache all results, that have no explicit caching related header. Will look into this next week.
Created attachment 37567 [details] Simple test plan to test the cache manager with different headers in responses
@Vinod, could you test the next nigthly or trunk build (https://jmeter.apache.org/nightly.html) and report back, whether the issue is solved for you? commit 589511cf254b894353494546b82df6f45a6e1066 AuthorDate: Mon Nov 16 13:22:57 2020 +0100 JMeter Cache Manager misbehaving when "Use Cache-Control/Expires header" is checked Don't store http responses in the cache, if they have no caching related headers. Bugzilla Id: 64915 --- .../jmeter/protocol/http/control/CacheManager.java | 21 ++++++++++++---- .../http/control/TestCacheManagerBase.java | 12 ++++++++++ .../protocol/http/control/TestCacheManagerHC4.java | 24 ++++++++++++++++--- .../control/TestCacheManagerUrlConnection.java | 6 +++++ .../control/TestCacheManagerUrlConnectionBase.java | 28 +++++++++++++++------- xdocs/changes.xml | 1 + 6 files changed, 76 insertions(+), 16 deletions(-)
Yes, @Felix, happy to test a nightly build. Thanks for quick attempted fix for this issue. I see 1911 presently available. Once 1912 or better is available, I will download and test and update post with what I find. If 1911 already contains your change and I don't need to wait for 1912, just let me know.
The 1912 should the next nightly with the changes. If you want to, you can take the build from trunk https://builds.apache.org/job/JMeter/job/JMeter-trunk/ which should be the same and contains the patch already.
Confirmed that the changes provided in nightly build 1912 fixes this issue. Thanks!
Thanks for reporting, checking and the good description of the problem, that made it easy to replicate the issue.
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/5430