tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: Special requirements on session id generator
Date Fri, 14 Feb 2014 17:48:19 GMT
2014-02-14 19:31 GMT+04:00 Rainer Jung <rainer.jung@kippdata.de>:
> On 14.02.2014 14:27, Mark Thomas wrote:
>> On 14/02/2014 13:15, Rainer Jung wrote:
>>> I ran into a special requirement for the session id generator
>>> (uniqueness of session id for a longer time interval). While I think
>>> that the requirement needed isn't a useful general purpose extension, I
>>> stumbled over the fact, that the SessionIdGenerator class is not pluggable.
>>>
>>> Would it make sense to introduce a new interface for the session Id
>>> generation, probably including setJvmRoute(), setSessionIdLength() and
>>> generateSessionId(), letting the current implementation be the base
>>> implementation, probably switching getRandomBytes() to protected, and
>>> allowing to set the implementation class in ManagerBase - or the Manager
>>> interface (trunk)?
>>>
>>> I haven't worked it out in detail, but it looks easy to do and useful.
>>>
>>> WDYT?
>>
>> I'm struggling to understand the use case. Are you saying the current
>> implementation generates collisions?
>
> Yes. But only over time, not concurrently. So some session ID used some
> time were again generated on later days. The rate was low, about one out
> of 100.000 IDs were generated again during the next 30 days. I don't see
> a problem here per se, but the application required the IDs to be unique
> over an extended period of time.
>

Add a timestamp, current date, a counter or some UUID?

2014-02-14 17:15 GMT+04:00 Rainer Jung <rainer.jung@kippdata.de>:
> Would it make sense to introduce a new interface for the session Id
> generation, probably including setJvmRoute(), setSessionIdLength() and
> generateSessionId(), letting the current implementation be the base
> implementation, probably switching getRandomBytes() to protected, and
> allowing to set the implementation class in ManagerBase - or the Manager
> interface (trunk)?
>
> I haven't worked it out in detail, but it looks easy to do and useful.
>

OK.

Does it need to be "jvm route",  or maybe just a prefix/suffix?

Do you intend to set it programmatically, or via configuration? (A
class name + maybe a set of prefixed properties like "socket." ones in
AbstractEndpoint.setProperty(...)?).

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message