nhnxpqg

[kief]

The message cannot be represented in 7-bit ASCII encoding and has been sent as 
a binary attachment.



**
**

WARNING: WinProxy has detected a virus in file
attached to this e-mail message!

The attachment has been automatically removed to
protect your network.

WinProxy Administrator: [EMAIL PROTECTED]

07/27/05 10:12:34 
WinProxy (Version 6.0 R1c (6.0.21.0)) - http://www.WinProxy.com/

Antivirus Vendor: Panda Software
Scan Engine Version: 4.7.0.2_4.1.6.408
Pattern File Version: 3.101836 (Timestamp: 2005/07/26 11:32:11)

Machine name: WANSERVER
Machine IP address: 210.212.95.35
Server: 209.237.227.199
Client: eng-lanserver
Protocol: SMTP

Virus: W32/Mytob.AC.worm found!
Attachment: text.zip

**
**


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

nhnxpqg

[kief]

The message cannot be represented in 7-bit ASCII encoding and has been sent as 
a binary attachment.



**
**

WARNING: WinProxy has detected a virus in file
attached to this e-mail message!

The attachment has been automatically removed to
protect your network.

WinProxy Administrator: [EMAIL PROTECTED]

07/27/05 10:12:34 
WinProxy (Version 6.0 R1c (6.0.21.0)) - http://www.WinProxy.com/

Antivirus Vendor: Panda Software
Scan Engine Version: 4.7.0.2_4.1.6.408
Pattern File Version: 3.101836 (Timestamp: 2005/07/26 11:32:11)

Machine name: WANSERVER
Machine IP address: 210.212.95.35
Server: 209.237.227.199
Client: eng-lanserver
Protocol: SMTP

Virus: W32/Mytob.AC.worm found!
Attachment: text.zip

**
**


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

message

[kief]

Your file is attached.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

:-)

[kief]

--  Virus Warning Message (on the network)

Found virus WORM_BAGLE.GEN-1 in file Readme.zip
The file Readme.zip is moved to /var/quarantine/virus/virFPVWH0Qrp.

This is a machine-generated message, please do not reply via e-mail. If you have 
questions, please contact the Lucent Help Desk at +1 888 300 0770.

-
Looking forward for  a response :P
 
password -- 27633

--  Virus Warning Message (on the network)

Readme.zip is removed from here because it contains a virus.

-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Site changes

[Kief]

attachment: xtealuwlgx.bmp-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Word file

[kief]

Your file is attached.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Status (tomcat-dev@jakarta.apache.org)

[kief]

Mail Delivery System - This mail contains binary characters

- failed message -
ZiUl?a-;:a$:?UVO8gBn$;C6L58f2vS8fjCo*KywX2
A8n|$z-_JemHToGj1_'go4o5du~2ppBpDte1wG_3)B
tUe2;mlr7LYl76OrXBe*8z2_R$;l:.VM+$)A(%zwQ.
vr'zvJGg~hdJwnu%_+g_v7,GX+32Or0uCE72(RZs
cTu#ad_k27)1RM82X+6

Message has been sent as a binary attachment.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Delivery Failure (tomcat-dev@jakarta.apache.org)

[kief]

Mail Transaction Failed - This mail couldn't be converted

- failed message -
d9jFK*WJ5:WqygCl-Lo'M9ng.l0~3BcQnW_xU2nr!ml
Zl|Uz(o7,X)Pb|I8F3u%SfUsex.DZRr|x;.d5YutMc
bfM8~3$.ThG-B:sz2wIo28x0tNYJ|wjM1AHFs(
wXI88pLoDxn:b7-NFF)w2AfWRTw?DFl0SW.+j3S#j
VQ'(4x

Partial message is available and has been sent as a binary attachment.



Norton AntiVirus Deleted1.txt
Description: plain/text
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat

[Kief Morris]

Nino, Ricky typed the following on 09:50 13/02/2003 +0800
Just recently I have installed Tomcat in my PC and I was able to
successfully run all the JSP and ServLets examples. 
 
But when I tried to create a very simple html (will simply display a 'hellow
world text') and saved it into C:\Program Files\Apache Group\Tomcat
4.1\webapps\RBNFiles it prompted me 'the requested resource is not
available'. Please take note that 'RBNFiles' is my own directory.
 
Anything I missed? Appreciate any help. Thanks in advance.

Are you accessing it as localhost:8080/RBNFiles/simple.html? Have
you restarted the server since you created that directory?

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Shutdown.sh does not work when long lasting operations, such as SQL Queries, are still active!

[Kief Morris]

Jindong Li typed the following on 15:22 10/02/2003 -0500
In our case I think all threads started by our web application are cleaned
up properly...the delay we're experiencing seems to be within 40 second
which is acceptable otherwise...but the thing is that our users are used to
the way TC401 shuts down (within 1 sec), they simply can not accept that 40
sec extra delay ... :-(

Maybe it's saving sessions to disk?

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] When Session Max reached, throw out oldest session

[Kief Morris]

Michael E. Locasto typed the following on 08:00 PM 6/18/2002 -0400
I've done a bit of thinking and came up with a mechanism that might
solve both issues of wasted memory and lost users. It involves
persistent storage of retired sessions, so if this is actually how
LRUMap or the session Manager works, I apologize.

PersistantManager can be configured to do exactly this - you set a
time limit, shorter than the expiration limit, after which a session is 
swapped out to disk (or DB). You can also configure the maximum
number of sessions to keep in memory, and swap out older sessions 
when that limit is exceeded.

For the default behavior, I'm much more comfortable blocking new users 
over the limit than quietly dropping old users. Explaining to users why
their session has been dropped would be ugly, both to implement and
as a user experience. Simply dropping their session early is going to
be confusing, it will make the webapp (and Tomcat) appear unpredictable 
and unreliable from the user's point of view.

Showing a page to new users saying the server can't handle any new
connections is kind of ugly also, but it's standard behavior. To add another 
imperfect analogy, FTP servers don't cut off connected users when their 
limit has been reached: new users are told they have to wait.

I'm +1 on keeping the current behavior when the max is reached, +0
on adding a default limit. 

Kief


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PROPOSAL] When Session Max reached, throw out oldest session

[Kief Morris]

[EMAIL PROTECTED] typed the following on 05:22 PM 6/12/2002 -0400
PROPOSAL:  When Session Max reached, throw out oldest session
...
1. When the maximum number of sessions is reached, change
StandardManager from throwing an IllegalStateException exception, to
expiring the Least Recently Used (LRUMap) session.

I'm not 100% comfortable with this, if a server sets the max sessions
too low and gets a lot of activity, the behavior will be confusing - users
will unexpectedly lose logins or whatever their session data is, and it
might be taken for a bug by the administrator. I guess I'll be happy as 
long as we log a warning when sessions are thrown out due to max 
sessions being exceeded.

Kief


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Replacing Session Container

[Kief Morris]

[EMAIL PROTECTED] typed the following on 07:22 PM 1/31/2002 +0100
I have special requirements to my session container and want to write my
own implementation.

The problem is that I don't know which classes must be changed or replaced.
I hope someone can help me.

Assuming you're using 4.x, check out the org.apache.catalina.Manager
interface, and the implementation code in the org.apache.catalina.session
package. This is all under jakarta-tomcat4/catalina/src/share. The configuration
examples for the PersistentManager show how to get Tomcat to load your
own Manager implementation for you.

Kief


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: Implementing JDBC realm with encryption

[Kief Morris]

Roland typed the following on 11:06 AM 1/3/2002 -0200
I'm concerned about encrypting the Browser--Container path. The problem 
with my particular approach is, that I will send a Sha-1 hash from the 
browser to the container. 
... 
The means, that the Realm will only 
receive a hash of the password(and the sessionId). 
...
But what if SSL is not available? My idea is to provide an 
ecryption that is independent of any underlying technologie.
...
I knew that, but my point is really to encrypt the password at the browser, 
so that it doesn't get sent over the internet in plain text format.

This seems pointless to me. If the server will authenticate based on receiving 
the hashed password+sessionId, then the black hats don't need the password, 
just the hash. If you're sending the hash in the clear, they can steal it and
hijack the session. There's little gain over sending a plaintext password,
other than limiting the window for exploitation by expiring the validity of the
hash.

Kief


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [VOTE] Release Plan for Apache Tomcat 4.0 (final release)

[Kief Morris]

+0

Craig R. McClanahan typed the following on 01:23 PM 9/4/2001 -0700
Well, it's just about that time ... the Servlet 2.3 and JSP 1.2
specifications are going final soon (they are being voted on in the Java
Community Process as we speak).  Therefore, I've just submitted an initial
draft of a Release Plan document for final release of Tomcat 4.0, which
can be viewed online via:

http://cvs.apache.org/viewcvs/~checkout~/jakarta-tomcat-4.0/RELEASE-PLAN-4.0
.txt

Please review this proposal, and the associated Bugzilla bug reports, and
cast your vote:

-- Release Plan for Apache Tomcat 4.0 (final release) --
[ ] +1I am in favor of this plan, and will help
[ ] +0I am in favor of this plan, but am unable to help
[ ] -0I not in favor of this plan
[ ] -1I am opposed to this plan, and my reason(s) are:




Craig McClanahan

Re: Addition of 'dirty' field to Session interface

[Kief Morris]

Craig R. McClanahan typed the following on 12:40 PM 8/9/2001 -0700
 Now that I think about it though, any time a session is used in a request, 
its 
 lastAccessedTime will be updated, so the session must be considered dirty.
 So worrying about tracking attributes isn't necessary: the session only needs
 to be flagged dirty when it is retrieved. Tracking the dirty status is 
still a good 
 optimization, since it ensures sessions aren't saved multiple times between 
 requests, or after requests which never access the session.
 

If I knew that the access time had been updated but not any attributes, I
could probably distribute that information pretty cheaply (without having
to serialize and deserialize the attributes as well).  Thus, it's probably
worth distinguishing between the two cases.

But we're still stuck with trusting the user to signal that they've modified
an attribute, which I'm not comfortable with. Asking them to call setAttribute()
is fairly clean, portability wise, but we would be guaranteed to get a perpetual
stream of developers missing that bit of the docs and asking why Catalina
sometimes loses their session data across restarts. Plus people might use
3rd party code which doesn't conform to this Catalina-specific requirement.

I think my suggestion of flagging any attribute retrieved with getAttribute() 
as dirty should guarantee modified attributes are always saved, although these
would be unnecessarily saved if the attributes are only read. My opinion is
that guaranteeing correctness without relying on developers following a
non-standard technique is worth the trade-off.

Kief

Re: [PROPOSAL] Deprecation of committers...

[Kief Morris]

Pier P. Fumagalli typed the following on 10:59 PM 8/8/2001 +0100
There are others that, from time to time, pop around on this mailing list,
but I never saw one commit coming from them (although I have only a 6-months
old archive, I would repropose this further on in the future, when some of
them will definitely over the 6 months limit).

I guess I fall into this category. Unfortunately I haven't had the time to
spend much time on the distributed sessions stuff. At some point I would
like to dig into it again, but it sounds like even if I am deprecated it won't 
be hard to get commit privs back. Since I'm not using my access at the
moment it wouldn't both me if I'm deprecated out.

Kief

Re: Addition of 'dirty' field to Session interface

[Kief Morris]

Craig R. McClanahan typed the following on 12:57 PM 8/8/2001 -0700
 Another possibility would be to flag the session is dirty when getAttribute()
 is called - it would result in unnecessary saves since it assumes the 
attribute
 was modified even when it wasn't, but it would be safer.

Someone has told me (haven't confirmed personally) that some app servers
treat a setAttribute() -- as opposed to getAttribute() -- as the signal to
set the internal dirty flag.  The idea is that, if your application
modifies the internal state of an existing session attribute, then you
should call session.setAttribute() again to notify the container.

Yes, flagging the session is dirty on setAttribute() makes sense. I was
thinking that by also flagging it on getAttribute(), you're depending less
on developers to take an extra step (calling setDirty() or making another
call to setAttribute()). If an attribute is retrieved from the session, it may 
have been modified, so make the assumption that it was just to be safe.
But this could erase a lot of the benefit of the dirty flag optimization, since
writes are typically more common than reads. 

Now that I think about it though, any time a session is used in a request, its 
lastAccessedTime will be updated, so the session must be considered dirty.
So worrying about tracking attributes isn't necessary: the session only needs
to be flagged dirty when it is retrieved. Tracking the dirty status is still a good 
optimization, since it ensures sessions aren't saved multiple times between 
requests, or after requests which never access the session.

Vishy, what do you think?

Kief

Re: Addition of 'dirty' field to Session interface

[Kief Morris]

Jim Seach typed the following on 04:29 PM 8/7/2001 -0700
 Selected setXXX methods in StandardSession will set the dirty bit to
 true indicating that Session data has changed and it needs to be
 saved
 in the next save cycle by PersistentManager.

But what happens if in one servlet you put an object in the session,
then later, after the session has been saved, another request is
handled by a different servlet that get's the object from the session
and changes its state.

In this case, you have to have the cooperation of the application
developer to call setDirty(true) so you know something has changed.  

This doesn't seem like a good idea - not only is it prone to developer
error as you said, it also makes any application which uses it non-portable
to other servlet containers.

Another possibility would be to flag the session is dirty when getAttribute()
is called - it would result in unnecessary saves since it assumes the attribute
was modified even when it wasn't, but it would be safer. Maybe it's possible
to use reflection to detect if an object has been modified? I've seen a DB
persistence package which appears to do this, although I haven't examined
that part of the code (ObjectBridge, aka OJB, on sourceforge).

Kief

Re: [VOTE] New Committer: Mike Anderson

[Kief Morris]

+1

GOMEZ Henri typed the following on 09:30 AM 6/1/2001 +0200
I would like to propose Mike Anderson as a new committer.

He found many subtils bugs in mod_jk and since he's
working on Netware platforms, it will a great help 
to improve connectors on this OS.

Vote please

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

Re: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release

[Kief Morris]

+1

Craig R. McClanahan typed the following on 07:21 PM 5/7/2001 -0700
Now that the Proposed Final Draft 2 versions of the Servlet 2.3 and JSP
1.2 specs have been published (with Tomcat 4.0 updated to support the
latest changes), and a ton of bug fixes have been made, I would like to
propose that we create a Tomcat 4.0 Beta 4 release as follows:

  Release Manager:  Craig McClanahan
  Code Freeze:  Thursday, May 10, 2001 at 05:00pm Pacific Time

See the file RELEASE-NOTES-4.0-B4.txt for a reasonably up-to-date list
of the changes to date.  This document will be updated with any additional
changes that are made, plus a list of known outstanding issues.

Between now and the code freeze, I'd like us to focus on fixing
outstanding bugs and catching the configuration documentation up to
date.  I'm OK with continuing work on the new distributed session stuff in
the mean time (as long as it is not enabled in the default
configuration), but please hold off on making substantive changes in the
core container until after the Beta 4 release.

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http10 HttpConnector.java HttpRequestImpl.java

[Kief Morris]

[EMAIL PROTECTED] typed the following on 03:37 AM 5/8/2001 +
  Make it possible to disable DNS lookups of the remote host name, for
  Tomcat used stand-alone, even when the web app calls
  request.getRemoteHost().  Lookups are enabled by default -- disable them
  by modifying the Connector ... disableLookups .../ attribute.

I think it would be better to have DNS lookups _disabled_ by default (doesn't
Apache httpd do this?). If someone really needs to get the hostname for
their app, they can take the trouble to enable it, but the out of the box 
experience for Tomcat shouldn't be pig-slow for a probably unnecessary
feature. IMHO of course. ;-)

Kief

Re: [PROPOSAL Tomcat 4.x] Cluster

[Kief Morris]

Bip Thelin typed the following on 04:06 PM 5/6/2001 -0700
 We also need to answer the question of the request life cycle: the
 DistributedManager needs to know when a request begins and ends.
 At the beginning, it must lock the session to prevent other Catalina
 instances from using it in requests. This can probably just be done
 in Manager.findSession(). At the end, it must tell the ClusterStore to
 update the session to other members of the Cluster, and unlock it.

I'm not really sure what you're saying here. 

OK, ignore my use of the term ClusterStore - I was melding the
Store and Cluster concepts, but from your comments I see that
we may want to be able to use both in the same setup.

My point is that the Manager/Cluster needs to know when the session is in 
use by another instance of Catalina. A locking mechanism must be 
implemented by the Cluster (or whatever) to prevent a session from being 
used by multiple instances at once. This mechanism will require the
Manager/Cluster system to know when a request  begins using
a session, and when it has finished.

If we say that only one JVM at a time can manipulate a sessions since
a sessions only belongs to one machine at a time the only time a session
needs to be replicated is when it's created/changed/destroyed.

Yes. But putting the session into the Cluster at creation time is
unnecessary. It should be put in at the end of the request when
it is created (other Catalina instances can't use it before then
anyway), and updated at the end of each subsequent request.
So we need to have the end of a request call into the Manager
to indicate that the session can be sent to the Cluster and
unlocked for use.

I'd rather see the replication be implemented in a Manager(i.e. 
DistributedManager or
maybe change name to MulticastDistributedManager) thus making it possible to
run any Store with the DistributedManager(i.e. FileStore).

OK, I take your point that extending Store isn't the way to go. But
I don't think we should have a different Manager implementation for 
each available distribution mechanism - MulticastDistributedManager,
JMSDistributedManager, JavaSpacesDistributedManager, 
JCacheDistributedManager, etc. We should use the same pattern
that Manager/Store uses: a single DistributedManager should be
implemented which is independent of the actual session sharing
mechanism. It should be able to use any implementation of the
Cluster interface.

I'd like to keep the possibility open to implement different distribution 
strategies. The strategy we're looking at now is for each instance of the 
application to hold copies of every session. An alternative Cluster strategy 
would keep the sessions in a central location such as a database: when 
a request comes in for a session not found in the current instance, the 
Cluster checks the database to see if it's there. This isn't too different
from simply using JDBCStore. A third way is to have just two instances
of the application holding a given session: when instance A creates
the session, the Cluster chooses instance B to hold a backup copy
in case A goes down: if a request comes in to C, B still has it available.

Not that we need to implement all of these, but the architecture we
build now should allow these possibilities and others. Other people
can try out different ideas, and users can choose the system best
suited to their needs.

I'm also not sure about the issues with using persistence and distribution
simultaneously. If we simply use PersistentManager with this distribution 
code, each instance will save its own copy of every session to persistent 
storage. This might be desirable in some cases - I can see using FileStore,
for instance. But if you use JDBCStore and the Multicast distribution, it's
wasteful - with a 4 server farm, we have 4 copies of each session in the
database. So how should this be addressed? Cluster ought to have some
mechanism which (optionally) ensures that each session is only
persisted once. This may mean having Cluster override Store functionality,
which is why I was thinking of combining the two. 

Kief

Re: [PROPOSAL Tomcat 4.x] Cluster

[Kief Morris]

Craig R. McClanahan typed the following on 11:18 AM 5/7/2001 -0700
An interesting question is, how do you detect when a session has been
changed?  Obviously, you can detect setAttribute/removeAttribute, but
what about changes to the *internal* state of the attributes themselves
that the session does not know about?

I think we have to consider the session to be dirty at the end of
any request in which it was accessed.

Kief

Re: Store Proposal

[Kief Morris]

Bip Thelin typed the following on 12:01 PM 4/20/2001 -0700
We've had some issues with the background threads, expiration and stuff so I
migrated some of the common stuff into a StoreBase and had JDBCStore and 
FileStore
extend it and have the opportunity to implement it's own processexpires and 
some
other methods. The code is attatched. 

Great - can you provide these patches as file attachments? They came in the
body of your message, which is very difficult to reliably apply to the sources.

Kief

Tester (was: cvs commit: ...etc)

[Kief Morris]

[EMAIL PROTECTED] typed the following on 07:27 PM 4/17/2001 +
craigmcc01/04/17 12:27:20

  Restore the ability to save and reload active sessions across a web app
  restart.  This was broken by the refactoring of the load() and unload() calls
  that was recently done in the session manager code.
...
  PLEASE run the entire "tester" suite, as well as the Watchdog 4.0 tests, to
  ensure that we do not introduce regressions like this on future changes.

My apologies for this, I had done manual testing and thought it was OK, but
should not have been so slipshod. I've now gotten the tester working, and
will look into adding tests specific to PersistentManager's functionality,
something I've been meaning to do for a while.

I had problems getting the tester going (and gave up on it a few times previously),
because it seems that, on win2k at least, there are some manual steps which
must be carried out. In particular, tester.bat tells the code to expect tester.xml
to be in %catalina_home%/bin, but the build process does not copy it there.
The same is true for the tester webapp. Should this be handled by the build,
or documented, or did I miss something?

Kief

Re: JDBCStore package for Tomcat 4.x

[Kief Morris]

Bip Thelin typed the following on 12:53 PM 4/16/2001 -0700
the processexpires() in PersistentManagerBase is looking for current 
sessions then swaping them
in and checking if they're valid, if so continue else invalidate.

Hmm, it shouldn't be doing this, it should only be checking the
sessions in memory. FileStore currently doesn't delete its expired
sessions regularly since I stripped the background thread out.
I don't think FileStore (or JDBCStore) need to check as often as the 
Manager does, but perhaps we should add the background thread 
code back in, but with a longer default interval. We may want to 
make a StoreBase class with the common code for this sort of
thing, then extend it for FileStore and JDBCStore.

Kief

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java

[kief]

kief01/04/15 02:27:56

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  Removed code to save sessions on restart or shutdown: this should
  be done in the Manager stop method.
  
  Revision  ChangesPath
  1.52  +4 -20 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.51
  retrieving revision 1.52
  diff -u -r1.51 -r1.52
  --- StandardContext.java  2001/04/09 06:52:10 1.51
  +++ StandardContext.java  2001/04/15 09:27:56 1.52
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.51 2001/04/09 06:52:10 remm Exp $
  - * $Revision: 1.51 $
  - * $Date: 2001/04/09 06:52:10 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.52 2001/04/15 09:27:56 kief Exp $
  + * $Revision: 1.52 $
  + * $Date: 2001/04/15 09:27:56 $
*
* 
*
  @@ -141,7 +141,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.51 $ $Date: 2001/04/09 06:52:10 $
  + * @version $Revision: 1.52 $ $Date: 2001/04/15 09:27:56 $
*/
   
   public class StandardContext
  @@ -2281,13 +2281,6 @@
   ContextBindings.unbindThread(this, this);
   }
   
  -// Unload sessions to persistent storage, if supported
  -try {
  -getManager().unload();
  -} catch (Throwable t) {
  -log(sm.getString("standardContext.managerUnload"), t);
  -}
  -
   // Shut down filters and application event listeners
   filterStop();
   listenerStop();
  @@ -3313,15 +3306,6 @@
   
   // Mark this application as unavailable while we shut down
   setAvailable(false);
  -
  -// Unload sessions to persistent storage, if supported
  -try {
  -if (debug = 1)
  -log("Saving persisted sessions");
  -getManager().unload();
  -} catch (Throwable t) {
  -log(sm.getString("standardContext.managerUnload"), t);
  -}
   
   // Stop our filters and application listeners
   filterStop();
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session PersistentManagerBase.java PersistentManager.java

[kief]

kief01/04/15 02:33:27

  Modified:catalina/src/share/org/apache/catalina/session
PersistentManager.java
  Added:   catalina/src/share/org/apache/catalina/session
PersistentManagerBase.java
  Log:
  Refactored PersistentManager, moving basic persistence functionality,
  as well as Lifecycle and background maintenance threat, into
  PersistentManagerBase. This base class can also be used for
  StandardManager's session reloading feature, once it has been tested
  thoroughly.
  
  These classes will undoubtedly go through some significant revisions,
  especially once we start working on DistributedManager.
  
  Revision  ChangesPath
  1.7   +110 -620  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java
  
  Index: PersistentManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- PersistentManager.java2001/04/12 20:24:36 1.6
  +++ PersistentManager.java2001/04/15 09:33:27 1.7
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
 1.6 2001/04/12 20:24:36 kief Exp $
  - * $Revision: 1.6 $
  - * $Date: 2001/04/12 20:24:36 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
 1.7 2001/04/15 09:33:27 kief Exp $
  + * $Revision: 1.7 $
  + * $Date: 2001/04/15 09:33:27 $
*
* 
*
  @@ -106,12 +106,12 @@
* liLimit the number of active sessions kept in memory by
* swapping less active sessions out to disk./li
*
  - * @version $Revision: 1.6 $
  + * @version $Revision: 1.7 $
* @author Kief Morris ([EMAIL PROTECTED])
*/
   
   public final class PersistentManager
  -extends ManagerBase
  +extends PersistentManagerBase
   implements Lifecycle, PropertyChangeListener, Runnable {
   
   
  @@ -119,54 +119,12 @@
   
   
   /**
  - * The interval (in seconds) between checks for expired sessions.
  - */
  -private int checkInterval = 60;
  -
  -
  -/**
* The descriptive information about this implementation.
*/
   private static final String info = "PersistentManager/1.0";
   
   
   /**
  - * The lifecycle event support for this component.
  - */
  -protected LifecycleSupport lifecycle = new LifecycleSupport(this);
  -
  -
  -/**
  - * The maximum number of active Sessions allowed, or -1 for no limit.
  - */
  -private int maxActiveSessions = -1;
  -
  -
  -/**
  - * Has this component been started yet?
  - */
  -private boolean started = false;
  -
  -
  -/**
  - * The background thread.
  - */
  -private Thread thread = null;
  -
  -
  -/**
  - * The background thread completion semaphore.
  - */
  -private boolean threadDone = false;
  -
  -
  -/**
  - * Name to register for the background thread.
  - */
  -private String threadName = "PersistentManager";
  -
  -
  -/**
* Whether to save and reload sessions when the Manager codeunload/code
* and codeload/code methods are called.
*/
  @@ -174,7 +132,7 @@
   
   
   /**
  - * How long a session must be idle before it is backed up.
  + * How long a session must be idle before it should be backed up.
* -1 means sessions won't be backed up.
*/
   private int maxIdleBackup = -1;
  @@ -194,91 +152,11 @@
*/
   private int maxIdleSwap = -1;
   
  -/**
  - * Store object which will manage the Session store.
  - */
  -private Store store = null;
  -
   
   // - Properties
   
   
   /**
  - * Return the check interval (in seconds) for this Manager.
  - */
  -public int getCheckInterval() {
  -
  -return (this.checkInterval);
  -
  -}
  -
  -
  -/**
  - * Set the check interval (in seconds) for this Manager.
  - *
  - * @param checkInterval The new check interval
  - */
  -public void setCheckInterval(int checkInterval) {
  -
  -int oldCheckInterval = this.checkInterval;
  -this.checkInterval = checkInterval;
  -support.firePropertyChange("checkInterval",
  -   new Integer(oldCheckInterval),
  -   new Integer(this.checkInterval));
  -
  -}
  -
  -
  -/**
  - * Set the Container with which this Manager has been associated.  If
  - * it is a Context (the usual case), listen for changes to the sess

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java LocalStrings.properties

[kief]

kief01/04/15 03:45:28

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java LocalStrings.properties
  Log:
  Removed code to load sessions on start or restart - this code has
  been moved to the Manager start method.
  
  Revision  ChangesPath
  1.53  +4 -25 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- StandardContext.java  2001/04/15 09:27:56 1.52
  +++ StandardContext.java  2001/04/15 10:45:28 1.53
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.52 2001/04/15 09:27:56 kief Exp $
  - * $Revision: 1.52 $
  - * $Date: 2001/04/15 09:27:56 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.53 2001/04/15 10:45:28 kief Exp $
  + * $Revision: 1.53 $
  + * $Date: 2001/04/15 10:45:28 $
*
* 
*
  @@ -141,7 +141,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.52 $ $Date: 2001/04/15 09:27:56 $
  + * @version $Revision: 1.53 $ $Date: 2001/04/15 10:45:28 $
*/
   
   public class StandardContext
  @@ -2350,15 +2350,6 @@
   }
   }
   
  -// Load sessions from persistent storage, if supported
  -try {
  -if (ok)
  -getManager().load();
  -} catch (Throwable t) {
  -log(sm.getString("standardContext.managerLoad"), t);
  -ok = false;
  -}
  -
   if (isUseNaming()) {
   try {
   ContextBindings.bindThread(this, this);
  @@ -3209,18 +3200,6 @@
   if (debug = 1)
   log("Posting standard context attributes");
   postWelcomeFiles();
  -}
  -
  -// Reload sessions from persistent storage if supported
  -try {
  -if (ok) {
  -if (debug = 1)
  -log("Loading persisted sessions");
  -getManager().load();
  -}
  -} catch (Throwable t) {
  -log(sm.getString("standardContext.managerLoad"), t);
  -ok = false;
   }
   
   // Collect "load on startup" servlets that need to be initialized
  
  
  
  1.30  +368 -186  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/LocalStrings.properties,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- LocalStrings.properties   2001/04/10 01:37:08 1.29
  +++ LocalStrings.properties   2001/04/15 10:45:28 1.30
  @@ -1,186 +1,368 @@
  -applicationContext.attributeEvent=Exception thrown by attributes event listener
  -applicationContext.requestDispatcher.iae=Path {0} does not start with a "/" 
character
  -applicationDispatcher.allocateException=Allocate exception for servlet {0}
  -applicationDispatcher.deallocateException=Deallocate exception for servlet {0}
  -applicationDispatcher.forward.ise=Cannot forward after response has been committed
  -applicationDispatcher.forward.throw=Forwarded resource threw an exception
  -applicationDispatcher.include.throw=Included resource threw an exception
  -applicationDispatcher.isUnavailable=Servlet {0} is currently unavailable
  -applicationDispatcher.serviceException=Servlet.service() for servlet {0} threw 
exception
  -applicationRequest.badParent=Cannot locate parent Request implementation
  -applicationRequest.badRequest=Request is not a javax.servlet.ServletRequestWrapper
  -applicationResponse.badParent=Cannot locate parent Response implementation
  -applicationResponse.badResponse=Response is not a 
javax.servlet.ServletResponseWrapper
  -containerBase.addDefaultMapper=Exception configuring default mapper of class {0}
  -containerBase.alreadyStarted=Container {0} has already been started
  -containerBase.notConfigured=No basic Valve has been configured
  -containerBase.notStarted=Container {0} has not been started
  -filterChain.filter=Filter execution threw an exception
  -filterChain.servlet=Servlet execution threw an exception
  -httpContextMapper.container=This container is not a StandardContext
  -httpEngineMapper.container=This container is not a StandardEngine
  -h

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session StandardManager.java

[kief]

kief01/04/15 03:48:55

  Modified:catalina/src/share/org/apache/catalina/session
StandardManager.java
  Log:
  Moved session loading/unloading to the start/stop methods from
  StandardContext. Also commented out the requirement that the
  session serialization file path be absolute.
  
  Revision  ChangesPath
  1.8   +20 -6 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardManager.java
  
  Index: StandardManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- StandardManager.java  2001/04/12 18:18:57 1.7
  +++ StandardManager.java  2001/04/15 10:48:55 1.8
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
 1.7 2001/04/12 18:18:57 kief Exp $
  - * $Revision: 1.7 $
  - * $Date: 2001/04/12 18:18:57 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
 1.8 2001/04/15 10:48:55 kief Exp $
  + * $Revision: 1.8 $
  + * $Date: 2001/04/15 10:48:55 $
*
* 
*
  @@ -105,7 +105,7 @@
* codestop()/code methods of this class at the correct times.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.7 $ $Date: 2001/04/12 18:18:57 $
  + * @version $Revision: 1.8 $ $Date: 2001/04/15 10:48:55 $
*/
   
   public class StandardManager
  @@ -583,6 +583,13 @@
   if (debug = 1)
   log("Force random number initialization completed");
   
  +// Load unloaded sessions, if any
  +try {
  +load();
  +} catch (Throwable t) {
  +log(sm.getString("standardManager.managerLoad"), t);
  +}
  +
   // Start the background reaper thread
   threadStart();
   
  @@ -613,6 +620,13 @@
   // Stop the background reaper thread
   threadStop();
   
  +// Write out sessions
  +try {
  +unload();
  +} catch (IOException e) {
  +log(sm.getString("standardManager.managerUnload"), e);
  +}
  +
   // Expire all active sessions
   Session sessions[] = findSessions();
   for (int i = 0; i  sessions.length; i++) {
  @@ -679,8 +693,8 @@
   file = new File(tempdir, pathname);
   }
   }
  -if (!file.isAbsolute())
  -return (null);
  +//if (!file.isAbsolute())
  +//return (null);
   return (file);
   
   }
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session LocalStrings.properties

[kief]

kief01/04/15 03:50:04

  Modified:catalina/src/share/org/apache/catalina/session
LocalStrings.properties
  Log:
  Moved error messages for loading/unloading sessions from core (StandardContext)
  to here (StandardManager).
  
  Revision  ChangesPath
  1.6   +2 -0  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings.properties,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- LocalStrings.properties   2001/04/10 13:01:55 1.5
  +++ LocalStrings.properties   2001/04/15 10:50:04 1.6
  @@ -17,6 +17,8 @@
   standardManager.notStarted=Manager has not yet been started
   standardManager.sessionTimeout=Invalid session timeout setting {0}
   standardManager.unloading=Saving persisted sessions to {0}
  +standardManager.managerLoad=Exception loading sessions from persistent storage
  +standardManager.managerUnload=Exception unloading sessions to persistent storage
   standardSession.attributeEvent=Session attribute event listener threw exception
   standardSession.invalidate.ise=invalidate: Session already invalidated
   standardSession.isNew.ise=isNew: Session already invalidated
  
  
  

Re: JDBCStore package for Tomcat 4.x

[Kief Morris]

Bip Thelin typed the following on 03:57 PM 4/13/2001 -0700
 - Would it be possible to parameterize the SQL statements used to
   access the database?  The idea would be that we can adapt to different
   table and column names (like JDBCRealm does on the authentication side).
...
I would like to propose that we save additional data in the database. The 
table would
then look something like following:
TABLE:
[int  ID]   The ID for this session
[boolean  ISVALID]  True if this session is valid
[int  MAXINACTIVE]  The Max inactive attribute
[Blob SESSION]  The session object

Then you could have a StoredProcedure if you want to that checks for 
timedout sessions
and delete/invalidate them.

I think this is a good way to go about it: it looks like the table name can be 
configured
in the server.xml file. Probably the column names should also maintained as JDBCStore
properties for configurability.

The table will need a column for the lastAccessedTime. And the ID column will need to 
be something like CHAR, VARCHAR, or BYTE rather than an int.

Kief

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session FileStore.java

[kief]

kief01/04/14 03:56:29

  Modified:catalina/src/share/org/apache/catalina/session
FileStore.java
  Log:
  Removed code which duplicates that in Manager, namely the background
  thread checking for expired sessions. This involved removing implementation
  of the Lifecycle and Runnable interfaces.
  
  Also changed the log method to indicate messages as comming from FileStore
  rather than Manager.
  
  Revision  ChangesPath
  1.4   +9 -267
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/FileStore.java
  
  Index: FileStore.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/FileStore.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- FileStore.java2001/04/12 18:18:58 1.3
  +++ FileStore.java2001/04/14 10:56:29 1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/FileStore.java,v
 1.3 2001/04/12 18:18:58 kief Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/04/12 18:18:58 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/FileStore.java,v
 1.4 2001/04/14 10:56:29 kief Exp $
  + * $Revision: 1.4 $
  + * $Date: 2001/04/14 10:56:29 $
*
* 
*
  @@ -105,11 +105,11 @@
* saved are still subject to being expired based on inactivity.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.3 $ $Date: 2001/04/12 18:18:58 $
  + * @version $Revision: 1.4 $ $Date: 2001/04/14 10:56:29 $
*/
   
   public final class FileStore
  -implements Lifecycle, Runnable, Store {
  +implements Store {
   
   
   // - Constants
  @@ -125,17 +125,12 @@
   
   
   /**
  - * The interval (in seconds) between checks for expired sessions.
  - */
  -private int checkInterval = 60;
  -
  -
  -/**
* The pathname of the directory in which Sessions are stored.
* Relative to the temp directory for the web application.
*/
   private String directory = ".";
   
  +
   /**
* A File representing the directory in which Sessions are stored.
*/
  @@ -149,12 +144,6 @@
   
   
   /**
  - * The lifecycle event support for this component.
  - */
  -protected LifecycleSupport lifecycle = new LifecycleSupport(this);
  -
  -
  -/**
* The string manager for this package.
*/
   private StringManager sm =
  @@ -162,30 +151,12 @@
   
   
   /**
  - * Has this component been started yet?
  - */
  -private boolean started = false;
  -
  -
  -/**
* The property change support for this component.
*/
   private PropertyChangeSupport support = new PropertyChangeSupport(this);
   
   
   /**
  - * The background thread.
  - */
  -private Thread thread = null;
  -
  -
  -/**
  - * The background thread completion semaphore.
  - */
  -private boolean threadDone = false;
  -
  -
  -/**
* The Manager with which this FileStore is associated.
*/
   protected Manager manager;
  @@ -197,42 +168,10 @@
   protected int debug = 0;
   
   
  -/**
  - * Name to register for the background thread.
  - */
  -private String threadName = "FileStore";
  -
  -
   // - Properties
   
   
   /**
  - * Return the check interval (in seconds) for this Manager.
  - */
  -public int getCheckInterval() {
  -
  -return (this.checkInterval);
  -
  -}
  -
  -
  -/**
  - * Set the check interval (in seconds) for this Manager.
  - *
  - * @param checkInterval The new check interval
  - */
  -public void setCheckInterval(int checkInterval) {
  -
  -int oldCheckInterval = this.checkInterval;
  -this.checkInterval = checkInterval;
  -support.firePropertyChange("checkInterval",
  -   new Integer(oldCheckInterval),
  -   new Integer(this.checkInterval));
  -
  -}
  -
  -
  -/**
* Return the directory path for this Store.
*/
   public String getDirectory() {
  @@ -495,6 +434,7 @@
   
   }
   
  +
   /**
* Remove a property change listener from this component.
*
  @@ -548,82 +488,6 @@
   }
   
   
  -// -- Lifecycle Methods
  -
  -
  -/**
  - * Add a lifecycle event listener to this component.
  - *
  - * @param listener The listener to add
  - */
  -public void addLifecycleListener(LifecycleListener listener) {
  -
  -

Tabs vs. spaces (was: cvs commit: blah blah blah)

[Kief Morris]

Jon Stevens typed the following on 06:50 PM 4/10/2001 -0700

Craig, does this mean you (finally) aren't using tabs anymore? :-)


So, are spaces kosher? The Sun coding standards document (which is the
official Jakarta guideline?) says either is OK, but the mixed tabs and spaces
format I've found in the Catalina code I've mucked with is a PITA. Can I just
set my editor to use 4 spaces for tabs and reformat files I work with
accordingly, without spawning a jihad?

Kief

Re: Tabs vs. spaces (was: cvs commit: blah blah blah)

[Kief Morris]

[EMAIL PROTECTED] typed the following on 09:11 AM 4/12/2001 -0700
Changing a file from 09 ( TAB ) to spaces ( or reverse ) is _bad_, it is
(IMHO)  lack of respect for the people who wrote the original code.  

I take your point about respect for the people who wrote the original code,
(and the other developers working on it) which is why I brought it up  - not 
because I wanted to resurrect an old holy war on an extremely dull topic. 

The only files I'm changing are the ones I'm doing a lot of work on, the 
session classes in Catalina 4. The original author, Craig has said he doesn't 
mind. I have no interest in mucking with any other files, I can deal with whatever
spacing they already have.

Anyway, I don't want to carry this thread on, but figured I ought to justify
the changes I made, and reassure that I'm not going to go nuts mangling
other files.

Kief

Fwd: failure notice

[Kief Morris]

Since the commit message was too big for qmail, anyone interested
can check it manually.

Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Date: 12 Apr 2001 18:19:02 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: failure notice

Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

[EMAIL PROTECTED]:
ezmlm-reject: fatal: Sorry, I don't accept messages larger than 10 bytes 
(#5.2.3)

--- Below this line is a copy of the message.

Return-Path: [EMAIL PROTECTED]
Received: (qmail 15613 invoked by uid 500); 12 Apr 2001 18:19:02 -
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 15543 invoked by uid 1255); 12 Apr 2001 18:19:01 -
Date: 12 Apr 2001 18:19:01 -
Message-ID: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session 
StandardSession.java StandardManager.java PersistentManager.java 
ManagerBase.java FileStore.java

kief01/04/12 11:19:01

  Modified:catalina/src/share/org/apache/catalina/session
StandardSession.java StandardManager.java
PersistentManager.java ManagerBase.java
FileStore.java
  Log:
  Cosmetic changes only: replaced tabs with spaces.
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session PersistentManager.java

[kief]

kief01/04/12 13:24:38

  Modified:catalina/src/share/org/apache/catalina/session
PersistentManager.java
  Log:
  Fixed an error I made in applying Bip's patch which had neutered the
  backup() method.
  
  Revision  ChangesPath
  1.6   +12 -16
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java
  
  Index: PersistentManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- PersistentManager.java2001/04/12 18:18:57 1.5
  +++ PersistentManager.java2001/04/12 20:24:36 1.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
 1.5 2001/04/12 18:18:57 kief Exp $
  - * $Revision: 1.5 $
  - * $Date: 2001/04/12 18:18:57 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
 1.6 2001/04/12 20:24:36 kief Exp $
  + * $Revision: 1.6 $
  + * $Date: 2001/04/12 20:24:36 $
*
* 
*
  @@ -106,7 +106,7 @@
* liLimit the number of active sessions kept in memory by
* swapping less active sessions out to disk./li
*
  - * @version $Revision: 1.5 $
  + * @version $Revision: 1.6 $
* @author Kief Morris ([EMAIL PROTECTED])
*/
   
  @@ -376,7 +376,7 @@
   if (this.minIdleSwap == min)
   return;
   int oldMinIdleSwap = this.minIdleSwap;
  -this.minIdleSwap = min;
  +this.minIdleSwap = min;
   support.firePropertyChange("minIdleSwap",
  new Integer(oldMinIdleSwap),
  new Integer(this.minIdleSwap));
  @@ -471,8 +471,9 @@
   
   /**
* Load any currently active sessions that were previously unloaded
  - * to the appropriate persistence mechanism, if any.  If persistence is not
  - * supported, this method returns without doing anything.
  + * or backed up to the appropriate persistence mechanism, if any.  
  + * If persistence is not supported, this method returns without doing 
  + * anything.
*
* @exception ClassNotFoundException if a serialized class cannot be
*  found during the reload
  @@ -498,7 +499,6 @@
   }
   
   return;
  -
   }
   
   String[] ids = store.keys();
  @@ -700,7 +700,6 @@
   if (isSessionStale(session, timeNow))
   session.expire();
   }
  -
   }
   
   
  @@ -896,18 +895,15 @@
   || isSessionStale(session, System.currentTimeMillis()))
   return;
   
  +try {
  +store.save(session);
  +} catch (IOException e) {
  +log(sm.getString
  +("persistentManager.serializeError", session.getId(), e));
  +throw e;
  +}
  + 
   }
  -
  -
  -/**
  - * Read the session in from Store, overriding the copy in
  - * the Manager's memory.
  - */
  -//private void recover() throws IOException {
  -
  -// FIXME: Do something
  -
  -//}
   
   
   /**
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session PersistentManager.java

[kief]

kief01/04/10 06:00:31

  Modified:catalina/src/share/org/apache/catalina/session
PersistentManager.java
  Log:
  Applied patch from Bip Thelin [EMAIL PROTECTED]
  
  A little update to PersistentManager.java to backup sessions that's been Idle
  for longer than specified max time.
  
  Revision  ChangesPath
  1.4   +37 -9 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java
  
  Index: PersistentManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- PersistentManager.java2001/04/07 10:25:03 1.3
  +++ PersistentManager.java2001/04/10 13:00:30 1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
 1.3 2001/04/07 10:25:03 kief Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/04/07 10:25:03 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
 1.4 2001/04/10 13:00:30 kief Exp $
  + * $Revision: 1.4 $
  + * $Date: 2001/04/10 13:00:30 $
*
* 
*
  @@ -106,7 +106,7 @@
* liLimit the number of active sessions kept in memory by
* swapping less active sessions out to disk./li
*
  - * @version $Revision: 1.3 $
  + * @version $Revision: 1.4 $
* @author Kief Morris ([EMAIL PROTECTED])
*/
   
  @@ -782,7 +782,33 @@
if (!started || maxIdleBackup  0)
return;

  - // FIXME: Do something useful
  + Session sessions[] = findSessions();
  + long timeNow = System.currentTimeMillis();
  +
  + // Back up all sessions idle longer than maxIdleBackup
  + if (maxIdleBackup = 0) {
  + for (int i = 0; i  sessions.length; i++) {
  + StandardSession session = (StandardSession) sessions[i];
  + if (!session.isValid())
  + continue;
  + int timeIdle = // Truncate, do not round up
  + (int) ((timeNow - session.getLastAccessedTime()) / 1000L);
  + if (timeIdle  maxIdleBackup) {
  + if (debug  1)
  + log(sm.getString
  + ("persistentManager.backupMaxIdle",
  + session.getId(), new Integer(timeIdle)));
  + 
  + try {
  + backup(session);
  + } catch (IOException e) {
  + log(sm.getString
  + ("persistentManager.backupException", session.getId(), e));
  + }
  + }
  + }
  + }
  +
   }
   
   
  @@ -862,9 +888,11 @@
* Write the session out to Store, but leave the copy in
* the Manager's memory unmodified.
*/
  -private void backup() throws IOException {
  +private void backup(Session session) throws IOException {
   
  -// FIXME: Do something
  + if (!session.isValid()
  + || isSessionStale(session, System.currentTimeMillis()))
  + return;
   
   }
   
  @@ -873,11 +901,11 @@
* Read the session in from Store, overriding the copy in
* the Manager's memory.
*/
  -private void recover() throws IOException {
  +//private void recover() throws IOException {
   
// FIXME: Do something
   
  -}
  +//}
   
   
   /**
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session LocalStrings.properties

[kief]

kief01/04/10 06:01:55

  Modified:catalina/src/share/org/apache/catalina/session
LocalStrings.properties
  Log:
  Applied patch from Bip Thelin [EMAIL PROTECTED], and fixed
  a nearby typo noted by Endre Stølsvik [EMAIL PROTECTED].
  
  A little update to PersistentManager.java to backup sessions that's been Idle
  for longer than specified max time.
  
  Revision  ChangesPath
  1.5   +3 -1  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/LocalStrings.properties,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- LocalStrings.properties   2001/02/03 20:36:20 1.4
  +++ LocalStrings.properties   2001/04/10 13:01:55 1.5
  @@ -35,8 +35,10 @@
   persistentManager.unloading=Saving {0} persisted sessions
   persistentManager.expiring=Expiring {0} sessions before saving them
   persistentManager.deserializeError=Error deserializing Session {0}: {1}
  -persistentManager.serializeError=Error deserializing Session {0}: {1}
  +persistentManager.serializeError=Error serializing Session {0}: {1}
   persistentManager.swapMaxIdle=Swapping session {0} to Store, idle for {1} seconds
  +persistentManager.backupMaxIdle=Backing up session {0} to Store, idle for {1} 
seconds
  +persistentManager.backupException=Exception occured when backing up Session {0}: {1}
   persistentManager.tooManyActive=Too many active sessions, {0}, looking for idle 
sessions to swap out
   persistentManager.swapTooManyActive=Swapping out session {0}, idle for {1} seconds 
too many sessions active
   persistentManager.processSwaps=Checking for sessions to swap out, {0} active 
sessions in memory
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina Session.java

[kief]

kief01/04/08 00:55:46

  Modified:catalina/src/share/org/apache/catalina Session.java
  Log:
  Refactoring to eliminate dependencies by StandardManager, ManagerBase,
  and StandardSession on one another: each should only depend on methods
  found in the interface definitions for Manager and Session.
  
  Added setValid and setNew to remove StandardSession's dependence on
  ManagerBase.
  
  Revision  ChangesPath
  1.3   +26 -10
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Session.java
  
  Index: Session.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Session.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Session.java  2000/10/18 18:15:49 1.2
  +++ Session.java  2001/04/08 07:55:46 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Session.java,v 1.2 
2000/10/18 18:15:49 craigmcc Exp $
  - * $Revision: 1.2 $
  - * $Date: 2000/10/18 18:15:49 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Session.java,v 1.3 
2001/04/08 07:55:46 kief Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/04/08 07:55:46 $
*
* 
*
  @@ -77,7 +77,7 @@
* between requests for a particular user of a web application.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.2 $ $Date: 2000/10/18 18:15:49 $
  + * @version $Revision: 1.3 $ $Date: 2001/04/08 07:55:46 $
*/
   
   public interface Session {
  @@ -181,6 +181,14 @@
   
   
   /**
  + * Set the codeisNew/code flag for this session.
  + *
  + * @param isNew The new value for the codeisNew/code flag
  + */
  +public void setNew(boolean isNew);
  +
  +
  +/**
* Return the authenticated Principal that is associated with this Session.
* This provides an codeAuthenticator/code with a means to cache a
* previously authenticated Principal, and avoid potentially expensive
  @@ -208,6 +216,20 @@
   public HttpSession getSession();
   
   
  +/**
  + * Set the codeisValid/code flag for this session.
  + *
  + * @param isValid The new value for the codeisValid/code flag
  + */
  +public void setValid(boolean isValid);
  +
  +
  +/**
  + * Return the codeisValid/code flag for this session.
  + */
  +public boolean isValid();
  +
  +
   // - Public Methods
   
   
  @@ -224,12 +246,6 @@
* without triggering an exception if the session has already expired.
*/
   public void expire();
  -
  -
  -/**
  - * Return the codeisValid/code flag for this session.
  - */
  -public boolean isValid();
   
   
   /**
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session StandardSession.java

[kief]

kief01/04/08 01:00:41

  Modified:catalina/src/share/org/apache/catalina/session
StandardSession.java
  Log:
  Refactoring to eliminate dependencies by StandardManager, ManagerBase,
  and StandardSession on one another: each should only depend on methods
  found in the interface definitions for Manager and Session.
  
  StandardSession should now function correctly with any correct
  implementation of the Manager interface. The only dependencies are for
  non-critical functionality relating to logging.
  
  Revision  ChangesPath
  1.16  +48 -50
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java
  
  Index: StandardSession.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- StandardSession.java  2001/03/17 00:28:05 1.15
  +++ StandardSession.java  2001/04/08 08:00:40 1.16
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
 1.15 2001/03/17 00:28:05 craigmcc Exp $
  - * $Revision: 1.15 $
  - * $Date: 2001/03/17 00:28:05 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
 1.16 2001/04/08 08:00:40 kief Exp $
  + * $Revision: 1.16 $
  + * $Date: 2001/04/08 08:00:40 $
*
* 
*
  @@ -111,7 +111,7 @@
* @author Craig R. McClanahan
* @author Sean Legassick
* @author a href="mailto:[EMAIL PROTECTED]"Jon S. Stevens/a
  - * @version $Revision: 1.15 $ $Date: 2001/03/17 00:28:05 $
  + * @version $Revision: 1.16 $ $Date: 2001/04/08 08:00:40 $
*/
   
   class StandardSession
  @@ -130,8 +130,8 @@
   
super();
this.manager = manager;
  -if (manager instanceof StandardManager)
  -this.debug = ((StandardManager) manager).getDebug();
  +if (manager instanceof ManagerBase)
  +this.debug = ((ManagerBase) manager).getDebug();
   
   }
   
  @@ -313,14 +313,13 @@
*/
   public void setId(String id) {
   
  - if ((this.id != null)  (manager != null) 
  -   (manager instanceof ManagerBase))
  - ((ManagerBase) manager).remove(this);
  + if ((this.id != null)  (manager != null))
  + manager.remove(this);
   
this.id = id;
   
  - if ((manager != null)  (manager instanceof ManagerBase))
  - ((ManagerBase) manager).add(this);
  + if (manager != null)
  + manager.add(this);
   
// Notify interested application event listeners
StandardContext context = (StandardContext) manager.getContainer();
  @@ -431,7 +430,18 @@
   }
   
   
  +/**
  + * Set the codeisNew/code flag for this session.
  + *
  + * @param isNew The new value for the codeisNew/code flag
  + */
  +public void setNew(boolean isNew) {
  +
  + this.isNew = isNew;
   
  +}
  +
  +
   /**
* Return the authenticated Principal that is associated with this Session.
* This provides an codeAuthenticator/code with a means to cache a
  @@ -472,6 +482,27 @@
   }
   
   
  +/**
  + * Return the codeisValid/code flag for this session.
  + */
  +public boolean isValid() {
  +
  + return (this.isValid);
  +
  +}
  +
  +
  +/**
  + * Set the codeisValid/code flag for this session.
  + *
  + * @param isValid The new value for the codeisValid/code flag
  + */
  +public void setValid(boolean isValid) {
  +
  + this.isValid = isValid;
  +}
  +
  +
   // - Session Public Methods
   
   
  @@ -502,8 +533,8 @@
   setValid(false);
   
// Remove this session from our manager's active sessions
  - if ((manager != null)  (manager instanceof ManagerBase))
  - ((ManagerBase) manager).remove(this);
  + if (manager != null)
  + manager.remove(this);
   
// Unbind any objects associated with this session
String keys[] = keys();
  @@ -592,16 +623,6 @@
   
   
   /**
  - * Return the codeisValid/code flag for this session.
  - */
  -public boolean isValid() {
  -
  - return (this.isValid);
  -
  -}
  -
  -
  -/**
* Release all object references, and initialize instance variables, in
* preparation for reuse of this object.
*/
  @@ -663,29 +684,6 @@
   
   
   /**
  - * Set the codeisNew/code flag for this session.
  - *
  - * @param isNew The new value for the codeisNew/code flag
  - */
  -void setNew(boolean isNew) {
  -
  - this.isNew = isNew;
  -
  -}
  -
  -
  -/**
  -

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session ManagerBase.java

[kief]

kief01/04/08 01:02:04

  Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
  Log:
  Refactoring to eliminate dependencies by StandardManager, ManagerBase,
  and StandardSession on one another: each should only depend on methods
  found in the interface definitions for Manager and Session.
  
  Revision  ChangesPath
  1.6   +35 -35
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java
  
  Index: ManagerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ManagerBase.java  2001/03/14 02:17:22 1.5
  +++ ManagerBase.java  2001/04/08 08:02:04 1.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
 1.5 2001/03/14 02:17:22 craigmcc Exp $
  - * $Revision: 1.5 $
  - * $Date: 2001/03/14 02:17:22 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
 1.6 2001/04/08 08:02:04 kief Exp $
  + * $Revision: 1.6 $
  + * $Date: 2001/04/08 08:02:04 $
*
* 
*
  @@ -86,7 +86,7 @@
* be subclassed to create more sophisticated Manager implementations.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.5 $ $Date: 2001/03/14 02:17:22 $
  + * @version $Revision: 1.6 $ $Date: 2001/04/08 08:02:04 $
*/
   
   public abstract class ManagerBase implements Manager {
  @@ -474,6 +474,20 @@
   
   
   /**
  + * Add this Session to the set of active Sessions for this Manager.
  + *
  + * @param session Session to be added
  + */
  +public void add(Session session) {
  +
  + synchronized (sessions) {
  + sessions.put(session.getId(), session);
  + }
  +
  +}
  +
  +
  +/**
* Add a property change listener to this component.
*
* @param listener The listener to add
  @@ -498,11 +512,11 @@
   public Session createSession() {
   
// Recycle or create a Session instance
  - StandardSession session = null;
  + Session session = null;
synchronized (recycled) {
int size = recycled.size();
if (size  0) {
  - session = (StandardSession) recycled.get(size - 1);
  + session = (Session) recycled.get(size - 1);
recycled.remove(size - 1);
}
}
  @@ -570,6 +584,20 @@
   
   
   /**
  + * Remove this Session from the active Sessions for this Manager.
  + *
  + * @param session Session to be removed
  + */
  +public void remove(Session session) {
  +
  + synchronized (sessions) {
  + sessions.remove(session.getId());
  + }
  +
  +}
  +
  +
  +/**
* Remove a property change listener from this component.
*
* @param listener The listener to remove
  @@ -618,20 +646,6 @@
   
   
   /**
  - * Add this Session to the set of active Sessions for this Manager.
  - *
  - * @param session Session to be added
  - */
  -void add(StandardSession session) {
  -
  - synchronized (sessions) {
  - sessions.put(session.getId(), session);
  - }
  -
  -}
  -
  -
  -/**
* Log a message on the Logger associated with our Container (if any).
*
* @param message Message to be logged
  @@ -686,24 +700,10 @@
*
* @param session Session to be recycled
*/
  -void recycle(StandardSession session) {
  +void recycle(Session session) {
   
synchronized (recycled) {
recycled.add(session);
  - }
  -
  -}
  -
  -
  -/**
  - * Remove this Session from the active Sessions for this Manager.
  - *
  - * @param session Session to be removed
  - */
  -void remove(StandardSession session) {
  -
  - synchronized (sessions) {
  - sessions.remove(session.getId());
}
   
   }
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

[kief]

kief01/04/07 03:22:40

  Modified:catalina/src/conf server.xml
  Log:
  Added configuration and documentation for PersistentManager,
  which is commented out by default.
  
  Revision  ChangesPath
  1.19  +46 -0 jakarta-tomcat-4.0/catalina/src/conf/server.xml
  
  Index: server.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- server.xml2001/03/24 21:15:24 1.18
  +++ server.xml2001/04/07 10:22:39 1.19
  @@ -181,6 +181,52 @@
 Ejb   name="ejb/EmplRecord" type="Entity"
home="com.wombat.empl.EmployeeRecordHome"
  remote="com.wombat.empl.EmployeeRecord"/
  +  !-- PersistentManager: Uncomment the section below to test Persistent 
  +Sessions.
  + 
  +   saveOnRestart: If true, all active sessions will be saved
  + to the Store when Catalina is shutdown, regardless of
  + other settings. All Sessions found in the Store will be 
  + loaded on startup. Sessions past their expiration are
  + ignored in both cases.
  +   maxActiveSessions: If 0 or greater, having too many active 
  + sessions will result in some being swapped out. minIdleSwap
  + limits this. -1 means unlimited sessions are allowed.
  + 0 means sessions will almost always be swapped out after
  + use - this will be noticeably slow for your users.
  +   minIdleSwap: Sessions must be idle for at least this long
  + (in seconds) before they will be swapped out due to 
  +   maxActiveSessions. This avoids thrashing when the site is 
  + highly active. -1 or 0 means there is no minimum - sessions
  + can be swapped out at any time.
  +   maxIdleSwap: Sessions will be swapped out if idle for this
  + long (in seconds). If minIdleSwap is higher, then it will
  + override this. This isn't exact: it is checked periodically.
  + -1 means sessions won't be swapped out for this reason,
  + although they may be swapped out for maxActiveSessions.
  + If set to = 0, guarantees that all sessions found in the
  + Store will be loaded on startup.
  +   maxIdleBackup: Sessions will be backed up (saved to the Store,
  + but left in active memory) if idle for this long (in seconds), 
  + and all sessions found in the Store will be loaded on startup.
  + If set to -1 sessions will not be backed up, 0 means they
  + should be backed up shortly after being used.
  +
  +   To clear sessions from the Store, set maxActiveSessions, maxIdleSwap,
  +   and minIdleBackup all to -1, saveOnRestart to false, then restart 
  +   Catalina.
  +  --
  +   !--
  +  Manager className="org.apache.catalina.session.PersistentManager"
  +  debug="0"
  +  saveOnRestart="true"
  +  maxActiveSessions="-1"
  +  minIdleSwap="-1"
  +  maxIdleSwap="-1"
  +  maxIdleBackup="-1"
  +Store className="org.apache.catalina.session.FileStore"/
  +  /Manager
  +   --
 Environment name="maxExemptions" type="java.lang.Integer"
 value="15"/
 Parameter name="context.param.name" value="context.param.value"
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session PersistentManager.java

[kief]

kief01/04/07 03:25:03

  Modified:catalina/src/share/org/apache/catalina/session
PersistentManager.java
  Log:
  Applied Bip Thelin's [EMAIL PROTECTED] patch to allow Store
  to be set from server.xml. Also added a check for the (default)
  case where Store is not set.
  
  Revision  ChangesPath
  1.3   +8 -9  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java
  
  Index: PersistentManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- PersistentManager.java2001/03/14 02:17:22 1.2
  +++ PersistentManager.java2001/04/07 10:25:03 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
 1.2 2001/03/14 02:17:22 craigmcc Exp $
  - * $Revision: 1.2 $
  - * $Date: 2001/03/14 02:17:22 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManager.java,v
 1.3 2001/04/07 10:25:03 kief Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/04/07 10:25:03 $
*
* 
*
  @@ -106,7 +106,7 @@
* liLimit the number of active sessions kept in memory by
* swapping less active sessions out to disk./li
*
  - * @version $Revision: 1.2 $
  + * @version $Revision: 1.3 $
* @author Kief Morris ([EMAIL PROTECTED])
*/
   
  @@ -264,6 +264,7 @@
   public void setStore(Store store) {
   
this.store = store;
  + store.setManager(this);

   }
   
  @@ -595,11 +596,9 @@
   if (debug = 1)
   log("Force random number initialization completed");
   
  - // Create the FileStore object.
  - // FIXME: Do this properly (configurable)
  - store = new FileStore();
  - store.setManager (this);
  - if (store instanceof Lifecycle)
  + if (store == null)
  + log("No Store configured");
  + else if (store instanceof Lifecycle)
((Lifecycle)store).start();

// Start the background reaper thread
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java

[kief]

kief01/04/07 03:26:06

  Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
  Log:
  Applied Bip Thelin's [EMAIL PROTECTED] patch to allow the Store
  used by Persistent Manager to be set in server.xml.
  
  Revision  ChangesPath
  1.19  +11 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java
  
  Index: Catalina.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- Catalina.java 2001/04/05 00:08:47 1.18
  +++ Catalina.java 2001/04/07 10:26:05 1.19
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
 1.18 2001/04/05 00:08:47 remm Exp $
  - * $Revision: 1.18 $
  - * $Date: 2001/04/05 00:08:47 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
 1.19 2001/04/07 10:26:05 kief Exp $
  + * $Revision: 1.19 $
  + * $Date: 2001/04/07 10:26:05 $
*
* 
*
  @@ -97,7 +97,7 @@
* /u
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.18 $ $Date: 2001/04/05 00:08:47 $
  + * @version $Revision: 1.19 $ $Date: 2001/04/07 10:26:05 $
*/
   
   public class Catalina {
  @@ -348,6 +348,13 @@
   createStartMapperDefaultContext(
"Server/Service/Engine/Host/DefaultContext",
mapper);
  +
  + mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
  + mapper.objectCreate(null, "className"));
  + mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
  + mapper.setProperties());
  + mapper.addRule("Server/Service/Engine/Host/Context/Manager/Store",
  + mapper.addChild("setStore", "org.apache.catalina.Store"));
   
mapper.addRule("Server/Service/Engine/Host/Listener",
  mapper.objectCreate
  
  
  

Re: [PATCH] patch to make PersistentManager work with different Store implementations.

[Kief Morris]

Bip Thelin typed the following on 02:35 PM 4/5/2001 -0700
This is a minor change so you can specify the store to use within server.xml.

Thanks Bip, I've applied these patches. I also added a check in PersistentManager's
start() method to check whether Store is null, since this is the default if no Store
tag is supplied. A message will be written to the log in this case.

I'll hope to have a first cut of the JDBCStore soon.

Cool, bring it on.

Kief

Re: Session Persistence

[Kief Morris]

Kevin Jones typed the following on 10:07 AM 3/31/2001 +0100
How do I enable the persistence manager in Beta 2. There's no entry in the
server.xml file, and I couldn't see anything in the docs.

It's currently an unofficial feature, so undocumented. Put the following
into your $CATALINA_HOME/conf/server.xml (not web.xml), in the 
Context section for your webapp: Catalina's xml parsing is strict,
so you need to put it in the right place in relation to other tags in
the Context, which is after Ejb/ and before Environment/

 Manager className="org.apache.catalina.session.PersistentManager"
  debug="0"
  saveOnRestart="true"
  maxActiveSessions="-1"
  minIdleSwap="-1"
  maxIdleSwap="-1"
  maxIdleBackup="-1"
  Store className="org.apache.catalina.session.FileStore"/
/Manager

Documentation:

saveOnRestart: If true, all active sessions will be saved
 to the Store when Catalina is shutdown properly, regardless of
 other settings. All Sessions found in the Store will be
 loaded on startup. Sessions past their expiration are
 ignored in both cases.

maxActiveSessions: If 0 or greater, having too many active
 sessions will result in some being swapped out. minIdleSwap
limits this. -1 means unlimited sessions are allowed.
0 means sessions will almost always be swapped out after
 use - this will be noticeably slow for your users.

minIdleSwap: Sessions must be idle for at least this long
(in seconds) before they will be swapped out due to
 maxActiveSessions. This avoids thrashing when the site is
 highly active. -1 or 0 means there is no minimum - sessions
 can be swapped out at any time.

maxIdleSwap: Sessions will be swapped out if idle for this
 long (in seconds). If minIdleSwap is higher, then it will
 override this. This isn't exact: it is checked periodically.
 -1 means sessions won't be swapped out for this reason,
 although they may be swapped out for maxActiveSessions.
 If set to = 0, guarantees that all sessions found in the
 Store will be loaded on startup.

 maxIdleBackup: Sessions will be backed up (saved to the Store,
 but left in active memory) if idle for this long (in seconds),
 and all sessions found in the Store will be loaded on startup.
 If set to -1 sessions will not be backed up, 0 means they
 should be backed up shortly after being used. [Not implemented yet]

   To clear sessions from the Store, set maxActiveSessions, maxIdleSwap,
   and minIdleBackup all to -1, saveOnRestart to false, then restart
   Catalina.
 
ISSUES:
- The Store/ tag doesn't currently work, FileStore is currently hard-coded
- Sessions which are restored after a restart, and have attributes changed,
  don't seem to be saved on the next shutdown: after a second restart, only 
  the attributes from the first restart are recovered.
- No test harness exists.
- Backup isn't implement.

RE: JDBC-Session store

[Kief Morris]

Jone Lin typed the following on 03:35 PM 3/28/2001 -0800
 No, we're much earlier in the development cycle than that - we haven't
 implemented any distributed session support at all. The work we're doing 
 on PersistentManager is groundwork for distributed sessions. This work 
 is 90% finished, so after restructuring the relevant class 
 hierarchy a bit 
 and finishing PersistentManager, we'll be ready to tackle 
 DistributedManager.

What is schedule for these two nice managers?  Tomcat 4.1, maybe?

PersistentManager will be in the next beta, albeit in a slightly unfinished
form: it swaps out idle sessions,  but doesn't back up sessions. Whether
DistributedManager makes it into 4.1 depends on the relative development
pace of it vs. the whole Tomcat - i.e., if we finish it before the release, it'll
go in. Sounds like there's a fair amount of interest, so hopefully we'll have
plenty of hands to get it done. It might even make it into 4.0, since the
final release has to wait on the 2.3/1.2 spec release.

Kief

Re: JDBC-Session store

[Kief Morris]

Bip Thelin typed the following on 10:46 AM 3/28/2001 -0800
I couldn't find anything about how to add the PersistenManager in server.xml
or in the manuals, however, after backtracking the maillist I found a "patch"
by Kief that seems to have been forgotten, I'll cat it to the end of this mail.
Maybe it can find it's way into the server.xml after all.

Excellent, I was wondering where that had gone. I'll commit it after the
codefreeze is lifted.

Re: JDBC-Session store

[Kief Morris]

Craig R. McClanahan typed the following on 07:05 PM 3/27/2001 -0800
Kief, a while back (when the work on PersistentManager was going on), the
need for a little refactoring work on Manager vs. StandardManager would be
useful.  Have you thought any more about what we should do here?

Yes, in fact I was just working on this last week, playing around with
different ways of attacking this. Replacing dependencies on StandardManager,
StandardSession with dependencies on the Manager and Session interfaces
is relatively easy, with a few additions to the interfaces required. Another
problem I've been tackling is the architecture of the Manager hierarchy.

The problem is that there is code currently in StandardManager which
is needed by (and currently, duplicated in) PersistentManager, which
isn't good for maintenance.

StandardManager implements the Lifecycle interface and functionality
to expire sessions with a background thread. These are also used
by PersistentManager, with the session management code being
extended to handle swapping out idle sessions and similar tasks.

Currently, StandardManager also has persistence code, which is used
only to handle saving sessions on restarts. This code doesn't use the
Store system.

There are two approaches which seem like they would address this.
One solution is to make StandardManager and PersistentManager
subclasses of a common superclass with the functionality common
to both. Another is to make PersistentManager a subclass of 
StandardManager.

The first approach, making a hierarchy, appeals to me because it
makes it easier to experiment with alternative session managers.
DistributedManager would become a sibling to StandardManager
and PersistentManager. This solution requires either moving the
common functionality into the ManagerBase class, or creating
an intermediary abstract class. The second approach allows the
ManagerBase to remain a clean implementation of the Manager
interface, although it extends the hierarchy an extra level. 

The second approach doesn't appeal to me, mainly because it
seems likely to get a bit muddled over time.

Either way, another issue I see is that StandardManager, as long
as it supports persistence on restarts, is going to use a fair amount 
of the code from PersistentManager. This isn't necessarily a bad
thing, it will keep PersistentManager fairly simple. But I would
prefer to make it easy to develop a fully working Manager which
doesn't include any persistence whatsoever: either StandardManager
could have this (requiring users who want restart persistence to
use PersistentManager), or there could be a separate SimpleManager.

The first of the two solutions: making StandardManager and
PersistentManager siblings rather than one a subclass of the
other, seems likely to offer cleaner support for a StandardManager
without persistence and/or a SimpleManager.

Once the beta is tagged (this weekend?) I can start committing
some work on this.

Kief

Re: JDBC-Session store

[Kief Morris]

Bip Thelin typed the following on 05:07 PM 3/27/2001 -0800
Kief Morris wrote:
 
 Excellent! Let us know if you need any help.

I will, BTW how is the work on distributed sessions coming along?
Is it possible to distribute sessions over x number of machines and
that if one goes down you could go to the other and happily continue
your session?

No, we're much earlier in the development cycle than that - we haven't
implemented any distributed session support at all. The work we're doing 
on PersistentManager is groundwork for distributed sessions. This work 
is 90% finished, so after restructuring the relevant class hierarchy a bit 
and finishing PersistentManager, we'll be ready to tackle DistributedManager.

The session management system consists of implementations of the Manager, 
Session, and Store interfaces found in the root org.apache.catalina package. 
When we finish with it, we should have three implementations of Manager:
StandardManager, PersistentManager, and DistributedManager. Any Store
implementations should, in theory, be usable by either of the second two.
So your JDBCStore class, if it works with PersistentManager, should also
work with DistributedManager. The only difference is how the Store is used
by the Manager: PersistentManager only stores the sessions of one JVM,
while DistributedManager will store them for multiple JVMs.

In reality, I suspect that DistributedManager will require changes to the
current Store interface, so if you implement JDBCManager now and get
it working with PersistentManager, it may have to be updated as we
work on DistributedManager. If you want to help with DistributedManager,
doing JDBCStore might be a good first step for you to get your head
into the code. One issue I haven't figured out yet is how to configure
Catalina to use different Store implementations - PersistentManager
currently has FileStore hard-coded. If you want to dig into that it would
be a bonus. Catalina's configuration system is really slick.

There should be some messages of mine from a few months ago in
the archive for this list where I puzzled over some of the particular
issues of implementing DistributedManager which may or may not
be worth looking over.

Kief

Re: [FOLLOWUP] Proposed Tomcat 4.0-Beta-2 Code Freeze Date?

[Kief Morris]

Craig R. McClanahan typed the following on 01:23 PM 3/28/2001 -0800
 It's been quite a while since beta 1 and the viewing public anxiously
 awaits a new release :-)

It was asked that we hold off for a bit.  Would doing the release this
Friday meet everyone's preferences?  If so, I will go ahead and submit the
vote request formally.

What are the issues for holding off?

Kief

Re: [VOTE] Proposed Tomcat 4.0-Beta-2 Code Freeze Date

[Kief Morris]

Craig R. McClanahan typed the following on 08:32 PM 3/19/2001 -0800
- Clip and Return This Portion -

+1  [ ]   I support the proposed release, and will work to support it
+0  [ ]   I support the proposed release, but cannot work on it
  at this time
-0  [ ]   I do not support the proposed release, but do not have an
  alternative to propose
-1  [ ]   I do not support the proposed release, for reasons specified
  below.

+1

Re: FYI: Tomcat 4.0 Release Planning Futures

[Kief Morris]

Craig R. McClanahan typed the following on 08:52 PM 3/19/2001 -0800
So where does that leave us in the mean time?  I propose that we continue
to innovate new features in succeeding beta releases of Tomcat 4.0
(treating them essentially the way that "milestone" releases get treated
in many development projects).  The quality of the code, and overall
performance, will continue to improve, and beta releases would be cut only
at points where the code is stable, and passes all current compliance
tests.

+1 on this. I'm in a position now where I can start devoting some time
to this (I've been on the road for the past month), especially the
persistent  distributed sessions.

Kief

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session StandardSessionInterceptor.java

[kief]

kief01/02/13 00:58:54

  Modified:src/share/org/apache/tomcat/session Tag: tomcat_32
StandardSessionInterceptor.java
  Log:
  Repaired the if clause which checks whether a session has been found
  from the session manager. The code was calling request.setSession(sess) even when 
the value
  of sess was null. This only seemed to have cropped up during forwarding, and then
  only when the request included an invalid session ID: the first servlet in the
  chain would create a session, then when the forwarded servlet requested the
  session this little bug wiped out the first session.
  
  This was reported as bug 504 in Bugzilla.
  
  I also standardized indentation in this area of the code, since it contributed to 
making
  the bug a bitch to track down!
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.5.2.4   +15 -13
jakarta-tomcat/src/share/org/apache/tomcat/session/Attic/StandardSessionInterceptor.java
  
  Index: StandardSessionInterceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/session/Attic/StandardSessionInterceptor.java,v
  retrieving revision 1.5.2.3
  retrieving revision 1.5.2.4
  diff -u -r1.5.2.3 -r1.5.2.4
  --- StandardSessionInterceptor.java   2000/11/18 01:33:59 1.5.2.3
  +++ StandardSessionInterceptor.java   2001/02/13 08:58:54 1.5.2.4
  @@ -123,19 +123,21 @@
log( "Configuration error in StandardSessionInterceptor - no context " + 
request );
}
   
  -  // Added by Hans:
  -  // First check if we have a valid session ID from the URL, set by the 
SessionInterceptor,
  -  // and if so, set it as the request session. If we have also received a valid 
session ID
  -  // as a cookie, the next section of code will reset the session to the one 
matching the
  -  // ID found in the cookie.
  -  String requestedSessionID = request.getRequestedSessionId();
  -  if (requestedSessionID != null) {
  -  if (debug  0) log("Found URL session ID: " + requestedSessionID);
  -  sess = sM.findSession(requestedSessionID);
  -  if (sess != null)
  -  if (debug  0) log("The URL session ID is valid");
  -  request.setSession(sess);
  -  }
  + // Added by Hans:
  + // First check if we have a valid session ID from the URL, set by the 
SessionInterceptor,
  + // and if so, set it as the request session. If we have also received a valid 
session ID
  + // as a cookie, the next section of code will reset the session to the one 
matching the
  + // ID found in the cookie.
  + String requestedSessionID = request.getRequestedSessionId();
  + if (requestedSessionID != null) {
  + if (debug  0) 
  + log("Found URL session ID: " + requestedSessionID);
  + sess = sM.findSession(requestedSessionID);
  + if (sess != null) {
  + if (debug  0) log("The URL session ID is valid");
  + request.setSession(sess);
  + }
  + }
   
// PF, loop across all cookies named JSESSIONID checking to see if any of them 
are valid.
// There should in most cases be a maximum of 2, and normally there will only 
be one. The
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTE] Tomcat 3.2.2 Release Plan

[Kief Morris]

Marc Saegesser typed the following on 09:21 AM 2/11/2001 -0600
- Please return this portion with your vote -

Tomcat 3.2.2 Release Plan Ballot:

  [X] +1   I am in favor of this plan and will help
  [ ] +0I am in favor of this plan, but am unable to help
  [ ] -0I am not in favor of this plan
  [ ] -1   I am against this plan being executed, and my
reason is:


-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Karma

[Kief Morris]

I'm trying to commit a patch for Tomcat 3.2.2 to fix bug #504, but
I'm getting told off for insufficient karma. I'm pretty sure I've got my
SSL tunnels working, maybe I don't have commit privs on the
jakarta-tomcat project?? 

 Access denied: Insufficient Karma 
(kief|jakarta-tomcat/src/share/org/apache/tomcat/session)
cvs server: Pre-commit check failed
cvs [server aborted]: correct above errors first!

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Session-expiry bug? getLastAccessedTime

[Kief Morris]

Craig R. McClanahan typed the following on 12:52 PM 2/10/2001 -0800
This was discussed by the expert group for servlet 2.3, and Kief's
understanding is what we came up with.  In addition, that is what Section 7.6
says in 2.3 PFD (emphasis is added):

The getLastAccessedTime method of the HttpSession interface
allows a servlet to determine the last time the session was
accessed BEFORE the current request.

Other subtleties:

* The access time should be updated at the beginning of the request,
  rather than the end.

* The session is considered "accessed" when the container recognizes
  that the request is part of a valid session, even if the application never
  calls request.getSession() on that particular request.

It doesn't look like we're doing this in Catalina 4.0, or am I missing something? 
Session.access() only seems to be called when request.getSession() is called.

Also, if the access time is updated at the beginning of the request, what should 
getLastAccessedTime() return? Let's say at the beginning of the request, the 
access() method is called, and does:

this.lastAccessedTime = this.thisAccessedTime;
this.thisAccessedTime = System.currentTimeMillis();

Fine. But what happens after the request is complete, and the session expiration 
thread calls getLastAccessedTime() to compare it against maxInactiveInterval, it 
will be using the time of the request before the most recent request. So if request B 
comes in 20 minutes after request A, the container will expire the session 10 
minutes after the most recent request (assuming default values), since 
getLastAccessedTime() will return the time that request A happened. What am I
missing?

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Session-expiry bug? getLastAccessedTime

[Kief Morris]

Murthy Gorty typed the following on 09:59 AM 2/9/2001 -0800
I noticed a problem with session timeouts in Tomcat3.2.1
The background thread that recycles sessions based on timeouts uses 
Session.getLastAccessedTime().
The session object itself has two variables
lastAccessedTime and thisAccessedTime.
-
public long getLastAccessedTime() 
{
   return (this.lastAccessedTime);
}

lastAccessedTime is the time a request is made BEFORE the present request.
So, getLastAccessedTime is the time of the (last-1)request 
and not the last request.

Isnt this a bug? shouldnt getLastAccessedTime return
thisAccesstime?

I haven't looked at this code in detail, but my thoughts on this are:
getLastAccessedTime() needs to return the (last - 1) during a request,
or it won't behave correctly for servlet code. After a request is finished, 
lastAccessedTime should be updated to = thisAccessTime, so 
getLastAccessedTime() will return the time of the last request when
checked by the expiration code. Is this not the case?

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[TOMCAT 4] server.xml configuration (Store, Session)

[Kief Morris]

I still haven't figured out how to get Catalina's server.xml processing to
handle a new tag for Store, and would also like to do it for Session so
different implementations of the Session interface can be configured.

Adding attributes to the Manager tag works auto-magically, which
is very slick. But I've messed around with adding a Store tag inside
the Manager tags, and fiddled endlessly with mapper.addRule() and
such in org.apache.catalina.startup.Catalina, but I can't get it to work.
Can anyone give me some pointers?

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[TOMCAT 4] Session refactoring

[Kief Morris]

I'm looking at a bit of refactoring of the Session and Manager code
before I get into more serious stuff. The objective of this round of
refactoring is to remove dependencies on StandardSession and
ManagerBase, and instead have code deal with these using the
Session and Manager interfaces. The benefits I see include:

- Ensures that the interfaces clearly specify the operations that
  an implementation of Session or Manager must support to work
  with Catalina.
- Makes the code cleaner and easier to understand, since there
  isn't so much casting and checking for instanceof.

What I need to do is:
- Add methods to the Session and Manager interfaces. I've done some
  preliminary work to see what these will be: New methods in the Session 
  interface include activate(), passivate(), setNew(), setValid(), readObjectData(),
  writeObjectData(). New methods in the Manager interface: remove(), add()
- Cleanup of code to remove dependencies on specific implementations
  of these interfaces.
- A way to define the Session class which will be used in server.xml.

After this I will look at moving code which is currently duplicated in
StandardManager and PersistentManager up to the ManagerBase
class. 

I'm posting this rather than just doing it because I want to check whether
I should do this on a separate branch to avoid screwing up the B2 release.
I also need to figure out the session testing code and see whether I need
to add anything to it so I can properly test any changes I make.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Common Session code 3.3/4.0 (was: [VOTE] New Committer: Kief Morris)

[Kief Morris]

[EMAIL PROTECTED] typed the following on 02:07 PM 2/6/2001 -0800
 ( +2 if he also ports them to tomcat 3.3 or makes them independent of
 the container architecture - i.e. general purpose utils for
 serialization/deserialization with a simple adapter for each server :-)
 
 Sure, the 3.3 code could be modified to use the Store interfaces to 
serialize 
 its sessions, although that would require sharing the Session interface. 
Maybe
 a bit too much work for the current release cycle.

This doesn't have to be part of tomcat3.3 release - it can be a standalone
module. The only issue is that the code you write ( Store, impls, etc )
need to be "standalone" - i.e. be usable in any container.

( the session manager for tomcat3.2 is based on early catalina session
managers, but it was a huge pain to extract the session management and use
it, since it depended on a lot of internals - Request, Lifecycle, etc).

True, this may make it more work than than it's worth. It would be possible
to define interfaces for SessionManager, Session, and Store which can be
used by both (and other) containers. As long as each container can depend 
only on the defined interfaces, without compromising their existing architectures,
someone could develop an implementation that can be used on any container
using the interfaces. 

I'd be willing to work with someone on these interfaces, but for the time being
I'm going to continue developing Catalina's session management code integrated 
with its architecture, which isn't likely to be portable. If someone wants to port
the stuff to a 3.3 module I'm happy to help.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [Tomcat 4] Session Handling Enhancements

[Kief Morris]

Craig R. McClanahan typed the following on 04:40 PM 2/5/2001 -0800
(1) Session Save/Restore Across App Restarts

Currently, StandardManager saves and restores sessions across app
restarts (i.e. autoreload if turned on, or normal shutdown and
startup).  It should be modified to use the new passivate() and
activate() methods of the session implementation to warn interested
session attributes that this activity is taking place.

-0 How about stripping this entirely out of StandardManager? People who
want to keep sessions over restarts can use PersistentManager, leaving
StandardManager as a slimmer, simpler default.

(2) Modify StandardSession.readObject() and writeObject()

Currently, when the session is being serialized, the attributes are
removed via removeAttribute() -- which triggers calls to valueUnbound()
of attributes that implement HttpSessionBindingListener, among other
things.  Likewise, when the session is reloaded in readObject,
setAttribute() is called and triggers calls to valueBound().  These
calls were initially made to give session attributes some knowledge that
a restart was being done.

Now that the activate and passivate mechanisms are in place, I propose
that these mechanisms be changed to *not* unbind and bind the attributes
during these processes.  Any interested attribute can implement
HttpSessionAttributeListener instead.

You mean HttpSessionActivationListener? If so I'm +1 on this - I can make
this change.

(3) Change "final" classes

One of the challenges Kief ran into is that StandardManager and
StandardSession are both marked final, and therefore cannot be
subclassed.  I propose to remove the "final" modifier so that this
restriction is no longer in place.  Additional refactoring can be
performed separately, but you should at least be able to subclass these
classes.

+1 - I can do this also. 

What do you think about pushing more functionality up into ManagerBase,
and creating a SessionBase class? Most of what I want to do shouldn't
need subclassing of StandardManager/Session.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTE] New Committer: Kief Morris

[Kief Morris]

Craig R. McClanahan typed the following on 09:16 AM 2/6/2001 -0800
Kief has recently proposed improvements to the session management code
in Tomcat 4, and wants to continue helping out.  I hereby propose him as
a committer on the Tomcat project.  Votes, please?

Thanks for the support everyone, I'm glad to be involved with this project.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Common Session code 3.3/4.0 (was: [VOTE] New Committer: Kief Morris)

[Kief Morris]

[EMAIL PROTECTED] typed the following on 09:44 AM 2/6/2001 -0800
 Kief has recently proposed improvements to the session management code
 in Tomcat 4, and wants to continue helping out.  I hereby propose him as
 a committer on the Tomcat project.  Votes, please?

+1

( +2 if he also ports them to tomcat 3.3 or makes them independent of
the container architecture - i.e. general purpose utils for
serialization/deserialization with a simple adapter for each server :-)

Sure, the 3.3 code could be modified to use the Store interfaces to serialize 
its sessions, although that would require sharing the Session interface. Maybe
a bit too much work for the current release cycle.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

4.0/4.1 merge

[Kief Morris]

Howdy folks, I've been on the road for a few days. What's the status of
the 4.0/4.1 merge? Are we ready for the new branch to work on session 
persistence stuff? Anything I can do to help things along if not?

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [PROPOSAL] Revised Tomcat 4.0-beta-2 Release Plan

[Kief Morris]

Morrison, John typed the following on 08:52 AM 1/23/2001 +
Rather than removing the TC4.1 cvs would it not be better to alias it back
to the TC4.0 repository and not broadcast that it exists?  This will keep
those who checked out the source from having to move back to 4.0.

-0, I've got both checked out and I think either way the update is going
to involve a lot of changes. Changing the actual CVS repository files that 
go with a particular project name seems like it could turn very ugly. 
Checking out a new project (or renaming your old checkout and checking
the project out again from scratch) isn't too big a deal IMO.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] Revised Tomcat 4.0-beta-2 Release Plan

[Kief Morris]

Craig R. McClanahan typed the following on 04:51 PM 1/22/2001 -0800
Therefore, I would like to propose "unfreezing" the 4.0 codebase, and 
opening it
again to new development, with some of the major items listed below.  The
revised release plan for Tomcat 4.0 Beta 2 would then become:

+1 (non-binding)

I'm not going to be able to help get the release ready (I'm on the road/
prospecting for work), but I can help with testing and bugfixing.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] Revised Tomcat 4.0-beta-2 Release Plan

[Kief Morris]

Craig R. McClanahan typed the following on 04:51 PM 1/22/2001 -0800
* Integrate the changes for persistent session storage, as well as
  session passivation and activation, proposed by Kief Morris.  This
  will initially be checked into a temporary branch for experimentation,
  but will likely be found solid enough to incorporate into 4.0-b2.  (I
  will do the commits now, but will also propose Kief as a committer
  in his own right if he's interested).

Yes I am interested, thanks.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: load balancing and failsafety

[Kief Morris]

Jayesh typed the following on 10:55 AM 1/21/2001 -0800
Anybody implemented load balancing and failsafety on tomcat stand alone?

I've started some work on session persistence, which works with
a single-instance application, which should lead into sharing
sessions between instances of a distributable application. If you're
interested in this area I'd appreciate if you'd have a look and let
me know what you think. It isn't in CVS yet because the 4.0 repository 
is being reorganized a bit, but if you check the archive for this list you 
should find the messages and patches, mostly in the past 2 weeks.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security ManagerFacades

[Kief Morris]

Craig R. McClanahan typed the following on 10:09 PM 1/19/2001 -0800
How about if we create a branch of 4.0, and I check in these changes on that
branch?  If things work out well, we can merge back to the main branch --
otherwise, wel'll have learned what needs to be done to add this functionality
into 4.1.

+1 This sounds like the right way to do it.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades

[Kief Morris]

Craig R. McClanahan typed the following on 02:00 PM 1/19/2001 -0800
THE PROPOSAL:

For each Servlet API interface that represents an internal Catalina object
exposed to an application object, create a new
org.apache.catalina.facade.XFacade class according to the following basic
pattern:

* Pass the internal object to the constructor (the facade
  will be a wrapper around it).

* Implement the appropriate servlet API interface (so the
  facade object can be passed to application components)

* For each public method in the interface, implement a doPrivileged
  block that calls the corresponding method on the underlying
  internal Catalina object.

Sounds cool. If the application doesn't use the security manager,
will the object simply continue "raw" without being wrapped by
the facade to avoid the added overhead? e.g:

// Raw session
Session mySession = whatever;

if (security_enabled) {
mySession = new SessionFacade (mySession);
}

// Raw or facade session, doesn't really matter
mySession.doStuff();

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: session timeout

[Kief Morris]

Jayesh typed the following on 08:00 AM 1/17/2001 -0800
I need to do some work when tomcat session gets timed out. Could anyone of
you suggest how I can do it.

With servlet 2.2 (Tomcat 3.x) you should make sure one of the attributes you're
adding to the session implements HttpSessionBindingListener. When the session
gets timed out, the container will call valueUnbound() on that object. As long as
you know you're not the one unbinding the object (e.g. by calling removeAttribute()
or replacing the attribute by calling setAttribute() with the same name), you can
assume the session is being expired or invalidated.

With servlet 2.3 (Tomcat 4.x) you can also create an object which implements 
HttpSessionListener, and configure it in your web.xml like this:

web-app

listener
listener-classcom.foo.SessionAttributeSnoop/listener-class
/listener

/web-app

This object will have its sessionDestroyed() method called
when it is destroyed for any reason.

Of course, if the server goes down in a bad way none of these
events will be called, so there are no guarantees.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: denial of service attack

[Kief Morris]

Scott Christley typed the following on 10:54 AM 1/17/2001 -0800
I must apologize first by saying that I originally found this bug with
Jserv not Tomcat, but those of you who are familiar with Tomcat
internals can probably tell fairly quickly if this would still be an
issue.

It could potentially be an issue, but can be controlled to some extent.
The PersistentManager class I have submitted for Tomcat 4 offers
a bit more control. I can offer a few comments on Tomcat 4 with and
without this class.

The nature of the possible attack, as I understand it, is that a bad guy
can make a rapid series of requests to the web app, causing the generation
of a large number of session objects thereby eating up available memory.

The current StandardSession implementation has a parameter called
maxActiveSessions which, if set (it's disabled by default), limits the number
of sessions which the server will create. A request which tries to create
any sessions after the limit is reached throws an IllegalStateException.

This isn't ideal for the user experience, but if it is set according to the
likely session memory usage and the heap size, it should occur just before
memory runs out, so it's better than the alternative.

PersistentManager, which would be an optional replacement for
StandardSession, allows you to have sessions swapped out of memory 
(to a file or DB most likely) based on configurable parameters: idle time
and the number of active sessions. Sessions over a certain number would
be swapped out, as would sessions idle for a configurable time.

The caveat on this is that there is a danger of thrashing when the site
is very active - sessions could be constantly swapped in and out of memory,
exacerbating performance problems. So there is an option to set a minimum
idle time - sessions which are idle for less than this time won't be swapped
out even if there are more than maxActiveSessions in memory. This 
effectively turns maxActiveSessions into a soft limit rather than a hard limit.

I did have an idea for how this issue can be resolved; I've not totally
thought it through, but it may be a good start.

=
Given a parameter (num_of_sessions) which is the maximum number of new
sessions.
Given a parameter (time_period) which is a time interval.

Implement a verification such that maximum number of new sessions that
can be created from the same client within a time interval.  This would
require that you maintain a creation date and client identifier with
each session.

As Tomas pointed out, identifying a client is problematic: the entire purpose
of using the cookie is to get around the difficulty in reliably identifying a client.
Perhaps this could be done on a system-wide level instead - limit the number
of new sessions created in a certain time period.

I tend to think that the PersistentManager options I outlined above can be used
to prevent this attack if configured correctly. maxActiveSessions can be
set as a hard limit to keep the active sessions to a number which can be 
safely supported by the heap size. This doesn't prevent an attacker from
eating up most of the available sessions and creating a bad situation for
legitimate users, but it should avoid an outright system crash. 


Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Session passivation (was: NullPointerException from HttpSessionFacade.invalidate())

[Kief Morris]

Craig R. McClanahan typed the following on 03:44 PM 1/14/2001 -0800
"Christopher K. St. John" wrote:
 
  If your server implements session swapping or distribution (as we are 
currently
  developing in the 4.1 repository), it is pretty much guaranteed that 
different
  session object instances may be used during the lifetime of the same 
session.
 

  But don't you get session lifecycle events if that happens?

Yes ... sessionWillPassivate() before the old session is removed, and
sessionDidActivate() after the new one has been installed.

I hadn't thought about the issue of web apps keeping references to a session,
this underlines the concern I mentioned earlier about passivation events and
backing up sessions. If web app code depends on these events to tell it when
a session is being removed from memory, then they shouldn't be fired when
a session is just being backed up to a Store. But these may be needed for
pre/post passivation/activation cleanup tasks.

I may send a message to the api feedback address to get clarification on the 
spec. Namely:

- Is it OK for the container to keep multiple copies of a session in a distributed 
  web application? The spec doesn't say no, although it does say that only one
  instance of the app should be handling requests for a session at a time, which
  implies you could have multiple copies if you have a locking mechanism and
  maintain data consistency.

- If it is OK, should the container send activation/passivation events when a
  session is being serialized (or whatever) for replication purposes? Whatever
  the answer is, it would be nice if the spec clarified it explicitly so webapp
  developers can depend on it being consistent on different containers.

This also raises a Catalina issue I forgot to mention in the message with my
PersistentManager patches. Currently there isn't any way (that I could see)
to tell when a request has finished handling a session. It's possible that my
persistence code could swap a session out while it's being used in a request.

I'm not sure what the best way is to handle this. Possibly ContainerBase.invoke()
could make a call to a new method in the Manager interface after the valves
have all been invoked? Something like:

public void invoke(Request request, Response response)
throws IOException, ServletException {

if (first != null)
first.invoke(request, response);
else if (basic != null)
basic.invoke(request, response);
else
throw new IllegalStateException
(sm.getString("containerBase.notConfigured"));

+ if (manager != null  request.getSession(false) != null)
+   manager.releaseSession(request.getSession());
}

Then the manager can enforce a locking mechanism on the session.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Session passivation (was: NullPointerException fromHttpSessionFacade.invalidate())

[Kief Morris]

Craig R. McClanahan typed the following on 11:42 AM 1/15/2001 -0800

 - If it is OK, should the container send activation/passivation events when a
   session is being serialized (or whatever) for replication purposes? 

The following comment is in the Javadocs at the top of
javax.servlet.http.HttpSessionActivationListener (the interface that defines 
the
passivate and activate listener methods):

A container that migrates sessions between VMs or
persists sessions is required to notify all attributes
bound to sessions implementing HttpSessionActivationListener.

OK, so it's clear that the activation events are appropriate only when
the session is actually being removed from a JVM. What I'm trying
to understand is whether a web app developer can ensure that they
get the chance to muck with an object used as a session attribute
before and after it is copied to a Store for backup. The spec says
the serialization events is not necessarily called by the container, so 
it seems the answer to this question is: no.

 This also raises a Catalina issue I forgot to mention in the message with my
 PersistentManager patches. Currently there isn't any way (that I could see)
 to tell when a request has finished handling a session. It's possible that my
 persistence code could swap a session out while it's being used in a request.


No, there isn't :-(.  We need a registration mechanism a request can call 
that says "I
am currently using this session" and "I am done using this session."

Ok, but the request doesn't have any way to know when this kind of
thing happens, so it can be done by the session itself.

 + if (manager != null  request.getSession(false) != null)
 +   manager.releaseSession(request.getSession());
 }

There is the possibility of referencing more than one session in the same 
request, in
at least a couple of circumstances:

* The originally requested session is no longer valid,
  and a new one is created.

* The currently valid session is invalidated, and a
  new one is created.

so any registration/locking mechanism needs to deal with this correctly.

If Manager.releaseSession() method is implemented (I don't really like that 
method name though), then StandardSession.expire() and invalidate() should
call it, and maybe some other places. 

I'm not sure about the originally requested session being invalid: the findSession()
method of the Manager should know about this when it hands it out - *should* it
return an invalid session? Would it be wrong for findSession() to check whether
the session is valid and return null or a new session if so? 


 Kief


Craig


Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Jakarta PMC Meeting Agenda / Info

[Kief Morris]

Jon Stevens typed the following on 11:50 AM 1/15/2001 -0800
Right, but I (and others) are still here and myself (and others) are still
in a responsible position for supporting this software. Therefore, I'm most
concerned with a developer who makes a huge number of changes and then
announces that he is going to disappear.

If you're *really* concerned about Costin wanting to disappear, why don't
you lighten up a bit? I wouldn't want to hang around either if I got half as
much harassment as Costin does.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Session passivation (was: NullPointerException fromHttpSessionFacade.invalidate())

[Kief Morris]

I typed the following on 03:10 PM 1/15/2001 -0500
If Manager.releaseSession() method is implemented (I don't really like that 
method name though), then StandardSession.expire() and invalidate() should
call it, and maybe some other places. 

Doh, actually the locking would probably be implemented in the StandardSession
class itself, so there wouldn't be any need to call the Manager.releaseSession().

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Jakarta PMC Meeting Agenda / Info

[Kief Morris]

Jon Stevens typed the following on 12:36 PM 1/15/2001 -0800
Costin's choice is his choice. If he doesn't want to stick around, it won't
be because of me (or at least I don't think I can understand that as an
argument...maybe my fault, maybe not), it will be because of the fact that
the project has decided to go in one direction and he wants to go in
another.

I think that's _your_ reason for thinking he should go. I get the impression
his own reasons for saying he wants to go has a lot more to do with the
pressure he's getting to either conform to the party line or get lost. What
you say above reads to me as "if he decides to leave it's his own fault for 
not conforming, it's not my fault for constantly pressuring him to conform".

I don't really see that everyone needs to be marching in lock step, and I
don't see the need to bully people who aren't toeing the party line. Tomcat
4 isn't ready yet, does everyone still loyal to the old 3.x order really need
to be purged?

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [Tomcat 4.0] Updated Documentation

[Kief Morris]

Craig R. McClanahan typed the following on 09:06 PM 1/13/2001 -0800
The information that is presented in the Server Configuration section is all up
to date AFAIKT, but several sections are not yet written.  With this, as with
the rest of the docs (and the code, of course :-), feel free to suggest 
changes,
send patches, or volunteer to do some of the writing!

I can do the Manager section, since I've been mucking around with that
code recently.

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[PATCHES] Catalina 4.1 Session Persistence

[Kief Morris]

These patches are my proposal for session persistence in Catalina 4.1. Please
look these over and give me your comments, and commit them if they look OK.

The main change is the addition of a PersistentManager class, an optional replacement
for StandardManager, providing the following configurable functionality:

- Saves sessions to a Store on shutdown, loads on restart. This is currently 
implemented 
  in StandardManager, but PersistentManager makes use of the Store interface.
- Swaps sessions out to a Store if the number in memory exceeds maxActiveSessions,
  to better manage resources. A minIdleSwap property prevents sessions from being
  swapped out if they haven't been idle for very long, to avoid thrashing.
- Swaps sessions out to a Store if they are idle for too long. With this feature, an 
app
  can have very long session expiration times without over-burdening memory.
- Backs sessions up to Store (but keeps them in memory) if they are idle for too long.
  This provides basic fault tolerance, since the sessions will be read in from the 
Store
  when the server starts after a crash. NOT IMPLEMENTED YET! There is an issue
  regarding the Servlet 2.3 specification which I will discuss below.

To test this out, see the server.xml file - there is a section to uncomment and tweak
the configuration.

ISSUES:


- Backing up Sessions: I believe that HttpSessionActivationListeners should be notified
  when sessions are being backed up and restored. However, application developers
  reading the Servlet 2.3 specification [PFD] might not expect a session to remain
  in active use after the sessionWillPassivate() method is called. I would like to get 
  some feedback on this.

- I still have not figured out how to get Catalina to instantiate the Store class for 
me,
  this patch hard-codes the use of FileStore in PersistentManager. I've tried mucking
  around in startup/Catalina.java, to no avail. Can anyone help me out with this?

- There is a lot of duplication of code between PersistentManager and StandardManager.
  Maybe this should be moved to ManagerBase?

- The use of Session/StandardSession is very messy in ManagerBase, StandardManager, 
  and now PersistentManager. Although some code uses the Session interface and executes
  StandardSession-specific code only after testing, much of this code will break if an
  alternative implementation is used (essential properties aren't set, etc.), and some
  code has StandardSession hard-coded without tests. 
  It looks as if someone had good intentions to make it possible to replace 
StandardSession 
  with a different implementation, but it hasn't been followed through, so it's just a 
mess.
  This means I can't create a PersistentSession class and keep persistence-related code
  out of StandardSession, which is too bad. 
  Fixing this will require a fair amount of refactoring.

- While developing apps you would sometimes like to wipe out all of the sessions,
  which is a bit awkward to do with persistence enabled because the server saves
  and restores them on restarts. Currently you would have to change the server.xml 
  configuration for PersistentManager to disable all persistence and backups, and then 
  it will clear out the Store when you restart. You can manually delete them from the 
  directory used by FileStore, but this won't work with other Store implementations.
  Ideally there should be a command line argument which causes the Store to be 
  cleared.

PATCH COMMENTS


Store.java

- Added getManager(), setManager(), and clear() methods.

FileStore.java

- Implemented Store functionality, sessions are serialized one per file.

PersistentManager

- Implemented persistence across server restarts
- Implemented swapping out of sessions to manage resources, based on
  the number of sessions in memory and idle times.
- Stubs for backing up of sessions based on idle times, not yet implemented.

server.xml

- Added a commented out section to enable and configure PersistentManager

LocalStrings.properties

- Added strings for logging by FileStore and PersistentManager.


Regards,
Kief


--- FileStore.java.orig Fri Aug 11 20:39:15 2000
+++ FileStore.java  Fri Jan 12 21:55:02 2001
@@ -74,18 +74,27 @@
 import java.io.FileNotFoundException;
 import java.io.FileOutputStream;
 import java.io.IOException;
+import java.io.InputStream;
 import java.io.ObjectInputStream;
 import java.io.ObjectOutputStream;
+import java.io.ObjectStreamClass;
 import java.io.Serializable;
 import java.util.Enumeration;
 import java.util.Hashtable;
 import java.util.Vector;
+import javax.servlet.ServletContext;
+import org.apache.catalina.Context;
+import org.apache.catalina.Globals;
 import

[PATCHES] Catalina Session handling

[Kief Morris]

This is the first of two sets of patches relating to sessions. The following
set will be my proposed session persistence package, while these are more
general and should be considered independently.

ManagerBase.java

- Fixed a bug where recycled sessions don't seem to have their Managers set.
  The session.recycle() clears the manager, so the createSession() method should
  set the manager if it uses a recycled session. It's possible this is done elsewhere,
  but I don't see it, caused some NullPointerExceptions while testing my persistence 
  code.
- Fixed a bug where findSession() apparently doesn't call access() on the returned
  session. The result is sessions will expire based on when they were first created,
  not when they were last accessed. Again, this might be set somewhere else, but
  it wasn't getting set in my persistence testing.

StandardSession.java

- Changed expire() to recycle the session if the Manager is a subclass of ManagerBase.
- Added activate() and passivate() methods which notify HttpSessionActivationListeners
  when the session is activated or passivated, as per the Servlet 2.3 specification 
PFD.

Kief


--- ManagerBase.java.orig   Fri Jan 12 22:03:13 2001
+++ ManagerBase.javaFri Jan 12 21:22:44 2001
@@ -506,7 +506,9 @@
recycled.remove(size - 1);
}
}
-   if (session == null)
+   if (session != null)
+   session.setManager(this);
+   else
session = new StandardSession(this);
 
// Initialize the properties of the new session and return it
@@ -544,7 +546,10 @@
if (id == null)
return (null);
synchronized (sessions) {
-   return ((Session) sessions.get(id));
+   Session session = (Session) sessions.get(id);
+   if (session != null)
+   session.access();
+   return (session);
}
 
 }


--- StandardSession.java.orig   Thu Jan 11 23:01:02 2001
+++ StandardSession.javaFri Jan 12 22:17:50 2001
@@ -77,6 +77,7 @@
 import java.util.Iterator;
 import javax.servlet.ServletException;
 import javax.servlet.http.HttpSession;
+import javax.servlet.http.HttpSessionActivationListener;
 import javax.servlet.http.HttpSessionAttributesListener;
 import javax.servlet.http.HttpSessionBindingEvent;
 import javax.servlet.http.HttpSessionBindingListener;
@@ -538,10 +539,58 @@
 
 // We have completed expire of this session
expiring = false;
+   if ((manager != null)  (manager instanceof ManagerBase)) {
+   recycle();
+   ((ManagerBase) manager).recycle(this);
+   }
 
 }
 
 
+/**
+ * Perform the internal processing required to passivate
+ * this session.
+ */
+public void passivate() {
+
+   // Notify ActivationListeners
+   HttpSessionEvent event = null;
+   String keys[] = keys();
+   for (int i = 0; i  keys.length; i++) {
+   Object attribute = getAttribute(keys[i]);
+   if (attribute instanceof HttpSessionActivationListener) {
+   if (event == null)
+   event = new HttpSessionEvent(this);
+   // FIXME: Should we catch throwables?
+   ((HttpSessionActivationListener)attribute).sessionWillPassivate(event);
+   }
+   }
+
+}
+
+
+/**
+ * Perform internal processing required to activate this
+ * session.
+ */
+public void activate() {
+
+   // Notify ActivationListeners
+   HttpSessionEvent event = null;
+   String keys[] = keys();
+   for (int i = 0; i  keys.length; i++) {
+   Object attribute = getAttribute(keys[i]);
+   if (attribute instanceof HttpSessionActivationListener) {
+   if (event == null)
+   event = new HttpSessionEvent(this);
+   // FIXME: Should we catch throwables?
+   ((HttpSessionActivationListener)attribute).sessionDidActivate(event);
+   }
+   }
+
+}
+
+
 /**
  * Return the codeisValid/code flag for this session.
  */



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Session Serialize code

[Kief Morris]

Jon Stevens typed the following on 12:16 PM 12/29/2000 -0800
on 12/29/2000 6:59 AM, "Matthew Dornquast" [EMAIL PROTECTED] wrote:
 Anyway, use this method, and you've got lean mean serialized objects that
 take up the least amount of space possible and have the lowest overhead to
 serialize/deserialize.

However, you need to remember that the only time you should be hitting this
code is during development. :-) Therefore, speed isn't necessarily an issue
if it is still happening in just a few seconds (or less). 

I can see this being used for fault tolerance. If your servlet engine crashes,
or if you have to restart it for some reasons, your users' sessions don't need 
to be lost.

Therefore, I'm
also not sure if it is worth going the extra distance of having to implement
Externalizable for all your objects that you place into the Session (except
for the fact that you made it easy with your example class smile).

Sounds like this is a good candidate for a separate Store class (for Catalina
at least).

Kief


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FileStore

[Kief Morris]

Craig R. McClanahan typed the following on 09:35 AM 12/27/2000 -0800
 * Create another level of nesting inside Manager called Store.  This is
   probably better, because you can now configure the properties of the
   Store implementation using Store attributes.

I haven't had much luck getting this working. I've got the following in my
server.xml:

Context path="/examples" docBase="examples" debug="3"
  reloadable="true"
Manager className="org.apache.catalina.session.PersistentManager"
  debug="3"
Store className="org.apache.catalina.session.FileStore"/
/Manager

Then I put some stuff into startup/Catalina.java, basically copying the
code for Manager (this is also in the attached patch for reference):

mapper.addRule("Server/Service/Engine/Host/Manager/Store",
   mapper.objectCreate
   ("org.apache.catalina.session.FileStore",
"className"));
mapper.addRule("Server/Service/Engine/Host/Manager/Store",
   mapper.setProperties());
mapper.addRule("Server/Service/Engine/Host/Manager/Store", mapper.addChild
   ("setStore", "org.apache.catalina.Store"));
[...]
mapper.addRule("Server/Service/Engine/Manager/Store", mapper.objectCreate
   ("org.apache.catalina.session.FileStore",
"className"));
mapper.addRule("Server/Service/Engine/Manager/Store",
   mapper.setProperties());
mapper.addRule("Server/Service/Engine/Manager/Store", mapper.addChild
   ("setStore", "org.apache.catalina.Store"));
[...]
mapper.addRule(prefix + "/Store",
   mapper.objectCreate
   ("org.apache.catalina.session.FileStore",
"className"));
mapper.addRule(prefix + "/Store",
   mapper.setProperties());
mapper.addRule(prefix + "/Store", mapper.addChild
   ("setStore", "org.apache.catalina.Store"));

The problem is I don't understand enough about what's going on here to
debug it - the FileStore doesn't seem to be instantiated, and the PersistentManager's
setStore() definitely isn't being called. Is there any reference to how this all fits 
together?
XmlMapper.java is uncommented :-( Otherwise, what should I do to make this work?

Kief


--- Catalina.java.orig  Thu Dec 28 11:34:30 2000
+++ Catalina.java   Thu Dec 28 10:29:54 2000
@@ -372,6 +372,15 @@
mapper.addRule("Server/Service/Engine/Host/Manager", mapper.addChild
   ("setManager", "org.apache.catalina.Manager"));
 
+   mapper.addRule("Server/Service/Engine/Host/Manager/Store",
+   mapper.objectCreate
+  ("org.apache.catalina.session.FileStore",
+   "className"));
+   mapper.addRule("Server/Service/Engine/Host/Manager/Store",
+   mapper.setProperties());
+   mapper.addRule("Server/Service/Engine/Host/Manager/Store", mapper.addChild
+  ("setStore", "org.apache.catalina.Store"));
+
mapper.addRule("Server/Service/Engine/Host/Realm", mapper.objectCreate
   (null, "className"));
mapper.addRule("Server/Service/Engine/Host/Realm",
@@ -424,6 +433,14 @@
mapper.addRule("Server/Service/Engine/Manager", mapper.addChild
   ("setManager", "org.apache.catalina.Manager"));
 
+   mapper.addRule("Server/Service/Engine/Manager/Store", mapper.objectCreate
+  ("org.apache.catalina.session.FileStore",
+   "className"));
+   mapper.addRule("Server/Service/Engine/Manager/Store",
+   mapper.setProperties());
+   mapper.addRule("Server/Service/Engine/Manager/Store", mapper.addChild
+  ("setStore", "org.apache.catalina.Store"));
+
mapper.addRule("Server/Service/Engine/Realm", mapper.objectCreate
   (null, "className"));
mapper.addRule("Server/Service/Engine/Realm", mapper.setProperties());
@@ -535,6 +552,15 @@
   mapper.setProperties());
mapper.addRule(prefix + "/Manager", mapper.addChild
   ("setManager", "org.apache.catalina.Manager"));
+
+   mapper.addRule(prefix + "/Store",
+  mapper.objectCreate
+  ("org.apache.catalina.session.FileStore",
+   "className"));
+   mapper.addRule(prefix + "/Store",
+  mapper.setProperties());
+   mapper.addRule(prefix + "/Store", mapper.addChild
+  ("setStore", "org.apache.catalina.Store"));
 
 mapper.addRule(prefix + "/Parameter", mapper.objectCreate
("org.apache.catalina.deploy.ApplicationParameter"));

Re: [RFC] Distributed sessions in Catalina

[Kief Morris]

Craig R. McClanahan typed the following on 09:19 AM 12/26/2000 -0800
I continue to believe, though, that 
we should
strive to agree on a high level functional requirements document before 
diving too
far down into the "how to do it" details.

OK, I can update my original RFC so it can be checked into CVS. What
else should go into it, any suggestions for structure, etc.?

A web application declares that it supports being run in a multiple-JVM 
container by
including the distributable/ element in the deployment descriptor.  If this
element is not included, the container *must* run that particular app in one 
and
only one container.  This applies whether sessions are being used or not -- 
thus,
the load balancing model that Apache JServ uses (for example) would not 
conform.

Ideally this can be enforced in a DistributedManager class, so Store
implementations won't have to worry about it.

Kief

---
Kief Morris
Director of Technology
bitBull Ltd. http://www.bitBull.com
phone +44 020 7598 9938 
fax  +44 020 7460 4081

[PATCH PROPOSAL]: Catalina 4.0: FileStore, PersistentManager

[Kief Morris]

void propertyChange(PropertyChangeEvent event) {

// Validate the source of this event
if (!(event.getSource() instanceof Context))
return;
Context context = (Context) event.getSource();

// Process a relevant property change
if (event.getPropertyName().equals("sessionTimeout")) {
try {
setMaxInactiveInterval
( ((Integer) event.getNewValue()).intValue()*60 );
} catch (NumberFormatException e) {
log(sm.getString("standardManager.sessionTimeout",
 event.getNewValue().toString()));
}
}

}


//  Private Methods


/**
 * Invalidate all sessions that have expired.
 */
private void processExpires() {

long timeNow = System.currentTimeMillis();
Session sessions[] = findSessions();

for (int i = 0; i  sessions.length; i++) {
StandardSession session = (StandardSession) sessions[i];
if (!session.isValid())
continue;
int maxInactiveInterval = session.getMaxInactiveInterval();
if (maxInactiveInterval  0)
continue;
int timeIdle = // Truncate, do not round up
(int) ((timeNow - session.getLastAccessedTime()) / 1000L);
if (timeIdle = maxInactiveInterval) {
session.expire();
}
}
}


/**
 * Sleep for the duration specified by the codecheckInterval/code
 * property.
 */
private void threadSleep() {

try {
Thread.sleep(checkInterval * 1000L);
} catch (InterruptedException e) {
;
}

}


/**
 * Start the background thread that will periodically check for
 * session timeouts.
 */
private void threadStart() {

if (thread != null)
return;

threadDone = false;
threadName = "PersistentManager[" + container.getName() + "]";
thread = new Thread(this, threadName);
thread.setDaemon(true);
thread.start();

}


/**
 * Stop the background thread that is periodically checking for
 * session timeouts.
 */
private void threadStop() {

if (thread == null)
return;

threadDone = true;
thread.interrupt();
try {
thread.join();
} catch (InterruptedException e) {
;
}

thread = null;

}


// -- Background Thread


/**
 * The background thread that checks for session timeouts and shutdown.
 */
public void run() {

// Loop until the termination semaphore is set
while (!threadDone) {
threadSleep();
processExpires();
}

}


}


--- Store.java.orig Fri Aug 11 02:24:12 2000
+++ Store.java  Wed Dec 27 09:50:50 2000
@@ -68,7 +68,6 @@
 import java.beans.PropertyChangeListener;
 import java.io.IOException;
 
-
 /**
  * A bStore/b is the abstraction of a Catalina component that provides
  * persistent storage and loading of Sessions and their associated user data.
@@ -92,6 +91,12 @@
  * codelt;descriptiongt;/lt;versiongt;/code.
  */
 public String getInfo();
+
+
+/**
+ * Return the Manager instance associated with this Store.
+ */
+public Manager getManager();
 
 
 /**
@@ -167,5 +172,11 @@
  */
 public void save(Session session) throws IOException;
 
+/**
+ * Set the Manager associated with this Store. 
+ *
+ * @param manager The Manager which will use this Store.
+ */
+public void setManager(Manager manager);
 
 }


---
Kief Morris
Director of Technology
bitBull Ltd. http://www.bitBull.com
phone +44 020 7598 9938 
fax  +44 020 7460 4081

FileStore

[Kief Morris]

I don't see anybody assigned to tackling the Catalina 4.0 FileStore 
implementation, or the Manager implementation for swapping active 
sessions to disk, so I've started messing around with this. If anyone 
else is interested in working on this (or already working on this) speak 
up!

So far I'm looking to implement the FileStore class by cribbing code
from StandardManager's load() and unload() methods, to store session
data in individual files named with the session ID. I've also created a
class called PersistentManager which will use this store.

I'd be interested in hearing comments on how the architect (Craig?)
who drafted up the Store class intended it to interact with Manager
and the rest of the container. I could also use some pointers in a
few areas, in particular:

- How exactly does the Container decide which Manager implementation
  to load? I've found in startup.Catalina.createStartMapperContext():
mapper.addRule(prefix + "/Manager",
   mapper.objectCreate
   ("org.apache.catalina.session.StandardManager",
"className"));
  ... but I'm guessing there's a way to override this in server.xml?

- I'll need to figure out how to make the choice of Store class configurable.
  Any pointers on this would be appreciated.

- The FileStore implementation I'm using needs to get access to the
  Container. Is there a recommended way to do this? At this point I've
  actually modified the Store interface to add setManager() and getManager()
  methods, which the Manager uses when instantiating its Store - this
  way the Store can get at most of the things it might need.

Thanks,
Kief

RE: Tomcat session replicator - more thoughts !!!

[Kief Morris]

[EMAIL PROTECTED] typed the following on 10:35 AM 12/22/2000 +0200
...
Mod_jk on each machine forward requests based on sessionID to the right
tomcat (this is my patch to 3.2b7).
...
THE NEW IDEA is, assuming all of what I have stated above is working. We can
take apache out of the picture.
HOW COME? I can point the load-balancing switch to the tomcat themselves.
Each tomcat will forward requests based on sessionID (we will need to move
mod_jk client side to into tomcat. Dan, would you like to take that?) is the
exist to the right tomcat (if there's no sessionID - will create one
locally). If Tomcat can't connect to master, it will forward the request to
the buddy.

What do you mean by forwarding the request? Wouldn't it be better if whichever
Tomcat instance got the second request could handle the request itself, getting
a copy of the session object? I've got some ideas on this which I'll post shortly.

Kief

---
Kief Morris
Director of Technology
bitBull Ltd. http://www.bitBull.com
phone +44 020 7598 9938 
fax  +44 020 7460 4081

[RFC] Distributed sessions in Catalina

[Kief Morris]

nce it can
assume it has a monoply on the session while it's being used by an
application. Questions this raises for me include:

- What should happen if a request comes in to server B while a 
  request for the same session is concurrently being handled by server A?
- Should it be possible for application code to access (and even modify?) 
  session data outside of handling a request, e.g. for diagnostic purposes?
  What requirements does this impose to ensure the integrity of the data?

DETECTING SESSION MODIFICATIONS

In short, this can't be done. While it's possible to monitor changes in an
HttpSession object's state by changing the implementation. It's also
possible to detect when attributes are added, removed, and replaced
using an HttpSessionAttributesListener. However, there is no efficient 
mechanism for the session distribution to detect when data within an
arbitrary attribute object is modified. Therefore the general session
distribution scheme should always assume a session has been
modified after handling a request in which the session was requested
by application code.

CATALINA SUPPORT FOR SESSION REPLICATION

The following are changes I would suggest need to be made to Catalina
to support session replication:

DistributedSessionManager interface:

Define an interface for a Manager class to manage distributed sessions.
Implementors of session distribution will implement this interface, and all
operations within Catalina which may affect session distribution will make
appropriate calls to the Manager implementation.

This is going to be closely tied in with the existing Manager interface.
Maybe it will be a replacement for the StandardManager class. Quite
likely an abstract DistributedSessionManagerBase class, or something
similar, can be provided in Catalina to cover functionality which will be
common to all implementations.

Catalina Session handling:

Various places in Catalina's code relating to the creation, storage, and
retrieval of sessions will need to be modified. They will check whether
the current application is distributable, and if so they will obtain a reference
to the DistributedSessionManager and make appropriate calls.

Session ID:

It may be necessary to provide more control over the session ID. I haven't looked 
closely enough to see if Catalina currently provides user-configurable domain
names for the Cookie ID, but this may be necessary to ensure that session
cookies are shared across servers (e.g. www1.me.com, www2.me.com).

Session distribution mechanisms may also want to use the session ID cookie
value to indicate important information, such as which Catalina instance created
the session. So the Manager should be given the option to override the session
ID value at creation.

NEXT STEPS

What do people think of this, both from a big picture perspective (is this the
right approach), and from a detailed perspective (what am I missing)? I can
whip up some more details of what the Manager class should look like, and
where it will integrate with Catalina. 

However I'm not sure how much time I'll have to devote to implementing it, 
especially to create sample distribution implementations which will be crucial 
to making sure it really works, since I'm between gigs.

Kief
---
Kief Morris
Director of Technology
bitBull Ltd. http://www.bitBull.com
phone +44 020 7598 9938 
fax  +44 020 7460 4081

Re: Suggestion for Mailing list page

[Kief Morris]

Jon Stevens typed the following on 09:44 14/12/2000 -0800
on 12/14/2000 2:40 AM, "Kief Morris" [EMAIL PROTECTED] wrote:

 I'd like to suggest that the mailing list page
 http://jakarta.apache.org/site/mail.html
 should be modified so tomcat-users appears before tomcat-dev.

Please send me a diff against the .xml file.

Attached.

Please do that for all of the lists and not just the Tomcat list. You are
making UI changes and you need to be consistent.

Agreed - they're currently inconsistent, fixed now. I also modified the 
description of the Velocity user's list to be consistent with the others 
(currently it says it's for developers of velocity).

Kief

 mail.xml.patch

Suggestion for Mailing list page

[Kief Morris]

I'd like to suggest that the mailing list page http://jakarta.apache.org/site/mail.html
should be modified so tomcat-users appears before tomcat-dev. 

I suspect many people with usage related questions jump on tomcat-dev to post 
because it's the first list under Tomcat, and "The Tomcat Developer List" sounds 
appropriate. Many people won't bother reading down far enough to see the warning 
about sending configuration and usage questions.

If tomcat-users were the first list under Tomcat, we might see fewer off-topic posts 
on this list. Other projects might benefit from the same rearrangement.

Kief

Patch:

--- mail.old.html   Thu Dec 14 10:35:45 2000
+++ mail.html   Thu Dec 14 10:37:18 2000
@@ -476,6 +476,21 @@
   /td/tr
   trtd
 blockquote
+
+p
+bThe Tomcat User List/bbr /
+bMedium Traffic/b
+a href="mailto:[EMAIL PROTECTED]"Subscribe/a
+a href="mailto:[EMAIL PROTECTED]"Unsubscribe/a
+a href="mailto:[EMAIL PROTECTED]"Send mail to list/a
+a href="http://mikal.org/interests/java/tomcat/index.html"Tomcat-User Archive/a
+/p
+
+p
+This is the list where users of Tomcat meet and discuss
+issues. Developers are also expected to be lurking on this list to
+offer support to users of Tomcat.
+/p
 
 p
 bThe Tomcat Developer List/bbr /
@@ -493,21 +508,6 @@
 testing notices, etc. bDo not send mail to
 this list with usage questions or configuration problems/b
 -- that's what tomcat-user is for.
-/p
-
-p
-bThe Tomcat User List/bbr /
-bMedium Traffic/b
-a href="mailto:[EMAIL PROTECTED]"Subscribe/a
-a href="mailto:[EMAIL PROTECTED]"Unsubscribe/a
-a href="mailto:[EMAIL PROTECTED]"Send mail to list/a
-a href="http://mikal.org/interests/java/tomcat/index.html"Tomcat-User Archive/a
-/p
-
-p
-This is the list where users of Tomcat meet and discuss
-issues. Developers are also expected to be lurking on this list to
-offer support to users of Tomcat.
 /p
 /blockquote
   /td/tr

---
  bitBull makes the Internet bite: http://www.bitBull.com/demos/

Re: [tomcat-4.0] building is hard

[Kief Morris]

Stuart Roebuck typed the following on 16:41 14/12/2000 +
On Thursday, December 14, 2000, at 09:44 AM, Pier P. Fumagalli wrote:
 Someone (me! :) proposed to do as they do in XML land with the Xerces 
 project. They distribute a simple "xerces-tools..." JAR containing all 
 libraries required for the build. What do you think? Would it be a good idea 
 to do the same for Tomcat? I'd rather not check in JARs in the CVS, but I 
 believe that a single big zip with all libraries would be great... 

Maybe as an option, but it should also be easy to build using libraries
you already have installed. Seems silly to download a separate copy
of ant, xml parser, etc. for each project.

Kief

---
  bitBull makes the Internet bite: http://www.bitBull.com/demos/

[PATCH]: Check for null in tag setter generation

[Kief Morris]

When the Jasper code gets the setter method for tag properties, it doesn't
check to see whether the m variable is null until after attempting to use its
getParameterTypes() method, which throws an uninformative NullPointerException. 
I simply moved the null check immediately after the variable m is set.

--- TagBeginGenerator.java.orig Wed Dec 13 12:18:12 2000
+++ TagBeginGenerator.java  Wed Dec 13 12:18:16 2000
@@ -193,6 +193,11 @@
 if (attrValue != null) {
String attrName = attributes[i].getName();
Method m = tc.getSetterMethod(attrName);
+   if (m == null)
+   throw new CompileException
+   (start, Constants.getString
+("jsp.error.unable.to_find_method",
+ new Object[] { attrName }));
 Class c[] = m.getParameterTypes();
 // assert(c.length  0)
 
@@ -203,13 +208,6 @@
 attrValue = convertString(c[0], attrValue, writer, 
attrName);
} else
attrValue = convertString(c[0], attrValue, writer, attrName);
-
-
-   if (m == null)
-   throw new CompileException
-   (start, Constants.getString
-("jsp.error.unable.to_find_method",
- new Object[] { attrName }));
 
writer.println(thVarName+"."+m.getName()+"("+attrValue+");");
 }
---
  bitBull makes the Internet bite: http://www.bitBull.com/demos/

Re: [PROPOSAL] JSSI for Tomcat

[Kief Morris]

Hans Bergsten typed the following on 19:17 10/12/2000 -0800
 But maybe I'm missing something. Are you saying the whole SSI processing
 should be done as an interceptor instead of as a servlet?

Is this something that could be done as a Servlet 2.3 Filter, and so be 
completely
container independent for 2.3 containers?

Kief

---
   bitBull makes the Internet bite: http://www.bitBull.com/demos/

[BUG] An invalid symlink gives ambiguous error

[Kief Morris]

Hello,

I tried to submit this to BugRat, but got a ServletException:

java.lang.NoClassDefFoundError: javax/activation/DataSource at 
org.gjt.bugrat.servlet.BugRatReport.processReportPOST(Compiled Code)

Anyway,

I ran into a little problem with Tomcat 3.2 final: it's so much a bug as an 
ambiguous
error message which made it a *real* PITA to run down the real problem. The 
problem
turned out  to be that I had a broken symlink to a jar file in my 
WEB-INF/lib directory
(the symlink was in that directory, not the target).

When the jar file can't be opened, an exception is thrown by 
AdapativeClassLoader
and caught by LoadOnStartupInterceptor, but the only message printed is that
the servlet can't be loaded. The jar file may well have nothing to do with the
servlet being loaded: in my case, the error printed to stdout after Tomcat's
startup was: "cannot load servlet name: jsp"

I propose that LoadOnStartupInterceptor be modified to print the message
from the Exception which is caught:

src/share/org/apache/tomcat/context/LoadOnStartupInterceptor.java
*** 132,136 
 } catch (Exception ee) {
 String msg = sm.getString("context.loadServlet.e",
! servletName);
 System.out.println(msg);
 }
--- 132,136 
 } catch (Exception ee) {
 String msg = sm.getString("context.loadServlet.e",
! servletName) + ": " + 
ee.getMessage();
 System.out.println(msg);
 }

It looks like there are a fair number of other errors which can be thrown
when a servlet is loaded, so this should be more generally useful than
my specific case.

Here's a patch, sorry if it's not in the proper format.

134c134
 servletName);
---
  servletName) + ": " + 
ee.getMessage();


Kief
---
   bitBull makes the Internet bite: http://www.bitBull.com/demos/