[xwiki-devs] [Idea] Implementing a Log console inside XE
thomas.mortagne at xwiki.com
Fri Mar 18 09:33:05 UTC 2011
On Fri, Mar 18, 2011 at 10:22, Jerome Velociter <jerome at xwiki.com> wrote:
> On Fri, Mar 18, 2011 at 9:39 AM, Vincent Massol <vincent at massol.net> wrote:
>> 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)
>> * 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
>> * 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.
> That could be the occasion to introducte a mecanism that enables comet
> communication between the server and the client. 
> 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
>  http://en.wikipedia.org/wiki/Comet_%28programming%29
>> devs mailing list
>> devs at xwiki.org
> devs mailing list
> devs at xwiki.org
More information about the devs