On Tue, Mar 5, 2013 at 11:24 AM, Ted Ross <tr...@redhat.com> wrote:

>
> On 03/05/2013 02:14 PM, Rajith Attapattu wrote:
>
>>
>> This is a good explanation that we need to put in the docs, as
>> Application developers certainly need to know how it behaves.
>> If one were to use the current C impl, it certainly gives the
>> impression that put() is meant to write messages into your internal
>> buffer and send() will actually write it to the wire.
>> Unfortunately some applications will depend on this behaviour, even
>> though it's not advisable
>>
>> If we are to change from say #2 to #1 or even #3 we need to release
>> note it prominently.
>>
>> I think the best solution is to make this behaviour configurable, and
>> advertise the default very prominently.
>> This way application developers will know exactly what they are
>> getting instead of us making changes underneath.
>>
>> Rajith
>>
>>
> Making this configurable multiplies the size of the test matrix.  Can't we
> make this simpler?
>
> To me, this sounds like an I/O facility in which your output lines may
> never get sent if you don't call fflush().  This will be a surprise to most
> programmers, who rarely use fflush().  I think most programmers would be
> happier if "put" caused the messages to be eventually sent and "send" was
> used only for blocking until messages were flushed out.


It isn't really possible to have "put" cause messages to be eventually sent
without a background thread, something we don't currently have. I also
don't think it's really analogous to the fflush() situation. If you're
pumping lines into a file and you forget to call fflush(), eventually the
buffer will run out of room and your I/O will get flushed to disk anyways
in order to clear the buffer. By comparison, if you're pumping messages at
a high rate down a slow TCP connection, even if they will all get written
eventually by some background thread, you can quite easily fill up all your
available memory. Given this, unlike in the file I/O situation, I think you
fundamentally need some strategy for pausing and waiting for the wire to
catch up.

--Rafael

Reply via email to