Do not return null objects in getAll of the InMemoryRequestJournalStore

[coder-hugo]

Under heavy load it's possible that serveEvents.get() is called with an UUID that doesn't exist anymore in the Map. The reason for this is that the spliatator (required for stream()) of the ConcurrentLinkedDeque is weakly consistent. This means that it's not guaranteed that an element that is currently processed in a Stream still exists in the collection. So under heavy load it may happen, that one thread reads an element of the ConcurrentLinkedDeque. Then this thread gets paused and another thread gets activated which than completely runs the remove method of the InMemoryRequestJournalStore. Now the first thread gets activated again and calls the get method of the serveEvents with an UUID that doesn't exist anymore in the Map which results in a null value. As the remaining code doesn't expect null values in the Stream they should be filtered out. Another solution would be to synchronize the code of the InMemoryRequestJournalStore but this would slow down the whole thing dramatically.

I haven't added any tests for this as it's hard to reproduce a concurrency issue.

References

• Wiremock server sometimes responds with 500 when log limit is set #2447

Submitter checklist

• Recommended: Join WireMock Slack to get any help in #help-contributing or a project-specific channel like #wiremock-java
• Recommended: If you participate in Hacktoberfest 2023, make sure you're signed up there and in the WireMock form
• The PR request is well described and justified, including the body and the references
• The PR title represents the desired changelog entry
• The repository's code style is followed (see the contributing guide)
• Test coverage that demonstrates that the change works as expected
• For new features, there's necessary documentation in this pull request or in a subsequent PR to wiremock.org

[tomakehurst]

Despite the lack of tests (which I agree are hard to reliably do) I think this looks safe to merge.