uPortal IRC Logs-2007-09-11

[04:03:52 EDT(-0400)] * jayshao (n=jayshao@pool-72-79-81-19.nwrknj.east.verizon.net) has joined ##uportal
[07:50:41 EDT(-0400)] * jayshao (n=jayshao@jayshao.rutgers.edu) has joined ##uportal
[07:53:54 EDT(-0400)] * jayshao (n=jayshao@jayshao.rutgers.edu) has joined ##uportal
[08:56:33 EDT(-0400)] * esm (n=esm@asdf.dkc.jhu.edu) has joined ##uportal
[09:34:36 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[09:38:26 EDT(-0400)] <esm> so the portlet session bug still exists in HEAD of 2-6 patches
[09:38:44 EDT(-0400)] <EricDalquist> hrm
[09:38:50 EDT(-0400)] <esm> i have to do some other stuff this morning but I'll start debugging this afternoon
[09:39:15 EDT(-0400)] <esm> when i built tomcat, i did it in /tmp
[09:39:19 EDT(-0400)] <esm> and i've since rebooted
[09:39:22 EDT(-0400)] <EricDalquist> oops
[09:39:43 EDT(-0400)] <EricDalquist> well since CPortletAdapter isn't multithreaded in 2.6 just syncing on getMarkup won't help much since each portlet on the page will have its own CPortletAdapter instance
[09:39:44 EDT(-0400)] <esm> so i have to rebuild and figure out what i did it my caffenninated, sleep-deprived state
[09:40:11 EDT(-0400)] <esm> i don't think syncing on getMarkup() would help anyway, even in 2.5.
[09:41:15 EDT(-0400)] <esm> so yeah if CPA is no longer a singleton and multi-threaded in 2.6, my guess is that CPA is instantiated and each instance is given a reference to the request.
[09:41:29 EDT(-0400)] <esm> *not multi-threaded
[09:41:44 EDT(-0400)] <esm> to the same request.
[09:42:07 EDT(-0400)] <EricDalquist> how does tomcat track the sessionfacade object again? is it in an instance variable in the request or through an internal request attribute or some such?
[09:42:22 EDT(-0400)] <esm> it is a member variable of the ApplicationHttpRequest
[09:43:56 EDT(-0400)] <EricDalquist> hrm
[09:44:21 EDT(-0400)] <esm> either that gets fixed in tomcat or the renderer has to send the requests to CPA serially instead of in parallel.
[09:44:36 EDT(-0400)] <EricDalquist> heh, that would be pretty bad
[09:45:10 EDT(-0400)] <esm> right. well, the same request object can't be rendered simulaneously by multiple threads, right?
[09:45:12 EDT(-0400)] <EricDalquist> is the only reason we don't see this in pluto 1.1 is that it renders serially?
[09:45:20 EDT(-0400)] <EricDalquist> yeah :/
[09:45:23 EDT(-0400)] <esm> i'm not sure. I'm wondering that myself actually.
[09:45:57 EDT(-0400)] <esm> I'll peek at the 1.1. invoker today and see what it is doing.
[09:47:10 EDT(-0400)] <EricDalquist> I wonder if there is a way in CPA to sync on the request when dispatching to pluto
[09:49:09 EDT(-0400)] <esm> hm.
[09:49:40 EDT(-0400)] <EricDalquist> oh and how does the ApplicationHttpRequest populate that member variable? (I should go grab the TC code)
[09:50:13 EDT(-0400)] <esm> thats where there is what I think is a bug
[09:51:36 EDT(-0400)] <esm> it calls super().getSession() and then it asks the Manager for the context to "convert" it into a session local to the context.
[09:52:32 EDT(-0400)] <EricDalquist> do you know which step in there the bad session appears?
[09:52:32 EDT(-0400)] <esm> I think AHR should check to see if the session it recieves from the super class has already been localized to the context, and just return it.
[09:53:36 EDT(-0400)] <esm> yeah.
[09:53:53 EDT(-0400)] <EricDalquist> I'm still trying to figure out why we don't see this problem
[09:54:12 EDT(-0400)] <esm> but its a race condition where AHR's super class is sometimes a RequestFacade, and somtimes AHR's super class is another AHR.
[09:54:45 EDT(-0400)] <esm> well, you may have code to guard agaisnt this issue
[09:54:55 EDT(-0400)] <esm> without even realizing it
[09:55:01 EDT(-0400)] <EricDalquist> ?
[09:55:42 EDT(-0400)] <esm> In my portlet, initial requests go to Controller A. Controller A puts stuff in the Session. Subsequent requests are routed to Controller B.
[09:55:53 EDT(-0400)] <esm> Controller B assumes that the objects are in the session.
[09:56:25 EDT(-0400)] <EricDalquist> When this came up though I deployed a test portlet twice and added it to a page a few times
[09:56:38 EDT(-0400)] <EricDalquist> all it does is allow you do add things to the session and dump everything in the session
[09:56:41 EDT(-0400)] <esm> Maybe I should work on coding a simple test portlet.
[09:56:57 EDT(-0400)] <EricDalquist> once objects are added I could never get them to disappear
[09:59:46 EDT(-0400)] <esm> yeah i guess i am not sure what to say... except that its a race condition that may not be being triggered by your test portlet.
[10:00:09 EDT(-0400)] <EricDalquist>
[10:00:21 EDT(-0400)] <esm> I did discover the Spring accesses the session very early in its render cycle
[10:00:28 EDT(-0400)] <esm> but.. i dunno.
[10:00:41 EDT(-0400)] <esm> i didn't see spring doing anything real funky.
[10:01:12 EDT(-0400)] <EricDalquist> I'm still wondering if our unwrappable wrapper is 'fixing' this for us
[10:01:42 EDT(-0400)] <esm> i'm not sure. because on dispatch tomcat will unwrap down to your unwrappable wrapper, and put an AHR around it.
[10:01:59 EDT(-0400)] <esm> actually let me check to se....
[10:03:12 EDT(-0400)] <esm> does your wrapper just return null for calls to getRequest()?
[10:04:08 EDT(-0400)] <EricDalquist> it delegates to the parent for everything except for attribute releated APIs
[10:05:15 EDT(-0400)] <EricDalquist> http://rafb.net/p/5MTU5U25.html
[10:06:38 EDT(-0400)] <EricDalquist> so what we do ... and it may be time to get this into the core of uP
[10:06:52 EDT(-0400)] <EricDalquist> is we modified PCS to use ThreadLocals to track the request and response
[10:07:13 EDT(-0400)] <EricDalquist> and we pass those object explicitly into the constructor of the Worker in ChannelRenderer
[10:07:32 EDT(-0400)] <EricDalquist> when the Worker runs it sets the req/res on the PCS object in the channel rendering thread
[10:07:57 EDT(-0400)] <EricDalquist> in the constructor of the Worker is where we wrap the req/res that the portal has been working with up to that point in that attribute scoping wrapper
[10:10:42 EDT(-0400)] <esm> http://rafb.net/p/lzgo4t19.html the Tomcat ApplicationDispatcher wrap code
[10:10:43 EDT(-0400)] <EricDalquist> oh and do your question about getRequest() we (against the servlet spec) don't extend HttpServletRequestWrapper but implement the bare HttpServletRequest interface
[10:10:58 EDT(-0400)] <esm> right yeah I see that
[10:11:27 EDT(-0400)] <esm> the tomcat app dispatcher wraps your request object with an ApplicationRequest, instead of ApplicationHttpRequest
[10:11:36 EDT(-0400)] <esm> er
[10:11:46 EDT(-0400)] <EricDalquist> since I ran into that same code when dealing with the JSP rendering issue
[10:12:29 EDT(-0400)] <esm> no your request still gets wrapped with an AHR... so...
[10:14:05 EDT(-0400)] <esm> cool thanks for the info... i gotta get back to some other stuff but I'll def come back to this early afternoon unless something else here blows up.
[10:15:51 EDT(-0400)] <EricDalquist> no problem, this bug really worries me so I'm trying to help as much as possible
[10:19:40 EDT(-0400)] <esm> I really appreciate it
[10:19:49 EDT(-0400)] <EricDalquist> now a maven question ...
[10:19:54 EDT(-0400)] <esm> I'm sorry I don't have a reproducable test case
[10:19:57 EDT(-0400)] <esm> so...
[10:19:58 EDT(-0400)] <esm> sue
[10:20:00 EDT(-0400)] <esm> er
[10:20:03 EDT(-0400)] <esm> please don't sue me
[10:20:08 EDT(-0400)] <esm> shoot
[10:20:15 EDT(-0400)] <EricDalquist> lol
[10:20:16 EDT(-0400)] <esm> not that I want you to shoot me either
[10:20:19 EDT(-0400)] <esm> but anyway
[10:20:27 EDT(-0400)] <EricDalquist> http://rafb.net/p/EqSATX19.html
[10:20:46 EDT(-0400)] <esm> wth
[10:21:08 EDT(-0400)] <EricDalquist> the jasig-parent artifact exists in the jasig repo
[10:22:01 EDT(-0400)]

[10:22:56 EDT(-0400)] <esm> is that stuff committed to svn? Can i check it out and run it and get the same error?
[10:23:16 EDT(-0400)] <esm> 1) unspecified:unspecified:jar:0.0
[10:23:20 EDT(-0400)] <esm> that bothers me... its weird
[10:23:24 EDT(-0400)] <EricDalquist> yeah
[10:23:30 EDT(-0400)] <EricDalquist> or it will be in just on sec
[10:23:49 EDT(-0400)] <EricDalquist> once you get it '
[10:24:31 EDT(-0400)] <EricDalquist> 'ant initportal' from the root of the project should result in everything being setup (you need a hsql db running but you won't get that far unless things are working right)
[10:24:41 EDT(-0400)] <esm> ok thanks, i'm updating now
[10:25:06 EDT(-0400)] <EricDalquist> ok, just made the last commit ... rev 42434 is what you need
[10:25:36 EDT(-0400)] <esm> is ant just too dumb to go online and download the pom? but that doesn't make any kind of sense.
[10:25:54 EDT(-0400)] <esm> by ant i mean the artifact tasks. but still.
[10:26:14 EDT(-0400)] <EricDalquist> they usually do try to go download them
[10:26:17 EDT(-0400)] <EricDalquist> oh
[10:26:21 EDT(-0400)] <EricDalquist> well
[10:26:28 EDT(-0400)] <EricDalquist> you can get up to that point with ant 1.7 I think
[10:26:49 EDT(-0400)] <EricDalquist> but there is a bug in 1.7 that prevents the macrodefs in the build from working so you need a 1.6 version
[10:27:07 EDT(-0400)] <esm> lol ok
[10:27:19 EDT(-0400)] <EricDalquist> I do some crazy stuff with macrodefs
[10:27:21 EDT(-0400)] <esm> let me grab 1.6 one sec
[10:28:50 EDT(-0400)] <EricDalquist> well if I change the installation of the root pom to actually call 'mvn -N install' it looks to be working
[10:29:18 EDT(-0400)] <EricDalquist> I'd just rather use the artifact tasks since they're faster
[10:31:15 EDT(-0400)] <esm> which module?
[10:31:51 EDT(-0400)] <esm> bootstrap?
[10:32:07 EDT(-0400)] <EricDalquist> it failed installing the root pom of the uportal project via the artifact task
[10:32:25 EDT(-0400)] <EricDalquist> but installing the root pom of the uportal project by doing the mvn call works
[10:36:05 EDT(-0400)] <EricDalquist> oh well ... this will work, it will just be a bit slower and more verbose
[10:38:03 EDT(-0400)] <esm> lol sorry i'm just grokking the build
[10:38:19 EDT(-0400)] <EricDalquist> no problem
[10:38:26 EDT(-0400)] <EricDalquist> the macrodef stuff is really quite handy
[10:38:51 EDT(-0400)] <EricDalquist> it makes the build tasks semi-intelligent by re-building needed modules only if needed
[10:43:47 EDT(-0400)] <EricDalquist> don't worry about it esm, I'll just do the 'mvn -N install' call instead
[10:44:01 EDT(-0400)] <EricDalquist> it looks like 'ant initportal' with an empty repo should work
[11:40:43 EDT(-0400)] <esm> sheesh.
[11:40:56 EDT(-0400)] <esm> ok so CPA in 2.6 is doing somethign with portlet session
[11:41:08 EDT(-0400)] <esm> it is a member variable of the portlet adapter.
[11:41:23 EDT(-0400)] <esm> so it will be interesting to see what funny business the debugging will turn up.
[11:41:38 EDT(-0400)] <EricDalquist> hrm
[11:42:57 EDT(-0400)] <esm> UP-1590 Portlet / Servlet session sharing
[11:42:57 EDT(-0400)] <esm> Use org.jasig.portal.container.PortletServlet instead of default plutot PortletServlet to serve portlets.
[11:42:58 EDT(-0400)] <esm> Track PortletSession from CPortletAdapter and invalidate it on a SESSION_DONE event.
[11:43:58 EDT(-0400)] <esm> http://developer.ja-sig.org/source/changelog/jasigsvn?cs=36785
[11:45:18 EDT(-0400)] <EricDalquist> when was that added?
[11:45:31 EDT(-0400)] <esm> 02 February 2007
[11:45:36 EDT(-0400)] <esm> its in 2.6.0 GA
[11:46:29 EDT(-0400)] <esm> hm
[11:48:49 EDT(-0400)] * andrew_petro_ubu (n=apetro@uni1.unicon.net) has joined ##uportal
[12:07:51 EDT(-0400)] * pberry (n=pberry@waldorf.CSUChico.EDU) has joined ##uportal
[12:52:54 EDT(-0400)] <esm> http://rafb.net/p/GCj9yS68.html
[12:53:24 EDT(-0400)] <esm> two CPA instances containing the same request object and then rendering that same request in two different threads.
[12:53:35 EDT(-0400)] <EricDalquist> yup
[12:53:42 EDT(-0400)] <EricDalquist> that is the expected behavior
[12:54:05 EDT(-0400)] <EricDalquist> the cross context dispatch that pluto does 'should' then give each portlet a different request object
[12:54:35 EDT(-0400)] <esm> well, the object that pluto dispatches is just a wrapped org.jasig.portal.RequestParamWrapper
[12:54:51 EDT(-0400)] <esm> i don't believe it constructs an entirely new request.
[12:55:06 EDT(-0400)] <EricDalquist> hrm
[12:55:52 EDT(-0400)] <esm> hrm
[12:55:59 EDT(-0400)] <esm> it
[12:56:47 EDT(-0400)] <esm> it unwraps it and then dispatches.
[12:56:55 EDT(-0400)] <EricDalquist> yeah
[12:57:01 EDT(-0400)] <esm> so pluto dispatches the same object that it is handed by CPA
[12:57:21 EDT(-0400)] <esm> right
[12:57:22 EDT(-0400)] <esm> ?
[12:57:27 EDT(-0400)] <EricDalquist> um ...
[12:57:30 EDT(-0400)] <EricDalquist> yeah
[12:57:46 EDT(-0400)] * lescour (n=JBouncer@adsl-38-10-98.tulsaconnect.com) has joined ##uportal
[12:57:46 EDT(-0400)] <EricDalquist> so Req1 comes into each CPA
[12:58:08 EDT(-0400)] <EricDalquist> each CPA passes Req1 to Pluto which calls dispatch() with Req1 as an arg
[12:58:37 EDT(-0400)] <EricDalquist> tomcat then unwraps Req1 to its base, adds another wrapper then uses that to make the request to the portlet servlet
[12:58:47 EDT(-0400)] <EricDalquist> so each portlet gets its 'own' req object
[12:58:51 EDT(-0400)] <esm> ah
[12:58:59 EDT(-0400)] <EricDalquist> which is really just a wrapper around Req1
[12:59:05 EDT(-0400)] <EricDalquist> I think that is how it works
[12:59:50 EDT(-0400)] <esm> except that req1 is getting simultaneously unwrapped and wrapped by tomcat, one for each dispatch
[13:00:10 EDT(-0400)] <esm> and so one request gets one wrapper, and the second request gets two wrappers.
[13:00:22 EDT(-0400)] <EricDalquist> yeah
[13:00:23 EDT(-0400)] <EricDalquist> so
[13:00:29 EDT(-0400)] <EricDalquist> I think we need to do what we've done here
[13:00:37 EDT(-0400)] <EricDalquist> which is add an 'unwrappable' wrapper
[13:00:55 EDT(-0400)] <EricDalquist> which isn't OK with the spec either
[13:01:14 EDT(-0400)] <EricDalquist> but it seems to fix this since we don't experience it and uP3 didn't see it
[13:01:20 EDT(-0400)] <EricDalquist> uP3 did the unwrappable wrapper trick too
[13:01:23 EDT(-0400)] <EricDalquist> the sandbox code
[13:01:40 EDT(-0400)] <esm> I'm willing to try
[13:02:03 EDT(-0400)] <esm> But the way I'm reading the code, preventing tomcat from unwrapping the request doesn't prevent it from wrapping it.
[13:02:11 EDT(-0400)] <EricDalquist> yup
[13:02:23 EDT(-0400)] <EricDalquist> tomcat just unwraps until it can't unwrap anymore then adds its wrapper
[13:02:26 EDT(-0400)] <EricDalquist> but that is ok
[13:02:43 EDT(-0400)] <esm> except in the second thread it will do the same thing
[13:02:56 EDT(-0400)] <EricDalquist> the unwrappable wrapper will be specific to that thread
[13:03:23 EDT(-0400)] <EricDalquist> so if there are 4 portlets on a page we will get 4 uwrappers (new word, yay) around the one request
[13:03:24 EDT(-0400)] * esm thinks
[13:03:50 EDT(-0400)] <EricDalquist> since the uwrapper will be created when the worker thread that renders the portlet is created
[13:04:42 EDT(-0400)] <EricDalquist> I think when we get to the pluto rendering / CPA code in the uP3 code we are going to just nuke PCS as it exists
[13:10:35 EDT(-0400)] <esm> so to make sure I understand
[13:10:41 EDT(-0400)] <esm> in the paste http://rafb.net/p/GCj9yS68.html
[13:12:35 EDT(-0400)] <esm> org.jasig.portal.RequestParamWrapper@57101a would be a uwrapper object
[13:12:49 EDT(-0400)] <EricDalquist> yes
[13:12:57 EDT(-0400)] <EricDalquist> and each CPA would have its own
[13:13:05 EDT(-0400)] <esm> gotcha.
[13:13:27 EDT(-0400)] <esm> nice. excellent trick.
[13:13:34 EDT(-0400)] <esm> i've had ahard time wrapping my mind around this
[13:13:52 EDT(-0400)] * esm grins
[13:13:57 EDT(-0400)] <esm> i never woulda thought of that
[13:13:58 EDT(-0400)] <esm> cool
[13:14:05 EDT(-0400)] <esm> very cool
[13:14:05 EDT(-0400)] <EricDalquist> thanks ... again it isn't ok with the spec to hand any req back to the container that is anything other than the original or wrapped with HttpServletRequestWrapper
[13:14:15 EDT(-0400)] <EricDalquist> but
[13:14:21 EDT(-0400)] <esm> its already being violated
[13:14:23 EDT(-0400)] <EricDalquist> lesser of two evils at this point
[13:14:25 EDT(-0400)] <EricDalquist> yup
[13:14:28 EDT(-0400)] <esm> right
[13:14:33 EDT(-0400)] <esm> oh
[13:14:53 EDT(-0400)] <EricDalquist> so, tomorrow morning I can start on getting our patched code into some version
[13:14:57 EDT(-0400)] <esm> will only CPA requests get uwrapped
[13:14:57 EDT(-0400)] <esm> ?
[13:15:01 EDT(-0400)] <EricDalquist> should I work on 2.6-patches
[13:15:07 EDT(-0400)] <EricDalquist> that is the next question
[13:15:12 EDT(-0400)] <EricDalquist> in our impl
[13:15:17 EDT(-0400)] <EricDalquist> everything gets uwrappers
[13:15:28 EDT(-0400)] <EricDalquist> but we don't use any channels beyond groups manager and such
[13:15:39 EDT(-0400)] <EricDalquist> another reason why this never made it back
[13:16:05 EDT(-0400)] <esm> i was just curious. if we wanted to limit our "spec divergence" to only requests targeted for CPA's
[13:16:27 EDT(-0400)] <EricDalquist> that would be really tricky
[13:16:33 EDT(-0400)] <EricDalquist> channels don't do the x-context stuff
[13:16:35 EDT(-0400)] <esm> ok yeah no biggy.
[13:16:38 EDT(-0400)] <EricDalquist> so I don't think they would even notice
[13:16:41 EDT(-0400)] <esm> yeah
[13:17:10 EDT(-0400)] <EricDalquist> the uwrapper I posted earlier has some behavior beyond being unwrappable (scoping request attributes) but that doesn't nessesarily need to be there
[13:17:24 EDT(-0400)] <EricDalquist> that behavior could be moved down to the CPA
[13:17:24 EDT(-0400)] <esm> so i have been using 2-6-patches just because it was easier than merging in the removal of imultithreading and such on our codebase.
[13:18:59 EDT(-0400)] <esm> ok
[14:11:42 EDT(-0400)] * colinclark (n=atrcwrk2@142.150.154.101) has joined ##uportal
[14:12:39 EDT(-0400)] <pberry> hola
[14:12:56 EDT(-0400)] <EricDalquist> don't be scaring people away again pberry
[14:13:00 EDT(-0400)] <EricDalquist>
[14:13:12 EDT(-0400)] <pberry> with my 31337 language skillz
[14:14:28 EDT(-0400)] <pberry> besides, I think jayshao is the only one who is afraid of me
[14:14:42 EDT(-0400)] <EricDalquist> ah
[14:15:22 EDT(-0400)] <jayshao> pberry - I read your tumblr, of course I'm scared of you...
[14:15:24 EDT(-0400)] <pberry> wow, reading all the other bios and platform statements for the summer elections, I feel like I may have kept mine too short
[14:15:28 EDT(-0400)] <pberry> jayshao: ha!
[14:19:51 EDT(-0400)] * pberry re-drafts his CAS 3 upgrade proposal
[14:29:54 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[17:35:06 EDT(-0400)] * andrew_petro_ubu (n=apetro@uni1.unicon.net) has left ##uportal
[17:38:18 EDT(-0400)] * lescour (n=JBouncer@adsl-38-10-98.tulsaconnect.com) has left ##uportal
[17:57:12 EDT(-0400)] <esm> night all
[21:07:37 EDT(-0400)] * jayshao (n=jayshao@pool-72-79-103-163.nwrknj.east.verizon.net) has joined ##uportal
[21:18:43 EDT(-0400)] * jayshao (n=jayshao@pool-72-79-103-163.nwrknj.east.verizon.net) has joined ##uportal
[22:29:12 EDT(-0400)] * jayshao (n=jayshao@pool-72-79-103-163.nwrknj.east.verizon.net) has joined ##uportal