[11:27:20 CST(-0600)] <jwennmacher1> EricDalquist: Good morning. Drew suggested I contact you about working on some statistics reporting.
[11:28:25 CST(-0600)] <EricDalquist> hi
[11:28:27 CST(-0600)] <EricDalquist> awesome
[11:29:21 CST(-0600)] <jwennmacher1> I am at a very early stage; I was just glancing at the statistics that are being collected right now. Initial observation is there are two sets currently collected not being reported on. Portlet/folder added/deleted/removed from layout. I was thinking maybe of starting with one of those (probably portlet). Thoughts?
[11:30:10 CST(-0600)] <EricDalquist> well, let me do a little overview of the whole stats/aggregation/reporting system
[11:30:51 CST(-0600)] <EricDalquist> opening up uPortal source just a minute ....
[11:33:09 CST(-0600)] <EricDalquist> so forgive me if you're familiar with parts of this already but I figure a full picture is good
[11:33:32 CST(-0600)] <EricDalquist> uportal uses an extension of the spring application context event apis
[11:33:38 CST(-0600)] <jwennmacher1> yep
[11:33:56 CST(-0600)] <EricDalquist> one of the event handlers sticks the events onto a concurrent queue
[11:34:08 CST(-0600)] <EricDalquist> and a background thread periodically flushes them out to the db via JpaPortalEventStore
[11:34:16 CST(-0600)] <EricDalquist> these are what we call raw events
[11:34:21 CST(-0600)] <EricDalquist> and are actually stored as JSON CLOBs
[11:35:32 CST(-0600)] <EricDalquist> then there is a background process that runs on one machine in the cluster that periodically aggregates that raw event data into some form that is easier to report on / process
[11:35:46 CST(-0600)] <EricDalquist> PortalEventProcessingManagerImpl is essentially the entry point for all of that logic