18 Mar
2011
18 Mar
'11
10:31 a.m.
Hello all,
although I cannot judge all of the arguments, having the possibility of a web-display of a
log of chosen logging-categories (in the existing logging infrastructure please!) would be
something immensely useful.
There are very commonly too-long-running requests and offering a developer or even
advanced user display of the request process would really really be useful and safer, you
never know if it was a communication failure or a true failure.
I would recommend to make such an "application" be enabled to "start
anytime to hook on a category" (without thinking of storing) and to "stop on
keyword".
paul
Le 18 mars 2011 à 09:39, Vincent Massol a écrit :
Hi,
Right now logs go to a file on the filesystem. However this is not right since most logs
are application logs and should be visible to wiki developers. For ex, if I use a
deprecated API, I need to see it. It shouldn't go to admins only and shouldn't
"pollute" the system logs.
Hence I believe we need a Log Console available somewhere (we could make it avail in the
Admin UI FTM).
I'd like to discuss an implementation idea I've had this morning:
* Send application logs as Observation Events and make the available in the Activity
Stream (AS)
Pros:
* Infrastructure already in place
* Fits the AS goal: temporary information and is purged regularly
* (Of course the Activity gadget would not display them)
* They can be sent remotely as remote events in the future; this allows implementing a
remote console to monitor an XE or XEM from a distance
Cons:
* We need to assess the performance risk and more generally we need to make the AS
scalable (I don't think it is now).
* 2 ideas for scaling up the Observation/AS:
1) Have the Observation Manager save events to be notified into a Queue and have one or
several separate threads take those events and send them to listeners. Right now if one
listener takes time in its onEvent() method it slows down the whole chain since they are
called serially. Note that if we want even better scalability, the Queue could be stored
externally to XWiki (a JMS queue for ex) and scalability can be achieved by app server
instances listening to this queue to process it.
2) Have a way to tell the AS what storage to use for specific Event Types. For example
the AS could use an in-memory storage for Log Events while using a DB storage for other
events. This would be useful since I don't think we really need to store logs in the
DB. Note that the cache could be indexed on the message so only one instance of each log
message is preserved (no need for dups), possibly with a counter to mention how many of
them there were (that's an optimization).
I believe 2) might be enough for performances in a first implementation of the log
console.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs