|
| >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 r
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 "adre
|
| >Rip away all the setters, incl. the private ones, make it totally
| >immutable (it's just a immutable "value object"), letting it have -one-
| >constructor taking all the arguments, take away all synch penalties on
| >construction, and optionally also make a utility Builder. Nice.
| >
| >The p
At 05:00 PM 1/11/2005, Endre Stølsvik wrote:
Curt, good points!
On Mon, 10 Jan 2005, Curt Arnold wrote:
|
| > 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 co
Curt, good points!
On Mon, 10 Jan 2005, Curt Arnold wrote:
|
| > 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
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
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 val
On Jan 10, 2005, at 3:05 PM, Ceki Gülcü wrote:
Two logging events that are identical in all other respects would
have a high likelihood of having distinct values for eventID and
acquiring the hash code would not incur an synchronization lock.
So, "all" you are suggesting is to replace
class Log
At 08:54 PM 1/10/2005, Curt Arnold wrote:
What I was suggesting as a potential approach (with the drawbacks
mentioned), is the value of hashCode at the time of creation could be
obtained and stored as a distinct member that would be be used to
distinguish objects that are identical in value in a
On Jan 10, 2005, at 12:33 PM, Ceki Gülcü wrote:
At 05:43 PM 1/10/2005, Curt Arnold wrote:
I said Object.hashCode, the underlying implementation if you had
called super.hashCode() within logging event. It has similar
characteristics to a memory address,
Yes, the Object.hashCode implementation is
At 05:43 PM 1/10/2005, Curt Arnold wrote:
I said Object.hashCode, the underlying implementation if you had called
super.hashCode() within logging event. It has similar characteristics to
a memory address,
Yes, the Object.hashCode implementation is computed over the object's
addres. However, two
On Jan 10, 2005, at 6:36 AM, Ceki Gülcü wrote:
At 06:23 AM 1/10/2005, Curt Arnold wrote:
I haven't worked any more on this, but I do intend to do so. I
thought that I would at least give a heads up that this issue isn't
dead.
The current approach has a couple of drawbacks:
it incurs a synchron
At 06:23 AM 1/10/2005, Curt Arnold wrote:
I haven't worked any more on this, but I do intend to do so. I thought
that I would at least give a heads up that this issue isn't dead.
The current approach has a couple of drawbacks:
it incurs a synchronization for every dispatched message,
yes
it add
I haven't worked any more on this, but I do intend to do so. I thought
that I would at least give a heads up that this issue isn't dead.
The current approach has a couple of drawbacks: it incurs a
synchronization for every dispatched message, it adds a sequenceCount
to the LoggingEvent which b
On Thu, 2004-12-30 at 09:49, Ceki GÃlcà wrote:
> Hello Elias,
>
> Currently, the sequence counter is managed per copy of the
> LoggingEvent class. If multiple logging repositories share the same
> log4j.jar file, then they will share the same sequence counter. I
> suppose the
Hello Elias,
Currently, the sequence counter is managed per copy of the
LoggingEvent class. If multiple logging repositories share the same
log4j.jar file, then they will share the same sequence counter. I
suppose the sequence counter could be managed per logger
re
On Thu, 2004-12-30 at 03:03, Ceki GÃlcà wrote:
> You couldn't possibly the sequence counter incremented within
> LoggingEvent to detect dropped messages. First, sequenceCounter is a
> class static variable shared by all LoggingRepositories within a JVM,
> all of which increment the
At 02:10 AM 12/29/2004, Curt Arnold wrote:
Didn't doubt the amount of mental activity. However, I didn't want to
guess at the motivation behind it and could find no discussion in the
archives.
Although everyone is encouraged to hold technical discussions on this
list, sometimes they occur elsew
On Tue, 28 Dec 2004, Ceki Gülcü wrote:
| Anyway, a non-trivial amount of thinking went into the implementation of
| the equals() method. In the absence of a malevolent adversary, it is also
| correct although only probabilistically so. Its only downside is the
| addition of the static sequenceCoun
On Dec 28, 2004, at 3:15 PM, Scott Deboy wrote:
The problem is that the object.equals isn't sufficient when events are
deserialized from a persistent store.
Being able to add events in a collection and know .contains will work
- regardless of where the event came from - is definitely worth the
Anyway, a non-trivial amount of thinking went into the implementation of
the equals() method. In the absence of a malevolent adversary, it is also
correct although only probabilistically so. Its only downside is the
addition of the static sequenceCount field and the sequenceNumber field in
Log
tract.
-Original Message-
From: Curt Arnold [mailto:[EMAIL PROTECTED]
Sent: Tue 12/28/2004 12:49 PM
To: Log4J Developers List
Cc:
Subject: Re: LoggingEvent.sequenceCount
On Dec 28, 2004, at 2:06 PM, Ceki Gülcü wrote:
>>
>
> The code currently says:
>
>
At 09:49 PM 12/28/2004, Curt Arnold wrote:
The point that I was trying to make and which I still think is valid
despite my mistaken analysis of the hashCode function, is that it is
better to have Chainsaw to make whatever comparison it thinks is
appropriate for its filtering needs and avoid havi
On Dec 28, 2004, at 2:06 PM, Ceki Gülcü wrote:
The code currently says:
/**
* The hashcode is computed as XOR of the lower 32 bits of
sequenceNumber and
* the higher 32 bits of timeStamp;
*/
public int hashCode() {
return (int)((timeStamp >> 32) ^ (sequenceNumber & 0x));
At 08:23 PM 12/28/2004, Curt Arnold wrote:
On Dec 28, 2004, at 7:50 AM, Ceki Gülcü wrote:
The sequenceNumber+timestamp combination makes it easy to implement
equals() method for LoggingEvent.
The implementation might be easy, but appears problematic. The default
implementation of equals and getHa
On Dec 28, 2004, at 7:50 AM, Ceki Gülcü wrote:
The sequenceNumber+timestamp combination makes it easy to implement
equals() method for LoggingEvent.
The implementation might be easy, but appears problematic. The
default
implementation of equals and getHashCode would be preferred if all you
cared
At 06:11 AM 12/28/2004, Curt Arnold wrote:
Also, Item 48 of Effective Java (Synchronize access to shared mutable
data) uses an example which appears to be almost exactly the scenario
in LoggingEvent and goes to great length why the code may not perform
as expected. Basically each thread is free to
On Dec 27, 2004, at 3:59 PM, Ceki Gülcü wrote:
(Switching order of comments)
>What do you mean by "the value of sequenceCount may be slightly out of
sync on different threads"?
http://java.sun.com/docs/books/vmspec/2nd-edition/html/
Concepts.doc.html#33308 (toward the end)
http://java.sun.com/
The sequenceNumber+timestamp combination makes it easy to implement
equals() method for LoggingEvent.
What do you mean by "the value of sequenceCount may be slightly out of sync
on different threads"?
At 10:45 PM 12/27/2004, you wrote:
I'm a bit concerned about LoggingEvent.sequenceNumber and
29 matches
Mail list logo
