18 Mar
2011
18 Mar
'11
10:10 a.m.
On Mar 18, 2011, at 10:01 AM, Thomas Mortagne wrote:
On Fri, Mar 18, 2011 at 09:46, Vincent Massol
<vincent(a)massol.net> wrote:
Yes i know but it's nice from an architecture POV to do it at this level rather than
*hope* that all listeners (including those not coded by us) will be good citizens.
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....
Yes can be a special tool for that.
-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.
IMO if a listener takes time in its onEvent() it can always do that
message queue itself, that's what Lucene plugin do for example. We
dono't absolutely need to implement that in Observation Manager. Also
you can't do that for all events since some of them are
question/answer events or event responsible for setting and unsetting
the contexte before and after a task for example.
Yes although I think I'd prefer to slowly move them to send events instead of logging
and have the logging be done in the listener (ie turn the logic upside down).
I'm not 100% sure though, needs some more thoughts.
> 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?
Make the default org.xwiki.component.logging.Logger take care of
producing theses events so that it support already existing log and
makes it easier for a component than having to do that using
Observation Manager. +1 for the general idea
Thanks
-Vincent