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? 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? 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
