Change Queue on to Deque in InMemoryRequestJournalStore

[pks-1981]

Change Queue on to Deque in InMemoryRequestJournalStore and ServeEvent

#2296

Submitter checklist

• 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

[pks-1981]

@tomakehurst @oleg-nenashev
please look MR how it will be possible

[oleg-nenashev]

I would definitely more confident about such a change if we had some performance test to prove impact when recording the journal and in the getter. My gut feeling is that it is a positive improvement, so I am +1 for trying it out in the beta

[pks-1981]

@tomakehurst @oleg-nenashev
MR finished. please look how it will be possible.

[tomakehurst]

I think this will be a breaking change for a lot of folks. How about we modify AbstractRequestJournal.getRequestsMatching(...) to reverse the results so that they'll come back in the same order as previously.

[pks-1981]

@tomakehurst
But we will return to what we left...
Breaking changes it's normal when update version IMHO...
And as a user, I'm waiting in "history" for more recent entries to be at the top...

[tomakehurst]

I mean reverse the result of the find query rather than the whole list, which would have a pretty trivial impact by comparison and only affect finding vs. fetching the whole journal.

Agree it's in principle acceptable to create breaking changes, but this one is avoidable and my instinct is that it'll annoy people.

[pks-1981]

@tomakehurst
Something like that:

    List<LoggedRequest> loggedRequests = getRequests().filter(thatMatch(requestPattern, customMatchers)).collect(toList());
    Collections.reverse(loggedRequests);
    return loggedRequests;

?

[tomakehurst]

Thanks!