The version here is Apache Ignite version. Here is the exception that I am talking about:
Caused by: org.apache.ignite.spi.IgniteSpiException: Local node and remote node have different version numbers (node will not join, Ignite does not support rolling updates, so versions must be exactly the same) [locBuildVer=2.7.5, rmtBuildVer=2.7.0, locNodeAddrs=[U.Y.Z], rmtNodeAddrs=[X.Y.Z] On Fri, Jul 5, 2019 at 5:19 PM Ilya Kasnacheev <ilya.kasnach...@gmail.com> wrote: > Hello! > > What do you mean by 'version' here? Can you quote the error in full? > > I think Ignite has versioning for compute tasks, but services are not > versioned and cannot be peer-deployed or URI-deployed. This is from the top > of my head. > > Regards, > -- > Ilya Kasnacheev > > > пт, 5 июл. 2019 г. в 10:51, Ankit Batra <ankit.batr...@gmail.com>: > >> Hi, >> >> I am facing an issue with Ignite's version mismatch check. I have a >> deployment where 3 micro-service instances also run as Ignite server nodes. >> The process to update these microservices is an automated one, where 1 >> microservice is rebooted with a newer build at one time and until that >> microservice comes up, another microservice does not reboot with a newer >> build for the upgrade to complete across all the 3 instances. >> >> This automated process of deployment exposes an issue when I bump up the >> Ignite version for the micro-services and publish a newer build. When the >> first microservice reboots with a newer version of Apache-Ignite (while the >> other microservices are still running an older version) it throws a version >> mismatch error and never comes up. >> >> I am not sure if Ignite allows skipping this version mismatch check. >> Looking for some guidance on how this can be solved? >> >> Regards >> Ankit Batra >> > -- -- Regards Ankit Batra
