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]
