Re: [infinispan-dev] Infinispan and change data capture

2016-12-16 Thread 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 Randall and I discussed

Re: [infinispan-dev] Infinispan and change data capture

2016-12-16 Thread Tristan Tarrant
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

[infinispan-dev] Accidental comments on some PRs

2016-12-16 Thread Jiri Holusa
Hi, some of you might noticed comments on some PRs: "Performance tests run successfully. Link to the results: ${report_url}". I'm sorry about that, it was a misconfiguration. Please ignore them, thanks. I apologize. Jiri ___ infinispan-dev mailing

Re: [infinispan-dev] Infinispan and change data capture

2016-12-16 Thread Emmanuel Bernard
> On 16 Dec 2016, at 16:25, Emmanuel Bernard wrote: > > >> On 16 Dec 2016, at 13:38, Tristan Tarrant wrote: >> >> On 16/12/16 13:12, Emmanuel Bernard wrote: >>> On 16 Dec 2016, at 09:48, Tristan Tarrant wrote:

Re: [infinispan-dev] Infinispan and change data capture

2016-12-16 Thread Emmanuel Bernard
> On 16 Dec 2016, at 13:38, Tristan Tarrant wrote: > > On 16/12/16 13:12, Emmanuel Bernard wrote: >> >>> On 16 Dec 2016, at 09:48, Tristan Tarrant wrote: >>> >>> On 16/12/16 09:34, Emmanuel Bernard wrote: > Yes, the above design is what sprung to

Re: [infinispan-dev] Infinispan and change data capture

2016-12-16 Thread Sanne Grinovero
On 16 Dec 2016 12:39, "Tristan Tarrant" wrote: On 16/12/16 13:12, Emmanuel Bernard wrote: > >> On 16 Dec 2016, at 09:48, Tristan Tarrant wrote: >> >> On 16/12/16 09:34, Emmanuel Bernard wrote: Yes, the above design is what sprung to mind initially.

Re: [infinispan-dev] Infinispan and change data capture

2016-12-16 Thread Tristan Tarrant
On 16/12/16 13:12, Emmanuel Bernard wrote: > >> On 16 Dec 2016, at 09:48, Tristan Tarrant wrote: >> >> On 16/12/16 09:34, Emmanuel Bernard wrote: Yes, the above design is what sprung to mind initially. Not sure about the need of keeping the log in memory, as we

Re: [infinispan-dev] Infinispan and change data capture

2016-12-16 Thread Emmanuel Bernard
> On 16 Dec 2016, at 09:48, Tristan Tarrant wrote: > > On 16/12/16 09:34, Emmanuel Bernard wrote: >>> Yes, the above design is what sprung to mind initially. Not sure about >>> the need of keeping the log in memory, as we would probably need some >>> form of persistent log

Re: [infinispan-dev] Infinispan and change data capture

2016-12-16 Thread Tristan Tarrant
On 16/12/16 09:34, Emmanuel Bernard wrote: >> Yes, the above design is what sprung to mind initially. Not sure about >> the need of keeping the log in memory, as we would probably need some >> form of persistent log for cache shutdown. Since this looks a lot like >> the append-log of the Artemis

Re: [infinispan-dev] Infinispan and change data capture

2016-12-16 Thread Emmanuel Bernard
> On 16 Dec 2016, at 08:46, Tristan Tarrant wrote: > > On 09/12/16 18:25, Emmanuel Bernard wrote: >> The total order would not be global but per key. >> Each node has a Debezium connector instance embedded that listens to the >> operations happening (primary and replicas

[infinispan-dev] Infinispan Managment Console versioning and releases

2016-12-16 Thread Sebastian Laskawiec
Hey guys, A while ago was been talking with Ryan and Tristan about automated releases for Infinispan Management Console. I would like to send the main point for wider audience. Long story short, we were considering different versioning schemes, such as X.Y.Z.SHA1 or using Z as an auto-increment