...
[11:55:58 CST(-0600)] <EricDalquist> do you have a specific code path that you suspect with the portlet registry?
[11:56:01 CST(-0600)] <Arvids> but still... around 300ms for portlet definition retrieval is too much
[11:56:07 CST(-0600)] <EricDalquist> right
[11:56:11 CST(-0600)] <EricDalquist> it should be VERY fast
[11:56:24 CST(-0600)] <EricDalquist> those portlet definitions should also only really ever be retrieved once
[11:56:26 CST(-0600)] <Arvids> that was my assumption, too
[11:56:27 CST(-0600)] <EricDalquist> and then stored in cache
[11:57:46 CST(-0600)] <EricDalquist> I'm wondering if there is some issue around MSSQL
[11:58:04 CST(-0600)] <EricDalquist> we had some other folks bring up an issue that I'm not sure ever got sorted out: http://permalink.gmane.org/gmane.comp.java.jasig.uportal/13830
[11:58:19 CST(-0600)] <EricDalquist> my guess is it is around how hibernate is dealing with CLOBs in MSSQL
[11:59:43 CST(-0600)] <Arvids> btw, I was using http://www.jvmmonitor.org/ on my local machine when I noticed that
[12:00:42 CST(-0600)] <EricDalquist> does that show method level detail?
[12:00:50 CST(-0600)] <Arvids> and it seems that it chokes each time when autoCommit is being set to false (at least i assume that it's setting false)
[12:00:57 CST(-0600)] <EricDalquist> like can you give me a list of methods that show bad response times?
[12:01:30 CST(-0600)] <Arvids> i will be able to do that tomorrow
[12:01:30 CST(-0600)] <EricDalquist> so one thought here ...
[12:01:47 CST(-0600)] <EricDalquist> PostgreSQL requires that CLOBs be read inside of a TX
[12:02:09 CST(-0600)] <EricDalquist> so all of the read methods on JpaPortletDefinitionDao and JpaPortletEntityDao are annotated with @Transactional(readOnly=true)
[12:02:15 CST(-0600)] <EricDalquist> you could try removing that annotation
[12:02:18 CST(-0600)] <EricDalquist> and see what happens
[12:02:28 CST(-0600)] <EricDalquist> it could be that the read-only TX is simply too expensive on MSSQL
[12:02:42 CST(-0600)] <EricDalquist> which means we would have to do a little work to only have that TX functionality for postgres
[12:02:44 CST(-0600)] <EricDalquist> which is doable
[12:02:46 CST(-0600)] <EricDalquist> just annoying 
[12:03:04 CST(-0600)] <Arvids> but the strange thing is that I also ran MSSQL profiler and each commit executes in 0-1ms
[12:03:37 CST(-0600)] <athena> the issue someone at unicon ran into yesterday w/ MSSQL was that the initial import for 4.0.2 failed with exceptions about connection already closed - think there was some stuff about autocommit in there, too
[12:03:57 CST(-0600)] <EricDalquist> yeah I would be very interested in what you get back from the Monitoring CPU usage feature of that tool
[12:04:17 CST(-0600)] <EricDalquist> I always enjoy (being serious here) looking at method call hotspot listings
[12:04:24 CST(-0600)] <Arvids> :O
[12:04:48 CST(-0600)] <athena> nothing like a nice glass of wine by the fire and a good thread dump . . .
[12:05:13 CST(-0600)] <EricDalquist> lol
[12:05:20 CST(-0600)] <Arvids> indeed
[12:05:25 CST(-0600)] <EricDalquist> I do realize there is something wrong with me
[12:06:16 CST(-0600)] <athena> lol
[12:06:24 CST(-0600)] <athena> we all have our weak spots
[12:06:38 CST(-0600)] <EricDalquist> but it benefits uPortal, so don't look at me too funny now
[12:08:16 CST(-0600)] <athena> it totally does
[12:08:25 CST(-0600)] <athena> and we do all have our exceptionally nerdy spots
[12:08:32 CST(-0600)] <Arvids> btw, have you had any chance to look at https://issues.jasig.org/browse/UP-3253
[12:08:50 CST(-0600)] <Arvids> this was the reason why we switched to MSSQL
[12:08:53 CST(-0600)] <EricDalquist> yes
[12:09:01 CST(-0600)] <EricDalquist> that will be fixed in 4.0.2
[12:09:01 CST(-0600)] <Arvids> (... and the presence of MSSQL admin)
[12:09:03 CST(-0600)] <EricDalquist> er 4.0.3
[12:09:10 CST(-0600)] <EricDalquist> it is fixed in master right now
[12:09:15 CST(-0600)] <Arvids> ah, nice
[12:09:21 CST(-0600)] <EricDalquist> I had to completely re-write how we do cluster based locking
[12:09:23 CST(-0600)] <EricDalquist>
[12:09:35 CST(-0600)] <Arvids> sounds painful
[12:09:40 CST(-0600)] <EricDalquist> just annoying
[12:09:47 CST(-0600)] <EricDalquist> since the original solution took 2-3 days
[12:09:55 CST(-0600)] <EricDalquist> and then the new solution was another 2-3 days
[12:10:03 CST(-0600)] <EricDalquist> wish I had easy access to all the different DBs for testing
[12:10:10 CST(-0600)] <EricDalquist> that is what we need someone to do
[12:10:23 CST(-0600)] <EricDalquist> setup an EC2 instance with MySQL, Postgres, MSSQL and Oracle on it
[12:10:41 CST(-0600)] <EricDalquist> then we can spin that up 1hr/day and run the uPortal build/init on it
[12:11:21 CST(-0600)] <Arvids> well... I can't do that each day, but it seems that i'll provide you the details regarding MSSQL issues
[12:11:46 CST(-0600)] <EricDalquist> yes
[12:11:47 CST(-0600)] <athena> EricDalquist: is the stats stuff in master?
[12:11:50 CST(-0600)] <EricDalquist> that is nearly as helpful
[12:11:51 CST(-0600)] <EricDalquist> not yet
[12:11:51 CST(-0600)] <Arvids> now that reminds me that we had to remove one uniqueness index
[12:11:55 CST(-0600)] <EricDalquist> I should have it in master tomorrow
[12:12:00 CST(-0600)] <athena> ah ok, cool 
[12:12:01 CST(-0600)] <EricDalquist> with at least one basic aggregation
[12:12:05 CST(-0600)] <athena> perfect
[12:12:06 CST(-0600)] <EricDalquist> https://github.com/edalquist/uPortal/commits/event-aggr
[12:12:10 CST(-0600)] <EricDalquist> that is where I'm working on it
[12:12:15 CST(-0600)] <athena> ah 
[12:12:26 CST(-0600)] <EricDalquist> also ... I love having my own repo with my own branch
[12:12:34 CST(-0600)] <athena> yeah, git is nice!
[12:12:35 CST(-0600)] <EricDalquist> several of those commits are completely non-functional
[12:12:51 CST(-0600)] <athena> lol
[12:13:29 CST(-0600)] <Arvids> next week i'll try to spend more time on uPortal platform
[12:13:44 CST(-0600)] <EricDalquist> that's great Arvids
[12:13:51 CST(-0600)] <Arvids> i've implemented a patch for https://issues.jasig.org/browse/UP-3270 but haven't had time to commit it back to our repository 
[12:13:54 CST(-0600)] <EricDalquist> your involvement and interest have been really helpful
[12:13:57 CST(-0600)] <EricDalquist> we need more of you
[12:13:57 CST(-0600)] <athena> +1!
[12:14:08 CST(-0600)] <EricDalquist> oh nice
[12:14:36 CST(-0600)] <Arvids> ... and that reminded that we have to be very careful when implementing new layout infrastructure
[12:15:00 CST(-0600)] <EricDalquist> yes
[12:15:09 CST(-0600)] <EricDalquist> we're going to have to do a lot of talking about requirements
[12:15:12 CST(-0600)] <EricDalquist> especially around i18n
[12:15:29 CST(-0600)] <EricDalquist> though simply getting layouts to use the same caching architecture as the rendering pipeline will help A LOT
[12:15:30 CST(-0600)] <Arvids> indeed - i'm also only learning about common issues in this area
[12:15:47 CST(-0600)] <EricDalquist> so that we are actually build the layout cache key to include ALL relavent bits of data
[12:15:55 CST(-0600)] <EricDalquist> so if any of them change we get a cache miss
[12:16:42 CST(-0600)] <Arvids> locale is certainly the one to remember
[12:16:46 CST(-0600)] <EricDalquist> yup
[12:17:36 CST(-0600)] <Arvids> ok, now time to relax
[12:17:52 CST(-0600)] <Arvids> thank you for your time - it was very valueable
[12:18:09 CST(-0600)] <EricDalquist> no problem
[12:18:15 CST(-0600)] <Arvids> i'll soon report my success regarding performance problems
[12:18:20 CST(-0600)] <EricDalquist> (]