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/07/26 07:49:33 UTC
Help needed with BinaryObjectException
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/
Re: Help needed with BinaryObjectException
Posted by "ilya.kasnacheev" <il...@gmail.com>.
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 rolling-upgrade problems.
Anyway, Apache Ignite stores data off-heap so it has to serialize data when
storing it in cache.
Hope this helps,
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Help needed with BinaryObjectException
Posted by Roger Janssen <ro...@ing.com>.
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 uptime. If using Ignite implies we
loose 24/7 uptime, that is an unexpected and unwelcome surprise.
The Ignite instances are embedded, so when we start the application (java /
spring) Ignite is automatically started in the same JVM as the application
(by the application).
In my opinion, Ignite should not care about the structure/content of our
model.
I can't give a quick reproducer. I can post our spring configuration class
content, but then you won't have our application and our domain model, so I
don't know if that would be of any help.
Kind regards,
Roger Janssen
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Help needed with BinaryObjectException
Posted by vkulichenko <va...@gmail.com>.
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 get to the bottom of it much
quicker.
-Val
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Help needed with BinaryObjectException
Posted by Roger Janssen <ro...@ing.com>.
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 stating this?
kind regards,
Roger Janssen
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Help needed with BinaryObjectException
Posted by Dave Harvey <dh...@jobcase.com>.
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 <ro...@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.