You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Keiichi Fujino <kf...@apache.org> on 2014/10/14 08:12:00 UTC
Question of new SessionIdGenerator implementation.
I have a question of new SessionIdGenerator implementation.
If reloading Manager( or Context), SessionIdGenerator is re-created based
on sessionIdGeneratorClass that is cached to Manager.
However, attributes of jvmRoute and sessionIdLength are default value.
I think these attributes are need to take over when reloading.
Or another workaround?
--
Keiichi.Fujino
Re: Question of new SessionIdGenerator implementation.
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-10-14 16:17 GMT+04:00 Konstantin Kolinko <kn...@gmail.com>:
> 2014-10-14 10:12 GMT+04:00 Keiichi Fujino <kf...@apache.org>:
>> I have a question of new SessionIdGenerator implementation.
>> If reloading Manager( or Context), SessionIdGenerator is re-created based
>> on sessionIdGeneratorClass that is cached to Manager.
>> However, attributes of jvmRoute and sessionIdLength are default value.
>> I think these attributes are need to take over when reloading.
>> Or another workaround?
>
> Looking at ManagerBase.startInternal(), I think that
>
> 1) jvmRoute shall not be set on <SessionIdGenerator> element. It is
> set on <Engine> and is inherited from there. The documentation on
> "jvmRoute" attribute in config/sessionidgenerator.html explicitly
> mentions that effect.
>
> It ManagerBase.startInternal() there is the following code:
> "sessionIdGenerator.setJvmRoute(getJvmRoute());"
>
> 2) For sessionIdLength I think one shall be able to configure it on
> <SessionIdGenerator>, so the current behaviour is a bug and is worth
> to be added to Bugzilla.
>
> The workaround is to set that attribute on <Manager> element. (This
> contradicts documentation that says that this attribute on Manager
> element is deprecated).
>
> The fix is probably to let SessionIdGenerator to implement Lifecycle interface.
>
> The "this.sessionIdGenerator = null;" assignment in
> ManagerBase.stopInternal() originates from r1044874. That is a wrong
> place to clear sessionIdGenerator reference. A better place would be
> destroyInternal(), or just do not clear it.
>
> The old code before r1044874 was calling "randoms.clear();" there. I
> think it is easier to expose that method via Lifecycle.stop().
I filed
https://issues.apache.org/bugzilla/show_bug.cgi?id=57089
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Question of new SessionIdGenerator implementation.
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-10-14 10:12 GMT+04:00 Keiichi Fujino <kf...@apache.org>:
> I have a question of new SessionIdGenerator implementation.
> If reloading Manager( or Context), SessionIdGenerator is re-created based
> on sessionIdGeneratorClass that is cached to Manager.
> However, attributes of jvmRoute and sessionIdLength are default value.
> I think these attributes are need to take over when reloading.
> Or another workaround?
Looking at ManagerBase.startInternal(), I think that
1) jvmRoute shall not be set on <SessionIdGenerator> element. It is
set on <Engine> and is inherited from there. The documentation on
"jvmRoute" attribute in config/sessionidgenerator.html explicitly
mentions that effect.
It ManagerBase.startInternal() there is the following code:
"sessionIdGenerator.setJvmRoute(getJvmRoute());"
2) For sessionIdLength I think one shall be able to configure it on
<SessionIdGenerator>, so the current behaviour is a bug and is worth
to be added to Bugzilla.
The workaround is to set that attribute on <Manager> element. (This
contradicts documentation that says that this attribute on Manager
element is deprecated).
The fix is probably to let SessionIdGenerator to implement Lifecycle interface.
The "this.sessionIdGenerator = null;" assignment in
ManagerBase.stopInternal() originates from r1044874. That is a wrong
place to clear sessionIdGenerator reference. A better place would be
destroyInternal(), or just do not clear it.
The old code before r1044874 was calling "randoms.clear();" there. I
think it is easier to expose that method via Lifecycle.stop().
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org