You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by VeenaMithare <v....@cmcmarkets.com> on 2021/02/09 16:01:36 UTC
Right Handling of UnRegisteredBinaryObjectTypeException
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/
Re: Right Handling of UnRegisteredBinaryObjectTypeException
Posted by andrei <ae...@gmail.com>.
Hi,
Answer was provided here -
http://apache-ignite-users.70518.x6.nabble.com/2-8-1-CacheEntryProcessor-for-insert-update-within-Transaction-supported-tt35918.html
BR,
Andrei
4/20/2021 3:50 PM, VeenaMithare пишет:
> Hello all,
>
> Please guide me on the right way to use cacheentryprocessor within a
> transaction to update cache records .
>
> As shown in the example above, insert of a new record always throws
> UnregisteredBinaryTypeException - unless a metadata is registered on the
> client side before starting the transaction.
>
> regards,
> Veena.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Right Handling of UnRegisteredBinaryObjectTypeException
Posted by VeenaMithare <v....@cmcmarkets.com>.
Hello all,
Please guide me on the right way to use cacheentryprocessor within a
transaction to update cache records .
As shown in the example above, insert of a new record always throws
UnregisteredBinaryTypeException - unless a metadata is registered on the
client side before starting the transaction.
regards,
Veena.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Right Handling of UnRegisteredBinaryObjectTypeException
Posted by VeenaMithare <v....@cmcmarkets.com>.
Hello,
Did anyone get a chance to look at this ?
Also I noticed that I can skip the execution of the entry processor if it is
executing on the client side ( could pass a variable that identifies where
it runs ) .
i.e. at the start of the entry processor put something like
public Object process(MutableEntry<BinaryObject, BinaryObject>
entry,
Object... arguments) throws EntryProcessorException {
if ( execution is on a client node )
{
return;
}
....
return ;
}
This avoids the time taken for the entry processor to execute on the client
side.
It ensures that the entry processor runs only the serverside and updates the
desired records.
Kindly guide if this approach is acceptable or will it have any other side
effects.
regards,
Veena
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Right Handling of UnRegisteredBinaryObjectTypeException
Posted by VeenaMithare <v....@cmcmarkets.com>.
Hi Anton,
Did you get a chance to look at this ?
regards,
Veena.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Right Handling of UnRegisteredBinaryObjectTypeException
Posted by VeenaMithare <v....@cmcmarkets.com>.
Hi Anton,
Please find a sample project with one of the
'unregisteredbinarytypeexception' . The readme.txt is present in the
attached zip.
TestProject.zip
<http://apache-ignite-users.70518.x6.nabble.com/file/t2757/TestProject.zip>
As mentioned in the readme.txt , the behaviour noticed is as below :
1. Run the UpdateClientNotWorking - insert of a record through entry
processor doesnt work.
2. Run the UpdateClientWorking - insert of a record through entry processor
works. This is because we do a dummy registration of metadata on the client
side before the entryprocessor is invoked within the transaction.
Questions are as below :
1. Why does the entry processor run in the client side ? As per the
definition of entry processor - it is used to execute updates on entries on
the nodes that store it . TestProject.zip
https://ignite.apache.org/docs/latest/distributed-computing/collocated-computations#entry-processor
2. Because of point 1, when we execute a transaction of say 1000 records, we
need to give a huge timeout value - since most of the time of the
transaction is spent in the client execution of the entry processor . Is
there any workaround for this ?
regards,
Veena.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Re: Right Handling of UnRegisteredBinaryObjectTypeException
Posted by VeenaMithare <v....@cmcmarkets.com>.
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/
Re: Right Handling of UnRegisteredBinaryObjectTypeException
Posted by VeenaMithare <v....@cmcmarkets.com>.
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/
Re: Right Handling of UnRegisteredBinaryObjectTypeException
Posted by akurbanov <an...@gmail.com>.
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/