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 there are no instances of the old type anywhere, Ignite currently has no way to determine this. So we end up with this pretty tedious restriction that no-one has proposed a great way out of. If you do not have persistent data, then stopping the cluster and purging the metadata is a way out. With persistence, it is difficult. On Thu, Jul 26, 2018 at 3:49 AM, Roger Janssen <roger.jans...@ing.com> wrote: > 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. We > start Ignite embedded from out application. On acc/prod in server mode, on > test in client mode. Like I said, we do not want any persistence! > > Now on test we run into the problem that we get a BinaryObjectException > like > : 'Conflicting enum values. Name 'OPEX_LOAN_LIMIT_WEIGHT' uses ordinal > value > (11) that is also used for name 'OPEX_RCK_MAX'' > > I traced the code and the mergeEnumValues of BinaryUtils throws this > exception. It seems to have a list of enum values stored in a map, with the > ordinal as key. But... that is of values is incorrect, values are missing! > It then receives a value not in that list, but with an ordinal already in > that list, and then throws the exception. > > My questions: > - What is happening here? > - How is it possible for Ignite to have an incorrect breakdown of our enum? > - Why is ignite serialising our objects if it is not persisting them? There > is no need for this, we just want an in-memory cache. > - Why is the Ignite marshaller persisting class data in the > tomcat/temp/ignite/... folder? Especially since it should be running in non > persistence mode. > - How can we fix this problem because right now, this prevents us from > going > to prod? > > If Ignite somehow persists information about your classes, how do you then > deploy new versions of your application with model changes and prevent > these > kind of problems from happening? > > Kind regards, > > Roger Janssen > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ > > Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
