Hi Frank-Olaf,
You are right. Setting the SO_SNDBUF to 1 does not mean that the packets are sent one
byte at a time. The SO_SNDBUF sets the send buffer high-water mark. As I understand
it, this parameter influences the level at which the TCP implementation will trigger
actual sending on the wire. So setting this value to 1 means that packets should be
sent as they arrive. If they arrive in chunks of N then they will be sent N bytes at a
time (not 1). Hence I suppose your suggestion to place a buffered stream in front of
the socket stream.
In other words, this solution will perform quite well contrary to what I stated
earlier. Thanks for enlightening us. Ceki
At 17:55 01.02.2001 +0000, you wrote:
>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]
----
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]
