Hi Abe, Our backward compatibility story between client and server is evolving. Our model to date has been: 1) update the server Phoenix jar first with the new release. Clients one minor release back will continue to work with the new server jar (this is the scenario for which we test). 2) upgrade *all* client versions to the new Phoenix jar
If there's any upgrade code that needs to run, it will run at step (2), the first time a new client connects to the cluster. It's possible that the upgrade code would make a change such that the older clients would no longer work. An example is between 4.1 and 4.2 in which the sequence table was salted to improve performance. Once it's salted (i.e. first time any 4.2 client connects with the 4.2 server), then sequences in 4.1 clients will no longer work. FWIW, you can set the client-side phoenix.sequence.saltBuckets to 0 in your hbase-sites.xml and this particular upgrade will not take place (nor will you get the performance gain, of course). There's a desire to improve this story and support mixed old/new client versions against a new server. Perhaps the biggest effort here will be to setup the tests to ensure that this works. It'll also constrain the kind of upgrades possible in a minor release. I've filed PHOENIX-1483 to further discuss. Thanks, James On Tue, Nov 25, 2014 at 6:11 AM, Abe Weinograd <[email protected]> wrote: > As we get a distributed client base, I am wondering if there is room for > different phoenix client and server versions to work together. This has > accidentally worked in the past. Is there an official message here? For > example, we plan on switching to the latest 4.2.X next week, but have folks > who will have the 4.1 or 4.0 client versions. Will they work? > > Thanks, > Abe
