How to disable the RegEx pattern cache?

[harrysun2006]

Hey Alex,

I'm just wondering is there a way to disable the RegEx pattern cache from command line? In my project, I need to response different payloads based on the request payload (url and headers are same). So I defined a few rules (request/response) with different RegEx pattern in post field and I noticed that the matching is tried on rules in natural order before any such rules are cached. However, after one rule is cached, the matching will be tried on potential matched rules first, this cause some inconsistency issue.
For example, I defined four rules below (pseudo code):

- description: rule1
   request:
      method: PUT
      url: service_endpoint
      post: regex1
   response:
      file: response1.json

- description: rule2
   request:
      method: PUT
      url: service_endpoint
      post: regex2
   response:
      file: response2.json

- description: rule3
   request:
      method: PUT
      url: service_endpoint
      post: regex3
   response:
      file: response3.json

And then I make a few requests with different payload (matching to the regular expressions). If the payload in first request only matches to rule3, then regex3 will be cached. And in a following request, when the payload matches to both rule1 and rule3, I was expecting rule1 gets matched and response1.json is picked.

It would be great if there is a way to turn off such RegEx pattern cache. Please let me know your thoughts on it.

Thanks,
Harry

[azagniotov]

Hi Harry,

For context:

There are two caches in stubby4j:

1. RegexPatternCache
2. StubHttpLifecycleCache

The RegexPatternCache is used by RegexParser class only to cache Java's compiled Pattern objects, not the regex matches. This is to avoid recompiling Pattern object for the same regex string when doing incoming HTTP request matching to stubs. For example, if there are repeated requests to the same stub within a small timeframe, there is no need to compile the same Pattern object over and over again

The StubHttpLifecycleCache is the one that maybe causing you headache. This cache is used in StubRepository (see StubRepository#matchStub). This cache caches matched stubs by the URL of the incoming request AFTER the incoming request was successfully matched to a stub.

If there is a repeated request for the same URL and the above cache contains a stub for this URL, then this cached stub (in the code the variable's name is cachedMatchCandidate) is evaluated first of all before all other stubs (this stub's stubbed properties evaluated for the equality against this new incoming request).

If the cached stub was not matched to the incoming request (even though that their URLs are equal), the incoming request is matched to all other stubs in their natural defined order.

[azagniotov]

I tried to reproduce the issue you are experiencing in the following PR #176 (see the stubs.yaml and the stubby4jIssue170 test case.

I made sure that the behavior of stubby4j is as expected and the test stubby4jIssue170 passes when the cache is disabled. I will disable the stub cache until I revisit this so that it would not be causing any issues.

[azagniotov]

Harry, I got to this sooner than I anticipated: version v7.1.3 has been pushed to Maven Central. So, you can skip the v7.1.2

[harrysun2006]

Hi Alex,
Thanks for the detailed explanation. Now I understand it's the StubHttpLifecycleCache which causes some issues in my test because I have stubs sharing same URL and method.
I will do some test with v7.1.3 and let you know the results.
Cheers,
Harry

[azagniotov]

Great, Harry. Looking forward to hear about the results and if there are any other issues

[harrysun2006]

It's tested and working well in v7.1.3. I can see now the first matched rule is always picked up even when some other rules (with same URL and method) were cached from earlier matches.
Great job. Thanks Alex 👍

[azagniotov]

Awesome!

[azagniotov]

Harry, just for the sake of clarity I wanted to mention that in v7.1.3 the StubHttpLifecycleCache is completely disabled.

I do have a PR outstanding to bring it back #179 where I am caching stubs not just by a URI, but by the hashCode of the incoming request, but I am not going to rush to merge it in as I want to perform more testing

[harrysun2006]

Hey Alex, I noticed that there was no stub matched from caches any more during my test with v7.1.3. I totally agree with you that StubHttpLifecycleCache based on URL + method + hash of request as cache key would be good enough.

[azagniotov]

Hi Harry, just FYI I release v7.2.0 to Maven just now. The changes are https://github.com/azagniotov/stubby4j/blob/master/CHANGELOG.md#720 I did not observe any issues when doing automated and manual testing, so I hope things will be as smooth for you as now.

[harrysun2006]

Hi Alex, I will do some text when v7.2.0 is available on mvnrepository and get back to you with my test results. Have a good weekend.

[azagniotov]

It is on Maven Central now: https://search.maven.org/search?q=g:io.github.azagniotov%20AND%20a:stubby4j

Have a great weekend too!

[harrysun2006]

Tested with version v7.2.0 jar, it's all good now. Thanks Alex! 😄

[azagniotov]

Nice! Thanks for letting me know!

[azagniotov]

@harrysun2006 apologies for reusing this ticket, but just FYI, new feature: https://github.com/azagniotov/stubby4j#request-proxying

[harrysun2006]

Hey Alex, no need to apologise and thank you for letting me know. It's a nice new feature that will be helpful in many scenarios.