On Fri, Sep 4, 2015 at 5:43 PM, Krishnan Parthasarathi < [email protected]> 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
