[Libevent-users] Re: Missed read callbacks while using filtering bufferevents

[Krishnan Parthasarathi <krishnan.parthasarathi@xxxxxxxxx>]

On Fri, Sep 4, 2015 at 5:43 PM, Krishnan Parthasarathi <krishnan.parthasarathi@xxxxxxxxx> wrote:

Hi all,

We are using libevent (libevent 2.0.22-1) for our lightweight RPC library[1] on top of libevent.
The RPC implementation is length-encoded, i.e the first 8 bytes of the message
contains the length of the message. We use filtered bufferevents to wait until
an entire message is 'pulled-up' into the input buffer before the read callback
is called. While doing the above we face the following issue,

We found out why our read callback registered on the filtered bufferevent wasn't called

for each 'successful' (i.e returning BEV_OK) input filter callback . This was due to our misunderstanding

of how filters worked in libevent. Libevent invokes input filter callback every time there is data

available in the underlying bufferevent. The filter accumulates the transformed data for the consumption

of subsequent filter components (if any) or the read callback, until there is no more data available to

read or it has reached the read-high-watermark for the filtered bufferevent. We found that

the read callback is called with all the data transformed as we needed in one-shot. We had written

our read callback to handle one message at a time.

In summary, we were using filters to read in units of our length-encoded messages, which doesn't

work as expected. Currently, we have modified our read callbacks to drain the filtered bufferevent

until there are no more messages to read. With filtered bufferevents we are guaranteeing that our

read callback is not called with partial messages.

Thanks to Azat for looking into this issue.

Regards,

Krishnan Parthasarathi