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