[16:27:19 CST(-0600)] <awills> done with UP-2899 EricDalquist
[16:27:29 CST(-0600)] <EricDalquist> great 
[16:34:12 CST(-0600)] <awills> also hit UP-2476 in the process: https://issues.jasig.org/browse/UP-2476
[16:34:52 CST(-0600)] <awills> works as expected for both fragment-layout files AND template-user files
[16:39:09 CST(-0600)] <EricDalquist> nice
[17:28:03 CST(-0600)] <athena> EricDalquist: you'd mentioned you might be doing some work for statistics in up-trunk?
[17:28:19 CST(-0600)] <EricDalquist> well we need to re-work the portal event objects
[17:28:21 CST(-0600)] <EricDalquist> and the handling APIs
[17:29:09 CST(-0600)] <EricDalquist> essentially re-instrument all the DAOs, rendering pipeline and portlet exeuction code
[17:29:46 CST(-0600)] <athena> is that stuff we need to do anyway? something that will be a lot of work?
[17:30:02 CST(-0600)] <EricDalquist> it is stuff we need to do anyway and shouldn't be a lot of work
[17:30:18 CST(-0600)] <EricDalquist> we can remove a lot of existing event handling code with some new spring 3 features
[17:30:38 CST(-0600)] <athena> sounds cool
[17:30:47 CST(-0600)] <athena> trying to figure out what direction to go in next
[17:31:01 CST(-0600)] <athena> eventually likely need to address https://issues.jasig.org/browse/UP-2603 (stats reporting portlet)
[17:31:44 CST(-0600)] <EricDalquist> yeah, well there are really 3 steps, 1st is the work that I just described
[17:31:58 CST(-0600)] <EricDalquist> 2nd is getting aggregation logic built in
[17:32:03 CST(-0600)] <EricDalquist> and working without really complex config
[17:32:11 CST(-0600)] <EricDalquist> 3rd is finally getting a stats reporting tool working
[17:32:13 CST(-0600)] <athena> gotcha
[17:32:31 CST(-0600)] <athena> how worried are you about the 2nd step? i know you have some code that's oracle-specific right now
[17:32:52 CST(-0600)] <EricDalquist> not that but I'm not that happy witht he code we have right now
[17:33:04 CST(-0600)] <EricDalquist> it uses spring-batch which I don't think is the right tool for the job
[17:33:10 CST(-0600)] <EricDalquist> we run into problems with it all the time
[17:33:19 CST(-0600)] <EricDalquist> also it uses plain JDBC level code
[17:33:59 CST(-0600)] <EricDalquist> I think your ideas about fixing up the event objects so jpa can be used for both writing and reading them
[17:34:05 CST(-0600)] <EricDalquist> then use that to do aggregation
[17:34:14 CST(-0600)] <EricDalquist> awills: added distributed locking code using hiberate
[17:34:34 CST(-0600)] <EricDalquist> which is really most of what is needed
[17:35:16 CST(-0600)] <EricDalquist> I'm thinking something like having a baked-in scheduled task that runs every minute and aggregates all stats events that haven't been aggregated so far and are older than 1 minute
[17:35:22 CST(-0600)] <EricDalquist> thats essentially what our process does right now
[17:35:41 CST(-0600)] <EricDalquist> and the hibernate locking code deals with making sure only one uPortal server ever runs that task at a time
[17:35:53 CST(-0600)] <EricDalquist> I think we can tune it enough to make it perform
[17:36:02 CST(-0600)] <EricDalquist> with non db specific SQL
[17:36:05 CST(-0600)] <EricDalquist> potentially even through JPA
[17:36:19 CST(-0600)] <athena> sounds good to me
General
Content
Integrations