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@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