We experienced what might be state being saved in nikita between requests recently. After an exception was thrown due to a bad payload, the returned description was being used in a later request. It is difficult to recreate this issue, but if there is a problem, it is the type of problem that only begins to manifest itself when testing under load. The chances of this being a JVM issue or hardware issue is not something I am willing to entertain, so I assume this is a nikita thing.

We examined the code to see if there was an obvious culprit. The description is stored in NoarkDeserializer in:

protected StringBuilder errors = new StringBuilder();

A StringBuilder is not thread safe, but nikita doesn't access data across threads, so I was never concerned with that. I always assumed Jackson created a new instance of the deserializer object for each deserialisation operation of a request. Therefore, I assumed a class variable was safe to use.

I found it difficult to find documentation that confirms that a new instance is created per request, so I asked a chatbot. The chatbot gave me a run around on the topic, so I don't have a clear answer.

I am left thinking that there may or may not be a potential issue that state can exist between requests, if a thread is reused or perhaps if spring is using a pool of deserialisers.

We can try to mitigate a potential problem by making the errors variable a method variable and pass it around where it is needed. Then I am making a change that I am unsure if it is necessary. We haven't experienced this problem before and I cannot recreate it.

So, we can do the following. a) ignore the problem and hope it doesn't come back, b) make a fix to the code to fix a potential issue that may or may not be there.

I think we should be pro-active and go for b).

Thomas