Hi Andrea,
On 18 March 2016 at 10:22, Andrea Aime <andrea.a...@geo-solutions.it> wrote:
> Hi Robert,
> sorry for the late reply, busy times, could not answer right away and then
> lost it in the build
> server failures storm that we have been into lately
>
No worries, I completely understand :)
>> - Alter the Request class to make it settable
>>
>> Roger that... maybe with a system variable too? Like we would not want a
> malicious user to pass the right header in a server that's not fronted by
> something else
> setting the x-request-id
>
Yes.
>
>> - Set it in a custom early Dispatcher init() callback from the header
>> if present -- it would miss some of the request parsing but that's not the
>> end of the world.
>>
>> Or the dispatcher itself could do it.
>
> One small extra note, it could also be useful to have also have the
> request id in the response header, so that
> if I have a problematic request in the client, I can go and look for the
> id and then grep the logs for just the log
> lines pertaining to it.
>
Well, if it's generally useful I could simplify the approach a bit:
- Add a global config option with a header to look at for inbound
requests (ie. X-Request-ID or whatever). For Geoserver instances without a
reverse proxy generating UUIDs sitting in front, they would just create a
UUID for each request like precent.
- *Always* add the request ID to the logging/monitor/sql contexts (and
pass it through to WPS/etc as discussed below), and have the Dispatcher set
it up initially.
- *Always* return the request ID as a response header (either using the
configured header name, or defaulting to GeoServer-Request-ID).
Always returning a header would add 60 bytes (using the above name) to
every response... how do people feel about that?
*Personally* I think OGC service responses are verbose enough that it'd be
unlikely to make any difference to users, and the ability to trace requests
and debug issues quickly and effectively massively trumps that overhead.
But most admins won't use it most of the time, so I'm interested in others
views. We could always make it disable-able if only a few admins might want
to optimise and are prepared to run with a custom applicationContext config.
Presumably changing the default behaviour and adding a new config setting
would need a GSIP?
>> - Add it to the logging MDC context in the same custom callback
>>
>> MDC... ? Ah:
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html
>
Yeah... I'm a little fuzzy on exactly which logging system GeoServer uses
(I don't spend enough time in Java), but the docs says it uses
java.util.logging but has log4j underneath (so MDC is available)? slf4j
looks like it wraps MDC for java.util.logging (
http://www.slf4j.org/api/org/slf4j/MDC.html) and that seems to be in the
POMs too... so I think I should be able to get it working somehow ¯\_(ツ)_/¯
>> 1. Obvious flaws? Am I missing an easier approach?
>>
>
> You should also create a ThreadLocalTransfer object so that the request id
> gets preserved for requests triggering action
> inside a thread pool, e.g., asynchronous WPS requests
>
Sounds good, I hadn't thought about WPS. From my quick reading of the
docs/code:
- &request=Execute will start processing, and creates an ExecutionID
- If the RequestID from the Execute request is attached to the
background processing via ThreadLocalTransfer & potentially via the
Hazelcast clustering, logs/etc can keep being associated with the initial
Execute user request if that's useful
- For Async requests any Dismiss/Status/Result requests require the
ExecutionID to be passed in. They'll each have their own RequestIDs as well.
- WPS ExecutionIDs should probably be put into the MDC/monitor/SQL/etc
contexts too if users want to track/log/use them for similar reasons.
Thinking further, it would also be good to pass request IDs to any upstream
cascaded WFS/WMS servers too, continuing the goal that a single end-user
request can be traced/followed as far as possible. Though I haven't looked
at *how* yet :)
Cheers,
Rob :)
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
