[infinispan-dev] Infinispan and change data capture

[Emmanuel Bernard]

Ok, So proposal "Emmanuel Dec 9th" is hereby rechristened Deelog.
I’ve captured it in the wiki https://github.com/infinispan/infinispan/wiki/Deelog:-direct-integration-with-Debezium <https://github.com/infinispan/infinispan/wiki/Deelog:-direct-integration-with-Debezium>

Randall and I discussed the case were more than two owners die too quickly (assuming a distribution factor of 2). We are in relatively deep trouble because we are breaking our eventual consistency rule (between Infinispan and the state in Kafka).
I’ve written the few options we have explored to compensate from that.

Emmanuel


> On 16 Dec 2016, at 17:00, Tristan Tarrant <ttarrant at redhat.com> wrote:
> 
> 
> 
> On 16/12/16 16:30, Emmanuel Bernard wrote:
> 
>> The Emmanuel Dec 9th proposal handles I think the case of topology changes and nodes going down.
> 
> We need a better name :)
> 
>> For a cluster-wide shutdown with no time to flush queues, I think both Artemis and the local debezium talking to remote Kafka will be in trouble.
>> 
>> The main difference is I imagine that your Artemis log will be local to the node being shut down. But that would mean a complex system to restart with the unflushed queue from all node that were shut down. Are we there yet?
> 
> I'm specifically thinking about when the Debezium embedded in Infinispan 
> cannot talk to Kafka for whatever reason, and the user wants to shutdown.
> 
> Tristan
> 
> -- 
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161216/d1a1d173/attachment.html