uPortal IRC Logs-2012-07-23

Owned by Apereo Infrastructure
Last updated: Jul 23, 2012
3 min read

[12:42:07 CDT(-0500)] <EricDalquist> so xstream 1.4.3 is bad

[12:42:16 CDT(-0500)] <EricDalquist> something in it touches AWT code

[12:42:25 CDT(-0500)] <EricDalquist> and results in AWT worker threads

[12:42:32 CDT(-0500)] <EricDalquist> and a dock icon for tomcat on OSX

[12:42:33 CDT(-0500)] <EricDalquist> (tongue)

[13:16:20 CDT(-0500)] <athena> oh jeez.

[13:17:56 CDT(-0500)] <EricDalquist> yeah

[13:18:06 CDT(-0500)] <EricDalquist> spent 2 hours tracking down which library change was triggering AWT

[14:00:46 CDT(-0500)] <athena> yikes.

[14:09:47 CDT(-0500)] <EricDalquist> though found this on friday: http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html

[14:09:56 CDT(-0500)] <EricDalquist> it is available as a stand-alone library

[14:10:03 CDT(-0500)] <EricDalquist> much simpler and easier to configure than dbcp

[14:10:11 CDT(-0500)] <EricDalquist> and I was able to hook it into hibernate's dialect resolver

[14:10:18 CDT(-0500)] <EricDalquist> so it automatically configures the validation query

[14:12:47 CDT(-0500)] <athena> oh fun!

[14:12:56 CDT(-0500)] <athena> that sounds really helpful

[14:13:04 CDT(-0500)] <EricDalquist> it is almost a drop in replacement for dbcp config wise

[14:13:22 CDT(-0500)] <EricDalquist> but is a "concurrent" pool instead of a synchronized pool like dbcp

[14:13:33 CDT(-0500)] <EricDalquist> so it should also relieve a bit of db side lock contention

[14:19:17 CDT(-0500)] <mmoayyed> Guys, question on person directory. I have a mergedPersonAttributeDao that wraps 5 other DAOs inside itself. To enable caching, do I just need to add the 'cachingMergedPersonAttributeDao' bean and refer it to the 'mergedPersonAttributeDao' ?

[14:19:30 CDT(-0500)] <EricDalquist> yeah

[14:20:14 CDT(-0500)] <mmoayyed> and it doesn't matter what the sources for the DAOs are, right? Jdbc, Ldap, etc?

[14:20:21 CDT(-0500)] <EricDalquist> right

[14:20:43 CDT(-0500)] <mmoayyed> Geat. I'll give it a shot. Thanks

[14:21:23 CDT(-0500)] <mmoayyed> P.S: May have found a small issue with the sample person-dir config on github that right now has 'userAttributeCacheKeyGenerator' commented out. Looks like the config is looking for a 'useAllAttributes' property, which does not exist

[14:28:14 CDT(-0500)] <mmoayyed> wow, what a performance improvement!

[14:31:31 CDT(-0500)] <EricDalquist> (smile)

[14:43:57 CDT(-0500)] <mmoayyed> it's amazing, we had like a 30 second delay after the cas login and it's like 4! now granted I removed a bunch of portlets from the layout but still...

[14:59:19 CDT(-0500)] <EricDalquist> person dir gets queries A LOT during login

[15:23:09 CDT(-0500)] <mmoayyed> so, in the interest of improving performance, I wonder if turning off event aggr. would help. the UM doesn't specify how to experiment with the on/off switch. any pointers?

[15:24:23 CDT(-0500)] <EricDalquist> I doubt it

[15:24:46 CDT(-0500)] <EricDalquist> events are fired off as things happen and placed on to a concurrent linked queue

[15:24:59 CDT(-0500)] <EricDalquist> then there is a background task that flushes the queue to the db once/second

[15:25:30 CDT(-0500)] <EricDalquist> so in the user driven threads (tomcat, portlet exec) the only event cost is creating the object

[15:33:36 CDT(-0500)] <mmoayyed> ok, what about logging? that's blocking IO

[15:33:59 CDT(-0500)] <EricDalquist> yeah

[15:34:10 CDT(-0500)] <EricDalquist> in prod you shouldn't really have logging levels above WARN

[16:07:18 CDT(-0500)] <athena> so it sounds like maybe we should make some changes to the default config?

[16:07:28 CDT(-0500)] <athena> make sure people are set up to use caching by default in persondire

[16:07:32 CDT(-0500)] <athena> and change the default log level

[16:07:32 CDT(-0500)] <EricDalquist> yeah

[16:07:32 CDT(-0500)] <athena> ?

[16:07:38 CDT(-0500)] <EricDalquist> well for caching that would be good

[16:07:40 CDT(-0500)] <EricDalquist> for logging ….

[16:07:44 CDT(-0500)] <EricDalquist> where is the balance?

[16:07:50 CDT(-0500)] <EricDalquist> are we shipping prod ready or dev ready code?

[16:07:58 CDT(-0500)] <EricDalquist> I'm fine with either

[16:08:02 CDT(-0500)] <athena> i guess my suggestion would be generally prod ready

[16:08:13 CDT(-0500)] <EricDalquist> sounds good to me

[16:08:22 CDT(-0500)] <athena> since people that want to do a bunch of dev are probably more familiar w/ log config and more able to change it to suit their needs

[16:08:36 CDT(-0500)] <athena> make sure we don't set people that are less familiar w/ java dev up for poor performance

[16:08:47 CDT(-0500)] <mmoayyed> yup. prod ready would be less work, definitely.

[16:13:17 CDT(-0500)] <mmoayyed> onto a different topic: I am curious; what is the purpose of the uportal-ear file?

[16:13:40 CDT(-0500)] <EricDalquist> lets us deploy more than one webapp

[16:13:51 CDT(-0500)] <EricDalquist> aka uportal + resource server + all the other portlet apps

[16:14:01 CDT(-0500)] <EricDalquist> using a standardizes packaging

[16:15:55 CDT(-0500)] <mmoayyed> wouldn't be faster to cut down the build time by allowing each pom to go through the pluto plugin, etc, such that at the end its war ends up in webapps? seems like right now, we generate a war, which gets put into an ear, which then gets deployed back out.

[16:16:08 CDT(-0500)] <mmoayyed> can we cut out the middle-man so to speak?

[16:16:15 CDT(-0500)] <mmoayyed> that's a lot of disk activity

[16:23:09 CDT(-0500)] <EricDalquist> there are also the shared libraries

[16:23:16 CDT(-0500)] <EricDalquist> I'm more than open to other ideas