[ 
https://issues.apache.org/jira/browse/SLING-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15127961#comment-15127961
 ] 

Chetan Mehrotra commented on SLING-5459:
----------------------------------------

bq. But allowing every user to create the logs might not be the best thing 
either. Not sure

This feature is disabled by default and need to enabled via OSGi config. So its 
expected that its enabled for debugging purpose for some time. I can add a 
health check which can issue failure if it is left enabled. Would that be fine

bq. I'm not happy about adding a dependency to Guava Cache. We have Sling Cache 
or maybe could use a simple solution, like we do elsewhere where simply the 
last N entries are kept

The logs generated in trace might be large and would hog the memory. Guava has 
good support for sizing the cache by memory size and also supports timed 
eviction. So tracer makes use of that and expires the cached entries after 10 
mins if they are not accessed. Would try to embed cache related classes and see 
how it work out via [Conditional 
Package|http://njbartlett.name/2014/05/26/static-linking.html]

> Recording of tracer logs
> ------------------------
>
>                 Key: SLING-5459
>                 URL: https://issues.apache.org/jira/browse/SLING-5459
>             Project: Sling
>          Issue Type: New Feature
>          Components: Extensions
>            Reporter: Chetan Mehrotra
>            Assignee: Chetan Mehrotra
>             Fix For: Log Tracer 1.0.0
>
>         Attachments: SLING-5459-v1.patch, tracer-recording.json
>
>
> Sling Log Tracer currently provides support for fine grained control of 
> enabling logs for specific request. To make this log more accessible it would 
> be useful to have a feature where the client can also fetch the logs from 
> specific request over HTTP.
> This feature would work like below
> # Client sends an HTTP request with header {{Sling-Tracer-Record​}}  set to 
> true
> {noformat}
> curl -D - -u admin:admin \
>   -H "Sling-Tracer-Record : true" \
>  -d "./jcr:content/jcr:title=Summer Collection" \
>  -d ":name=summer-collection" \
>  -d "./jcr:primaryType=sling:Folder" \
>  -d "./jcr:content/jcr:primaryType=nt:unstructured" \
>  -d "tracers=oak-writes" \
>  http://localhost:4802/content/dam/
> {noformat}
> # Server includes a request id as part of {{Sling-Tracer-Request-Id}} 
> response headers
> {noformat}
> HTTP/1.1 201 Created
> Date: Wed, 27 Jan 2016 07:30:22 GMT
> Sling-Tracer-Request-Id: 9b5b01f6-f269-47c3-a889-2dc8d4d7938f
> X-Content-Type-Options: nosniff
> X-Frame-Options: SAMEORIGIN
> Location: /content/dam/summer-collection
> Content-Type: text/html; charset=UTF-8
> Transfer-Encoding: chunked
> {noformat}
> # The logs in json format can then be fetched like 
> http://localhost:4802/system/console/tracer/9b5b01f6-f269-47c3-a889-2dc8d4d7938f.json
>  (see [attached output|^tracer-recording.json]. it includes following data 
> for now. It can be extended as per need
> ## RequestProgressTracker logs
> ## JCR Queries made
> Key points
> # Request id is randomly generated
> # The access to request log is via Web Console Plugin servlet hence its only 
> accessible to admin user account
> # The request data would only be recorded for those request which have the 
> {{​Sling-Tracer-Record}} header set. The data would be kept in memory for 
> *some time* with the assumption that client would fetch it soon. After some 
> time the data would expire
> # This feature would need to explicitly enabled via config option
> # The feature is somewhat similar to 'Recent Request' support. However it 
> exposes a JSON rendition and only keeps the data for request where client 
> requested that. 
> # For this feature dependency is added for Guava Cache to make use of space 
> bound/expiring cache. We can to an extent use {{LinkedHashMap}} but given 
> that Guava is now being used in Sling for Oak it makes sense to make use of 
> its feature. If required can look into embedding minimum required set



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to