You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Roger Janssen <ro...@ing.com> on 2018/08/02 07:28:12 UTC

How to do rolling updates with embedded Ignite and changing models

Hi,

I understand and experience that Ignite crashes (binaryobjectexceeptions)
when I redeploy my application (with an embedded Ignite server node) in a
cluster and the new redeployed application has a different model (like enums
with added values).

This results in the inability to have my application up 24/7 because I can't
do rolling updates. It suggest I need to kill all my application instances
(and thus the embedded Ignite instances) first and then deploy and restart
them. But this is not acceptable.

How do I need to configure Ignite to be able to do rolling updates with
changing models? If this is not possible, what is the use of Ignite as a
distributed cache?

Configuration details:
- server nodes only
- non persistent
- cached replicated (in fact I am only interested in distributed cache
invalidations)
- server nodes run embedded in/from a java/spring/tomcat application

Kind regards,

Roger Janssen



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: How to do rolling updates with embedded Ignite and changing models

Posted by "ilya.kasnacheev" <il...@gmail.com>.
Hello!

My expectation that you can also use Binarylizable classes with some forward
compatibility and avoid this problem.

You could also focus on using SQL/binary objects. It should be working, but
if it doesn't, please supply code snippets & exception traces.

Regards,



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: How to do rolling updates with embedded Ignite and changing models

Posted by Roger Janssen <ro...@ing.com>.
Using the BinaryObject API, which is used out-of-the-box by Ignite, we get
this exception that I am trying to solve.

We just want a simple in-memory cache, so I am not sure why I would use a
heavy Ignite implementation as an inmem DB with SQL. That is overkill.
And... why would that solve the problem... does Ignite internally store the
data different then?

I still cant grasp that this simple thing does not work and that it looks
like I am the only one on this planet that uses Ignite with a distributed
application that does rolling updates.

With the info I have right now, I can only conclude that Ignite can not
serve as a distributed cache because you can not redeploy your application
with rolling updates (and thus guarantee 24/7 uptime) if your model (the
data you cache) changes (as example : add a new value to an enum). 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: How to do rolling updates with embedded Ignite and changing models

Posted by vkulichenko <va...@gmail.com>.
Roger,

To be able to change the schema in runtime, you need to make sure there are
no model classes deployed on server nodes and therefore no deserialization
happens. Since you run in embedded mode and have only server nodes, then you
actually can't use POJOs in your data modes at all. You should use
BinaryObject API [1] or SQL [2] instead. This way you would be able to
change schemas dynamically without restarts (even rolling restart is not
needed).

[1] https://apacheignite.readme.io/docs/binary-marshaller
[2] https://apacheignite-sql.readme.io/docs

-Val



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/