Any chance any of you can review this? It was a little bit more invasive, and I wanted to have a quick sanity check.
Quick synopsis:
new console specific ows callback created to track gwc cache hits
maintaining a concurrent hash map to correlate monitor-core request data objects and console specific data objects
monitor-console needed a place to store additional data during the request lifecycle (an alternative could be to have the monitor-core's RequestData grow the ability to hang other data generically off it)
RequestData::id is used to establish the link. Hopefully this can be counted on to be unique. In my testing it was.
I'm manually removing entries from this map after done to prevent memory leaks. Maybe a weak hash map can be used instead as a better guard? I don't understand weakhashmaps well enough to be able to say definitively here.
if we have console specific data (currently only if it was an ows request) then I include whether it was a cache hit or not at the root of the json in the serializer. On the receiving end this means that it's either present as a boolean, or not in the document at all.
I attempted to factor out the logic of determining whether a request was a hit or not so it wasn't directly in the callback. My hope was that it, or something like it could be useful in other contexts.
@jdeolive @tschaub @jmarin
Any chance any of you can review this? It was a little bit more invasive, and I wanted to have a quick sanity check.
Quick synopsis: