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

[Ralph Goers]

On Mar 2, 2009, at 11:51 AM, Ceki Gulcu wrote:

>
> 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?  :-)
>


I'm simply trying to understand what problem you are solving. I also  
think your assumption regarding the socket approach being the fastest  
is correct only under the simplest of circumstances. Finally, while  
the SocketAppender definitely clears up the client side, I haven't  
seen any discussion about what it is connecting to except that it is a  
Logback running remotely. Frankly, that is the part I find most  
important and why I'm making any kind of issue out of this. If you are  
simply looking to improve the existing SocketAppender without  
providing the other end of the connection, then I apologize and you  
can ignore everything I've said.

Let's assume you use a SocketAppender and connect to something  
listening for some kind of serialized LogEvent. What if the client  
wants to dictate to the server whether it should get control back  
immediately after the event is received or wait until the event is  
procesed? What if I want to communicate the locale or timezone of the  
client to the server? I'm pulling this off the top of my head but  
hopefully you get the idea that by specifying the service interface  
that you get more flexibility for enhancement down the road. And the  
cost of serializing a method where one of the parameters is the  
LogEvent probably isn't even measturable vs the cost of serializing  
the event itself. So my point is simply that if I was doing this I  
would have the SocketAppender use the service interface to establish  
the connection with whatever parameters are desired and then use the  
service to invoke the method to send the event. Doing this also allows  
you to create different appenders that use the same service one of  
which might be on top of Spring remoting so that any of its remoting  
implementations could be used. On the server side they would call the  
same implementation class as what the SocketAppender ends up  
interacting with.

Does that clear it up?

Ralph