From: grahn+nntp@snipabacken.se
On Mon, 17 Aug 2009 01:30:37 -0400, Barry Margolin wrote:
> In article ,
> Jorgen Grahn wrote:
>
>> - A partial log line doesn't get finished until the next time
>> the client tries to log something -- maybe hours later.
>>
>> - If the server is naively written to read a complete line, it may
>> be blocked for hours waiting for such a remainder. On the other
>> hand, such a server would block forever anyway, if the client host
>> disappeared from the network in the middle of a log line.
>
> It seems to me that the only reason for adding the complexity you
> described is because you tend to log messages faster than the server can
> read them. If that's the case, the above concerns should be moot.
Not really ... you can have a problem which causes say 1000 msg/s for
a little while, but when that period ends you can have a slow and
steady flow of log messages. Also, we think that during those bursts,
the users would prefer to lose log messages, not have the application
block just because every single log message must be delivered
regardless of cost.
> And if it's not, why are you bothering with this complex design?
Compared to just using the native syslog and/or using a simple UDP-based
protocol, you mean. Legacy reasons.
But compared to anything *more* complex than UDP, is it really that
complex? That was actually one of my implicit questions -- can a
solution with a non-blocking TCP socket be relatively simple? I can
imagine, for example, discovering that I must be able to reconnect to
the server when it gets restarted. Trying to do that with a
non-blocking TCP connect would be complex, I suppose.
/Jorgen
--
// Jorgen Grahn O o .
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
