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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
