Hello!
You mentioned that you have client nodes in test setup. This means that data
has to be serialized to be sent from client to server.
If you only use server nodes, you can configure them in such fashion that
they never form a cluster but only function individually, and thus you
should avoid
It happens after we redeploy the application. There might be changes to our
model, in this scenario an enum is the problem, we added values to it. We
switched persistence of.
We currently have multiple instances of our application running. We redeploy
them one by one so we can guarantee 24/7
Hi,
We do not have persistence. How can I purge the metadata?
Can I purge the metadata runtime?
If we have multiple instances of the application running, and we need to be
24/7 up, we can't shutdown all instances at once, but this suggest that
using Ignite, that is NOT possible! Am I correct
Roger,
When exactly do you get this exception and what are the steps to reproduce
it? Do you change the set of values in the enum? Do you restart the cluster
when doing this?
Ideally, it would be great if you provide a reproducer that we can just run
to recreate the problem. That would help to
The cluster needs to agree on how to decode various versions of the
BinaryObjectSchema. Changing the type of a field name or an enum's value
are non-upwards compatible changes which Ignite cannot handle.
There is the question of the lifetime of the version of a type, and while
you may know that
Hi,
Just some context first: We have a java application, and use spring function
caching. In acceptance and prod, we have multiple instances and for that we
use Ignite as a distributed in-memory cache. On test we run single
instances, and we use Ignite just as a non-distributed in memory cache.
