This message was deleted.

Does this fail reliably i.e. same number of times, same position in run each time or is it random?

Random

WireMock doesn’t do a great job of reporting the full error here. I suggest setting a breakpoint on

MatchesXPathPattern:124

and doing a “run until failure”, then you should be able to see the underlying exception that’s causing this.

Hi Tom. I debugged as you suggest and underlying exception was "Prefix must resolve to a namespace" that means namespace using in xPath expression is not found in xPathNamespaces I set in mapping file. But it must be found as you can see from example above. During debug I found that sometimes namespace context of the xPath object is changing by another thread, because of using InheritableThreadLocal as a cache for xPath. I changed it to simple ThreadLocal and errors desappeared. I created a PR with this change, could you please consider to merge it? https://github.com/wiremock/wiremock/pull/2618 Thank you.

I’m happy to merge this, although I’m troubled that this should be the fix. I can’t see how the inheritance mechanism should make any difference. In your debugging, did you see which thread the namespaces were being set vs. used in?

Difference - one thread is running in

XmlDocument:57

(evaluating xPath expression) and another thread (e.g. child) is setting another namespace context in

XmlDocument:54

. I attached screenshots from debugging where you can see that prefixResolver somehow changing whet it's just passing into constructor without a change. Prefix resolver is an attribute of xPath object.

Maybe I’m misunderstanding something, but that’s the same thread in both screenshots isn’t it?

Yes it's the same thread. I wanted to show this mystical change. Below there are screenshots from different threads where you can see that threads are using one xPath object and setting different namespace context into it.