Thanks. I thought I was setting acks as 1 but was setting as 0 due to a bug
in my code. Works fine now.
On Fri, Jun 12, 2015 at 7:17 PM, Gokulakannan M (Engineering - Data
Platform)
Hi,
What is the value set for acks config property?
If acks=0 then the producer will not wait for any
@Jay:
Regarding your first proposal: wouldn't that mean that a producer wouldn't
know whether a write succeeded? In the case of event sourcing, a failed CAS
may require re-validating the input with the new state. Simply discarding
the write would be wrong.
As for the second idea: how would a
Ewen: would single-key CAS necessitate random reads? My idea was to have
the broker maintain an in-memory table that could be rebuilt from the log
or a snapshot.
On lør. 13. jun. 2015 at 20.26 Ewen Cheslack-Postava e...@confluent.io
wrote:
Jay - I think you need broker support if you want CAS to
Daniel: By random read, I meant not reading the data sequentially as is the
norm in Kafka, not necessarily a random disk seek. That in-memory data
structure is what enables the random read. You're either going to need the
disk seek if the data isn't in the fs cache or you're trading memory to
But wouldn't the key-offset table be enough to accept or reject a write?
I'm not familiar with the exact implementation of Kafka, so I may be wrong.
On lør. 13. jun. 2015 at 21.05 Ewen Cheslack-Postava e...@confluent.io
wrote:
Daniel: By random read, I meant not reading the data sequentially as
If you do CAS where you compare the offset of the current record for the
key, then yes. This might work fine for applications that track key, value,
and offset. It is not quite the same as doing a normal CAS.
On Sat, Jun 13, 2015 at 12:07 PM, Daniel Schierbeck
daniel.schierb...@gmail.com wrote:
Jay - I think you need broker support if you want CAS to work with
compacted topics. With the approach you described you can't turn on
compaction since that would make it last-writer-wins, and using any
non-infinite retention policy would require some external process to
monitor keys that might
Hi,
I am using mirror maker in trunk to replica data across two data centers.
While the destination broker was having busy load and unresponsive the send
rate of mirror maker was very low and the available producer buffer was
quickly filled up. At the end mirror maker threw OOME. Detailed
I do not think that Kafa fits here. You should better use another storage
for your events, and use kafka to propagate the events to your views/query.
Le sam. 13 juin 2015 à 21:36, Ewen Cheslack-Postava e...@confluent.io a
écrit :
If you do CAS where you compare the offset of the current record
On Sat, Jun 13, 2015 at 10:47 PM, Yann Simon yann.simon...@gmail.com
wrote:
I do not think that Kafa fits here. You should better use another storage
for your events, and use kafka to propagate the events to your views/query.
This is also how I understood a use case of Martin Kleppmann for
10 matches
Mail list logo
