Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 26 Next »

[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> (smile)
[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.
[17:43:40 EDT(-0400)] <pberry> we ran ALM pretty well for almost 2 years
[17:44:13 EDT(-0400)] <pberry> Liking DLM a lot more, although ALM had some nice concepts. Implementation was a bit, shaky
[17:45:24 EDT(-0400)] <EricDalquist> are there things about ALM that you miss now that you're on DLM?
[17:45:34 EDT(-0400)] <EricDalquist> (just curious so they can be addressed as we go forward)
[17:47:18 EDT(-0400)] <pberry> I liked the fragment manager interface
[17:47:28 EDT(-0400)] <pberry> I liked that I didn't need a user for each fragment
[17:47:36 EDT(-0400)] <pberry> but that might be hard because of the power of DLM
[17:48:03 EDT(-0400)] <EricDalquist> both are good issues and things that will hopefully be addressed eventually
[17:48:05 EDT(-0400)] <pberry> for instance, right now with the way channels you don't have permission to see are silently dropped from the layout lets us to all kinds of nice things
[17:48:23 EDT(-0400)] <pberry> do all
[17:49:13 EDT(-0400)] <pberry> we have this horrid service that all first semester students have to do or they get a hold placed on their registration. Right now we can have that channel in the student layout, but only give perms to that group of students, so only they see it.
[17:49:28 EDT(-0400)] <EricDalquist> (smile)
[17:49:31 EDT(-0400)] <pberry> In ALM, I had to have two different, almost identical tabs. Please don't make me go back!
[17:49:37 EDT(-0400)] <EricDalquist> lol
[17:49:52 EDT(-0400)] <EricDalquist> well I'm out for the day ... catch everyone tomorrow
[17:49:54 EDT(-0400)] <pberry> they had to have the same tab name, which caused, at times, some confusion
[17:50:06 EDT(-0400)] <apetro_work_desk> that would cause confusing
[17:50:08 EDT(-0400)] <apetro_work_desk> confusion
[17:50:16 EDT(-0400)] <apetro_work_desk> I hear ya on the clever ways to use DLM to do this sort of thing
[17:50:23 EDT(-0400)] <apetro_work_desk> but i still wonder whether there's value in
[17:50:29 EDT(-0400)] <apetro_work_desk> mainstreaming Rutgers Alerts
[17:50:39 EDT(-0400)] <apetro_work_desk> which raised alerts to a first order portal concept
[17:51:01 EDT(-0400)] <apetro_work_desk> could interrupt the login experience to first present alerts, even make some alerts that you couldn't get rid of till you dealt with them
[17:51:09 EDT(-0400)] <pberry> it's a nice feature, but you will be dooming implementors
[17:51:23 EDT(-0400)] <apetro_work_desk> how's that?
[17:51:41 EDT(-0400)] <pberry> it opens a can of "people problems" the size of Texas
[17:52:01 EDT(-0400)] <pberry> how gets to send alerts, when, how often, to what groups
[17:52:04 EDT(-0400)] <pberry> how do you define groups
[17:52:12 EDT(-0400)] <apetro_work_desk> yes
[17:52:30 EDT(-0400)] <pberry> again, technology is awesome
[17:52:35 EDT(-0400)] <apetro_work_desk> sort of, you have these problems already, you're just solving them with DLM tricks rather than a dedicated alerts system
[17:52:55 EDT(-0400)] <pberry> well, we're about to roll out the Academus Toro notification thingy
[17:53:01 EDT(-0400)] <pberry> so, I'm in the process of doing both
[17:53:15 EDT(-0400)] <pberry> which is how I discovered all these awesome people problems (wink)
[17:53:20 EDT(-0400)] <pberry> brb, snack time
[18:39:13 EDT(-0400)] <apetro_work_desk> snacking on Junior Caramels here. Not half bad, but they melted on the walk back from the convenience store

  • No labels