At 02:50 PM 1/17/2005, Endre Stølsvik wrote:
Java GC generally takes more than 1 millisecond from start to finish, was my point. This goes even if it is incremental: the GC'ing of the single object, or dozens of objects might go very fast, but the time it takes from start to finish (where the "adress" again is available) would "most probably" take more than a milli.
In addition, it would have to be -a LoggingEvent object- that was produced with this specific address for a collision to happen.
You may be right. Nevertheless, the above is based on your conjectures about how the GC behaves or should behave. In the absence of facts, we cannot base an important part of the log4j framework on speculation.
| | Who can guarantee that no two events in a group of N+M events will not have | the same address? After all, the probability of any two persons having the | same birthday in a randomly chosen group of 23 persons is higher than 50%. | Yes, there are 365+1 possible birth dates but only a few people are needed | to produce a collision. (The Birthday Paradox)
The birthday paradox does not apply here, as I've understood it.
Do not consider garbage collection as something that happens every other blue moon. Depending on the algorithm used, the JVM may be garbage collecting constantly, perhaps thousands of times every millisecond.
See for example: http://www-106.ibm.com/developerworks/java/library/j-jtp11253/
Remember the within-a-millisecond criteria, the no-two-"persons"-can-have-the-same-birthday-while-within-one "garbage generation" criteria, and add on to that the from the same logger criteria, the same level criteria, and possibly also with the same message criteria. You're rather far from the birtday paradox now, I feel.
But still, it -could- happen. It just seems rather unlikely.
We don't know for sure.
Look up a couple of UUID/GUID algorithms. This is actually what you're after, isn't it? Preferrably w/o synchronization hits.
Any references?
Endre.
-- Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
