[08:31:56 EDT(-0400)] * esm (n=esm@clue.mse.jhu.edu) has joined ##uportal
[08:33:18 EDT(-0400)] * esm (n=esm@clue.mse.jhu.edu) has joined ##uportal
[10:15:09 EDT(-0400)] <EricDalquist> morning
[10:15:17 EDT(-0400)] <EricDalquist> esm on the merge stuff
[10:15:26 EDT(-0400)] <EricDalquist> one massive merge sounds like a lot less work
[10:15:32 EDT(-0400)] <esm> EricDalquist: i agree
[10:36:45 EDT(-0400)] * pberry (n=pberry@waldorf.CSUChico.EDU) has joined ##uportal
[10:42:39 EDT(-0400)] <EricDalquist> morning pat
[10:43:01 EDT(-0400)] <pberry> hola
[10:43:16 EDT(-0400)] <pberry> How is the Great White North?
[10:43:18 EDT(-0400)] <pberry>
[10:43:23 EDT(-0400)] <EricDalquist> wet
[10:43:25 EDT(-0400)] <EricDalquist> and stormy
[10:43:41 EDT(-0400)] <EricDalquist> and actually quite green
[10:43:50 EDT(-0400)] <pberry> sounds like spring to me
[10:44:01 EDT(-0400)] <EricDalquist> yup
[10:44:31 EDT(-0400)] <pberry> Eric, you guys running on tomcat?
[10:44:52 EDT(-0400)] <EricDalquist> yup
[10:44:58 EDT(-0400)] <EricDalquist> 5.5.20 I believe
[10:45:05 EDT(-0400)] <pberry> are you guys clustering for session replication?
[10:45:10 EDT(-0400)] <EricDalquist> nope
[10:45:21 EDT(-0400)] <EricDalquist> management brings session replication up every few months
[10:45:32 EDT(-0400)] <pberry> heh
[10:45:36 EDT(-0400)] <EricDalquist> my standard response is 'what problems do we have that session repl would solve'
[10:45:44 EDT(-0400)] <EricDalquist> and no one has given me a good answer yet
[10:45:51 EDT(-0400)] <EricDalquist> we don't have server crashes
[10:45:54 EDT(-0400)] <pberry> bringing down a node and not losing the user sessions on that node
[10:46:10 EDT(-0400)] <EricDalquist> we don't do updates during times of high use
[10:46:18 EDT(-0400)] <pberry> yeah
[10:46:21 EDT(-0400)] <pberry> that works too
[10:46:25 EDT(-0400)] <EricDalquist> we have a weekly 2 hour window that we do maintenance
[10:46:32 EDT(-0400)] <pberry> ahhh...
[10:46:36 EDT(-0400)] <EricDalquist> we do a rolling rsync/restart during that time
[10:46:39 EDT(-0400)] <pberry> yeah, we don't have that (for the portal)
[10:47:02 EDT(-0400)] <EricDalquist> if you happen to be on the machine that gets removed from the l4 you do loose your session but with SSO you just get bounced to the main tab
[10:47:09 EDT(-0400)] <EricDalquist> and we don't have a lot of statefull apps in the portal
[10:47:39 EDT(-0400)] <EricDalquist> and our 2 hour window starts at 5am tuesday mornings
[10:47:47 EDT(-0400)] <pberry> we do what I call The Portal Dance. The guy who runs the Cisco gear sets the weight for one box to 0 and we wait for the sessions to "drain"
[10:47:49 EDT(-0400)] <EricDalquist> when we have very little traffic
[10:48:05 EDT(-0400)] <EricDalquist> brb
[10:48:08 EDT(-0400)] <pberry> lather, rinse, repeat until all production boxes are done
[12:08:48 EDT(-0400)] <EricDalquist> sorry bout that
[12:08:53 EDT(-0400)] <EricDalquist> some post incident review stuff here
[12:11:43 EDT(-0400)] <pberry> ugh
[12:11:48 EDT(-0400)] <pberry> hope it wasn't security related
[12:11:52 EDT(-0400)] <EricDalquist> nope
[12:12:01 EDT(-0400)] <pberry> just a typical developer knife fight?
[12:12:02 EDT(-0400)] <EricDalquist> oracle's JDBC driver giving me hearburn
[12:12:18 EDT(-0400)] <pberry> Oh man...tell me about.
[12:12:36 EDT(-0400)] <pberry> It's enough to make you switch to mysql
[12:12:36 EDT(-0400)] <EricDalquist> twice now we've gotten into this weird state where connections to the DB fail (throw an exception) but the driver leaves the sockets open
[12:12:47 EDT(-0400)] <EricDalquist> eventually hitting the limit of the listener
[12:12:59 EDT(-0400)] <EricDalquist> and rolling restarts don't clear the problem
[12:13:02 EDT(-0400)] <pberry> I think we've seen something like that as well
[12:13:06 EDT(-0400)] <EricDalquist> we have to shut all the servers down
[12:13:09 EDT(-0400)] <EricDalquist> and start them back up
[12:13:33 EDT(-0400)] <pberry> We have some luck with restarting the listener
[12:14:27 EDT(-0400)] <EricDalquist> the weird thing is the 'bad connects' seem to be specific to the user
[12:14:33 EDT(-0400)] <EricDalquist> other users can connect to the db ok
[12:14:37 EDT(-0400)] <EricDalquist> but the portal user always fails
[12:14:43 EDT(-0400)] <EricDalquist> untill we do the full restart
[12:14:46 EDT(-0400)] <EricDalquist> hrm
[12:14:55 EDT(-0400)] <EricDalquist> I'm not sure if we've tried that
[12:15:07 EDT(-0400)] <pberry> I love how it wont reconnect to a database if it restarts
[12:15:17 EDT(-0400)] <pberry> the db that is
[12:15:46 EDT(-0400)] <pberry> we had some real trouble with one db lately (it gets refreshed nightly from PeopleSoft)
[12:15:57 EDT(-0400)] <pberry> luckily it was only for secondary group info
[12:16:10 EDT(-0400)] <pberry> but still...the friggin' mysql drivers will reconnect...
[12:16:15 EDT(-0400)] <EricDalquist>
[12:16:17 EDT(-0400)] <pberry> EricDalquist: you using the OCI or the thin?
[12:16:20 EDT(-0400)] <EricDalquist> thin
[12:16:27 EDT(-0400)] <pberry> same here...
[12:16:35 EDT(-0400)] <EricDalquist> Oracle requested that we try switching to OCI
[12:16:41 EDT(-0400)] <EricDalquist> but I'm not sure we will
[12:17:03 EDT(-0400)] <EricDalquist> I'd rather run as little native code as possible in the portal
[12:17:36 EDT(-0400)] <pberry> that was our thought as well...
[12:18:02 EDT(-0400)] <EricDalquist> and it is just avoiding this issue that their JDBC driver can leak resource
[12:18:05 EDT(-0400)] <EricDalquist> resources*
[12:18:51 EDT(-0400)] <pberry> yup
[16:26:49 EDT(-0400)] <EricDalquist> hows things in IRC lang?
[16:26:51 EDT(-0400)] <EricDalquist> land*
[17:04:39 EDT(-0400)] <pberry> very quiet
[17:22:22 EDT(-0400)] <EricDalquist>
[17:32:05 EDT(-0400)] <andrew_petro_ubu> Pat, were you looking for me before?
[17:32:39 EDT(-0400)] * andrew_petro_ubu (n=apetro@uni1.unicon.net) has left ##uportal
[17:33:48 EDT(-0400)] * andrew_petro_ubu (n=apetro@uni1.unicon.net) has joined ##uportal
General
Content
Integrations