[08:40:41 EDT(-0400)] * michelled_ (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined ##uportal
[09:06:31 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176444670.dsl.bell.ca) has joined ##uportal
[09:16:45 EDT(-0400)] * tsnfoo (n=tsnfoo@140.141.15.78) has joined ##uportal
[09:22:02 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[09:24:17 EDT(-0400)] * athena (n=athena@adsl-75-58-127-15.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[10:25:51 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[10:34:42 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[10:42:13 EDT(-0400)] * athena (n=athena@adsl-75-58-127-15.dsl.wlfrct.sbcglobal.net) has joined ##uportal
[11:05:46 EDT(-0400)] * lennard1 (n=sparhk@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[12:07:34 EDT(-0400)] * EricDalquist (n=EricDalq@76.210.73.13) has joined ##uportal
[12:09:41 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined ##uportal
[12:49:50 EDT(-0400)] * Sememmon (n=Sememmon@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[14:12:29 EDT(-0400)] <EricDalquist> athena: have you done anything more with the ajax portlet support refactoring?
[14:12:32 EDT(-0400)] <EricDalquist> for annotation support?
[14:12:38 EDT(-0400)] <athena> no
[14:12:46 EDT(-0400)] <EricDalquist> ok
[14:12:47 EDT(-0400)] <athena> i checked in all the refactoring i'd done to offer a service
[14:12:53 EDT(-0400)] <EricDalquist> great
[14:13:05 EDT(-0400)] <athena> i haven't had a chance to refactor the existing inheritance-based classes to use the service rather than duplicating code
[14:13:07 EDT(-0400)] <EricDalquist> just wanted to make sure we won't have conflicting commits
[14:13:23 EDT(-0400)] <athena> the only uncommitted fixes i have are for spelling errors in the javadocs 
[14:13:30 EDT(-0400)] <EricDalquist> ok
[15:40:58 EDT(-0400)] <EricDalquist> ok athena ajax portlet support 1.0.5 is released
[15:47:53 EDT(-0400)] <athena> wooo!
[16:01:31 EDT(-0400)] <athena> EricDalquist: so i think before the weather portlet gets released it also need to get re-licensed
[16:01:46 EDT(-0400)] <athena> and before that happens, someone needs to track down the appropriate people and get them to sign licensing agreements
[16:01:55 EDT(-0400)] <EricDalquist> ah yeah
[16:02:05 EDT(-0400)] <athena> might be worth pinging parker about that
[16:02:15 EDT(-0400)] <EricDalquist> though that is more of a 'move out of sandbox' step
[16:02:20 EDT(-0400)] <EricDalquist> we can tag a release of it
[16:02:35 EDT(-0400)] <athena> yeah, it could be released under the current license
[16:02:56 EDT(-0400)] <athena> but since that's already in incubation it wouldn't be bad to get that taken care of if we can
[16:03:00 EDT(-0400)] <EricDalquist> it is currently just the New BSD
[16:03:06 EDT(-0400)] <athena> yep
[17:03:11 EDT(-0400)] * awills (n=awills@wsip-72-215-204-133.ph.ph.cox.net) has joined ##uportal
[17:11:47 EDT(-0400)] <awills> you there EricDalquist?
[17:11:54 EDT(-0400)] <EricDalquist> yup
[17:12:31 EDT(-0400)] <awills> i'm thinking perhaps athena already brought this up to you, but turns out last Thursday I was looking at the wrong cache
[17:12:52 EDT(-0400)] <awills> it's the system-wide cache that's interesting: http://uportal.pastebin.com/d389d5c98
[17:13:13 EDT(-0400)] <EricDalquist> ah
[17:13:35 EDT(-0400)] <awills> the line ##s weren't matching up, so i mistakenly looked at the channelCache in ChannelRenderer
[17:13:46 EDT(-0400)] <awills> but it turns out this is the one
[17:14:08 EDT(-0400)] <awills> and unlike the channelCache, this is 1 instance for all worker threads
[17:14:40 EDT(-0400)] <EricDalquist> yeah
[17:14:40 EDT(-0400)] <EricDalquist> so there could be cme's there
[17:15:12 EDT(-0400)] <awills> well, if UGA is experiencing this as a bug, then CME isn't what happens... at least not to them
[17:16:02 EDT(-0400)] <EricDalquist> yeah
[17:16:09 EDT(-0400)] <EricDalquist> I'm rather impressed that that code works at all
[17:16:16 EDT(-0400)] <EricDalquist> since ReferenceMap claims to be unsynchronized
[17:16:21 EDT(-0400)] <awills> 1 worker thread (perhaps more than 1 sometimes) get's "caught" and spins
[17:16:23 EDT(-0400)] <EricDalquist> unless there is some other sync happening somewhere
[17:16:36 EDT(-0400)] <EricDalquist> spins doing what?
[17:16:46 EDT(-0400)] <awills> well, it only affects channels whose cache keys are system-scoped
[17:17:11 EDT(-0400)] <awills> petro suggested infinite loop of some sort
[17:17:26 EDT(-0400)] <awills> i'm not certain how it would look
[17:17:54 EDT(-0400)] <EricDalquist> yeah, a stack trace would be quite helpful
[17:18:04 EDT(-0400)] <awills> thread deadlock, i guess, with one threaad thinking somehow it can work
[17:18:36 EDT(-0400)] <awills> here: http://uportal.pastebin.com/d1e5969ad
[17:18:50 EDT(-0400)] <awills> that's what lead me to that code in the first place
[17:19:19 EDT(-0400)] <EricDalquist> well a thread in RUNNABLE isn't a deadlock
[17:19:29 EDT(-0400)] <awills> if you look at 3.0.2 GA the line ##s match up
[17:20:04 EDT(-0400)] <EricDalquist> looking at the code in AbstractHashedMap
[17:20:19 EDT(-0400)] <awills> but what would cause a RUNNABLE thread to spin up the CPU +50%?
[17:20:31 EDT(-0400)] <EricDalquist> http://uportal.pastebin.com/m7c0d23f4
[17:20:49 EDT(-0400)] <EricDalquist> if "entry == entry.next"
[17:20:51 EDT(-0400)] <EricDalquist> you have your bug
[17:21:14 EDT(-0400)] <EricDalquist> also a deadlock wouldn't cause an CPU utilization since the threads would be locked
[17:21:43 EDT(-0400)] <EricDalquist> a thread in RUNNABLE using an entire CPU implies a tight loop or some such
[17:22:07 EDT(-0400)] <EricDalquist> so perhaps this is the non-threadsaftey showing
[17:22:20 EDT(-0400)] <EricDalquist> resulting in a Map node that points to itself for next
[17:22:23 EDT(-0400)] <EricDalquist> which would cause a problem
[17:22:33 EDT(-0400)] <EricDalquist> not sure what it would do to performance
[17:22:33 EDT(-0400)] <awills> what does it take to make a channel system-cachable? (accross users) it was my impression that usually they're not set up that way
[17:22:51 EDT(-0400)] <EricDalquist> but an easy fix would be to wrap the thing with Collections.synchronizedMap
[17:22:59 EDT(-0400)] <awills> yeah that's what we proposed
[17:23:26 EDT(-0400)] <EricDalquist> no idea
[17:23:33 EDT(-0400)] <EricDalquist> I've never really looked into that stuff
[17:23:37 EDT(-0400)] <awills> well, since I already spoke w/ you on it, wanted to bring you up to speed before I made a JIRA
[17:23:50 EDT(-0400)] <awills> but I'm happy to do that now
[17:24:36 EDT(-0400)] <EricDalquist> the other option
[17:24:40 EDT(-0400)] <EricDalquist> if they are on 3.x
[17:24:50 EDT(-0400)] <EricDalquist> would be to switch it out with an EhCache backed Map
[17:25:06 EDT(-0400)] <awills> yes, i think that's the better option
[17:25:10 EDT(-0400)] <EricDalquist> the thing to be sure of there is that you can't staticly initialize it
[17:25:19 EDT(-0400)] <EricDalquist> you need to look up the Map each time it is referenced
[17:25:23 EDT(-0400)] <EricDalquist> since this code is not spring managed
[18:09:30 EDT(-0400)] * athena7 (n=athena@adsl-75-58-127-15.dsl.wlfrct.sbcglobal.net) has joined ##uportal
General
Content
Integrations