On Jan 10, 2005, at 4:34 PM, Ceki G�lc� wrote:
At 11:01 PM 1/10/2005, Curt Arnold wrote:
In the original message, I outlined two approaches and their perceived drawbacks. One was just replacing sequenceCount with the value of super.hashCode. This would likely work okay, but the short-lifetime of LoggingEvent's might result in recurring values for hashCode and that would have to be investigated.
The hashCode is also computed over the timestamp. I'd expect the following version to give entirely satisfactory results.
public int hashCode() { return (int)((timeStamp & 0xFFFFFFFF) ^ (eventId)); }
My favored approach in that message was a full value comparison implementation of equals and hashCode. I had not expected the requirement that identical but distinct logging messages not compare as equal. To address that short-coming, you could still add the eventID and use that in a full value comparison implementation of equals.
If we pool LoggingEvent objects then successive events will have the same address and hence the same eventId.
I am not 100% sure about the safety of eventId=super.hashCode(). With hundreds of events created and GCed every millisecond, the probability of two events having the same eventId seems non-negligible. We'd need to check for more fields in LoggingEvent.equals() but I guess that's exactly what you are suggesting. :-)
It may be adequate for equals and hashCode to only check the timestamp, event id and message text. I think it would be very very rare that two messages in the wild would have duplicate values for all three, and if they did having Chainsaw drop one as a duplicate would not be a significant issue.
Except if we pool LoggingEvent objects
Object pooling was a was an beneficial optimization for early JVM's, but I believe that the current accepted wisdom is that object pooling for modern JVM's is generally detrimental. The next to last paragraph end of item 4 on Effective Java has these quotes:
Conversely, avoiding object creation by maintaining your own object pool is a bad idea unless the objects in the pool are extremely heavyweight. A prototypical example... database connection. .. Generally speaking, however maintaining your own object pools clutters up your code, increases memory footprint and harms performance.
If I remember correctly, a large part of the rework of Xerces-J 1 to create Xerces-J 2 was to eliminate memory pools which were added to increase performance at the time, but slowed the application down on later JVM's.
I'll take a stab at just the Builder rework. Do you have any objections to my committing it if it seems pretty straightforward and passes all the tests?
No objections as long as the Category.forcedLog method remains unchanged.
Shouldn't be a problem.
When logging an event, we should not build two objects (LoggingEventBuilder+LoggingEvent) instead of the current one (LoggingEvent).
In that high volume use and reentrant code, it might be best to continue to use a special constructor, but that might be made package private so it can only be used within log4j.
Have you considered adding support for LoggingEvent object pooling?
See previous quotes.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
