well, I figured it out finally... It is "feature" is Jetspeed: Jetspeed
caches portlets, so when there are two threads accessing the portlet
simultaneously they both get reference to the same instance of a portlet (or
at least same RunData). When I commented out the caching part, everything
works fine. This caching is ok for portlets that have the same data for all
the portlets, but doesn't work in the case of "personalized" portlets.
Also, there is some other bug somewhere in integration with Cocoon: if I
send some 10 requests per second to the page with Cocoon portlet(s), servlet
engine hangs.... this happens with Tomcat and Resin, so it probably isn't a
problem in servlet engine.
Any ideas?
Neeme
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of burtonator
> Sent: Tuesday, August 29, 2000 7:17 AM
> To: JetSpeed
> Subject: Re: cocoon portlets reusing bug
>
>
> Neeme Praks wrote:
> >
> > > -----Original Message-----
> > > From: burtonator [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, August 28, 2000 1:27 PM
> >
> > [snip]
> >
> > > ug. Can you point out the sections of code you think might be a
> > > problem?
> >
> > well, I haven't found any particular part of the code yet. But I'll
> > explain what am I doing and the behaviour that I'm
> getting... maybe you
> > can tell me something obvious that could be wrong...
> >
> > > Multithreadint can be interesting. It has a *really* good way of
> > > finding situations you didn't think of or didn't know was
> possible.
> > > Worse yet when there is a bug it is just *wierd* behavior
> > > like what you
> > > are experiencing. In most other situations it is usually a
> > > exception or
> > > somethign that can be tested in a regular manner (IE not time
> > > dependent).
> >
> > yep, this is the worst kind of bugs... difficult to
> reproduce exactly.
> >
> > Ok, here is a short overview of what I'm doing:
> > In order to output some meaningful data in Cocoon portlet,
> I need access
> > to PortletConfig (and RunData). I've solved this by storing
> > PortletConfig in JetspeedServletRequest. Inside portlet
> (under Cocoon,
> > in XSP page) I retrieve PortletConfig by casting the
> request object to
> > JetspeedServletRequest and getting the PortletConfig from there.
>
> Actually... this isn't that bad. I have hacked together
> RunData/PortletConfig access within XSP. I would be +1 for
> making this
> the default operation for the CocoonPortlet. Not elagent but
> certainly
> more so than the current solution (using RunData factory :)
>
> ... I added this to ./docs/TODO so that it will eventually
> get in there
> :)
>
> > Maybe there is something wrong with this approach? (This is
> the first
> > place I have my suspicions about)
> >
> > From PortletConfig I retrieve also Rundata and from Rundata I get
> > ParameterParser and User object.
>
> All of this code is supposed to be threadsafe.
>
> > The second place that I have my suspicions about is the way
> I retrieve
> > User object from Turbine:
> > Basically, the situation is that we have two user classes:
> > 1. our proprietary system has it's own User object that we
> use in our
> > code instead of Turbine's.
> > 2. then there is a modified version of Turbine user class
> that has all
> > the database functionality (peers) commented out and simply
> sits there
> <snip>
>
> You have got me stumped. I read over everythign and put some decent
> thought into it. I can't see how this could be Jetspeed's fault.
> Possibly Turbines or your third party authentication. Dont' know :(
>
> Good luck :)
>
> Kevin
>
> --
> ** Should SUN Open Source Java? Please Vote:
> http://relativity.yi.org/java **
>
> Kevin A Burton (e-mail: [EMAIL PROTECTED], UIN: 73488596, ZKey:
> burtonator)
> http://relativity.yi.org | http://www.openprivacy.org
> Message to SUN Microsystems: "Please Open Source Java!"
> To fight and conquer in all your battles is not supreme excellence;
> supreme
> excellence consists in breaking the enemy's resistance
> without fighting.
> - Sun Tzu, 300 B.C.
>
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/main/mail.html>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
