Page Comparison

[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