You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Craig R. McClanahan" <cm...@mytownnet.com> on 2000/01/08 04:59:08 UTC
[TOMCAT.NEXT] Proposal Sources Checked In
The documentation (index.html) and associated sources (*.java) for the
"Tomcat.Next" proposal that has been discussed recently on the
TOMCAT-DEV mailing list have now been checked in to the CVS repository
for the "jakarta-tomcat" project, under the directory name
"proposals/tomcat.next". As such, these files are *not* part of the
official source code -- they are merely a proposal that is available for
perusal through the usual mechanisms to retrieve CVS files.
As incremental changes to the actual Tomcat servlet engine are made,
corresponding copies of these files will be checked in to the usual
source code tree. Changes will undoubtedly be made, but they will be
reflected only in the source code hierarchy -- the proposal will remain
as originally posted.
Craig McClanahan
Re: [TOMCAT.NEXT] Proposal Sources Checked In
Posted by co...@eng.sun.com.
"For the record, JServ's approach to load balancing is very useful, but not quite
> what that term has come to mean in the last few months. When you access a
> JServ-based application without being in a session yet, you are randomly assigned
> to a particular server (based on a weighting forumula if you want). Once you
> begin a session, you stay on that server "forever". There is no session
> migration in the current implementation.
To add: this mechanism doesn't work right now for tomcat ( but it's easy to
fix ). The main reason - the name of the session cookie is different, and
the convention for session id doesn't match.
If anyone has the time to fix it (again, it's easy) ( and test it a bit
AND write a small howto!!!), it would be really great.
Costin
Re: [TOMCAT.NEXT] Proposal Sources Checked In
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Assaf Arkin wrote:
> > Could we this persistence as a piece of the pie for load-blancing/failover
> > support?
>
> That's what we have in mind :-)
>
This is definitely within the vision of what these components are designed to
support.
>
> >
> > I know that JServ does load balancing, and that is awesome. I just think
> > that we should take it one more step and try for failover support as well.
> > I am sure that there are many other issues with this, but I am sure that you
> > guys have/are thinking about it?
>
For the record, JServ's approach to load balancing is very useful, but not quite
what that term has come to mean in the last few months. When you access a
JServ-based application without being in a session yet, you are randomly assigned
to a particular server (based on a weighting forumula if you want). Once you
begin a session, you stay on that server "forever". There is no session
migration in the current implementation.
>
> I'm giving this issue some thought, especially since I'm looking at two
> types of solution.
>
> In one solution everything in the session comes from the database. For
> example, when you view your bank account information all the important
> session information is up there in the database. Server goes down,
> server comes back, session recreated, reloads itself, and you're back in
> business.
>
Yep.
>
> In other cases, the session holds information that is not in the
> database, e.g. when you fill a multi-page form before committing it. In
> this case server goes down, server comes up, session returns to original
> state, user gets Web rage.
>
I suppose we could call this "in progress transaction persistence." It is
distinct from the database notion of a transaction.
>
> If the session can be persisted at the end of every servlet response,
> you can guarantee that on server restart users will be able to continue
> where they left off. It does raise a few problems, though:
>
> 1. Performance -- serialization is rather expensive
>
Because the objects you are persisting can define their own serialization formats
(by overriding readObject() and writeObject()), the application designer can
affect the impact of this issue. For example, if you have a heavyweight object
cached in the session, but you could recreate it at reload time based on stuff
already in the database, then you could store a very lightweight version of your
object that basically contains the rules to reconstruct it on reload.
>
> 2. Overlapping -- if you use the two approaches you want Tomcat to do
> fail over only for those part of your session that do not come from the
> database
>
2a -- Multithreading
You also have to figure out how you want to deal with the fact that multiple
threads could be accessing your session at the same time. This is most obvious
in a web app based on a framed UI (the browser will often issue requests for the
various frames simultaneously) but can also happen when the user opens a new
window.
>
> 3. ACIDity -- a session cannot be recovered if the server failed in the
> middle of executing the Servlet, unless the Servlet is specifically
> aware of that
>
We might only need to be able to make such guarantees *in between* requests, not
during a request.
>
> 4. Setup -- should fail over rely on persistence in a single server, a
> hot stand by, or simply redirecting to another server in the cluster?
>
One thing that becomes obvious very quickly -- this is not a "one size fits all"
environment. One of the key features of the Tomcat.Next component design is that
you can plug in different components (such as a session manager that does/does
not persist on every request, or does/does not persist across server restarts,
and so on -- to say nothing of selecting where and how the persistence should
take place), without affecting the reliability of the rest of the servlet
container.
>
> arkin
>
Craig
>
> >
> > I know that this is probably a long way down the road, but I for one think
> > that it would make Tomcat a world-class engine.
> >
> > Scott Sanders
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [TOMCAT.NEXT] Proposal Sources Checked In
Posted by Assaf Arkin <ar...@exoffice.com>.
Wong Kok Wai wrote:
>
> Assaf Arkin wrote:
>
> >
> > I'm giving this issue some thought, especially since I'm looking at two
> > types of solution.
> >
>
> Sounds like EJB session beans...
Only if you care for the EJB semantics and willing to pay the lines of
code/performance overhead.
Fact of life is that many developers out there will not be using EJB,
and most of the legacy Servlets do not. That's why I've focused on
getting the transaction and JDBC persistence working for Tomcat first,
EJB second.
Keep in mind that Tomcat is also a J2EE container, it needs to take some
of the responsibilities on itself without brushing them off to EJB land.
But yes, I recommend the EJB approach :-)
arkin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [TOMCAT.NEXT] Proposal Sources Checked In
Posted by Wong Kok Wai <wo...@pacific.net.sg>.
Assaf Arkin wrote:
>
> I'm giving this issue some thought, especially since I'm looking at two
> types of solution.
>
Sounds like EJB session beans...
Re: [TOMCAT.NEXT] Proposal Sources Checked In
Posted by Assaf Arkin <ar...@exoffice.com>.
> Could we this persistence as a piece of the pie for load-blancing/failover
> support?
That's what we have in mind :-)
>
> I know that JServ does load balancing, and that is awesome. I just think
> that we should take it one more step and try for failover support as well.
> I am sure that there are many other issues with this, but I am sure that you
> guys have/are thinking about it?
I'm giving this issue some thought, especially since I'm looking at two
types of solution.
In one solution everything in the session comes from the database. For
example, when you view your bank account information all the important
session information is up there in the database. Server goes down,
server comes back, session recreated, reloads itself, and you're back in
business.
In other cases, the session holds information that is not in the
database, e.g. when you fill a multi-page form before committing it. In
this case server goes down, server comes up, session returns to original
state, user gets Web rage.
If the session can be persisted at the end of every servlet response,
you can guarantee that on server restart users will be able to continue
where they left off. It does raise a few problems, though:
1. Performance -- serialization is rather expensive
2. Overlapping -- if you use the two approaches you want Tomcat to do
fail over only for those part of your session that do not come from the
database
3. ACIDity -- a session cannot be recovered if the server failed in the
middle of executing the Servlet, unless the Servlet is specifically
aware of that
4. Setup -- should fail over rely on persistence in a single server, a
hot stand by, or simply redirecting to another server in the cluster?
arkin
>
> I know that this is probably a long way down the road, but I for one think
> that it would make Tomcat a world-class engine.
>
> Scott Sanders
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [TOMCAT.NEXT] Proposal Sources Checked In
Posted by Scott Sanders <sc...@eionline.com>.
> > Great stuff. The Interceptor, Realm and Session work for me.
> >
> > Free beer on me :-)
> >
>
> And he hasn't even seen the coming attractions yet (once the basic session
> management code is stable :-):
>
> * A "Store" inteface that abstracts mechanisms
> for persistent storage of sessions (for use across
> server restarts and/or when auto-reloading is
> implemented).
>
> * Implementations of this interface for flatfiles and
> JDBC databases (plus any others that people
> want to use).
>
Could we this persistence as a piece of the pie for load-blancing/failover
support?
I know that JServ does load balancing, and that is awesome. I just think
that we should take it one more step and try for failover support as well.
I am sure that there are many other issues with this, but I am sure that you
guys have/are thinking about it?
I know that this is probably a long way down the road, but I for one think
that it would make Tomcat a world-class engine.
Scott Sanders
Re: [TOMCAT.NEXT] Proposal Sources Checked In
Posted by Assaf Arkin <ar...@exoffice.com>.
> * A "Store" inteface that abstracts mechanisms
> for persistent storage of sessions (for use across
> server restarts and/or when auto-reloading is
> implemented).
>
> * Implementations of this interface for flatfiles and
> JDBC databases (plus any others that people
> want to use).
Cool.
As always, a question about how this plays with the other stuff (I'll be
waiting for the API to see how the components interact).
- Do you automatically store/reload all the sessions?
- When doing auto-reloading, will it break if one of the classes has
been changed?
- Is there any specific transaction context during that store?
- Do you load/store them all at one, or is it possible to do this one at
a time, or should I just plug in a different Interceptor to do that?
>
> The original thinking was that the configuration process for a container
> would be going through the appropriate parameters, and call addInterceptor()
> to add each defined Interceptor. Within the addInterceptor() implementation,
> the container would call the Interceptor's setContainer() method, as outlined
> in the Javadoc comments for addInterceptor(). This chain of events could be
> interrupted by any of the following cases:
Assuming that only the configuration code is allowed to call
addInterceptor, which as I recall is a public method.
Anyway, I don't like InvalidArgumentException as "I reject doing
something". Look at the event listener interface for example. When you
add two listeners to a source that can only support one, it throws a
TooManyListeners exception, not an IAE.
> * Container does not support any Interceptors, or
> any more Interceptors (so addInterceptor() throws
> IllegalStateException).
>
> * Container refuses to accept this particular Interceptor
> (so addInterceptor() throws IllegalArgumentException)
> -- this one is not documented yet, but will be.
>
> * Interceptor is already attached to a different Container
> (so setContainer() throws IllegalStateException)
> -- this one is not documented yet, but will be.
>
> * Interceptor refuses to be attached to this particular
> Container (so setContainer() throws IllegalArgumentException).
I totally agree with these four cases, I just don't like the use of IAE,
but ISE is used exactly as it was ment to be.
> Are you thinking of any particular case? I believe that the only
> implementations included in the proposal already build an array on the stack
> before they return it (like ContainerBase.findChildren() does). Therefore,
> the internal collection itself is not corruptible. The objects returned in
> the array are the "real" objects from the collection, because that is what
> the caller wants to deal with.
Good. Keep it that way.
This sort of problem doesn't happen when you're returning an array from
a collection, it only happens if you're returning an array from an
array. (Yep, it just bit me :-) )
>
> By the way, I chose to return arrays for these kinds of things for the
> following reasons:
>
> * The number of objects in any of these collections will tend to be
> pretty small, so we're not occupying huge amounts of space for
> the array itself.
>
> * Avoids the decision between returning an Enumeration (JDK 1.1)
> or an Iterator (JDK 1.2). If and when Tomcat migrates to requiring
> JDK 1.2 or later, these interfaces will not change.
>
> * Returning the complete array avoids race conditions that can happen
> with Enumerations or Iterators when another thread is modifying the
> underlying collection while you are walking through the results.
All sound reasons.
arkin
>
> >
> > arkin
> >
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [TOMCAT.NEXT] Proposal Sources Checked In
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Assaf Arkin wrote:
> Great stuff. The Interceptor, Realm and Session work for me.
>
> Free beer on me :-)
>
And he hasn't even seen the coming attractions yet (once the basic session
management code is stable :-):
* A "Store" inteface that abstracts mechanisms
for persistent storage of sessions (for use across
server restarts and/or when auto-reloading is
implemented).
* Implementations of this interface for flatfiles and
JDBC databases (plus any others that people
want to use).
>
> I saw that Interceptor throws an IllegalArgumentException on
> setContainer. This should be changed to either an IllegalStateException
> (the argument is valid), and I recommend that IllegalStateException be
> thrown only if the interceptor is already associated with some container
> (should never happen). Instead a container can refuse the association by
> throwing some application exception.
>
The original thinking was that the configuration process for a container
would be going through the appropriate parameters, and call addInterceptor()
to add each defined Interceptor. Within the addInterceptor() implementation,
the container would call the Interceptor's setContainer() method, as outlined
in the Javadoc comments for addInterceptor(). This chain of events could be
interrupted by any of the following cases:
* Container does not support any Interceptors, or
any more Interceptors (so addInterceptor() throws
IllegalStateException).
* Container refuses to accept this particular Interceptor
(so addInterceptor() throws IllegalArgumentException)
-- this one is not documented yet, but will be.
* Interceptor is already attached to a different Container
(so setContainer() throws IllegalStateException)
-- this one is not documented yet, but will be.
* Interceptor refuses to be attached to this particular
Container (so setContainer() throws IllegalArgumentException).
Therefore, it seems that either ISE or IAE might be appropriate, depending on
who is complaining and what they are complaining about. Doing it this way
also avoids having to define any application-level exceptions for these
conditions. To me, IllegalStateException and IllegalArgumentException say
the right thing for the four cases above. Does that make sense?
> Also, several methods return arrays of objects. You may consider cloning
> the array before returning it to prevent the caller from corrupting it.
>
Are you thinking of any particular case? I believe that the only
implementations included in the proposal already build an array on the stack
before they return it (like ContainerBase.findChildren() does). Therefore,
the internal collection itself is not corruptible. The objects returned in
the array are the "real" objects from the collection, because that is what
the caller wants to deal with.
By the way, I chose to return arrays for these kinds of things for the
following reasons:
* The number of objects in any of these collections will tend to be
pretty small, so we're not occupying huge amounts of space for
the array itself.
* Avoids the decision between returning an Enumeration (JDK 1.1)
or an Iterator (JDK 1.2). If and when Tomcat migrates to requiring
JDK 1.2 or later, these interfaces will not change.
* Returning the complete array avoids race conditions that can happen
with Enumerations or Iterators when another thread is modifying the
underlying collection while you are walking through the results.
>
> arkin
>
Craig
Re: [TOMCAT.NEXT] Proposal Sources Checked In
Posted by Assaf Arkin <ar...@exoffice.com>.
Great stuff. The Interceptor, Realm and Session work for me.
Free beer on me :-)
I saw that Interceptor throws an IllegalArgumentException on
setContainer. This should be changed to either an IllegalStateException
(the argument is valid), and I recommend that IllegalStateException be
thrown only if the interceptor is already associated with some container
(should never happen). Instead a container can refuse the association by
throwing some application exception.
Also, several methods return arrays of objects. You may consider cloning
the array before returning it to prevent the caller from corrupting it.
arkin
"Craig R. McClanahan" wrote:
>
> The documentation (index.html) and associated sources (*.java) for the
> "Tomcat.Next" proposal that has been discussed recently on the
> TOMCAT-DEV mailing list have now been checked in to the CVS repository
> for the "jakarta-tomcat" project, under the directory name
> "proposals/tomcat.next". As such, these files are *not* part of the
> official source code -- they are merely a proposal that is available for
> perusal through the usual mechanisms to retrieve CVS files.
>
> As incremental changes to the actual Tomcat servlet engine are made,
> corresponding copies of these files will be checked in to the usual
> source code tree. Changes will undoubtedly be made, but they will be
> reflected only in the source code hierarchy -- the proposal will remain
> as originally posted.
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org