[09:51:39 EDT(-0400)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[09:52:12 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:56:18 EDT(-0400)] <EricDalquist> morning
[10:08:23 EDT(-0400)] <esm> morning
[10:09:21 EDT(-0400)] <EricDalquist> I'm way behind on maven for the trunk
[10:09:31 EDT(-0400)] <EricDalquist> these 2.6 issues are sucking up the time
[10:09:45 EDT(-0400)] <esm> yeah if you want I can take a look at it
[10:09:56 EDT(-0400)] <esm> probably not until Friday though
[10:10:09 EDT(-0400)] <EricDalquist> that would probably be helpful just to review what I've done so far
[10:10:27 EDT(-0400)] <EricDalquist> so right now I'm thinking of still doing an EAR file
[10:10:43 EDT(-0400)] <EricDalquist> and then having a tomcat specific assembly for dealing with container wide JDBC drivers
[10:12:02 EDT(-0400)] <esm> ok
[10:12:12 EDT(-0400)] <esm> so the tomcat-specific assembly will be an overlay?
[10:12:18 EDT(-0400)] <EricDalquist> yeah
[10:12:24 EDT(-0400)] <esm> user cd's into their tomcat directory and unzips the overlay?
[10:12:25 EDT(-0400)] <esm> ok
[10:12:37 EDT(-0400)] <esm> that sounds cool
[10:12:50 EDT(-0400)] <EricDalquist> it would explode the EAR into webapps and shared/lib directories
[10:12:57 EDT(-0400)] <EricDalquist> then add the JDBC driver to common/lib
[10:13:10 EDT(-0400)] <EricDalquist> that last bit is all that the assembly needs to do
[10:17:25 EDT(-0400)] <esm> so the entire uportal distribution is packaged as a tomcat overlay?
[10:17:50 EDT(-0400)] <EricDalquist> there would likely need to be a dist assembly as well
[10:18:01 EDT(-0400)] <EricDalquist> that included some documentation with the tomcat overlay
[10:18:36 EDT(-0400)] <esm> yeah
[10:19:05 EDT(-0400)] <esm> the tomcat overlay distribution would already be packaged with the webapps exploded
[10:19:15 EDT(-0400)] <esm> so there won't be an ear file in the overlay right?
[10:19:22 EDT(-0400)] <EricDalquist> correct
[10:19:27 EDT(-0400)] <esm> ok
[10:19:47 EDT(-0400)] <EricDalquist> so we'll likely end up having some disccusions about how we want to package distributions
[10:20:10 EDT(-0400)] <EricDalquist> there could be the option of having a tomcat-dist and a generic-dist
[10:20:28 EDT(-0400)] <esm> well
[10:20:39 EDT(-0400)] <esm> right now we'd have to have a tomcat-5-dist and a tomcat-6-dist
[10:20:51 EDT(-0400)] <EricDalquist> with the generic having the same documentation but packaging the actual EAR in it
[10:20:52 EDT(-0400)] <EricDalquist> yeah
[10:21:01 EDT(-0400)] <esm> or i guess we just decide to support one or the other
[10:21:08 EDT(-0400)] <EricDalquist> 
[10:21:19 EDT(-0400)] <EricDalquist> for now the target is tomcat 55
[10:21:27 EDT(-0400)] <EricDalquist> we'll see where we go from here
[10:22:20 EDT(-0400)] <EricDalquist> right now I think I have enough of a plan sketched out so I can complete mavenizing the current code base
[10:22:28 EDT(-0400)] <EricDalquist> so we can start on the other tasks
[10:22:43 EDT(-0400)] <esm> ok
[10:23:02 EDT(-0400)] <EricDalquist> some of this is going to be a bit ugly until we get other pieces in place
[10:23:22 EDT(-0400)] <EricDalquist> like I think the EAR packaging and running the deployer on the portlet WARs is going to be a bit hackish for a while
[10:23:42 EDT(-0400)] <EricDalquist> at least until we get to pluto 1.1 and can use the nice ear packager you made in the sandbox
[10:25:32 EDT(-0400)] <esm> I agree, we just need to be practical and not get too fancy as we move through this
[10:25:39 EDT(-0400)] <esm> (I always try to get too fancy)
[10:25:41 EDT(-0400)] <EricDalquist> yup
[10:25:53 EDT(-0400)] <esm> we can add the polish later
[10:26:25 EDT(-0400)] <EricDalquist> yup
[12:00:52 EDT(-0400)] * pberry (n=pberry@waldorf.CSUChico.EDU) has joined ##uportal
[12:15:46 EDT(-0400)] <pberry> Greetings, programs!
[12:18:47 EDT(-0400)] <pberry> So, does everybody see memory usage like this? http://tinyurl.com/2apf2x
[12:26:28 EDT(-0400)] <EricDalquist> yes
[12:26:32 EDT(-0400)] <EricDalquist> well
[12:26:33 EDT(-0400)] <EricDalquist> wait
[12:26:38 EDT(-0400)] <EricDalquist> is that OS memory usage?
[12:26:42 EDT(-0400)] <pberry> JVM
[12:26:48 EDT(-0400)] <EricDalquist> then yes
[12:26:51 EDT(-0400)] <pberry> cool
[12:26:54 EDT(-0400)] <pberry> 1.5
[12:26:57 EDT(-0400)] <EricDalquist> our saw tooth is much faster
[12:26:58 EDT(-0400)] <pberry> Sun
[12:27:13 EDT(-0400)] <EricDalquist> though we don't do full GCs very often
[12:27:33 EDT(-0400)] <EricDalquist> we have our GCs tuned to do concurrent collection of the survivor and tenured space
[12:27:45 EDT(-0400)] <EricDalquist> and the new space is a parallel collector
[12:27:55 EDT(-0400)] <EricDalquist> so we see a fast sawtooth for eden space
[12:27:55 EDT(-0400)] <pberry> I'm on default -server settings
[12:28:15 EDT(-0400)] <EricDalquist> and then maybe one full GC a day which deals more with code cache space than tenured
[12:28:43 EDT(-0400)] <EricDalquist> http://www.ja-sig.org/wiki/display/UPC/uPortal+Heap+Tuning
[12:28:52 EDT(-0400)] <EricDalquist> http://www.ja-sig.org/wiki/display/UPC/JVM+Configurations
[12:34:35 EDT(-0400)] <apetro_work_desk> with due respect to Paul, I really liked my proposed approach of shut everything down and then bring it all up again, rather than the whack-a-mole process guessing
[12:35:04 EDT(-0400)] <EricDalquist> yeah ... I was going to volunteer to do it late this evening to avoid impack
[12:35:07 EDT(-0400)] <EricDalquist> impact*
[12:35:09 EDT(-0400)] <EricDalquist> oh well
[12:35:24 EDT(-0400)] <apetro_work_desk> yeah
[12:35:33 EDT(-0400)] <apetro_work_desk> I'm not sure the out-of-business-hours timing is necessary
[12:35:40 EDT(-0400)] <apetro_work_desk> I mean, all down, all up, takes what, ten minutes?
[12:35:47 EDT(-0400)] <apetro_work_desk> on the outside?
[12:35:57 EDT(-0400)] <EricDalquist> on the ja-sig box?
[12:36:00 EDT(-0400)] <EricDalquist> 20 to 30
[12:36:04 EDT(-0400)] <apetro_work_desk> really?>
[12:36:06 EDT(-0400)] <EricDalquist> you have to wait for each TC to start
[12:36:07 EDT(-0400)] <apetro_work_desk> what takes forever to start?
[12:36:09 EDT(-0400)] <EricDalquist> and it is a SLOW box
[12:36:14 EDT(-0400)] <apetro_work_desk> sigh
[12:36:31 EDT(-0400)] <EricDalquist> confluence, jira and fisheye are all 2-5 minute start times
[12:36:58 EDT(-0400)] <EricDalquist> and equal clean shutdown times
[12:37:38 EDT(-0400)] <EricDalquist> oh well ... eventaully we'll get this new box actually up and ssh'able to
[12:37:42 EDT(-0400)] <EricDalquist> and then we can start moving things
[12:44:40 EDT(-0400)] <pberry> Confluence is a hog on startup
[12:44:55 EDT(-0400)] <EricDalquist> yup
[12:50:12 EDT(-0400)] <pberry> "Set the initial & max heap size to the same value."
[12:50:14 EDT(-0400)] <pberry> hrm
[12:50:20 EDT(-0400)] <pberry> that does seem like a good idea
[12:51:39 EDT(-0400)] <EricDalquist> yeah
[12:51:43 EDT(-0400)] <EricDalquist> less work for the JVM & OS
[12:53:23 EDT(-0400)] <pberry> On our Confluence install we had to crank MaxPermSize to 128m
[12:53:36 EDT(-0400)] <EricDalquist> if you need me IM loudly .... I'm going to be whitboarding for a bit
[12:59:25 EDT(-0400)] <apetro_work_desk> try not to succumb to marker fumes
[13:15:50 EDT(-0400)] <esm> pberry: we had to bump perm gen as well
[13:19:00 EDT(-0400)] <pberry> we haven't had a problem since we did that
[13:22:03 EDT(-0400)] <esm> yeah
[16:16:31 EDT(-0400)] <apetro_work_desk> So, how does anyone actually survive the experience of using ALM with bugs like UP-1164?
[16:31:48 EDT(-0400)] <EricDalquist> wow
[16:31:51 EDT(-0400)] <EricDalquist> that's ugly
[16:43:50 EDT(-0400)] <esm> lol
[17:32:15 EDT(-0400)] <apetro_work_desk> I was all ready to merge it into 2-6-patches
[17:32:21 EDT(-0400)] <apetro_work_desk> extra goodness for the delay on 2.6.1
[17:32:26 EDT(-0400)] <apetro_work_desk> but no, already fixed there
[17:33:16 EDT(-0400)] <apetro_work_desk> there's a pretty good marketing story to tell at this point around, look, even if you want to stay on ALM cuz you're heavily invested in it, etc., etc., upgrade to 2.6.0 for all the fixes. Awful lot of fixes in there.
General
Content
Integrations