On Fri, Mar 18, 2011 at 10:22, Jerome Velociter <[email protected]> wrote: > On Fri, Mar 18, 2011 at 9:39 AM, Vincent Massol <[email protected]> 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? > > That could be the occasion to introducte a mecanism that enables comet > communication between the server and the client. [1] > > This way logs could be displayed live, without having to refresh the > UI every now and then. > > Note that the comet communication is likely something that the > extension manager UI could leverage too (to display installation > progress for example)
Yep that's planned ;) I was thinking of it mostly for question/answer from the install/uninstall handlers and later install/uninstall scripts. > > Jerome > > [1] http://en.wikipedia.org/wiki/Comet_%28programming%29 > >> >> 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 > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
