On Sat, Jun 13, 2015 at 10:47 PM, Yann Simon
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 "Bottled
Water"
at Berl
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 a
écrit :
> If you do CAS where you compare the offset of the current record for the
> key, th
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:
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
wrote:
> Daniel: By random read, I meant not reading the data sequentially as is the
> norm i
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
avoid
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 exceptio
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
wrote:
> Jay - I think you need broker support if you want CAS to work with
> comp
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 exp
@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 clie