Rainer Jung wrote:
My impression now is, that we should backout the commit and the user
should instead first try to use the existing Valve as described by Peter.
I agree,
Filip
Filip Hanik - Dev Lists wrote:
Rainer Jung wrote:
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
if ((session != null) && !session.isValid())
session = null;
if (session != null) {
+ if(!requestedSessionId.equals(session.getId())) {
+ Cookie cookie = new
Cookie(Globals.SESSION_COOKIE_NAME,
+ session.getIdInternal());
+ configureSessionCookie(cookie);
+ response.addCookie(cookie);
+ }
I don't know if that's a good idea. It looks a bit risky. I think
it should include && (getContext() != null) &&
getContext().getCookies().
Rémy
Also if I remember correctly, session replication with delta manager
(default) applies replica messages to sessions with the same id: So
in a three node cluster with one node failing renaming the id on a
second node might break replication from the second to the third.
Unfortunately I can't check right now, but since it might be, that
5.5.21 is not too far, I would find this new rewriting behaviour a
bit risky as a default.
Peter did the session rewriting implementation, I haven't worked on
it, but it seems that the session Id to piggy back on could have been
done without going that deep in the code.
Not sure what the concern is in Rainer's statement above, but that
scenario should work just fine as the cluster replicates the
sessionId changes, again a far from ideal solution.
It would have been easier to filter out the JVM route way before we
hit the session manager, and then append it before the request gets
sent out, that way we could avoid both the patch above and the
session Id listeners and jvm route binder stuff. so in short terms,
the session manager never knows about jvmRoute, that is something
happening on the "edge".
does that make sense?
Filip
I'm also asking Peter about the state of his rewriting listeners,
because I somehow remember a functionality like that might already
exist.
Maybe Filip likes to comment on my first concern.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
