You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@kafka.apache.org by Tianning Zhang <Ti...@zanox.com> on 2013/08/07 11:38:18 UTC
Lost of messages at C++ Kafka client
Hi,
I am using Kafka (version 0.7.2) for publishing events from some C++ applications (ca. 20K event /sec). The C++ client is used, which is based on asio.
With the asynchronous and batched messaging, one issue I have is that in case Kafka server is broken, the client will not notice the socket lost immediately. Messages go lost between the moment the socket broke and the moment when the C++ client issues an error notification. Message lost is not tolerated in our application. Although we have some proprietary component to deal with the problem – it is not a convenient solution.
As I understand, this is a known issue. But I would like to know more about experiences and best practices for dealing this problems. What can future versions of Kafka offer to deal with this problems?
Kind regards
Tianning Zhang :: tianning.zhang@zanox.com<ma...@zanox.com>
[disclaimer logo: ZANOX.de AG]
STRAIGHT TO PERFORMANCE
--------------------------------------------------------------------------------
ZANOX.de AG | Headquarters: Berlin AG Charlottenburg | HRB 75459 | VAT identification number: DE 209981705
Executive Board: Thomas Joosten (CEO) | Stefanie Lüdecke (CSO) | Joachim Piroth (CFO) | Christian Rebernik (CTO)
Chairman of the Supervisory Board: Ralph Büchi
This e-mail and any attachments may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail from your system.
Any other use, copying, disclosure or distribution is strictly forbidden.
[100 Partnerprogramme 2012]
Re: Lost of messages at C++ Kafka client
Posted by Jun Rao <ju...@gmail.com>.
Yes, in 0.7, one of the limitations is that the producer doesn't wait for
any acknowledgement from the broker. So, if the broker is down, messages
still in the client socket buffer may be lost. In 0.8, we added the option
so that the producer can wait for an ack, which will help this particular
kind of data loss.
Thanks,
Jun
On Wed, Aug 7, 2013 at 2:38 AM, Tianning Zhang <Ti...@zanox.com>wrote:
> Hi,
>
> I am using Kafka (version 0.7.2) for publishing events from some C++
> applications (ca. 20K event /sec). The C++ client is used, which is based
> on asio.
> With the asynchronous and batched messaging, one issue I have is that in
> case Kafka server is broken, the client will not notice the socket lost
> immediately. Messages go lost between the moment the socket broke and the
> moment when the C++ client issues an error notification. Message lost is
> not tolerated in our application. Although we have some proprietary
> component to deal with the problem – it is not a convenient solution.
>
> As I understand, this is a known issue. But I would like to know more
> about experiences and best practices for dealing this problems. What can
> future versions of Kafka offer to deal with this problems?
>
> Kind regards
>
> Tianning Zhang :: tianning.zhang@zanox.com<mailto:
> tianning.zhang@zanox.com>
>
>
>
> [disclaimer logo: ZANOX.de AG]
>
> STRAIGHT TO PERFORMANCE
>
> --------------------------------------------------------------------------------
>
> ZANOX.de AG | Headquarters: Berlin AG Charlottenburg | HRB 75459 | VAT
> identification number: DE 209981705
> Executive Board: Thomas Joosten (CEO) | Stefanie Lüdecke (CSO) | Joachim
> Piroth (CFO) | Christian Rebernik (CTO)
> Chairman of the Supervisory Board: Ralph Büchi
>
> This e-mail and any attachments may contain confidential and/or privileged
> information.
> If you are not the intended recipient (or have received this e-mail in
> error) please notify the sender immediately and delete this e-mail from
> your system.
> Any other use, copying, disclosure or distribution is strictly forbidden.
>
> [100 Partnerprogramme 2012]
>
Re: Lost of messages at C++ Kafka client
Posted by Philip O'Toole <ph...@loggly.com>.
If I understand what you are asking, I have dealt successfully with the
same type of issue. It can take more than one Boost async_write() over a
broken connection before the client software notices that the connection is
gone.
The best way to detect if a connection is broken is not by detecting that
the ASIO async_write() call returns an error (or raises an exception).
Instead, also start an async_read on the socket (doesn't matter if you
never expect to actually read from it). This call will return immediately
when a connection is broken, allowing much quicker detection of this event.
See if this helps.
Philip
On Wed, Aug 7, 2013 at 2:38 AM, Tianning Zhang <Ti...@zanox.com>wrote:
> Hi,
>
> I am using Kafka (version 0.7.2) for publishing events from some C++
> applications (ca. 20K event /sec). The C++ client is used, which is based
> on asio.
> With the asynchronous and batched messaging, one issue I have is that in
> case Kafka server is broken, the client will not notice the socket lost
> immediately. Messages go lost between the moment the socket broke and the
> moment when the C++ client issues an error notification. Message lost is
> not tolerated in our application. Although we have some proprietary
> component to deal with the problem – it is not a convenient solution.
>
> As I understand, this is a known issue. But I would like to know more
> about experiences and best practices for dealing this problems. What can
> future versions of Kafka offer to deal with this problems?
>
> Kind regards
>
> Tianning Zhang :: tianning.zhang@zanox.com<mailto:
> tianning.zhang@zanox.com>
>
>
>
> [disclaimer logo: ZANOX.de AG]
>
> STRAIGHT TO PERFORMANCE
>
> --------------------------------------------------------------------------------
>
> ZANOX.de AG | Headquarters: Berlin AG Charlottenburg | HRB 75459 | VAT
> identification number: DE 209981705
> Executive Board: Thomas Joosten (CEO) | Stefanie Lüdecke (CSO) | Joachim
> Piroth (CFO) | Christian Rebernik (CTO)
> Chairman of the Supervisory Board: Ralph Büchi
>
> This e-mail and any attachments may contain confidential and/or privileged
> information.
> If you are not the intended recipient (or have received this e-mail in
> error) please notify the sender immediately and delete this e-mail from
> your system.
> Any other use, copying, disclosure or distribution is strictly forbidden.
>
> [100 Partnerprogramme 2012]
>