I'm stupid, there's no need to relate it to the AS. The AS can simply ignore those events and we can have a separate listener to receive them....
-Vincent On Mar 18, 2011, at 9:39 AM, Vincent Massol wrote: > 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
