Re: [infinispan-dev] Cache migration (rolling upgrades, dump/restore, etc)

2017-05-22 Thread Wolf Fink
This is mentioned by Tristan "L4 client intelligence" which mean HotRod not Network On Mon, May 22, 2017 at 1:52 PM, Sebastian Laskawiec wrote: > > > On Fri, May 19, 2017 at 1:18 PM Wolf Fink wrote: > >> +1 for Vojtech >> >> yes the client's need to moved to the new cluster in one shot current,

Re: [infinispan-dev] To Optional or not to Optional?

2017-05-22 Thread Galder Zamarreño
I think Sanne's right here, any differences in such large scale test are hard to decipher. Also, as mentioned in a previous email, my view on its usage is same as Sanne's: * Definitely in APIs/SPIs. * Be gentle with it internals. Cheers, -- Galder Zamarreño Infinispan, Red Hat > On 18 May 2017

Re: [infinispan-dev] Cache migration (rolling upgrades, dump/restore, etc)

2017-05-22 Thread Gustavo Fernandes
On Mon, May 22, 2017 at 1:59 PM, Martin Gencur wrote: > Hi Wolf, > that was exactly my thought. Clients redirected to the target cluster do > not get updates written by other clients in the source cluster during the > rolling upgrade process. It is because the clients in target cluster won't > re

Re: [infinispan-dev] In Memory Data Grid Patterns Demos from Devoxx France!

2017-05-22 Thread Galder Zamarreño
Another thing, isn't the package.json file missign dependencies? https://github.com/vjuranek/tf-ispn-demo/blob/master/nodejs-consumer/package.json It should have infinispan dependency, 0.4.0 or higher. Cheers, -- Galder Zamarreño Infinispan, Red Hat > On 22 May 2017, at 15:50, Galder Zamarreño

Re: [infinispan-dev] In Memory Data Grid Patterns Demos from Devoxx France!

2017-05-22 Thread Galder Zamarreño
Hey Vojtech, Really cool demo!! As you know, we've created an organization to keep infinispan related demos called `infinispan-demos` Can you transfer that demo to the infinispan-demos organization? https://help.github.com/articles/about-repository-transfers/ Cheers, -- Galder Zamarreño Infin

Re: [infinispan-dev] Exposing cluster deployed in the cloud

2017-05-22 Thread Tristan Tarrant
We would need to provide a way to supply the external address at runtime, e.g. via JMX. Tristan On 5/22/17 2:50 PM, Sebastian Laskawiec wrote: > Hey Tristan! > > I checked this part and it won't do the trick. The problem is that the > server does not know which address is used for exposing its

Re: [infinispan-dev] Cache migration (rolling upgrades, dump/restore, etc)

2017-05-22 Thread Martin Gencur
Hi Wolf, that was exactly my thought. Clients redirected to the target cluster do not get updates written by other clients in the source cluster during the rolling upgrade process. It is because the clients in target cluster won't read the data through the remote cache store if they already hav

Re: [infinispan-dev] Exposing cluster deployed in the cloud

2017-05-22 Thread Sebastian Laskawiec
Hey Tristan! I checked this part and it won't do the trick. The problem is that the server does not know which address is used for exposing its services. Moreover, this address can change with time. Thanks, Sebastian On Tue, May 9, 2017 at 3:28 PM Tristan Tarrant wrote: > Sebastian, > are you

Re: [infinispan-dev] Cache migration (rolling upgrades, dump/restore, etc)

2017-05-22 Thread Sebastian Laskawiec
On Fri, May 19, 2017 at 1:18 PM Wolf Fink wrote: > +1 for Vojtech > > yes the client's need to moved to the new cluster in one shot current, > that was discussed before. > And it makes the migration because most of the customers are not able to > make that happen. > So there is a small possibili

Re: [infinispan-dev] REST Refactoring - breaking changes

2017-05-22 Thread Galder Zamarreño
All look good to me :) Thanks Sebastian! -- Galder Zamarreño Infinispan, Red Hat > On 16 May 2017, at 11:05, Sebastian Laskawiec wrote: > > Hey guys! > > I'm working on REST Server refactoring and I changed some of the previous > behavior. Having in mind that we are implementing this in a min

Re: [infinispan-dev] Cache migration (rolling upgrades, dump/restore, etc)

2017-05-22 Thread Vojtech Juranek
> This line basically says: if data is being written by the rolling upgrade > process itself, write it to the stores (excluding the remoteStore), > regardless if the command is conditional or not. ok, make sense to me now, thanks for explanation! signature.asc Description: This is a digitally sig

[infinispan-dev] Concurrency API

2017-05-22 Thread Katia Aresti
Hi all, I've been working last week on a concurrent API design, trying to keep the scope small (but not too small). I've came up with a proposal (WIP) while I've been having a look to what competitors do today. I've shared a small design proposal concerning an Infinispan Global API Object too. TBH

[infinispan-dev] Infinispan Spring Boot Starters 1.0.0.Final released

2017-05-22 Thread Sebastian Laskawiec
Hey! I'm happy to announce that Infinispan Spring Boot Starters 1.0.0.Final have been released. Change-list: * [https://github.com/infinispan/infinispan-spring-boot/pull/27] Infinispan 9.0.0.Final is used by default * [https://github.com/infinispan/infinispan-spring-boot/pull/25] Added metadata d

Re: [infinispan-dev] Cache migration (rolling upgrades, dump/restore, etc)

2017-05-22 Thread Gustavo Fernandes
On Mon, May 22, 2017 at 7:45 AM, Vojtech Juranek wrote: > On pátek 19. května 2017 13:05:00 CEST Gustavo Fernandes wrote: > > After the latest changes, new entries written to the target cluster are > > supposed to propagated back to the source [1]. > > I thought that when the rolling upgrade is i