Ceki,
As I said there is a drawback if you do split (for whatever reason) the message into
pieces. Than you are right. But you are wrong if you believe while the buffer is only
one byte only one byte is send at a time. If you use write(byte[], int, int) the whole
array is send in on TCP packet (if it fits into frame).
I know it sounds a bit obfuscated and first I thought same as you. But I convert.
Kind regards
Frank-Olaf Lohmann
>>> Ceki Gülcü <[EMAIL PROTECTED]> 01.02.2001 16.44 Uhr >>>
Frank-Olaf,
Isn't this the worst possible solution? I mean *hideously* bad. Maybe I don't
understand it but here is what I think will happen,
set SO_SNDBUF to 1;
while(there is something to send) {
send 1 byte();
// that is:
// encapsulate that single *byte* in a TCP packet;
// encapsulate the TCP header in an IP packet;
// send the IP packet over the wire; packet is now around 50 bytes;
// wait for acknowledgement on packet just sent;
// the wait period will be at least the round-trip latency of the channel,
// this is the most important factor as the latency will be high even in a gigabit
LAN.
}
Depending on the size of the LoggingEvents sent around, this solution will be say 100
to 200 times slower then the application level acks. Am I missing something? Ceki
At 16:16 01.02.2001 +0000, you wrote:
>Mark,
>
>If you want to be on the save side set your send buffer size to 1.
>Setting it is not guarantied by Java but I have tested with NT an there it works
>fine. Then if you write something to the socket the write is blocked until your data
>is send or you get an exception (timeout by the OS). If you call close in the same
>thread you are on the save side now. If you get an exception you have to decide what
>to do with your unsent message.
>Be aware of usage of multiple writes in a loop for only one message. With buffer size
>set to one you really send one package after the other each acknowledged over the
>wire first. writeObject() that is used in SocketAppender has this drawback. Now you
>are more secure for the price of degrade in link performance. To solve this drawback
>it is a good idea to use a buffered stream in front of the socket stream and use the
>flush that now do what we expect.
>
>Kind regards
>Frank-Olaf Lohmann
>
>
>>>> Mark Douglas <[EMAIL PROTECTED]> 01.02.2001 14.17 Uhr >>>
>Hi Ceki,
>
>I could get all apps to call into my utility code before they exit, but I
>was kind of hoping that I could 'hide' the fact that I was using log4j.
>It's a shame there are no destructors as in C++ ;-)
>
>I've had a quick play with trying to flush the Socket, but you are calling
>oos.flush() anyway in the SocketAppender.append() method.
>
>I have even tries playing with the SO_LINGER option on the socket, and that
>seemed to have no effect.
>
>Looks like the only thing that works is calling Category.shutdown().
>
>Sorry if this topic has been discussed before, but I'm fairly new to this
>forum.
>
>Thanks to everyone for all the feedback :)
>
>Mark Douglas
>Systems Union Group plc
>
>-----Original Message-----
>From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
>Sent: 01 February 2001 13:22
>To: LOG4J Developers Mailing List
>Subject: Re: Request for new method.
>
>
>At 12:04 01.02.2001 +0000, you wrote:
>>Hi All,
>>
>>I would like for a new method to be added to the Category class (along the
>>lines of the shutdown() method). The new method 'flush' would be called to
>>flush the buffers of all appenders in all categories. This really only
>>makes sense for SocketAppender and AsyncAppender as the other appenders
>>don't tend to buffer output (my understanding - possibly incorrect). Most
>>appenders would simply return from a call to their flush() method. The
>>SocketAppender would call oos.flush() for example.
>
>Hello Mark,
>
>Flushing the SocketAppender won't help at all. Not one bit. This makes sense
>because sending depends on the acknowledgement of the other side (the
>receiving side). Flushing on one side is pretty much useless.
>Closing the SocketAppender is different because the call will not return
>until all packets in the send buffer are acknowledged or until there is a
>timeout exception.
>
>What you need to do is to close all appenders (or call Category.shutdown)
>when your VM exists. Is that a possibility? Ceki
>
>>The reason:
>>At the moment, the only way to ensure that all Appender output is 'flushed'
>>is to call Category.shutdown(). This is fine for an app. that is about to
>>terminate, but for an app. that is continuing, calling Category.shutdown()
>>means that no further logging takes place.
>>
>>Why do I want to flush the buffers?
>>I have some utility code that is used in a number of applications. After
>my
>>code is called, some apps terminate and other do not. If I call
>>Category.shutdown() before my code returns, the apps that terminate are
>>fine, but the others carry on and can't perform further logging (all the
>>appenders have been deleted). If I don't call Category.shutdown(), the
>apps
>>that terminate lose a few logging messages because they are buffered in the
>>SocketAppender.
>>
>>To fix this, my utility code needs to be able to flush the buffers before
>>returning. This way, both types of app. would work correctly. Also, I
>>don't the apps to have to 'know' about log4j and therefore it would be
>>unreasonable for them to call Category.shutdown() before they exit.
>>
>>Ceki, is it possible to add this functionality for 1.1? Or is there
>>something I can do right now to solve this?
>>
>>Mark Douglas
>>Systems Union Group
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
----
Ceki Gülcü - Independent IT Consultant
av. de Rumine 5 Tel: ++41 21 351 23 15
CH-1005 Lausanne e-mail: [EMAIL PROTECTED] or
Switzerland [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
