[logback-dev] RFC: LoggingEvent redesign

[Joern Huxhorn]

On 24.02.2009, at 17:41, Thorbjoern Ravn Andersen wrote:

> Joern Huxhorn skrev:
>>
>>> The sole reason for compressing is because the network connection is
>>> too slow.  Does that hold here?
>>>
>>> It would be nice if the server allowed for both compressed and
>>> uncompressed transparently.  Also gzipping is rather slowish :)
>>>
>> Well, I'm using the benchmarked classes as the native file format  
>> of Lilith.
>> My appenders (both the xml and serialization version) all have
>> compression as an option. Ultimately, it all depends on the
>> infrastructure and the actual logging events.
>> We use logging in our live environment (our web-developers are  
>> receiving
>> errors if something is wrong in one of the templates of our CMS) and
>> single events can get quite big so in our case it increases  
>> performance.
>>
> I am not doubting that you have real life experience with this, but  
> I am curious if you have benchmarked to see how large the gain is by  
> compressing the large events you describe?
>
> (I guess you are on a 100 Mbit network?)

I haven't run a real benchmark because it's pretty hard to create a  
real-life situation. There are times where >10 people are listening to  
events of the same machine. My appender serializes (and gzips) the  
event only once and sends that package to every recipient. Because of  
that, I think that the additional cost of compression is legitimate.  
To make benchmarking even harder, we are all connected to the server  
using a tunnel that is nowhere near 100MBit (I think the last I heard  
was 6MBit...) :p
We are using serialized objects, not XML, so they decrease in size to  
about 35%.
The benchmark in the ticket does not take network into account at all.  
It's just reading and writing to files so the speed of the hard disk  
is the limiting factor.

>
>>>
>> Ok, I *do* understand what immutability is *supposed* to be about but
>> reality is quite different. In the two languages that I know best -  
>> Java
>> and C++ - constness and immutability can be circumvented easily.
>>
>>
> If you can access an object through reflection you can do anything  
> with it, including making a private member public (IIRC) and vice  
> versa.    The idea as I understand it is not to "protect" anything  
> but to state that events are not changable after the fact.  Which  
> makes sense to me.

Definitely. Although I like the phrase "should not be changed" better :)

>  A good example of a framework on immutable objects is the JODA  
> framework for handling dates and times, which is recommended reading  
> for anyone who has suffered with dealing with dates and times across  
> timezones in the Calendar framework (which was not designed by Sun).

I haven't checked but I somewhat doubt that those are initialized lazily

>
>> If this results in significantly reduced functionality (like e.g. the
>> inability to use XMLEncoder) then the price is too high
>> for the mere illusion of some kind of security (who is protected
>> against what, anyway?).
>>
>>
> Strings are immutable.  Have that been a major hinderance in your  
> programming work so far?

No, but it didn't exactly help me either ;)
Seriously, I know the pro arguments of immutable objects quite well  
(e.g. thread-safety) but there are different types of immutability.
Is an object immutable if it initializes certain properties lazily?
Is an object immutable if all references contained will stay the same  
(i.e. are final) but the referenced objects change because they are  
not immutable?
Or is an object only "really" immutable if it contains just basic data  
types with no setter? (like, probably, the JODA time objects)

> What would make XMLEncoder break?

In short, the class to be en/decoded should have a default constructor  
and should adhere to the Java Beans method naming conventions. That  
way it will "simply work". It is possible to implement special  
persistence delegates in case of non-standard properties but I never  
needed to do so (beside the one for Enums in [4])

For more information, just read the docs ;) [1][2][3]

Special care must be taken if the class contains references to Enums  
because those are only handled correctly starting with JDK 1.6. See [4]


>> I'm not very fond of the memento suggestion because it would create
>> twice the amount of objects as the current implementation and I guess
>> that this will have some garbage collection impact.
>>
> Java programs generally create a lot of short lived objects and the  
> garbage collectors know very well how to deal with them.  I suggest  
> we measure to see if there is a difference :)  You probably have  
> some very large datasets?

I'm just a bit worried that Logback could lose ground in comparison to  
log4j.
The reading and writing of objects doesn't have to be coupled with the  
data objects at all so there is no immediate use for the memento. All  
that is needed are Reader/Writer interfaces and various  
implementations of those. Serialization would just be the simplest  
(and probably fastest but unstable) implementation. I've done it that  
way in Lilith.

Joern.