You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Kelvin Tan <ke...@relevanz.com> on 2002/01/08 02:36:28 UTC
Torque, Cache and Commons
This message is in part related to an ongoing discussion on the commons-dev mailing list, the debate being whether a new validator package should be included into commons when Turbine, for instance, already has intake, and it might make more sense to migrate that into commons instead. Here's a representative thread. http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=101036144030278&w=2
Over on our side, I understand Aaron's in the process of importing JCS (http://jcs.sourceforge.net) into Turbine (stratum, I think?). Now I recently discovered that Jakarta actually has not one but _TWO_ existing caching subsystems, one at Commons and another at Cocoon (which according to http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=101045218126806&w=2, are somewhat different and are complementary). With the addition of Aaron's JCS, Jakarta will likely have 3 caching subsystems.
I'm not totally sure what the status of the other projects are.
Errmmm...the question I guess is, what's the policy, if any, on a situation like this, where multiple projects have existing codebases which duplicate functionality and purpose? Should we go ahead with the original plan, or maybe wait for a conclusion to be reached over at commons-dev?
Personally, I can't wait (in _every_ sense of the word) for the caching to be imported and work to begin on integrating it with Torque but that's for purely selfish reasons of course...:)
Regards,
Kelvin Tan
Relevanz Pte Ltd
http://www.relevanz.com
Re: Torque, Cache and Commons
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Kelvin Tan" <ke...@relevanz.com> writes:
> ----- Original Message -----
> From: Daniel Rall <dl...@finemaltcoding.com>
> To: Turbine Users List <tu...@jakarta.apache.org>
> Sent: Tuesday, January 15, 2002 6:05 PM
> Subject: Re: Torque, Cache and Commons
>
>
>> Kurt Schrader <ks...@engin.umich.edu> writes:
>>
>> > On Tuesday, January 8, 2002, at 10:05 PM, Kelvin Tan wrote:
>> >
>> >> I think more important, is not whether or not he should introduce
>> >> JCS, but
>> >> rather that everyone (not just in Turbine but in Jakarta) knows that
>> >> he is.
>> >
>> > Good point.
>>
>> mailto:general@jakarta.apache.org
>
> hmmmm...are you suggesting
>
> 1) the announcement of introduction of caching be sent to
> general@jakarta.apache.org,
> 2) that's what general@jakarta.apache.org is for,
> 3) or that the proposal regarding the policy of announcing the introduction
> of sub-projects or part thereof be sent to jakarta@apache.org?
>
> The evils of conciseness...:)
Take your pick.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque, Cache and Commons
Posted by Kelvin Tan <ke...@relevanz.com>.
----- Original Message -----
From: Daniel Rall <dl...@finemaltcoding.com>
To: Turbine Users List <tu...@jakarta.apache.org>
Sent: Tuesday, January 15, 2002 6:05 PM
Subject: Re: Torque, Cache and Commons
> Kurt Schrader <ks...@engin.umich.edu> writes:
>
> > On Tuesday, January 8, 2002, at 10:05 PM, Kelvin Tan wrote:
> >
> >> I think more important, is not whether or not he should introduce
> >> JCS, but
> >> rather that everyone (not just in Turbine but in Jakarta) knows that
> >> he is.
> >
> > Good point.
>
> mailto:general@jakarta.apache.org
hmmmm...are you suggesting
1) the announcement of introduction of caching be sent to
general@jakarta.apache.org,
2) that's what general@jakarta.apache.org is for,
3) or that the proposal regarding the policy of announcing the introduction
of sub-projects or part thereof be sent to jakarta@apache.org?
The evils of conciseness...:)
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque, Cache and Commons
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Kurt Schrader <ks...@engin.umich.edu> writes:
> On Tuesday, January 8, 2002, at 10:05 PM, Kelvin Tan wrote:
>
>> I think more important, is not whether or not he should introduce
>> JCS, but
>> rather that everyone (not just in Turbine but in Jakarta) knows that
>> he is.
>
> Good point.
mailto:general@jakarta.apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque, Cache and Commons
Posted by Kurt Schrader <ks...@engin.umich.edu>.
On Tuesday, January 8, 2002, at 10:05 PM, Kelvin Tan wrote:
> I'm tempted to cross-post to commons-dev, but I'll refrain for now.
Please do. Let the noise die down a bit for now. :)
> I think more important, is not whether or not he should introduce JCS,
> but
> rather that everyone (not just in Turbine but in Jakarta) knows that he
> is.
Good point.
> IMHO, Jakarta would benefit from a developer announcement mailing list
> and/or web page, which contains a list of projects or sub-projects that
> developers are intending to introduce. This facility may very well
> already
> exist, but it sure as hell is evident that it's not being utilized.
I believe that this would be the point where Jon tells you organize/build
one then, but I think he's busy trying to get his Beta of Scarab out. :)
-Kurt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque, Cache and Commons
Posted by Kelvin Tan <ke...@relevanz.com>.
I'm tempted to cross-post to commons-dev, but I'll refrain for now.
The reasons Aaron have stated seem to justify his case.
I think more important, is not whether or not he should introduce JCS, but
rather that everyone (not just in Turbine but in Jakarta) knows that he is.
IMHO, Jakarta would benefit from a developer announcement mailing list
and/or web page, which contains a list of projects or sub-projects that
developers are intending to introduce. This facility may very well already
exist, but it sure as hell is evident that it's not being utilized.
Do the commons developers know about JCS? Maybe.
Will knowledge of it impact the decisions they're making now with regards to
the commons cache subsystem? Probably.
Regards,
Kelvin
----- Original Message -----
From: Aaron Smuts <aa...@verizon.net>
To: 'Turbine Users List' <tu...@jakarta.apache.org>
Sent: Wednesday, January 09, 2002 10:56 AM
Subject: RE: Torque, Cache and Commons
>
>
> > -----Original Message-----
> > From: Kurt Schrader [mailto:kschrade@engin.umich.edu]
> > I am under the impression that the Stratum repository is a temporary
> > solution and the code within it will eventually be moving to Commons
> > anyway. I worry about how bringing another caching project into the
> > Jakarta fold will reflect on us as a project if there are already two
> > caches here as is, especially in light of the recent flame fest on
> > general/commons. What advantages does JCS have over these other two
> > projects that justify us bringing it in instead of just using one of
> > those?
> >
>
> I don't want to complain about the redundancy problem(?) in the Jakarta
> project as a whole, since in general the various competing systems make
> it far more valuable.
>
> Since there is no discrete caching system getting much outside
> attention, like there is a logging project, I'm all for another caching
> addition. Perhaps the best solution or a hybrid could become another
> stand alone project. I wouldn't propose adding another logging project
> since there is a popular, stable, replete system already being used.
> This would just be silly. Caching in Jakarta is no where close to
> logging. When and if it ever is, then talk of adding another system
> will be equally stupid.
>
> In my last email I addressed some of the features and reasons why JCS
> would be a value add. One important feature is the pluggable framework,
> similar to log4j. Such frameworks can meet a vast array of needs and
> are well suited to open source development. I recently started using
> JBuilder solely because of the plugins made possible by the open tools
> api. I've written my own plugins to suit special needs. The power of
> the ide is greatly enhanced this way. I thought I'd never use an ide
> but the features are just too attractive when you add up the plugins.
>
> I hope the cache can benefit from the same strategy.
>
> I never said that the new version of the cache is bug free. There are
> still some group based bugs to solve, and there are a few places where
> I'd like to make the code more efficient, but the features should not be
> overlooked.
>
> Here's a brief doc on some features:
>
> ****************************************
>
> Java Caching System (JCS)
>
>
>
> JCS is a distributed caching system written in java for
> server-side java applications. It is intended to speed up dynamic web
> applications by providing a means to manage cached data of various
> dynamic natures. Like any caching system, the JCS is most useful for
> high read, low put applications. Dynamic content and reporting systems
> can benefit most. However, any site that repeatedly constructs pages,
> dropdowns, or common search results form a database that is updated at
> intervals (rather than across categories continuously) can improve
> performance and scalability by implementing caching. Latency times drop
> sharply and bottlenecks move away from the database in an effectively
> cached system.
>
>
> The JCS goes beyond simply caching objects in memory. It
> provides several important features, necessary for any Enterprise level
> caching system:
>
>
>
> . Memory management
>
> . Disk overflow (and defragmentation)
>
> . Element grouping
>
> . Quick nested categorical removal
>
> . Data expiration
>
> . Extensible framework
>
> . Fully configurable runtime parameters
>
> . Remote synchronization
>
> . Remote store recovery
>
> . Non-blocking "zombie" (balking facade) pattern
>
> . Optional lateral distribution of elements via (HTTP, TCP, or
> UDP)
>
> . Remote server clustering and failover (almost complete)
>
>
>
> These features provide a framework with no point of failure, allowing
> for full session failover including session data across up to 256
> servers.
>
> *********************************
>
> I have addressed the features of JCS and what I hope it can become in
> several posts.
>
> A recent commons post points to an archive of one such email
>
> > -----Original Message-----
> > From: Kelvin Tan [mailto:kelvin@relevanz.com]
> > Sent: Monday, January 07, 2002 8:51 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [proposal] some store components for the commons-sandbox
> >
> > I'm not sure if anyone is aware of
> > http://marc.theaimsgroup.com/?l=turbine-user&m=100872531107216&w=2,
> but
> > Aaron is intending to import JCS into Jakarta as well...
> >
> > Regards,
> > Kelvin
>
>
> Cheers,
>
> Aaron
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Trying to throw requests received while a request is in progress
Posted by Doal Miller <dm...@syntricity.com>.
Greetings, I am not sure this is a Turbine issue, so if it isn't perhaps
someone could point me in the right direction.
We have extended the VelocityPage to implement a simple state machine and
therefore, control the transitions from one screen to another based on the
current screen and the action in the URL. What I want to do is throw away
any requests received while processing a request. So if a user presses a
button, and while that action is being processed, they press another button,
I want to just ignore the second request. IOW I want to prevent any type
ahead.
The solution I have implemented is to provide a locking mechanism based on
our UserSession. When a request enters MyVelocityPage.doBuildBeforeAction it
acquires the lock. If the UserSession is already locked this request is
flagged to be thrown away, a do nothing action is executed, and when this
request enters MyVelocityPage.doBuildAfterAction, I do:
data.setStatusCode(HttpServletResponse.SC_NO_CONTENT);
Then when the first request that got the lock finishes processing in
MyVelocityPage.doBuildAfterAction it releases the lock so the next request
can get it.
Everything seems to work fine and the current screen stays on the browser
while processing the first request. However, when the original request
completes, I never see the new screen that it has set. I stepped through the
Turbine code to see that nothing is having a problem. It appears that it is
going through the motions of writing the output to the page but I never see
it in the browser. The following code in Turbine's doGet routine is
executed, the status code is 200 which is SC_OK, data is representing the
correct screen, and the output operation seems to go fine.
// Set the status code.
data.getResponse().setStatus ( data.getStatusCode() );
// Output the Page.
data.getPage().output (data.getOut());
Any advise or suggestions would be welcomed. Does what I am doing seem
correct? It does to me anyway, but then it doesn't work. Thanks for any help
you can provide.
Doal Miller
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque, Cache and Commons
Posted by Kurt Schrader <ks...@engin.umich.edu>.
On Tuesday, January 8, 2002, at 09:56 PM, Aaron Smuts wrote:
> I don't want to complain about the redundancy problem(?) in the Jakarta
> project as a whole, since in general the various competing systems make
> it far more valuable.
I agree actually, and I personally am not too jazzed about the other two
systems, I just didn't remember seeing an overview of everything yours
did, so thanks for tossing one up here.
You had my +1 a long time ago anyway. :)
-Kurt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Torque, Cache and Commons
Posted by Aaron Smuts <aa...@verizon.net>.
> -----Original Message-----
> From: Kurt Schrader [mailto:kschrade@engin.umich.edu]
> I am under the impression that the Stratum repository is a temporary
> solution and the code within it will eventually be moving to Commons
> anyway. I worry about how bringing another caching project into the
> Jakarta fold will reflect on us as a project if there are already two
> caches here as is, especially in light of the recent flame fest on
> general/commons. What advantages does JCS have over these other two
> projects that justify us bringing it in instead of just using one of
> those?
>
I don't want to complain about the redundancy problem(?) in the Jakarta
project as a whole, since in general the various competing systems make
it far more valuable.
Since there is no discrete caching system getting much outside
attention, like there is a logging project, I'm all for another caching
addition. Perhaps the best solution or a hybrid could become another
stand alone project. I wouldn't propose adding another logging project
since there is a popular, stable, replete system already being used.
This would just be silly. Caching in Jakarta is no where close to
logging. When and if it ever is, then talk of adding another system
will be equally stupid.
In my last email I addressed some of the features and reasons why JCS
would be a value add. One important feature is the pluggable framework,
similar to log4j. Such frameworks can meet a vast array of needs and
are well suited to open source development. I recently started using
JBuilder solely because of the plugins made possible by the open tools
api. I've written my own plugins to suit special needs. The power of
the ide is greatly enhanced this way. I thought I'd never use an ide
but the features are just too attractive when you add up the plugins.
I hope the cache can benefit from the same strategy.
I never said that the new version of the cache is bug free. There are
still some group based bugs to solve, and there are a few places where
I'd like to make the code more efficient, but the features should not be
overlooked.
Here's a brief doc on some features:
****************************************
Java Caching System (JCS)
JCS is a distributed caching system written in java for
server-side java applications. It is intended to speed up dynamic web
applications by providing a means to manage cached data of various
dynamic natures. Like any caching system, the JCS is most useful for
high read, low put applications. Dynamic content and reporting systems
can benefit most. However, any site that repeatedly constructs pages,
dropdowns, or common search results form a database that is updated at
intervals (rather than across categories continuously) can improve
performance and scalability by implementing caching. Latency times drop
sharply and bottlenecks move away from the database in an effectively
cached system.
The JCS goes beyond simply caching objects in memory. It
provides several important features, necessary for any Enterprise level
caching system:
. Memory management
. Disk overflow (and defragmentation)
. Element grouping
. Quick nested categorical removal
. Data expiration
. Extensible framework
. Fully configurable runtime parameters
. Remote synchronization
. Remote store recovery
. Non-blocking "zombie" (balking facade) pattern
. Optional lateral distribution of elements via (HTTP, TCP, or
UDP)
. Remote server clustering and failover (almost complete)
These features provide a framework with no point of failure, allowing
for full session failover including session data across up to 256
servers.
*********************************
I have addressed the features of JCS and what I hope it can become in
several posts.
A recent commons post points to an archive of one such email
> -----Original Message-----
> From: Kelvin Tan [mailto:kelvin@relevanz.com]
> Sent: Monday, January 07, 2002 8:51 PM
> To: Jakarta Commons Developers List
> Subject: Re: [proposal] some store components for the commons-sandbox
>
> I'm not sure if anyone is aware of
> http://marc.theaimsgroup.com/?l=turbine-user&m=100872531107216&w=2,
but
> Aaron is intending to import JCS into Jakarta as well...
>
> Regards,
> Kelvin
Cheers,
Aaron
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Torque, Cache and Commons
Posted by Kurt Schrader <ks...@engin.umich.edu>.
On Monday, January 7, 2002, at 09:11 PM, Aaron Smuts wrote:
> In the coming moths I hope to devote a good deal of time working with
> everyone to making it the best caching solution available. I don't care
> where it goes. I just want it to be useful, easy to use, and the best
> tool available. I'd like to get started in the stratum repository and
> see what happens.
I am under the impression that the Stratum repository is a temporary
solution and the code within it will eventually be moving to Commons
anyway. I worry about how bringing another caching project into the
Jakarta fold will reflect on us as a project if there are already two
caches here as is, especially in light of the recent flame fest on
general/commons. What advantages does JCS have over these other two
projects that justify us bringing it in instead of just using one of
those?
-Kurt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Torque, Cache and Commons
Posted by Aaron Smuts <aa...@verizon.net>.
>Over on our side, I understand Aaron's in the process of importing JCS
>(http://jcs.sourceforge.net) into Turbine (stratum, I think?).
I'm just waiting for sufficient karma.
>Now I recently discovered that Jakarta actually has not one but _TWO_
>existing caching subsystems, one at Commons and another at Cocoon
(which >according to
http://marc.theaimsgroup.com/?l=jakarta-commons->dev&m=101045218126806&w
=2, are somewhat different and are complementary). >With the addition of
Aaron's JCS, Jakarta will likely have 3 caching >subsystems.
That's a lot of cache.
I was in on the commons discussion some time back. . . .
I need to some up with some decent examples and clean up a few things
with the explicit grouping, but I think the JCS will be a valuable
addition to Jakarta. If it doesn't pan out then of course it will be
replaced by a superior product.
JCS is pluggable and could perhaps incorporate some of the work from
other caching systems. The strategy pattern lends itself to benefiting
from community contributions. And since it is close to the JSR 107
specification, the API might become widely familiar and well documented.
. . .
In the coming moths I hope to devote a good deal of time working with
everyone to making it the best caching solution available. I don't care
where it goes. I just want it to be useful, easy to use, and the best
tool available. I'd like to get started in the stratum repository and
see what happens.
Aaron
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>