https://bz.apache.org/bugzilla/show_bug.cgi?id=65159
--- Comment #24 from Atle Solbakken <[email protected]> --- Hi in #65307 I've suggested a patch in attempt to help with the issues with the counter. This is the same patch as in the GitHub PR mentioned by Joe. The following fields are used to produce an ID. - Process ID of the running process - Thread ID of the running thread - Timestamp in microseconds - 16 bit incrementing counter for each thread - 16 bit server ID manually set in UniqueIdServerId (defaults to 0) The process ID is derived using getpid(). The thread ID is derived using some a technique borrowed from server/log.c, basically apr_os_thread_current() is used. I'm not 100% sure if this will always produce a unique number within each process but somebody else might know this. The timestamp is derived using apr_time_now(). The early versions of mod_unique_id ensured global uniqueness using IP-addresses of the server and client. This has since has been removed as this no longer works and a random number is now used. I suggest to set a server ID manually in the configuration file to guarantee uniqueness across servers, these IDs must be set up to actually be unique among servers which share the same backend/DB etc. (in environments where collisions are not acceptable). The counter in this case is unique for each thread which avoids problems with concurrency, this is already in place after the last change. If threads are not enabled, a static counter is used which will then be per process. The code is set up to use the new function apr_encode_base64 in newer versions. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
