Capture QueryString and POST payload on http requests

[bkbonner]

To troubleshoot the performance of servers, it is desirable to capture the query string and POST payload (body) on HTTP requests.

I think issue #429 was asking for something similar, but I'd like to reiterate and have some discussion around it. We've been using JavaMelody for awhile, and if we're pointed in the right direction, we might be able to provide a pull request for such an enhancement.

It feels like a many-to-many relationship between the URL path and this data, and I don't know the full details of how JavaMelody stores the information, but I'll dig into it, unless there are glaring issues that someone can bring to my attention.

Thank you.

[evernat]

Sorry, but javamelody does not store every http request parameters and payloads and in fact, javamelody does not store every http events either, but just statistics. Only for http parameters, the volume of data stored would be multiplied by a thousand or by a million depending on the webapp's usage. So http parameters are only displayed in the "Current requests".
This choice is the deal for a negligeable overhead. How could it be otherwise?

What could possibly be done is to store and display the last 100 "slow" http hits with date/time, request and parameters, like the last 100 http errors. Http hits would be "slow" only when their duration was greater than some global threshold (for example, 2 * standard deviation of the latest global request computed in the Collector.collectCounterData method for the http counter).

[kortov]

@evernat what about POST payload for current requests? Is is working now or it's not implemented due memory usage of payload?

[evernat]

@kortov POST payload is not read by javamelody.
It would be possible, but memory usage of payload could be an issue, for multipart (upload) requests and for other POST requests. And it would not be easy to have a suitable place to display it in the current requests (it would need a popup perhaps). Moreover it's not absolutely needed to display that in the current requests. I think that it is less a priority than displaying the last 100 "slow" http hits for example.