Right Handling of UnRegisteredBinaryObjectTypeException

[VeenaMithare]

Hello Team

Our configuration is as follows :
Ignite Version : 2.8.1
Server nodes : 3
Native Persistence : yes

Cache Mode : Replicated
Write Sync Mode : FULL_SYNC

Updates/Inserts : Through entry processor .

No. of caches : ~ 30
No. of records per cache : ~30k


Our entry processor code looks something  like this :
class ProjectCacheEntryProcessor implements
CacheEntryProcessor<String, Integer, Object> {

            public Object process(MutableEntry<BinaryObject, BinaryObject>
entry,
Object... arguments) throws EntryProcessorException {
                BinaryObject value = entry.getValue();
              BinaryObjectBuilder builder;
 
                if (value == null ) {
        builder = ignite.binary().builder(tablename);

                } else {
                builder =value.toBuilder();
                                   
                }

      If ( some logic ){
            Builder.setField(columname,<somevalue> )
      }

      entry.setValue(builder.build())

}

}


It is noticed that when we populate the caches for the first time  ( i.e.
sync data in from other db ) , where all the updates are happening in
parallel in separate threads ( around 10 tables at a time ) , update/insert
for some records show 'UnRegisteredBinaryObjectException' on some server
nodes . ( We dont get this exception if we sync any single cache alone )

The detailed message for this says :
class org.apache.ignite.internal.UnregisteredBinaryTypeException: Attempted
to update binary metadata inside a critical synchronization block (will be
automatically retried). This exception must not be wrapped to any other
exception class. If you encounter this exception outside of EntryProcessor,
please report to Apache Ignite dev-list. Debug info [typeId=-1816288802,
binaryMetadata=null, fut=MetadataUpdateResultFuture [key=SyncKey
[typeId=-1816288802, ver=3]]]

Because of that message , we had not caught this exception. But looks like
this causes the data not inserted on that node . Since this exception is not
caught , client doesn't receive any exception for the update/insert of the
record. This causes data inconsistency between nodes for the data of any
given replicated cache.

Kindly let us know the below :
1. What is the correct/recommended way to handle
UnregisteredBinaryTypeException
2. Considering that we are using FULL_SYNC mode, shouldnt this exception
have propagated to the client and prevent the record update rather than
cause data inconsistency between the server nodes for a REPLICATED cache.

What is the right way to handle any RunTimeExceptions ? Should we catch
these and propagate it to the clients ?

regards,
Veena.




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

[akurbanov]

Hello Veena,

Could you please attach a runnable reproducer project which will showcase
the issue and also could you please explain the difference between the case
where you do see this exception and the one where you don't.

What does exactly "We dont get this exception if we sync any single cache
alone" mean?

Best regards,
Anton



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

[VeenaMithare]

Hi Anton ,

Thank you for the reply,

We sync tables/caches in from a source db. i.e. we read all the records of a
table and insert/update records into the table/cache in ignite.

When the sync application runs just for a single table - we dont see the
unregisteredbinarytypeexception .

When we run sync for say 10 tables - where update of the 10 tables happen in
parallel through threads , we see this exception for a few records on some
server nodes.

I am not sure if this issue is happening because of the update load or
because there are multiple tables getting synced at the same time.

Please note each of the 10 tables are independent of each other ( i.e. when
we update one table, it doesnt affect the update of another table )

I read somewhere that this exception happens if registering metadata happens
while the topology is locked. I am not sure what 'topology locked' means.
There is no baseline topology change while these updates are taking place.

regards,
Veena.  



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

[VeenaMithare]

Hi Anton,

>>I read somewhere that this exception happens if registering metadata
happens
while the topology is locked.

Could you kindly help me understand this exception.

Also what is the right way to handle any runtimeexception within the entry
processor ? Is it by wrapping  it with an EntryProcessorException and
throwing the same,

regards,
Veena.



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