I think I've lost the point of this discussion somewhere. The subject says something about submitting events remotely yet this discussion seems to be totally about serialization. If it is really about something like a "service" to submit events than I would suggest looking at Spring remoting and some of the protocols it supports - such as Hessian or Burlap. I would argue that a discussion about how best to serialize an object is pointless without having first decided on what the service API is. For example, are you presuming that one system will log to an Appender that will forward to a server that will turn around and log the event again? Or perhaps an Appender would just forward the event to an Appender on the remote system? Or, using Spring Remoting one could imagine that the local Appender is just a client stub generated by Spring forwarding to the "real" Appender somewhere else. Ralph On Mar 1, 2009, at 4:23 PM, Thorbjoern Ravn Andersen wrote:
Joern Huxhorn skrev:
Well, a stream could contain both LoggingEvent0916 and LoggingEvent0918 and the Deserializer would produce the correct output using instanceof and some defined conversion. The point is that the old class would not be lost as it is the case if just the serialVersionUID is changed. It could therefore still be deserialized. After thinking it over I believe that this is the exact reason why XMLEncoder/XMLDecoder was introduced in the first place - the ability to read in old classes.
I don't think that it is possible to get to work _well_ but I'm always happy for a good discussion.
Have you had the time to check my xml format? While it's not exactly terse ;) it's definitely human-readable. I think I have understood what the problem with my use of the "humanly readable" term is. It is not the actual XML with names and tags, but the data carried I am talking about. Timestamps are fine but is not really readable to a human.
I can easily live with one character tag and attribute names if the data in the fields carry meaning to the human eye :)
Well, I'm using yyyy-MM-dd'T'HH:mm:ss.SSSZ as the primary time stamp format and then apply some magic to change it into a valid xml timestamp, i.e. I add a colon between hh and mm of the timezone. It mad my sigh quite a bit when I realized that SimpleDateFormat did not support this...
A valid xml timestamp? According to what dialect? SOAP? Frankly I think that these date objects are expensive to reconstruct - perhaps you should look into this if performance is an issue to you? I believe the date object just serializes the long datestamp which is much cheaper to deserialize than to deconstruct a string into pieces and build a date/calendar object from it. Note you also need timestamp information for this so it most likely goes through a Calendar.
Point taken, I wasn't really thinking about that when I was implementing it, I primarily wanted to do it *right* ;)
It's an xs:dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime) which seemed reasonable to me. xs:dateTime expects a colon between timezone hh and mm while SimpleDateFormat does only support hhmm :p
I implemented your suggestion and it's - unsurprisingly - deserializing quite a bit faster, now. Hehe, if I read your tables correctly the lilithXmlUncompressedDeserializer went from 1.974544 sec to 0.497055 sec, which is four times faster so "quite a bit" is quite a bit of an understatement :)
Also the value is very close to the 0.493445 value for serializationUncompressedDeserializer so it appears that the two approaches have about the same runtime performance.
Now I just need to update the schema... and I really need to implement an EventWrapper Serializer that's using my xml so I can use it as the Lilith file format...! Performance and size is absolutely acceptable.
Now I just need to bully you into shortening all tags and attribute names into one character and skip any namespace prefixes :) Then we agree O:-)
I moved the benchmarks to http://apps.sourceforge.net/trac/lilith/wiki/SerializationPerformance so I don't have to change the closed bug all the time :p You _could_ also just reopen the bug :)
-- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev