[09:46:55 CST(-0600)] <cwaymire> EricDalquist: got a question for you regarding event aggregation
[09:47:11 CST(-0600)] <EricDalquist> sure, doing a standup right now but ask away and I'll answer when done
[09:49:04 CST(-0600)] <cwaymire> EricDalquist: does the current system support a single event being aggregated by 2 aggregators? right now the PortletExecutionAggregator is aggregating on PortletExecutionEvent events and now i'm tyring to also aggregate PortletActionExecutionEvent event's which are a subclass of PortletExecutionEvent. Wanting to make sure that won't cause an issue
[09:49:40 CST(-0600)] <cwaymire> I ask because I have it set up and when I fire off a Search event and the aggregator runs its throwing a constraint violation on the UP_DATETIME table
[09:49:45 CST(-0600)] <cwaymire> and i'm not sure why
[09:50:11 CST(-0600)] <cwaymire> UP_DATE_DIMENSION i mean
[09:54:31 CST(-0600)] <EricDalquist> it should be fine
[09:54:37 CST(-0600)] <EricDalquist> in fact I know it is
[09:54:53 CST(-0600)] <EricDalquist> for example if you have all of the portlet exec type aggregators turned on
[09:55:08 CST(-0600)] <EricDalquist> you end up with multiple aggregators handling one event
[09:55:42 CST(-0600)] <EricDalquist> can you gist the stack trace for the constraint error?
[09:56:49 CST(-0600)] <cwaymire> yeah. just a sec. let me reproduce it again so I can grab the log
[09:58:10 CST(-0600)] <cwaymire> https://gist.github.com/waymirec/5109064
[10:01:12 CST(-0600)] <EricDalquist> hrm
[10:01:54 CST(-0600)] <EricDalquist> so it appears that the date dimension query is causing a flush
[10:02:02 CST(-0600)] <EricDalquist> which probably isn't good
[10:04:33 CST(-0600)] <EricDalquist> and is probably hiding the underlying issue
[10:06:03 CST(-0600)] <cwaymire> i'm going to de-register this new aggregator and confirm that the issue goes away just to make sure i'm fighting the right issue
[10:06:16 CST(-0600)] <EricDalquist> ok
[10:06:28 CST(-0600)] <EricDalquist> I'm looking at some potential improvements to flush behavior
[10:15:54 CST(-0600)] <cwaymire> ok I took out my aggregator and I still see the exception
[10:18:55 CST(-0600)] <EricDalquist> yeah I bet something got screwed up in the date dimension table
[10:25:34 CST(-0600)] <cwaymire> If the aggregator gets called but I do not want to persist the event in question, what is the "proper" way to do that without causing any issues? There's a lot of moving parts here with the creation of the date and time rows etc and its possible I caused some data corruption.
[10:25:56 CST(-0600)] <EricDalquist> just ignore the event
[10:26:10 CST(-0600)] <EricDalquist> the aggregator is simply being told "this is the next event you care about"
[10:26:17 CST(-0600)] <EricDalquist> and it can do with it what it will
[10:26:33 CST(-0600)] <EricDalquist> in theory the data/time dimension parts should all be populated and static by that point
[10:26:40 CST(-0600)] <EricDalquist> I'm working on a few changes to help ensure that
[10:27:16 CST(-0600)] <cwaymire> ok. my concern was that the aggregation classes we are writing arent actually persisting anything. that is being done up in the super classes
[10:27:45 CST(-0600)] <cwaymire> and i wasnt sure if by me not populating the aggregation data it could cause a problem farther up where its trying to persist it.
[10:27:58 CST(-0600)] <EricDalquist> no, it shouldn't
[10:28:07 CST(-0600)] <EricDalquist> also if your aggregation doesn't fit the existing pattern
[10:28:21 CST(-0600)] <EricDalquist> you very much can just implement IPortalEventAggregator directly
[10:29:34 CST(-0600)] <EricDalquist> hrm
[10:29:41 CST(-0600)] <EricDalquist> so it does look like data will be created no matter what
[10:29:47 CST(-0600)] <EricDalquist> if you extend BasePortalEventAggregator
[10:30:05 CST(-0600)] <cwaymire> which I am
[10:30:06 CST(-0600)] <EricDalquist> aggregations will be created for each interval your aggregator is configured for and sees events for
[10:30:22 CST(-0600)] <EricDalquist> they will just be in their default state if you don't modify them at all
[10:31:58 CST(-0600)] <cwaymire> see heres the thing . The actual event is PortletActionExecutionEvent but thats not what im aggregating/persisting in this case. I am looking inside the action at the parameters and if the action was a search request I am persisting a SearchRequestAggregation object
[10:32:20 CST(-0600)] <EricDalquist> ok
[10:32:34 CST(-0600)] <cwaymire> if its not a search request this aggregator doesnt care about the event
[10:32:38 CST(-0600)] <cwaymire> and I do nothing with it.
[10:32:43 CST(-0600)] <EricDalquist> does SearchRequestAggregation need the same level of pivot data that the other aggregations need?
[10:32:55 CST(-0600)] <EricDalquist> like do you want date, time, interval, group?
[10:32:59 CST(-0600)] <cwaymire> yeah
[10:33:02 CST(-0600)] <EricDalquist> ok
[10:33:08 CST(-0600)] <EricDalquist> I have an idea ... just a minute
[10:33:14 CST(-0600)] <cwaymire> works pretty much the same with the addition that we are tracking search term
[10:34:40 CST(-0600)] <EricDalquist> are you doing this in trunk or 4-0 patches?
[10:34:46 CST(-0600)] <EricDalquist> just curious for work-sharing ease
[10:36:15 CST(-0600)] <cwaymire> master
[10:36:18 CST(-0600)] <EricDalquist> ok
[10:43:23 CST(-0600)] <EricDalquist> so I'm just going to add a supports(PortalEvent) to the aggregator method
[10:43:31 CST(-0600)] <EricDalquist> er to the aggregator interface
[10:43:49 CST(-0600)] <EricDalquist> then you can tell the framework if you want to support that event or not before it actually aggregates it
[10:45:16 CST(-0600)] <cwaymire> the aggregator class already has a supports method
[10:45:26 CST(-0600)] <EricDalquist> right
[10:45:36 CST(-0600)] <EricDalquist> but it is a support(Class) method
[10:45:44 CST(-0600)] <EricDalquist> I'll add one that is a support(PortalEvent) method
[10:45:50 CST(-0600)] <EricDalquist> you can then do your "is this a search event" check there
[10:45:56 CST(-0600)] <cwaymire> ah gotcha
[10:46:05 CST(-0600)] <EricDalquist> and then you won't create aggregations for events you don't care agbout
[10:46:13 CST(-0600)] <cwaymire> sounds good
[10:46:17 CST(-0600)] <EricDalquist> it should actually make the perf of this aggregator much better
[10:48:48 CST(-0600)] <EricDalquist> drewwills:
[10:48:56 CST(-0600)] <EricDalquist> I'm trying to do a "clean initportal" on master
[10:49:01 CST(-0600)] <EricDalquist> and I'm getting the following error
[10:49:15 CST(-0600)] <EricDalquist> Unknown lifecycle phase "". You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>. Available lifecycle phases are: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resourc
[10:49:27 CST(-0600)] <cwaymire> not to be mean but im glad you're getting that error 
[10:49:29 CST(-0600)] <cwaymire> because I'm getting it
[10:49:33 CST(-0600)] <EricDalquist> yeah
[10:49:34 CST(-0600)] <cwaymire> and i was afraid it was just me
[10:49:36 CST(-0600)] <EricDalquist> no
[10:49:49 CST(-0600)] <EricDalquist> it is something with the new data-import stuff from drewwills / jwennmacher
[10:49:55 CST(-0600)] <EricDalquist> did you figure out a work around cwaymire?
[10:50:10 CST(-0600)] <cwaymire> not yet. i do know its happening in the call to portlet-data-import
[10:50:41 CST(-0600)] <EricDalquist> ah
[10:50:43 CST(-0600)] <EricDalquist> I see the problem ...
[10:51:08 CST(-0600)] <EricDalquist> it passes an argument of "" to ant exec
[10:51:13 CST(-0600)] <EricDalquist> but ant doesn't build a big CLI string
[10:51:19 CST(-0600)] <EricDalquist> it uses these as actual parameters
[10:51:31 CST(-0600)] <EricDalquist> and maven has no idea what to do with a cli parameter of ""
[10:51:43 CST(-0600)] <EricDalquist> which is why in our MVN command we pass -Djasig.ignore instead of ""
[10:51:54 CST(-0600)] <EricDalquist> I'll get that committed shortly
[10:51:57 CST(-0600)] <cwaymire> <param name="goal" value="$ " /> that seems to be the culprit
[10:52:08 CST(-0600)] <EricDalquist> yup
[10:52:17 CST(-0600)] <EricDalquist> <condition property="packageArg" value="-Djasig.ignore">
[10:52:20 CST(-0600)] <cwaymire> commenting thta out and changing the next line to a name of "goal" seems to get around it
[10:52:24 CST(-0600)] <EricDalquist> update line 332 to that
[10:52:52 CST(-0600)] <EricDalquist> or maybe not ...
[10:53:25 CST(-0600)] <cwaymire> 523
[10:54:16 CST(-0600)] <EricDalquist> ah yeah
[10:54:18 CST(-0600)] <EricDalquist> two places 
[10:54:30 CST(-0600)] <cwaymire> yep that fixed it
[10:55:12 CST(-0600)] <cwaymire> now hopefully you're change will fix my other problem and I can get back to some meaningful coding
[10:55:22 CST(-0600)] <cwaymire> *your
[10:55:43 CST(-0600)] <EricDalquist>
[10:57:19 CST(-0600)] <EricDalquist> arg
[10:57:27 CST(-0600)] <EricDalquist> now I'm seeing the build error that is on bamboo
[10:57:29 CST(-0600)] <EricDalquist> @#$!@#$#$
[10:57:36 CST(-0600)] <EricDalquist> [artifact:mvn] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.2:war (default-war) on project CalendarPortlet: Error loading property file '/home/edalquist/JavaClasses/workspace_42/uPortal/uportal-portlets-overlay/CalendarPortlet/../../uportal-war/target/classes/properties/rdbm.properties' -> [Help 1]
[11:01:03 CST(-0600)] <cwaymire> i'm not seeing that
[11:01:34 CST(-0600)] <EricDalquist> yeah it happens if you do something like "ant clean initdb"
[11:02:37 CST(-0600)] <cwaymire> yeah. i see that now.
[11:02:48 CST(-0600)] <EricDalquist> I think I have that fixed too ...
[11:17:28 CST(-0600)] <EricDalquist> ok
[11:17:34 CST(-0600)] <EricDalquist> just verifying these aggr changes all work
[11:17:40 CST(-0600)] <EricDalquist> and I should have it committed in 10 minute
[11:19:16 CST(-0600)] <cwaymire> ok. cool.
[11:30:58 CST(-0600)] <EricDalquist> drewwills: can you please review https://issues.jasig.org/browse/UP-3670 and see if the same changes need to be applied to 4.0-patches?
[11:32:13 CST(-0600)] <EricDalquist> ok cwaymire
[11:32:18 CST(-0600)] <EricDalquist> my commits are there
[11:32:24 CST(-0600)] <EricDalquist> I'd try a new initdb
[11:32:26 CST(-0600)] <EricDalquist> and work from there
[11:32:37 CST(-0600)] <EricDalquist> let me know if you see more constraint issues
[11:32:45 CST(-0600)] <EricDalquist> at least we should get a better log message now if you do
[11:36:08 CST(-0600)] <cwaymire> got 'em. making my local changes then i'l ltest
[11:52:15 CST(-0600)] <cwaymire> well thats progress. the aggregation ran successfully but it did not aggregate my event. i'll have to do some debugging to see whats going on.
[11:52:51 CST(-0600)] <EricDalquist> ok
[12:09:23 CST(-0600)] <cwaymire> EricDalquist: I put breaks in and I see it going through the PortletExecutionAggregator but I do not see it touching my SearchRequestAggregator
[12:09:33 CST(-0600)] <EricDalquist> huh
[12:09:40 CST(-0600)] <EricDalquist> it is wired up as a spring bean?
[12:14:08 CST(-0600)] <cwaymire> think i found it
[12:14:20 CST(-0600)] <cwaymire> redeploying and hopefully this works now
[12:29:38 CST(-0600)] <cwaymire> ugh. now its complaining that my entity class is not an entity
[12:29:46 CST(-0600)] <EricDalquist> ?
[12:30:30 CST(-0600)] <cwaymire> Caused by: java.lang.IllegalArgumentException: Not an entity: class org.jasig.portal.events.aggr.action.SearchRequestAggregationImpl
[12:30:37 CST(-0600)] <cwaymire> trying to find out why. its annotated as an entity
[12:36:09 CST(-0600)] <EricDalquist> I think it might need to be listed in the stats hibernate cfg xml
[12:40:10 CST(-0600)] <cwaymire> yeah I think i forgot to add it to the map
[12:41:10 CST(-0600)] <cwaymire> thought it was auto detecting that based on the jpa annoation
[12:41:23 CST(-0600)] <cwaymire> forgot about the events aggr hibernate map definitions
[12:43:12 CST(-0600)] <EricDalquist> yeah it is annoying to have to add it to the xml files :/
[12:46:39 CST(-0600)] <cwaymire> i'm noticing that if i start up uportal and do a search the aggregation runs clean but if I shut it down and start it back up the next time the aggregation takes place it throws that constraint violation again
[12:46:54 CST(-0600)] <cwaymire> if i shut it down, initdb, and restart it runs clean again
[12:48:10 CST(-0600)] <EricDalquist> huh
[12:48:14 CST(-0600)] <EricDalquist> thats no good
[12:48:25 CST(-0600)] <EricDalquist> I'll see if I can reproduce that in a little bit
[12:48:36 CST(-0600)] <EricDalquist> does the constraint error look any different now?
[12:48:42 CST(-0600)] <EricDalquist> could you share the latest version of it?
[12:50:06 CST(-0600)] <cwaymire> https://gist.github.com/waymirec/5110662
[12:51:38 CST(-0600)] <EricDalquist> can you add in the rest of the stack?
[12:51:45 CST(-0600)] <EricDalquist> I want to see if it is coming from a different location now
[12:52:34 CST(-0600)] <EricDalquist> drewwills: you there?
[12:52:42 CST(-0600)] <drewwills> just got back
[12:52:54 CST(-0600)] <EricDalquist> you have a few minutes to chat about the courses portlet data model?
[12:52:59 CST(-0600)] <drewwills> sure
[12:53:06 CST(-0600)] <drewwills> chat? or pone?
[12:53:07 CST(-0600)] <EricDalquist> hrm
[12:53:13 CST(-0600)] <EricDalquist> actually I need a few more minutes
[12:53:16 CST(-0600)] <EricDalquist> I was going to say in chat
[12:53:22 CST(-0600)] <EricDalquist> but what I thought I was seeing I am not
[12:53:25 CST(-0600)] <drewwills> gotcha
[12:54:07 CST(-0600)] <EricDalquist> I'm taked with merging the 10+ months of divergent dev on that portlet
[12:54:17 CST(-0600)] <EricDalquist> so just trying to grok all of the changes on both sides
[12:57:11 CST(-0600)] <drewwills> roger
[12:57:31 CST(-0600)] <drewwills> thanks for the fix of the "" mvn argument btw... reading today's IRC logs
[12:57:32 CST(-0600)] <cwaymire> EricDalquist: i'll get the rest of the trace. just have to reproduce it again.
[12:57:39 CST(-0600)] <EricDalquist> ok cwaymire
[12:57:47 CST(-0600)] <EricDalquist> yup
[12:57:55 CST(-0600)] <EricDalquist> can you check and see if 4-0p-atches needs that same fix?
[12:59:59 CST(-0600)] <drewwills> looking
[13:13:41 CST(-0600)] <drewwills> EricDalquist I cherry-picked your fix into 4-0-patches
[13:13:46 CST(-0600)] <EricDalquist> great
[13:13:47 CST(-0600)] <EricDalquist> thanks drewwills
[13:13:58 CST(-0600)] <EricDalquist> I think I have my courses portlet question answered for now
[13:14:02 CST(-0600)] <EricDalquist> but I'll likely be asking more soon
[13:14:04 CST(-0600)] <drewwills> ah cool
[13:14:13 CST(-0600)] <EricDalquist> do you know how many places actually have this deployed right now?
[13:14:15 CST(-0600)] <drewwills> i'm in phoenix next week
[13:14:32 CST(-0600)] <EricDalquist> we do .. but our code is 10 months out of date and has lots of changes we never ported back in
[13:14:35 CST(-0600)] <drewwills> manhattan, oakland, sinclair (unreleased)
[13:14:36 CST(-0600)] <EricDalquist> so I'm going to be working on that
[13:14:38 CST(-0600)] <EricDalquist> ok
[13:14:42 CST(-0600)] <drewwills> maybe more
[13:14:47 CST(-0600)] <EricDalquist> I'll do my best to be careful with the merge
[13:14:50 CST(-0600)] <drewwills> usd (unreleased)
[13:15:01 CST(-0600)] <drewwills> progress is good
[13:19:34 CST(-0600)] <cwaymire> EricDalquist: do you know if theres any way to get access to the eventName property of an event? I see it in the raw event json but don't see any way to gain access to that value going all the way back through the chain to ApplicationEvent
[13:22:25 CST(-0600)] <EricDalquist> hrm
[13:23:13 CST(-0600)] <EricDalquist> I'm not sure what you're looking at ...
[13:23:46 CST(-0600)] <EricDalquist> I see json that looks like: {"@c":".PortalRenderEvent","timestamp":1362595016525,"serverId":"teti","eventSessionId":"2ryyhafk","userName":"dalquist","requestPathInfo":null,"urlState":"NORMAL","urlType":"RENDER","parameters":{},"targetedLayoutNodeId":null,"executionTimeNano":2116884281}
[13:24:19 CST(-0600)] <cwaymire> ahh.. i was looking at a PortletEventExecutionEvent
[13:24:32 CST(-0600)] <EricDalquist> ah
[13:24:35 CST(-0600)] <EricDalquist> ok
[13:25:03 CST(-0600)] <cwaymire> it would be nice to be able to have this thing basically filter so it only cares about events that match the search QNAME
[13:25:29 CST(-0600)] <cwaymire> but not a big deal
[13:25:40 CST(-0600)] <EricDalquist> PortletEventExecutionEvent.getEventName()
[13:25:49 CST(-0600)] <EricDalquist> doesn't that give you what you want?
[13:26:13 CST(-0600)] <EricDalquist> https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/java/org/jasig/portal/events/PortletEventExecutionEvent.java#L54
[13:26:51 CST(-0600)] <EricDalquist> drewwills: this isn't thread safe: https://github.com/Jasig/CoursesPortlet/blob/master/courses-portlet-api/src/main/java/org/jasig/portlet/courses/model/xml/CourseMeetingWrapper.java#L34
[13:27:02 CST(-0600)] <EricDalquist> I think I'm going to look at switching it to joda-time
[13:27:15 CST(-0600)] <EricDalquist> but DateFormat objects aren't safe for concurrent usage :/
[13:31:15 CST(-0600)] <EricDalquist> also any thoughts/objections to switching the portlet to use slf4j & logback?
[13:35:49 CST(-0600)] <cwaymire> EricDalquist: https://gist.github.com/waymirec/5111062
[13:36:01 CST(-0600)] <EricDalquist> any more than that
[13:36:04 CST(-0600)] <EricDalquist> ?
[13:36:15 CST(-0600)] <cwaymire> thats the entire log
[13:36:28 CST(-0600)] <EricDalquist> uh that is weird
[13:36:32 CST(-0600)] <cwaymire> wait
[13:36:33 CST(-0600)] <EricDalquist> it is missing the log statement
[13:36:36 CST(-0600)] <cwaymire> did it get cut off?
[13:36:38 CST(-0600)] <EricDalquist> yeah
[13:36:42 CST(-0600)] <EricDalquist> https://gist.github.com/waymirec/5111062/raw/d493ea3cd0e36cedab29f54fc49e151fa7e279f8/gistfile1.txt
[13:38:13 CST(-0600)] <cwaymire> https://gist.github.com/waymirec/5111083
[13:38:24 CST(-0600)] <cwaymire> weird. kiwi was truncating my copy-paste
[13:39:11 CST(-0600)] <EricDalquist> that is so bizzar ...
[13:39:14 CST(-0600)] <EricDalquist> so this happens every time
[13:39:16 CST(-0600)] <EricDalquist> after you init
[13:39:19 CST(-0600)] <EricDalquist> then restart uportal?
[13:39:45 CST(-0600)] <cwaymire> it happens if i shut down uportal then restart it and create an event for aggregation
[13:39:54 CST(-0600)] <cwaymire> if i shut it down, initdb, then restart the problems doesnt happen
[13:40:05 CST(-0600)] <cwaymire> i can recreate it each time
[13:41:08 CST(-0600)] <EricDalquist> wtf
[13:42:14 CST(-0600)] <EricDalquist> ok can you do me a favor (I realize this isn't helping you get the task at hand done but ...) can you turn on debug logging for org.jasig.portal.events.aggr.PortalEventDimensionPopulatorImpl into the portal event log
[13:42:21 CST(-0600)] <EricDalquist> nuke your log file
[13:42:23 CST(-0600)] <EricDalquist> and start up the portal
[13:42:34 CST(-0600)] <EricDalquist> I'm very interested what the dimension populator is trying to do
[13:42:40 CST(-0600)] <EricDalquist> since if you just did an initdb
[13:42:48 CST(-0600)] <EricDalquist> there shouldn't be anything to populate after the first time it runs
[13:43:01 CST(-0600)] <cwaymire> it doesnt happen right after an initdb
[13:43:03 CST(-0600)] <EricDalquist> my guess is that this is some infuriatingly evil time zone issue
[13:43:04 CST(-0600)] <EricDalquist> right
[13:43:14 CST(-0600)] <EricDalquist> so you do init
[13:43:19 CST(-0600)] <EricDalquist> aggr runs correctly
[13:43:26 CST(-0600)] <cwaymire> do you know off hand where the log4j config is for the portal-events.log?
[13:43:29 CST(-0600)] <EricDalquist> which would trigger the dimension populator
[13:43:36 CST(-0600)] <EricDalquist> src/main/resources/logback.xml
[13:48:12 CST(-0600)] <cwaymire> ok. restarting now. back to an earlier conversation PortletActionExecutionEvent cannot be casted to PortletEventExecutionEvent which is why i cant get to that getEventName() method
[13:48:23 CST(-0600)] <EricDalquist> oh right
[13:48:27 CST(-0600)] <EricDalquist> well they are two different events
[13:48:37 CST(-0600)] <EricDalquist> so the search portlet works via:
[13:48:45 CST(-0600)] <EricDalquist> search form is submitted via a portlet action
[13:48:49 CST(-0600)] <EricDalquist> that action generates a "Search event"
[13:48:56 CST(-0600)] <EricDalquist> which then portlets can listen for and respond to
[13:49:18 CST(-0600)] <EricDalquist> so in theory if things are working right you should see the PortletActionExecutionEvent and then at least 1 PortletEventExecutionEvent in the db
[13:49:25 CST(-0600)] <EricDalquist> if you aren't seeing the PortletEventExecutionEvent objects
[13:49:27 CST(-0600)] <EricDalquist> something is broken
[13:49:31 CST(-0600)] <EricDalquist> and not firing those events
[13:49:39 CST(-0600)] <cwaymire> I do see the PortletEventExecutionEvent in the raw table
[13:49:44 CST(-0600)] <cwaymire> maybe I should be aggregating off that then
[13:49:44 CST(-0600)] <EricDalquist> ok
[13:49:47 CST(-0600)] <EricDalquist> yes
[13:49:56 CST(-0600)] <cwaymire> thats a quick change
[13:50:17 CST(-0600)] <EricDalquist> that won't show you the seach terms though
[13:50:18 CST(-0600)] <drewwills> here's something new... at USD we're seeing an issue with authN... some users have uid in LDAP like 'John.Doe' – but they log in via CAS with 'john.doe'
[13:50:23 CST(-0600)] <EricDalquist> unless you add more data into the event
[13:50:33 CST(-0600)] <drewwills> CAS is happy with that, but persondirs fails
[13:50:41 CST(-0600)] <EricDalquist> right now PortletEventExecutionEvent just captures the QName of the event payload
[13:50:54 CST(-0600)] <EricDalquist> you would need to look at capturing the entire event payload
[13:50:59 CST(-0600)] <EricDalquist> which would be doable
[13:51:06 CST(-0600)] <EricDalquist> just more data to run through the DB
[13:51:25 CST(-0600)] <EricDalquist> drewwills: they likely need some sort of case sensitivity filter somewhere
[13:51:33 CST(-0600)] <EricDalquist> sounds like "fun" to figure out where though :/
[13:52:22 CST(-0600)] <drewwills> https://gist.github.com/anonymous/5108798
[13:53:23 CST(-0600)] <drewwills> IncorrectResultSizeDataAccessException: Incorrect result size: expected 1, actual 2
[13:53:49 CST(-0600)] <drewwills> yeah... i'm sure there's a way to lick this issue
[13:54:07 CST(-0600)] <EricDalquist> so I bet PD is trying to merge results based on username
[13:54:20 CST(-0600)] <EricDalquist> and the query for "user.name" does not match the result of "User.Name"
[13:55:22 CST(-0600)] <drewwills> yep
[13:55:48 CST(-0600)] <drewwills> oh wait... i got a thought
[13:56:13 CST(-0600)] <drewwills> there's currently some sort of echo DAO configured
[13:59:13 CST(-0600)] <drewwills> uPortalJdbcUserSource... do we even need it? (w/ LDAP configured)
[14:05:52 CST(-0600)] <cwaymire> EricDalquist: added the logger you specified but I still just see the same error logs in portal-events.log
[14:06:04 CST(-0600)] <EricDalquist> do you see a bunch more info before the error?
[14:06:29 CST(-0600)] <cwaymire> no. it looks the same. I can post it.
[14:07:26 CST(-0600)] <EricDalquist> :/
[14:07:36 CST(-0600)] <EricDalquist> I was really hoping to see what it is trying to do
[14:07:36 CST(-0600)] <EricDalquist> ok
[14:07:43 CST(-0600)] <EricDalquist> I'll see if i can reproduce that issue locally :
[14:09:17 CST(-0600)] <cwaymire> https://gist.github.com/waymirec/5111351
[14:11:30 CST(-0600)] <EricDalquist> are you using the local hsql db
[14:11:32 CST(-0600)] <EricDalquist> or something else?
[14:11:40 CST(-0600)] <cwaymire> standalone hsql
[14:12:33 CST(-0600)] <cwaymire> 2.2.9
[14:12:56 CST(-0600)] <EricDalquist> blarg
[14:32:27 CST(-0600)] <cwaymire> i hereby rename Event Aggregation to Event Aggravation
[14:33:07 CST(-0600)] <cwaymire> debug shows it calling the supports(PortalEvent) method and I am returning true, but none of the other methods (updateAggregation, or even createAggregationKey) are being called
[14:33:36 CST(-0600)] <EricDalquist> heh
[14:33:41 CST(-0600)] <EricDalquist> is it a bug with my new code>?
[14:34:45 CST(-0600)] <cwaymire> not sure. I just threw a breakpoint at various places in my aggregator and I see it calling the supports but none of the others and no entry is getting created in the aggregation table i created.
[14:35:03 CST(-0600)] <cwaymire> i'll keep digging
[14:35:19 CST(-0600)] <EricDalquist> :/
[15:16:54 CST(-0600)] <cwaymire> EricDalquist: I found out why my aggregator isnt getting called. The aggregateEvent method in the BasePortalEventAggregator accepts a map of intervals and when the search event i am interested in is executed that method is called with a blank map.
[15:17:05 CST(-0600)] <EricDalquist> ah
[15:17:15 CST(-0600)] <EricDalquist> so due to popular demand
[15:17:26 CST(-0600)] <EricDalquist> the deafult aggregation behavior is now aggregate nothing if no config is specified
[15:17:37 CST(-0600)] <EricDalquist> so you need to update the db aggr config
[15:17:42 CST(-0600)] <EricDalquist> and specific which intervals you care about
[15:18:12 CST(-0600)] <cwaymire> i did. let me double check that i reimported it after the last initdb
[15:19:17 CST(-0600)] <cwaymire> ugh i didnt. i've ran this so many times it all blurrs together
[15:19:24 CST(-0600)] <EricDalquist>
[15:27:26 CST(-0600)] <cwaymire> finally!
[15:27:34 CST(-0600)] <EricDalquist> yay!
[15:28:03 CST(-0600)] <cwaymire> it is finally logging/aggregating search terms
[15:28:11 CST(-0600)] <EricDalquist> yay
[15:28:24 CST(-0600)] <EricDalquist> did you add the event payload to the eventevent?
[15:28:29 CST(-0600)] <EricDalquist> (what a great name)
[15:28:59 CST(-0600)] <cwaymire> now lets just hope it increments them properly (crosses fingers)
[15:29:15 CST(-0600)] <EricDalquist>
[15:29:50 CST(-0600)] <cwaymire> no. that is probably the better way to go about it but righ t now i'm under a bit of time crunch so I just have it comparing the fname against "search" and checking that there is a query parameter.
[15:30:17 CST(-0600)] <cwaymire> not the best solution considering its coupled to an arbitrary fname but that can be corrected later.
[15:30:23 CST(-0600)] <EricDalquist> ah
[15:30:25 CST(-0600)] <EricDalquist> cool
[15:30:26 CST(-0600)] <EricDalquist> yeah
[15:30:44 CST(-0600)] <cwaymire> tryin to get this thing up and running by tomorrow
[15:34:53 CST(-0600)] <cwaymire> ok its almost working properly but not quite.
[15:35:16 CST(-0600)] <drewwills> you're the man 
[15:36:43 CST(-0600)] <cwaymire> its not aggregating on the search term properly. some of them it creates a new row and some of them it just increments the counter on an existing one
[15:48:13 CST(-0600)] <cwaymire> ugh. really annoying when my laptop decides to just freeze.
[16:19:29 CST(-0600)] <cwaymire> EricDalquist: you still around?
[16:20:31 CST(-0600)] <EricDalquist> yup
[16:21:56 CST(-0600)] <cwaymire> hey. ok so this aggregation table has (in addition to the normal date, time, group, interval, etc) a search term column and a count column. I have an aggregation key defined that extends from BaseAggregationKeyImpl and just adds in a getter for the searchTerm and adjusts the hashcode/equals methods appropriately.
[16:22:21 CST(-0600)] <cwaymire> i'm seeing a situation where sometimes it properly creates a new row given a new search term, and sometimes it increments the count of an existing row even though its a unique search term
[16:22:31 CST(-0600)] <cwaymire> would that be an issue with the key?
[16:22:48 CST(-0600)] <EricDalquist> hrm
[16:23:08 CST(-0600)] <cwaymire> not sure exactly how the key is used underneath
[16:23:23 CST(-0600)] <EricDalquist> it could be ... you'd need to make sure the DAO is consistently creating the key based on the event
[16:23:38 CST(-0600)] <EricDalquist> if you want to push this out on a branch I could potentially take a look at it tonight
[16:24:00 CST(-0600)] <cwaymire> I put a debug statement in and I watch it call the createAggregationKey for each interval and have confirmed the key is correct
[16:24:07 CST(-0600)] <cwaymire> yet the update was wrong
[16:24:32 CST(-0600)] <cwaymire> i'll push it out to my github repos
[16:26:06 CST(-0600)] <EricDalquist> ok
[16:26:09 CST(-0600)] <EricDalquist> thanks
[16:27:42 CST(-0600)] <cwaymire> https://github.com/waymirec/uPortal/commits/NOJIRA is where it will live