Neeme Praks wrote:
> 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.
>
The caching is allright, given that anything that dependes on the request
(session parameters, rundata, ...) is not cached. We will be fixing it, I
imagine that will be for 1.2b3 or 1.2final (after proposal #3). I have already
modified part of this behaviour to enable session tracking through URL
rewriting. This is supported by Turbine, but the caching of portlets broke the
behaviour.
If you deactivate cookies and go to hisitech.com:8080/servlet/jetspeed, it
should work. Unfortunately the creation of a new account does not work, due to
some error in the handling of SQL (it assumes that ";" is allowed as terminator,
while instantDB takes "." or nothing). I don't know where to fix this behaviour
of village or jyve.
>
> 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.
>
I think this is due to the number of workers configured at Tomcat startup. Try
to upper this number. In some stress tests I did it did not hang, but started
dropping requests after ten simultaneous arrived. It is very possible that Resin
also configures 10 workers by default (a magic number).
Also, I think some Cocoon versions have a bug in that, if a class is not
compiled and a request arrives, it will try to compile, but it will not
synchronize. So it you start with a burst of requests before the class is
compiled, cocoon could try to compile a class ten times in parallel. So ensure
that the class is compiled before the test.
>
> 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]
--
--------------------------------------------------------------
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]
