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 39 Next »

[23:59:47 EDT(-0400)] * colinclar1 (n=atrcwrk2@bas5-toronto63-1096706696.dsl.bell.ca) has joined ##uportal
[00:00:02 EDT(-0400)] * colinclar1 (n=atrcwrk2@bas5-toronto63-1096706696.dsl.bell.ca) has left ##uportal
[08:48:54 EDT(-0400)] * colinclark (n=atrcwrk2@bas5-toronto63-1096706696.dsl.bell.ca) has joined ##uportal
[08:55:19 EDT(-0400)] * jayshao (n=jayshao@jayshao.rutgers.edu) has joined ##uportal
[09:00:37 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:42:23 EDT(-0400)] <EricDalquist> anyone know an easy way to switch the license in a bunch of files?
[10:42:54 EDT(-0400)] * colinclark (n=atrcwrk2@bas5-toronto63-1096706696.dsl.bell.ca) has joined ##uportal
[10:54:54 EDT(-0400)] * pberry (n=pberry@waldorf.CSUChico.EDU) has joined ##uportal
[11:46:01 EDT(-0400)] * esm (n=esm@esm.qis.net) has joined ##uportal
[11:46:08 EDT(-0400)] <esm> humph.
[11:46:34 EDT(-0400)] <pberry> yeah
[11:46:36 EDT(-0400)] <pberry> Friday
[11:46:40 EDT(-0400)] <esm> (smile)
[11:46:58 EDT(-0400)] <pberry> my motivation is dropping when I need it most
[11:47:20 EDT(-0400)] <esm> yeah same. This pesky portlet session problem takes a lot of concentration.
[11:47:26 EDT(-0400)] <esm> i am working from home to focus
[11:47:38 EDT(-0400)] <esm> (people in my office are very entertaining and great, but distracting sometimes)
[11:59:16 EDT(-0400)] <esm> ok bbiab
[11:59:26 EDT(-0400)] * esm takes a deep breath, goes under
[11:59:32 EDT(-0400)] <EricDalquist> have fun
[12:32:10 EDT(-0400)] * lescour (n=JBouncer@adsl-38-10-98.tulsaconnect.com) has joined ##uportal
[13:24:51 EDT(-0400)] <EricDalquist> ant macrodefs are wonderful things
[13:40:32 EDT(-0400)] * esm (n=esm@esm.qis.net) has joined ##uportal
[13:48:41 EDT(-0400)] <EricDalquist> how's the portlet session research going esm?
[13:48:46 EDT(-0400)] <esm> ok
[13:49:27 EDT(-0400)] <esm> The pluto portlet session is backed by an http session object.
[13:50:24 EDT(-0400)] <esm> Pluto's PortletRequestImpl manages the portletsession - it instantiates it and maintains the session as part of the portlet request's internal state.
[13:51:18 EDT(-0400)] <esm> in the getPortletSession() method (of the portlet request impl) there is logic which determines whether or not the backing http session is valid.
[13:53:37 EDT(-0400)] <esm> even if the backing http session is valid, the portletrequestimpl requests a new httpsession object from its super class: super.getRequest().getSession(true)
[13:54:06 EDT(-0400)] <EricDalquist> hrm well getSession() and getSession(true) should be the exact same behavior
[13:54:18 EDT(-0400)] <esm> point being that a valid backing httpsession may already exist but portlet request impl requests another one anyway
[13:54:19 EDT(-0400)] <esm> right.
[13:54:20 EDT(-0400)] <esm> so
[13:54:49 EDT(-0400)] <esm> sometimes the getSession(true) call returns a different session object than the original httpSession object.
[13:55:23 EDT(-0400)] <EricDalquist> that's not cool
[13:55:28 EDT(-0400)] <esm> and that different http session object is "bad" in that it has none of the request attributes, etc.
[13:57:12 EDT(-0400)] <EricDalquist> hrm
[13:58:34 EDT(-0400)] <EricDalquist> is tomcat handling getSession(true) differently than getSession()?
[13:58:52 EDT(-0400)] <esm> I haven't looked at the tomcat source yet
[13:59:15 EDT(-0400)] <esm> most of the time, getSession(true) is returning the same object that getSession(false) is.
[14:01:28 EDT(-0400)] <esm> the reason this isn't a problem on every request is because two conditions need to be met: the session from getSession needs to be the bogus session, and PortletRequestImpl must have a null PortletSession - e.g. the bogus session must be returned on the first call to getPortletSession()
[14:02:44 EDT(-0400)] <esm> i guess i'm going to dig up the tomcat source
[14:15:01 EDT(-0400)] <esm> http://rafb.net/p/Uabfi621.html
[14:15:33 EDT(-0400)] <esm> when you enter the method the backing http session is org.apache.catalina.session.StandardSessionFacade@13fde6e
[14:15:53 EDT(-0400)] <esm> but after calling getSession(true) it is org.apache.catalina.session.StandardSessionFacade@1ffb7d4
[14:16:13 EDT(-0400)] <EricDalquist> that is weird
[14:16:20 EDT(-0400)] <esm> 13fde6e is the "good" session and 1ffb7d4 is the "bad" one
[14:16:29 EDT(-0400)] <esm> normally, they are the same
[14:17:06 EDT(-0400)] <esm> you can see that 13fde6e has "good" attributes while the others have none.
[14:17:07 EDT(-0400)] <esm> yeah
[14:17:23 EDT(-0400)] <EricDalquist> are there multiple portlets for the one web-app on the page?
[14:17:46 EDT(-0400)] <esm> no. the page has three portlets on it, but each of them are in their own web app.
[14:18:24 EDT(-0400)] <EricDalquist> and nothing in the logs is pointing to interaction between the sessions form the differing webapps?
[14:20:20 EDT(-0400)] <esm> sometimes the good facade ends up associated to other requests.
[14:20:26 EDT(-0400)] <esm> if that makes sense
[14:21:37 EDT(-0400)] <esm> hmm one sec i want to say no but...
[14:30:14 EDT(-0400)] <esm> no it does not normally change.
[14:31:40 EDT(-0400)] <esm> Sometimes I see the good facade associated with other render requests for another portlet.
[14:31:45 EDT(-0400)] <esm> for example
[14:32:15 EDT(-0400)] <esm> The portlet that has the problem renders on threads: 95, 107, 116, 125, 134. Each thread is one render request cycle.
[14:33:14 EDT(-0400)] <esm> sometimes the "good" facade shows up on other threads for (presumably) the other portlets on the page
[14:33:47 EDT(-0400)] <esm> on threads 95, 107, 116, the facade object is the same.
[14:34:30 EDT(-0400)] <esm> thread 125 gets a bad facade object, but the portlet request has already created the portlet session, so the bad facade never ends up being used.
[14:34:38 EDT(-0400)] <EricDalquist> so I wonder if you synchronize on the HttpServletRequest around the getSession calls what would happen
[14:34:40 EDT(-0400)] <esm> thred 134 is where it is a problem.
[14:34:54 EDT(-0400)] <esm> yeah good question.
[14:35:36 EDT(-0400)] <EricDalquist> since the base HttpServletRequest object that uPortal passes to pluto is shared
[14:35:52 EDT(-0400)] <EricDalquist> though since pluto does the cross-context call each portlet should have its own request ...
[15:02:57 EDT(-0400)] * lescour (n=JBouncer@adsl-38-10-98.tulsaconnect.com) has joined ##uportal
[15:08:42 EDT(-0400)] * esm goes back to the vpn
[15:16:17 EDT(-0400)] <jayshao> jayshao - can't see anything again... need... new... IRC... client...
[15:18:13 EDT(-0400)] <EricDalquist> lol
[16:03:22 EDT(-0400)] <EricDalquist> anyone still awake?
[16:08:56 EDT(-0400)] <colinclark> I am vaguely awake.
[16:09:01 EDT(-0400)] <colinclark> (tongue)
[16:10:07 EDT(-0400)] <EricDalquist> I'm having fun trying to clone the up2 build.xml to work with the maven version
[16:10:30 EDT(-0400)] <EricDalquist> it is all pretty much there
[16:11:57 EDT(-0400)] <colinclark> Wow, that's great. We have found just the migration from Maven 1 to 2 has been a terrible pain, but porting from Ant to M2 must have taken awhile!
[16:12:30 EDT(-0400)] <EricDalquist> well getting uPortal to build under maven2 was about a week, getting it to run after re-arranging things was another week
[16:12:52 EDT(-0400)] <colinclark> That's pretty good!
[16:12:58 EDT(-0400)] <EricDalquist> and now another week getting the ant tasks that we had in the build.xml working again
[16:18:56 EDT(-0400)] <colinclark> Nice work.
[16:19:14 EDT(-0400)] <EricDalquist> thanks
[16:28:34 EDT(-0400)] * colinclark (n=atrcwrk2@bas5-toronto63-1096706696.dsl.bell.ca) has left ##uportal

  • No labels