On 14.02.2014 18:48, Konstantin Kolinko wrote: > 2014-02-14 19:31 GMT+04:00 Rainer Jung <rainer.j...@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?
Timestamp is my plan. > 2014-02-14 17:15 GMT+04:00 Rainer Jung <rainer.j...@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? Could be prefix and suffix, but at the end I think there's no real benefit in more configurable flexibility in the base class itself. So I tend to keep it more minimalistic, and the abstract reason for the jvmRoute is supporting stateless stickyness in the load balancer. So "route" or "jvmRoute" isn't that bad as name and it would be up to the impl whether it puts it at the end or does something else with it. By the way there's an overlap with an idea of mine a few weeks ao, namely setting a jvmRoute per connector. If the session id generator gets an additional getSessionId(jvmRoute) method, that would be easier. And we coud end up supporting jvmRoute without configuration by passing them from the load balancer to Tomcat as part of the request. But that's another thing not directly related to pluggable session id generation. > 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(...)?). I thought about the typical className pattern. Haven't yet thought about possible configurations of the session id generator itself. I'll experiment a bit. It sounds as if it's worth trying this. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
