[logback-dev] What is the most efficient way - preferrably platform agnostic - to submit events from "the outside"?

[Ralph Goers]

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 at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev