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.