Yeah, I do use Beta 2. In fact: It is a checkout from just before christmas eve.
-----Original Message-----
From: Patrick Lightbody [mailto:[EMAIL PROTECTED]]
Sent: den 8 januari 2004 17:56
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load
Significantly faster would also be a bit incorrect. WebWork 2 is faster
than 1.4 in the area of raw EL support (math, boolean statements, etc).
It is about 50% slower than WebWork 1.4 whenever the ValueStack is
involved (which is almost all the time), which is something we indeed to
look in to as a final piece of work before 2.0 final goes out.
Daniel, are you using beta 2 (or later)? Until beta 2, the VS was about
6X slower than it is now due to a bug.
Pat
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
Hani Suleiman
Sent: Thursday, January 08, 2004 8:46 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load
The threadlocal issue is a red herring, ww1 uses it and it's
significantly faster than ww2.
Daniel Pfeifer wrote:
> That might be slightly off-topic, but it fits to the subject. However,
> personally I think that webwork is quite slow once you do some serious
> work with it. We are testing a webwork-based website on a P4 3Ghz plus
1
> gig of RAM and some requests really do take ages (especially when the
> ValueStack is involved) to complete. I hope you find some ways to
> improve it before WW2 goes final.
>
> /Daniel
>
> -----Original Message-----
> From: Patrick Lightbody [mailto:[EMAIL PROTECTED]]
> Sent: den 8 januari 2004 17:10
> To: [EMAIL PROTECTED]
> Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load
>
>
> Well, about a year ago when we had the initial XW meetings, it was
> decided to keep the TL for now. Maybe post-2.0 we'll find ways to
slowly
> migrate away from it. I agree though, ThreadLocals suck ass.
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of
> Scott Farquhar
> Sent: Wednesday, January 07, 2004 6:00 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load
>
> On Wed, Jan 07, 2004 at 11:56:28PM +0100, Jens Riboe wrote:
> > What was the design rationale for putting it in thread local
storage?
> >
> > This works for servlets, but it may cause mysterious bugs in Swing
> > applications, every time one uses a worker thread for a time
consuming
> > UI event.
> >
> > How about putting state info, like actionCtx, config, etc into
> > a single XWork object and then let the impl choose to store it
> > appropriately. The ctx can then be created from that object.
> >
> > For a servlet one can use thread-based singleton, like above
> > or put it into the servletCtx, and the actionCtx can be created and
> stored
> > into the request.
> >
> > For a Swing app, it generally suffice to go for a classloader
> singleton,
> > aka static variable, for both config and actionCtx.
>
> I like the way that PicoContainer has done it:
>
> public interface ObjectReference {
> Object get();
>
> void set(Object item);
> }
>
> Then there can be a ThreadLocalObjectReference, or a
> SingletonObjectReference as needed.
>
> I've needed to change the way that things are stored in Pico, and it
was
> a 5 line change due to this abstraction.
>
> So you have the ActionContext take an ObjectReference of where to
store
> itself?
>
> Cheers,
> Scott
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
