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

[Ceki Gulcu]

Ralph,

You are right to note that the subject line is more general than the
issue of data encoding, a.k.a data binding. Joern and I seems to be
focused on the data binding part of the general problem because as
Joern's observes, any generic RPC-type of solution is bound to be
slower than a simple TCP socket approach which implies zero protocol
overhead. The socket appender approach might not be the most
user-friendly or reliable but it is bound to be the fastest.  The only
remaining issue then (having fixed the transport mechanism to basic
TCP socket) is data binding.

What is the essence of your objection? Do you think we are wasting our
time or is there something else?  :-)



Ralph Goers wrote:
> 
> On Mar 2, 2009, at 8:33 AM, Joern Huxhorn wrote:
> 
>> Exactly.
>> We are just trying to find a less fragile approach than serialization
>> for the events sent using SocketAppender (or my multipex-appenders).
>> Ideally, it should be platform- and programming-language-neutral and
>> shouldn't perform much worse than java serialization.
>> protobuf seems to be a ideal candidate from what I've read so far. I'll
>> definitely give it a try.
> 
> This is a completely different problem than what the subject line 
> implies. Are you presupposing that the decision to use the 
> SocketAppender to get a LogEvent into a remote Logback has already been 
> made? Even so, what service in the remote system would the Appender 
> call? AFAIK there is nothing in Logback today to handle that .
> 
> The way I read the subject line is "something" wants to act as a Logback 
> remote client and feed events into a system where Logback is running. 
> The client might be an appender or something completely different.
> 
>>
>>
>> While this is just a subset of "send this logging event there" I had the
>> impression that the question of transport was already solved more or
>> less. There's little alternative to a message based approach (int
>> containing size of data followed by data bytes) if Java serialization is
>> not used.
> 
> Here you seem to be making the classic confusion between messaging and 
> RPC. The only real difference is that RPC contains information about 
> what service to invoke. In actuality many "messaging" systems do the 
> exact same thing. They just embed the name of the service in the message 
> and use their own proprietary logic to figure out what to do with the 
> message based on the data received instead of just using something 
> standard.
> 
>>
>>
>> Any kind of RMI will *definitely* be slower than this approach and we
>> should evaluate it as an additional possibility after implementing the
>> high-speed one.
> 
> Who said anything about RMI?
> 
> Ralph
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev
> 

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch