Remy Maucherat wrote:
Jess Holle wrote:
[Yes, the Request change would still be necessary to prevent the
chance of requests randomly getting their sessions passivated and
recycle after they findSession() but before access().]
A session can be passivated at any (bad) time (which will screw up
req
Jess Holle wrote:
[Yes, the Request change would still be necessary to prevent the chance
of requests randomly getting their sessions passivated and recycle after
they findSession() but before access().]
A session can be passivated at any (bad) time (which will screw up
requests), and we already
Attached are a new PersistentManagerBase patch and a new
PersistentSession class. Together these eliminate the need for the
changes to ManagerBase and StandardSession (but not to Request, but this
change is an innocuous reordering of a couple of lines of code).
I've not had a chance to test th
On further analysis it seems that StandardSession is only constructed by
ManagerBase and indirectly from SimpleTcpReplicationManager via the
ReplicatedSession subclass.
Given that SimpleTcpReplicationManager is mutually exclusive of
PersistentManager, it would appear I should move my StandardSe
Remy Maucherat wrote:
Jess Holle wrote:
Where have I "faked" robustness? I will not claim I actually achieve
it, but I certainly tried, fixed real race condition cases, and don't
know of ones I missed.
The only race condition that I can possibly imagine is on accessCount,
which I think is somet
Remy Maucherat wrote:
Jess Holle wrote:
It is not useful without the rest of the changes as without the rest
of the changes there are intolerable race conditions.
Right. I suppose that's the end of the discussion then, it would be a
waste of time to continue. -1 for your patch.
If you really fee
Jess Holle wrote:
Where have I "faked" robustness? I will not claim I actually achieve
it, but I certainly tried, fixed real race condition cases, and don't
know of ones I missed.
The only race condition that I can possibly imagine is on accessCount,
which I think is something quite unimportant
Remy Maucherat wrote:
Jess Holle wrote:
Remy Maucherat wrote:
I'd appreciate comments as to what's wrong with the patch :-)
I am clearly new to this area of Tomcat, but there were clear issues
in this area of the code that I cannot ignore if I am to depend on
PersistentManager.
* Extremely in
Jess Holle wrote:
It is not useful without the rest of the changes as without the rest of
the changes there are intolerable race conditions.
Right. I suppose that's the end of the discussion then, it would be a
waste of time to continue. -1 for your patch.
If you really feel insecure, then you c
Jess Holle wrote:
Remy Maucherat wrote:
I'd appreciate comments as to what's wrong with the patch :-)
I am clearly new to this area of Tomcat, but there were clear issues in
this area of the code that I cannot ignore if I am to depend on
PersistentManager.
* Extremely inefficient behavior whe
Jess Holle wrote:
Remy Maucherat wrote:
Jess Holle wrote:
And finally, here are the patches against 5.5.6 (same as HEAD at
this moment in this case).
Ok, but I still dislike the patch ;)
I'd appreciate comments as to what's wrong with the patch :-)
Sorry I missed your previous comments somehow. I
Remy Maucherat wrote:
Jess Holle wrote:
And finally, here are the patches against 5.5.6 (same as HEAD at this
moment in this case).
Ok, but I still dislike the patch ;)
I'd appreciate comments as to what's wrong with the patch :-)
I am clearly new to this area of Tomcat, but there were clear issue
Jess Holle wrote:
And finally, here are the patches against 5.5.6 (same as HEAD at this
moment in this case).
Ok, but I still dislike the patch ;)
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [
And finally, here are the patches against 5.5.6 (same as HEAD at this
moment in this case).
--
Jess Holle
Jess Holle wrote:
Here's the patches against 5.5.4
Jess Holle wrote:
For those who tried finding through the patches only to find that
they did not properly map against CVS (as I just us
Here's the patches against 5.5.4
Jess Holle wrote:
For those who tried finding through the patches only to find that they
did not properly map against CVS (as I just used 'diff -u' in a
directory not in a proper CVS tool...), please see the attached patch
files against 5.0.30 (which were don
For those who tried finding through the patches only to find that they
did not properly map against CVS (as I just used 'diff -u' in a
directory not in a proper CVS tool...), please see the attached patch
files against 5.0.30 (which were donoe with a proper CVS tool).
I have reworked this for 5
A week or two ago I found I had need of the persistent session manager,
PersistentManagerBase -- and also noticed its experimental status.
Looking at the sources I found "FIXME" comments regarding: (1) a race
condition between session passivation and session usage and (2) a lack
of LRU sorting
Jess Holle wrote:
A week or two ago I found I had need of the persistent session
manager, PersistentManagerBase -- and also noticed its experimental
status.
Looking at the sources I found "FIXME" comments regarding: (1) a race
condition between session passivation and session usage and (2) a la
18 matches
Mail list logo
