Re: BinaryObjectException

[Alex Plehanov]

Thin client before version 2.9 throws an exception when there is more
than one scheme with the same type name and compact footers are enabled.
The scheme is a set of field names of the object, so, using only one scheme
per type (if it's possible in your case) will solve the problem.
If you don't want to update Ignite server, you can update only thin client,
it will also solve the problem.

пн, 22 нояб. 2021 г. в 12:57, Naveen Kumar :

> Thanks Alex..
> Here it says it throws this exception when ignite does not find this record
> In our case, data exists and it get resolved if we do a node restart
>
> And, any work-around we have to fix this  issue with current version
> ignite 2.8.1
>
> Thanks
>
> On Mon, Nov 22, 2021 at 12:20 PM Alex Plehanov 
> wrote:
>
>> Hello!
>>
>> Most probably it's related to ticket [1] that is fixed in 2.9 release.
>>
>> [1]: https://issues.apache.org/jira/browse/IGNITE-13192
>>
>> пн, 22 нояб. 2021 г. в 03:11, Naveen Kumar :
>>
>>> Hi All
>>>
>>> We are using 2.8.1
>>> At times, we do get this BinaryObjectException while calling GETs thru
>>> thin client, we dont see any errors or exceptions on node logs, this only
>>> be seen on the cline tside.
>>> what could be the potential reason for this
>>>
>>> Attached the exact error message
>>>
>>>
>>>
>>>
>>> Thanks
>>>
>>> --
>>> Thanks & Regards,
>>> Naveen Bandaru
>>>
>>
>
> --
> Thanks & Regards,
> Naveen Bandaru
>

Re: BinaryObjectException

[Naveen Kumar]

Thanks Alex..
Here it says it throws this exception when ignite does not find this record
In our case, data exists and it get resolved if we do a node restart

And, any work-around we have to fix this  issue with current version ignite
2.8.1

Thanks

On Mon, Nov 22, 2021 at 12:20 PM Alex Plehanov 
wrote:

> Hello!
>
> Most probably it's related to ticket [1] that is fixed in 2.9 release.
>
> [1]: https://issues.apache.org/jira/browse/IGNITE-13192
>
> пн, 22 нояб. 2021 г. в 03:11, Naveen Kumar :
>
>> Hi All
>>
>> We are using 2.8.1
>> At times, we do get this BinaryObjectException while calling GETs thru
>> thin client, we dont see any errors or exceptions on node logs, this only
>> be seen on the cline tside.
>> what could be the potential reason for this
>>
>> Attached the exact error message
>>
>>
>>
>>
>> Thanks
>>
>> --
>> Thanks & Regards,
>> Naveen Bandaru
>>
>

-- 
Thanks & Regards,
Naveen Bandaru

Re: BinaryObjectException

[Alex Plehanov]

Hello!

Most probably it's related to ticket [1] that is fixed in 2.9 release.

[1]: https://issues.apache.org/jira/browse/IGNITE-13192

пн, 22 нояб. 2021 г. в 03:11, Naveen Kumar :

> Hi All
>
> We are using 2.8.1
> At times, we do get this BinaryObjectException while calling GETs thru
> thin client, we dont see any errors or exceptions on node logs, this only
> be seen on the cline tside.
> what could be the potential reason for this
>
> Attached the exact error message
>
>
>
>
> Thanks
>
> --
> Thanks & Regards,
> Naveen Bandaru
>

BinaryObjectException

[Naveen Kumar]

Hi All

We are using 2.8.1
At times, we do get this BinaryObjectException while calling GETs thru thin
client, we dont see any errors or exceptions on node logs, this only be
seen on the cline tside.
what could be the potential reason for this

Attached the exact error message




Thanks

-- 
Thanks & Regards,
Naveen Bandaru

Re: BinaryObjectException: Unsupported protocol version

[Alex Plehanov]

Hello,

Most probably it's related to [1], which is fixed since Ignite 2.9.1.

[1]: https://issues.apache.org/jira/browse/IGNITE-13401

чт, 19 авг. 2021 г. в 09:53, Naveen Kumar :

> Hi All
>
> We are using Ignite 2.8.1 and using the thin clients majorly.
> Facing a strange issues for last couple of days, all PUTs are working
> fine, but GETs are failing with a reason : BinaryObjectException:
> Unsupported protocol version.
>
> After the node restart, GETs started working fine, and dont see anything
> specific in the node logs as well.
>
> Any pointers towards this, how did the node restart resolved the issue.
>
> None of the GETs were working earlier only PUTs were working (PUTs were
> done thru JDBC SQL), GERs are using the Java KV API.
>
> --
> Thanks & Regards,
> Naveen Bandaru
>

BinaryObjectException: Unsupported protocol version

[Naveen Kumar]

Hi All

We are using Ignite 2.8.1 and using the thin clients majorly.
Facing a strange issues for last couple of days, all PUTs are working fine,
but GETs are failing with a reason : BinaryObjectException: Unsupported
protocol version.

After the node restart, GETs started working fine, and dont see anything
specific in the node logs as well.

Any pointers towards this, how did the node restart resolved the issue.

None of the GETs were working earlier only PUTs were working (PUTs were
done thru JDBC SQL), GERs are using the Java KV API.

-- 
Thanks & Regards,
Naveen Bandaru

Re: BinaryObjectException: Conflicting Enum Values

[Ilya Kasnacheev]

Hello!

I guess this information was stored somewhere and is causing conflicts now.
You can try dropping binary_meta/ directory from ignite work dir on all
nodes, hope that it would be repopulated all right. Make sure to back it up
first!

Regards,
-- 
Ilya Kasnacheev


чт, 25 февр. 2021 г. в 21:21, Mitchell Rathbun (BLOOMBERG/ 731 LEX) <
mrathb...@bloomberg.net>:

> We have recently been seeing the following error:
>
> SEVERE: Failed to serialize object
> [typeName=com.bloomberg.aim.wingman.cachemgr.Ts3DataCache$Ts3CalcrtKey]
> class org.apache.ignite.binary.BinaryObjectException: Failed to write
> field [name=calcrtType]
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.write(BinaryFieldAccessor.java:164)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:822)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:232)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:152)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:248)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:548)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:1403)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:1198)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:751)
> at
> com.bloomberg.aim.wingman.cachemgr.Ts3DataCache.lambda$null$29(Ts3DataCache.java:1457)
> at java.base/java.lang.Iterable.forEach(Iterable.java:75)
> at
> com.bloomberg.aim.wingman.cachemgr.Ts3DataCache.lambda$updateMetadataAsyncHelper$30(Ts3DataCache.java:1456)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class org.apache.ignite.binary.BinaryObjectException:
> Conflicting enum values. Name 'INT' uses ordinal value (2) that is also
> used for name 'INTEGER'
> [typeName='com.bloomberg.aim.wingman.common.dto.RealCalcrtFieldType']
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeEnumValues(BinaryUtils.java:2501)
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:1028)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport.requestMetadataUpdate(BinaryMetadataTransport.java:211)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:603)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.addMeta(CacheObjectBinaryProcessorImpl.java:285)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:764)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerDescriptor(BinaryContext.java:723)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClass(BinaryContext.java:581)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClass(BinaryContext.java:556)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteEnum(BinaryWriterExImpl.java:829)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.writeEnumField(BinaryWriterExImpl.java:1323)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write0(BinaryFieldAccessor.java:670)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.write(BinaryFieldAccessor.java:157)
> ... 16 more
>
>
> As part of the key in one of our classes, we have an enum, for which one
> of the values is INT. It used to be INTEGER, but that was like 5 months
> ago. Looking in this cache, there are multiple entries with INT being used,
> and none with INTEGER. So why are we still getting this error? Writes with
> INT have clearly worked in the past, and INTEGER is not in the cache and
> hasn't been used in a long time. We recently updated from 2.7.5 to 2.9.1 as
> well, not sure if that is related.
>
>

BinaryObjectException: Conflicting Enum Values

[Mitchell Rathbun (BLOOMBERG/ 731 LEX)]

We have recently been seeing the following error:

SEVERE: Failed to serialize object 
[typeName=com.bloomberg.aim.wingman.cachemgr.Ts3DataCache$Ts3CalcrtKey]
class org.apache.ignite.binary.BinaryObjectException: Failed to write field 
[name=calcrtType]
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor.write(BinaryFieldAccessor.java:164)
at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:822)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:232)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:152)
at 
org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:248)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:548)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:1403)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:1198)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:751)
at 
com.bloomberg.aim.wingman.cachemgr.Ts3DataCache.lambda$null$29(Ts3DataCache.java:1457)
at java.base/java.lang.Iterable.forEach(Iterable.java:75)
at 
com.bloomberg.aim.wingman.cachemgr.Ts3DataCache.lambda$updateMetadataAsyncHelper$30(Ts3DataCache.java:1456)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: class org.apache.ignite.binary.BinaryObjectException: Conflicting 
enum values. Name 'INT' uses ordinal value (2) that is also used for name 
'INTEGER' [typeName='com.bloomberg.aim.wingman.common.dto.RealCalcrtFieldType']
at 
org.apache.ignite.internal.binary.BinaryUtils.mergeEnumValues(BinaryUtils.java:2501)
at 
org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:1028)
at 
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport.requestMetadataUpdate(BinaryMetadataTransport.java:211)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:603)
at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.addMeta(CacheObjectBinaryProcessorImpl.java:285)
at 
org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:764)
at 
org.apache.ignite.internal.binary.BinaryContext.registerDescriptor(BinaryContext.java:723)
at 
org.apache.ignite.internal.binary.BinaryContext.registerClass(BinaryContext.java:581)
at 
org.apache.ignite.internal.binary.BinaryContext.registerClass(BinaryContext.java:556)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteEnum(BinaryWriterExImpl.java:829)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.writeEnumField(BinaryWriterExImpl.java:1323)
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write0(BinaryFieldAccessor.java:670)
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor.write(BinaryFieldAccessor.java:157)
... 16 more


As part of the key in one of our classes, we have an enum, for which one of the 
values is INT. It used to be INTEGER, but that was like 5 months ago. Looking 
in this cache, there are multiple entries with INT being used, and none with 
INTEGER. So why are we still getting this error? Writes with INT have clearly 
worked in the past, and INTEGER is not in the cache and hasn't been used in a 
long time. We recently updated from 2.7.5 to 2.9.1 as well, not sure if that is 
related.

Re: BinaryObjectException: Conflicting enum values

[Ilya Kasnacheev]

Hello!

Currently it is not implemented. Metadata will be preserver unless cluster
is restarted (in case persistence is enabled, unless it is cleared)

Regards,
-- 
Ilya Kasnacheev


вс, 7 июн. 2020 г. в 02:32, Andrew Munn :

> So once I insert an instance of a class in a Map I can't change the type
> of any existing member variable in the class, even if I clear the map?
> Seems like there should be some programatic way to clear any left-over
> class metadata/schema if simply clearing the cache won't do it. Right?
>
> On Sat, Jun 6, 2020 at 10:43 AM Denis Magda  wrote:
>
>> You might have hit the following specificity ("Cluster Doesn’t Start
>> After Field Type Changes") that happens if you change a type of a field:
>> https://www.gridgain.com/docs/latest/perf-troubleshooting-guide/troubleshooting#cluster-doesnt-start-after-field-type-changes
>>
>> -
>> Denis
>>
>>
>> On Fri, Jun 5, 2020 at 10:53 AM Andrew Munn  wrote:
>>
>>> I'm seeing the same issue as this one
>>> <http://apache-ignite-users.70518.x6.nabble.com/Help-needed-with-BinaryObjectException-td22938.html>
>>> .
>>>
>>> I had values in the cache.  I cleared the cache, but did not shutdown
>>> the cluster node.  I modified the enums in the class.  Then I repopulated
>>> the cache with instances of the updated class.  There must be some way to
>>> purge leftover metadata without bringing the cluster down, right?   Can it
>>> be purged when the cache is cleared?
>>>
>>> Thanks
>>>
>>>

Re: BinaryObjectException: Conflicting enum values

[Andrew Munn]

So once I insert an instance of a class in a Map I can't change the type of
any existing member variable in the class, even if I clear the map?
Seems like there should be some programatic way to clear any left-over
class metadata/schema if simply clearing the cache won't do it. Right?

On Sat, Jun 6, 2020 at 10:43 AM Denis Magda  wrote:

> You might have hit the following specificity ("Cluster Doesn’t Start After
> Field Type Changes") that happens if you change a type of a field:
> https://www.gridgain.com/docs/latest/perf-troubleshooting-guide/troubleshooting#cluster-doesnt-start-after-field-type-changes
>
> -
> Denis
>
>
> On Fri, Jun 5, 2020 at 10:53 AM Andrew Munn  wrote:
>
>> I'm seeing the same issue as this one
>> <http://apache-ignite-users.70518.x6.nabble.com/Help-needed-with-BinaryObjectException-td22938.html>
>> .
>>
>> I had values in the cache.  I cleared the cache, but did not shutdown the
>> cluster node.  I modified the enums in the class.  Then I repopulated the
>> cache with instances of the updated class.  There must be some way to purge
>> leftover metadata without bringing the cluster down, right?   Can it be
>> purged when the cache is cleared?
>>
>> Thanks
>>
>>

Re: BinaryObjectException: Conflicting enum values

[Denis Magda]

You might have hit the following specificity ("Cluster Doesn’t Start After
Field Type Changes") that happens if you change a type of a field:
https://www.gridgain.com/docs/latest/perf-troubleshooting-guide/troubleshooting#cluster-doesnt-start-after-field-type-changes

-
Denis


On Fri, Jun 5, 2020 at 10:53 AM Andrew Munn  wrote:

> I'm seeing the same issue as this one
> <http://apache-ignite-users.70518.x6.nabble.com/Help-needed-with-BinaryObjectException-td22938.html>
> .
>
> I had values in the cache.  I cleared the cache, but did not shutdown the
> cluster node.  I modified the enums in the class.  Then I repopulated the
> cache with instances of the updated class.  There must be some way to purge
> leftover metadata without bringing the cluster down, right?   Can it be
> purged when the cache is cleared?
>
> Thanks
>
>

BinaryObjectException: Conflicting enum values

[Andrew Munn]

I'm seeing the same issue as this one
<http://apache-ignite-users.70518.x6.nabble.com/Help-needed-with-BinaryObjectException-td22938.html>
.

I had values in the cache.  I cleared the cache, but did not shutdown the
cluster node.  I modified the enums in the class.  Then I repopulated the
cache with instances of the updated class.  There must be some way to purge
leftover metadata without bringing the cluster down, right?   Can it be
purged when the cache is cleared?

Thanks

Re: SQL Error [08006]: Failed to communicate with Ignite cluster <-- BinaryObjectException: Not enough data to read the value

[Joshua Taylor]

It's the same stacktrace as in the original post from Devin (just with a
different value for position in the cause). The Ignite instance I'm
connecting to is v2.7.6.

org.jkiss.dbeaver.model.sql.DBSQLException: SQL Error [08006]: Failed
to communicate with Ignite cluster.
at 
org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.executeStatement(JDBCStatementImpl.java:134)
at 
org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.executeStatement(SQLQueryJob.java:491)
at 
org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.lambda$0(SQLQueryJob.java:426)
at 
org.jkiss.dbeaver.model.exec.DBExecUtils.tryExecuteRecover(DBExecUtils.java:170)
at 
org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.executeSingleQuery(SQLQueryJob.java:418)
at 
org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.extractData(SQLQueryJob.java:778)
at 
org.jkiss.dbeaver.ui.editors.sql.SQLEditor$QueryResultsContainer.readData(SQLEditor.java:2942)
at 
org.jkiss.dbeaver.ui.controls.resultset.ResultSetJobDataRead.lambda$0(ResultSetJobDataRead.java:111)
at 
org.jkiss.dbeaver.model.exec.DBExecUtils.tryExecuteRecover(DBExecUtils.java:170)
at 
org.jkiss.dbeaver.ui.controls.resultset.ResultSetJobDataRead.run(ResultSetJobDataRead.java:109)
at 
org.jkiss.dbeaver.ui.controls.resultset.ResultSetViewer$17.run(ResultSetViewer.java:3478)
at org.jkiss.dbeaver.model.runtime.AbstractJob.run(AbstractJob.java:103)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.sql.SQLException: Failed to communicate with Ignite cluster.
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:916)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:231)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:559)
at 
org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.execute(JDBCStatementImpl.java:338)
at 
org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.executeStatement(JDBCStatementImpl.java:131)
... 12 more
Caused by: class org.apache.ignite.binary.BinaryObjectException: Not
enough data to read the value [position=4016, requiredBytes=1,
remainingBytes=0]
at 
org.apache.ignite.internal.binary.streams.BinaryAbstractInputStream.ensureEnoughData(BinaryAbstractInputStream.java:305)
at 
org.apache.ignite.internal.binary.streams.BinaryAbstractInputStream.readByte(BinaryAbstractInputStream.java:35)
at 
org.apache.ignite.internal.binary.streams.BinaryAbstractInputStream.readBoolean(BinaryAbstractInputStream.java:53)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.readBoolean(BinaryReaderExImpl.java:548)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcQueryExecuteResult.readBinary(JdbcQueryExecuteResult.java:167)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcResult.readResult(JdbcResult.java:207)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcResponse.readBinary(JdbcResponse.java:153)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinTcpIo.readResponse(JdbcThinTcpIo.java:451)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinTcpIo.sendRequest(JdbcThinTcpIo.java:423)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:890)
... 16 more


On Thu, Apr 9, 2020 at 1:08 AM Denis Magda  wrote:

> What’s the exception you see in DBeaver?
>
> Denis
>
> On Wednesday, April 8, 2020, waterwagen  wrote:
>
>> I had the exact same error with select statements submitted from DBeaver
>> 7.0.2, which comes with ignite-core 2.8.0.
>>
>> I solved the problem by updating the Ignite driver settings in DBeaver to
>> downgrade to ignite-core 2.7.6.
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>
>
> --
> -
> Denis
>
>

Re: SQL Error [08006]: Failed to communicate with Ignite cluster <-- BinaryObjectException: Not enough data to read the value

[VeenaMithare]

Do you have security enabled in your project ? I think sqls not being able to
run on dbeaver is a known issue on 2.8.0 for security enabled projects : 

https://issues.apache.org/jira/browse/IGNITE-12833




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

Re: SQL Error [08006]: Failed to communicate with Ignite cluster <-- BinaryObjectException: Not enough data to read the value

[Denis Magda]

What’s the exception you see in DBeaver?

Denis

On Wednesday, April 8, 2020, waterwagen  wrote:

> I had the exact same error with select statements submitted from DBeaver
> 7.0.2, which comes with ignite-core 2.8.0.
>
> I solved the problem by updating the Ignite driver settings in DBeaver to
> downgrade to ignite-core 2.7.6.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>


-- 
-
Denis

Re: SQL Error [08006]: Failed to communicate with Ignite cluster <-- BinaryObjectException: Not enough data to read the value

[waterwagen]

I had the exact same error with select statements submitted from DBeaver
7.0.2, which comes with ignite-core 2.8.0.

I solved the problem by updating the Ignite driver settings in DBeaver to
downgrade to ignite-core 2.7.6. 



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

Re: SQL Error [08006]: Failed to communicate with Ignite cluster <-- BinaryObjectException: Not enough data to read the value

[Devin Bost]

It turns out that I still get the SQL SELECT error even when using Ignite
2.8.0.

Devin G. Bost


On Tue, Mar 10, 2020 at 3:19 PM Devin Bost  wrote:

> Hi Denis,
>
> Thanks for the information! I think it was just my IntelliJ that was
> complaining for no reason. I ran `mvn clean install`, and it pulled the
> package for me.
>
> Devin G. Bost
>
>
> On Tue, Mar 10, 2020 at 2:59 PM Denis Magda  wrote:
>
>> Hi Devin,
>>
>> I can see the latest Ignite artifacts in Maven:
>> https://search.maven.org/search?q=a:ignite-core
>>
>> Are you missing any particular package?
>>
>> -
>> Denis
>>
>>
>> On Tue, Mar 10, 2020 at 11:48 AM Devin Bost  wrote:
>>
>>> Hi Andrei,
>>>
>>> Thanks for the information. Do you know anything about when Ignite 2.8
>>> will be released? It looks like the Maven packages are unavailable.
>>>
>>> Devin G. Bost
>>>
>>>
>>> On Tue, Mar 10, 2020 at 4:17 AM aealexsandrov 
>>> wrote:
>>>
 Hi,

 Can you please test the Apache Ignite 2.8. It should contain the
 following
 fix:

 https://issues.apache.org/jira/browse/IGNITE-11953

 BR,
 Andrei



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

>>>

Re: SQL Error [08006]: Failed to communicate with Ignite cluster <-- BinaryObjectException: Not enough data to read the value

[Devin Bost]

Hi Denis,

Thanks for the information! I think it was just my IntelliJ that was
complaining for no reason. I ran `mvn clean install`, and it pulled the
package for me.

Devin G. Bost


On Tue, Mar 10, 2020 at 2:59 PM Denis Magda  wrote:

> Hi Devin,
>
> I can see the latest Ignite artifacts in Maven:
> https://search.maven.org/search?q=a:ignite-core
>
> Are you missing any particular package?
>
> -
> Denis
>
>
> On Tue, Mar 10, 2020 at 11:48 AM Devin Bost  wrote:
>
>> Hi Andrei,
>>
>> Thanks for the information. Do you know anything about when Ignite 2.8
>> will be released? It looks like the Maven packages are unavailable.
>>
>> Devin G. Bost
>>
>>
>> On Tue, Mar 10, 2020 at 4:17 AM aealexsandrov 
>> wrote:
>>
>>> Hi,
>>>
>>> Can you please test the Apache Ignite 2.8. It should contain the
>>> following
>>> fix:
>>>
>>> https://issues.apache.org/jira/browse/IGNITE-11953
>>>
>>> BR,
>>> Andrei
>>>
>>>
>>>
>>> --
>>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>>
>>

Re: SQL Error [08006]: Failed to communicate with Ignite cluster <-- BinaryObjectException: Not enough data to read the value

[Denis Magda]

Hi Devin,

I can see the latest Ignite artifacts in Maven:
https://search.maven.org/search?q=a:ignite-core

Are you missing any particular package?

-
Denis


On Tue, Mar 10, 2020 at 11:48 AM Devin Bost  wrote:

> Hi Andrei,
>
> Thanks for the information. Do you know anything about when Ignite 2.8
> will be released? It looks like the Maven packages are unavailable.
>
> Devin G. Bost
>
>
> On Tue, Mar 10, 2020 at 4:17 AM aealexsandrov 
> wrote:
>
>> Hi,
>>
>> Can you please test the Apache Ignite 2.8. It should contain the following
>> fix:
>>
>> https://issues.apache.org/jira/browse/IGNITE-11953
>>
>> BR,
>> Andrei
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>

Re: SQL Error [08006]: Failed to communicate with Ignite cluster <-- BinaryObjectException: Not enough data to read the value

[Devin Bost]

Hi Andrei,

Thanks for the information. Do you know anything about when Ignite 2.8 will
be released? It looks like the Maven packages are unavailable.

Devin G. Bost


On Tue, Mar 10, 2020 at 4:17 AM aealexsandrov 
wrote:

> Hi,
>
> Can you please test the Apache Ignite 2.8. It should contain the following
> fix:
>
> https://issues.apache.org/jira/browse/IGNITE-11953
>
> BR,
> Andrei
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: SQL Error [08006]: Failed to communicate with Ignite cluster <-- BinaryObjectException: Not enough data to read the value

[aealexsandrov]

Hi,

Can you please test the Apache Ignite 2.8. It should contain the following
fix:

https://issues.apache.org/jira/browse/IGNITE-11953

BR,
Andrei



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

SQL Error [08006]: Failed to communicate with Ignite cluster <-- BinaryObjectException: Not enough data to read the value

[Devin Bost]

I created a plugin that implements GridSecurityProcessor because our
implementation requries very specialized authorization; but now, whenever I
try to run a SQL SELECT query on Ignite over JDBC,
`AuthorizationProcessor.authenticate(..)` is run many times, like this:

```
Running AuthorizationPluginProvider.createCacheProvider(..)
Running AuthorizationPluginProvider.createComponent(..)
Running AuthorizationPluginProvider.createCacheProvider(..)
Running AuthorizationPluginProvider.createComponent(..)
// Initial setup completed
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
Running AuthorizationProcessor.enabled()
Running AuthorizationProcessor.authenticate(..)
Username is: ignite
```

and then my JDBC client (using DBeaver as my client with a JDBC Ignite
driver) gives me this error:

```org.jkiss.dbeaver.model.sql.DBSQLException: SQL Error [08006]: Failed to
communicate with Ignite cluster.
at
org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.executeStatement(JDBCStatementImpl.java:134)
at
org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.executeStatement(SQLQueryJob.java:488)
at
org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.lambda$0(SQLQueryJob.java:425)
at
org.jkiss.dbeaver.model.exec.DBExecUtils.tryExecuteRecover(DBExecUtils.java:170)
at
org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.executeSingleQuery(SQLQueryJob.java:417)
at
org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.extractData(SQLQueryJob.java:775)
at
org.jkiss.dbeaver.ui.editors.sql.SQLEditor$QueryResultsContainer.readData(SQLEditor.java:2914)
at
org.jkiss.dbeaver.ui.controls.resultset.ResultSetJobDataRead.lambda$0(ResultSetJobDataRead.java:111)
at
org.jkiss.dbeaver.model.exec.DBExecUtils.tryExecuteRecover(DBExecUtils.java:170)
at
org.jkiss.dbeaver.ui.controls.resultset.ResultSetJobDataRead.run(ResultSetJobDataRead.java:109)
at
org.jkiss.dbeaver.ui.controls.resultset.ResultSetViewer$17.run(ResultSetViewer.java:3423)
at org.jkiss.dbeaver.model.runtime.AbstractJob.run(AbstractJob.java:103)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.sql.SQLException: Failed to communicate with Ignite cluster.
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:916)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:231)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:559)
at
org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.execute(JDBCStatementImpl.java:338)
at
org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.executeStatement(JDBCStatementImpl.java:131)
... 12 more
Caused by: class org.apache.ignite.binary.BinaryObjectException: Not enough
data to read the value [position=20, requiredBytes=1, remainingBytes=0]
at
org.apache.ignite.internal.binary.streams.BinaryAbstractInputStream.ensureEnoughData(BinaryAbstractInputStream.java:305)
at
org.apache.ignite.internal.binary.streams.BinaryAbstractInputStream.readByte(BinaryAbstractInputStream.java:35)
at

Re: ICacheEntryProcessor throws BinaryObjectException when WRITE_SYNCHRONIZATION_MODE=FULL_ASYNC

[Ilya Kasnacheev]

Hello!

Can you please share a full reproducer project (using Github for example)?
This way people who don't have strong .Net skills can still participate in
solution.

Regards,
-- 
Ilya Kasnacheev


вт, 28 авг. 2018 г. в 21:50, crenique :

> Hi, We are testing WRITE_SYNCHRONIZATION_MODE=FULL_ASYNC mode to compare
> performance to PRIMARY_SYNC. These same code works fine in PRIMARY_SYNC,
> but it throws BinaryObjectException on FULL_ASYNC mode. Would you please
> recommend any way to fix this issue ? Thanks! *Environment: * ignite 2.6
> jdk 8 Windows C# ignite.net *Cache creation: * CREATE TABLE IF NOT EXISTS
> UserDataCache ( CacheKey VARCHAR, AffinityKey LONG, LastUpdated TIMESTAMP,
> Data VARBINARY(MAX), PRIMARY KEY (CacheKey, AffinityKey) ) WITH
> ""BACKUPS=2, TEMPLATE=UserDataCache, WRITE_SYNCHRONIZATION_MODE=FULL_ASYNC,
> AFFINITYKEY=AffinityKey, VALUE_TYPE=UserData"" *Cache EntryProcessor for
> data upsert* [Serializable] public class UserDataUpsertEntryProcessor :
> ICacheEntryProcessor { public int
> Process(IMutableCacheEntry entry, UserData addVal) {
> if (entry.Exists) { var updateVal = entry.Value; updateVal.LastUpdated =
> DateTime.UtcNow; updateVal.Data = addVal.Data; entry.Value = updateVal;
> return 1; } else { entry.Value = addVal; return 0; } } } *call Invoke*
> await cache.Invoke(key, new StateDataUpsertEntryProcessor(), userData); 
> *BinaryObjectException
> on FULL_ASYNC mode*
> \Ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Binary\BinaryReader.cs,
> Ln 537 BinaryObjectException: Invalid data on deserialization. Expected:
> 'System.Int32' But was: null
> --
> Sent from the Apache Ignite Users mailing list archive
> <http://apache-ignite-users.70518.x6.nabble.com/> at Nabble.com.
>

ICacheEntryProcessor throws BinaryObjectException when WRITE_SYNCHRONIZATION_MODE=FULL_ASYNC

[crenique]

Hi,  We are testing WRITE_SYNCHRONIZATION_MODE=FULL_ASYNC mode to compare
performance to PRIMARY_SYNC.These same code works fine in PRIMARY_SYNC, but
it throws BinaryObjectException on FULL_ASYNC  mode.  Would you please
recommend any way to fix this issue ?Thanks!*Environment: * ignite 2.6 jdk 8 
Windows C# ignite.net*Cache creation: *CREATE TABLE IF NOT EXISTS
UserDataCache(CacheKey VARCHAR,AffinityKey LONG,LastUpdated
TIMESTAMP,Data VARBINARY(MAX),PRIMARY KEY (CacheKey,
AffinityKey))WITH ""BACKUPS=2, TEMPLATE=UserDataCache,
WRITE_SYNCHRONIZATION_MODE=FULL_ASYNC, AFFINITYKEY=AffinityKey,
VALUE_TYPE=UserData""*Cache EntryProcessor for data
upsert*[Serializable]public class UserDataUpsertEntryProcessor :
ICacheEntryProcessor{public int
Process(IMutableCacheEntry entry, UserData addVal)   
{if (entry.Exists){var updateVal = entry.Value; 
  
updateVal.LastUpdated = DateTime.UtcNow;updateVal.Data =
addVal.Data;entry.Value = updateVal;return 1;   
}else{entry.Value = addVal;return 0;
   
}}}*call Invoke*await cache.Invoke(key, new
StateDataUpsertEntryProcessor(), userData);*BinaryObjectException on
FULL_ASYNC
mode*\Ignite\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Binary\BinaryReader.cs,
Ln 537BinaryObjectException: Invalid data on deserialization. Expected:
'System.Int32' But was: null



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

Re: Help needed with BinaryObjectException

[ilya.kasnacheev]

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

[Roger Janssen]

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

[Roger Janssen]

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

[vkulichenko]

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

[Dave Harvey]

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 
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.

Help needed with BinaryObjectException

[Roger Janssen]

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: Getting "BinaryObjectException: Failed to deserialize object" while trying to execute the application using multi node

[vkulichenko]

Michael,

There is no much detail to add. Although it's technically possible to
serialize lambdas and anonymous classes, it's usually not recommended, as
they can reference some objects from outside. If these objects are not
serializable (or not intended to be serialized), you're likely to get errors
and performance issues that are not easy to isolate.

To be on safe side it's better to use static classes instead for anything
that is serialized and sent across network. That gives you full control and
therefore this approach is less error-prone.

-Val



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

Re: Getting "BinaryObjectException: Failed to deserialize object" while trying to execute the application using multi node

[Michael Jay]

Hi, val. I just met with the same problem. Would you mind giving more
detailed solutions? thanks



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

Re: Upgrade from 2.2.0 to 2.3.0 problem with BinaryObjectException

[Denis Mekhanikov]

Oh, looks like this problem is already fixed:
https://issues.apache.org/jira/browse/IGNITE-6944
I checked, your project works, when Ignite from current master is used.

So, you can just wiat for the next release and switch to it.

Denis

ср, 20 дек. 2017 г. в 13:10, Denis Mekhanikov :

> Hi Łukasz!
>
> This problem is caused by *@Cacheable* annotation on 
> *SampleRepo#getSampleEntity()
> *method.
> When you invoke it for the first time, its result is put into an Ignite
> cache. And for the second time the result is just taken from the cache, you
> probably know that.
>
> The problem is that *SampleEntity* contains a *key* field, which
> internally uses *SingletonImmutableList* class. This class has
> *writeReplace()* method, that alters the serialization. I guess, that
> lookup for this method was broken for *BinaryMarshaller* in 2.3 release.
>
> *SingletonImmutableList* has a transient field *element*. When you put
> this value into a cache, it is serialized, and value of this field is
> omitted. When you get this value from cache, this field is null, which
> causes the NPE.
>
> But actually this class should be serialized, using *writeReplace()*
> method. It works fine if you change marshaller to Optimized. To do it, add
> the following line to *CacheConfig#provideDevIgniteConfiguration():*
>
> cfg.setMarshaller(new OptimizedMarshaller(false));
>
> Note, that Optimized marshaller actually has a number of restrictions.
> Features like IgniteCache.withKeepBinary(), .NET, C++, ODBC won't work with
> it. It may also affect performance, especially if you use SQL.
>
> I'll investigate this problem further. I hope, it will be fixed by 2.4
> release.
>
> Denis
>
> вт, 19 дек. 2017 г. в 0:37, lukaszbyjos :
>
>> I have created repo for this error to easier recreate.
>>
>> https://github.com/Mistic92/ignite-bug
>>
>> When using 2.2.0 everything is ok. But after update to 2.3.0 I get error
>>
>> Caused by: org.apache.ignite.binary.BinaryObjectException: Failed to read
>> field [name=]
>> at
>>
>> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:168)
>> ~[ignite-core-2.3.0.jar:2.3.0]
>> at
>>
>> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843)
>> ~[ignite-core-2.3.0.jar:2.3.0]
>> ... 135 more
>> Caused by: java.lang.NullPointerException
>> at
>> com.google.common.collect.ImmutableList.hashCode(ImmutableList.java:571)
>> ~[guava-20.0.jar:?]
>> at java.util.Arrays.hashCode(Arrays.java:4146) ~[?:1.8.0_152]
>> at java.util.Objects.hash(Objects.java:128) ~[?:1.8.0_152]
>> at com.google.cloud.datastore.BaseKey.hashCode(BaseKey.java:204)
>> ~[google-cloud-datastore-1.8.0.jar:1.8.0]
>> at
>>
>> com.jmethods.catatumbo.DefaultDatastoreKey.hashCode(DefaultDatastoreKey.java:134)
>> ~[catatumbo-catatumbo-2.4.0.jar:2.4.0]
>> at java.util.HashMap.hash(HashMap.java:339) ~[?:1.8.0_152]
>> at java.util.HashMap.put(HashMap.java:612) ~[?:1.8.0_152]
>> at java.util.HashSet.add(HashSet.java:220) ~[?:1.8.0_152]
>> at
>>
>> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2093)
>> ~[ignite-core-2.3.0.jar:2.3.0]
>> at
>>
>> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
>> ~[ignite-core-2.3.0.jar:2.3.0]
>> at
>>
>> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>> ~[ignite-core-2.3.0.jar:2.3.0]
>> at
>>
>> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
>> ~[ignite-core-2.3.0.jar:2.3.0]
>> at
>>
>> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:679)
>> ~[ignite-core-2.3.0.jar:2.3.0]
>> at
>>
>> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164)
>> ~[ignite-core-2.3.0.jar:2.3.0]
>> at
>>
>> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843)
>> ~[ignite-core-2.3.0.jar:2.3.0]
>> ... 135 more
>>
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>

Re: Upgrade from 2.2.0 to 2.3.0 problem with BinaryObjectException

[Denis Mekhanikov]

Hi Łukasz!

This problem is caused by *@Cacheable* annotation on
*SampleRepo#getSampleEntity()
*method.
When you invoke it for the first time, its result is put into an Ignite
cache. And for the second time the result is just taken from the cache, you
probably know that.

The problem is that *SampleEntity* contains a *key* field, which internally
uses *SingletonImmutableList* class. This class has *writeReplace()* method,
that alters the serialization. I guess, that lookup for this method was
broken for *BinaryMarshaller* in 2.3 release.

*SingletonImmutableList* has a transient field *element*. When you put this
value into a cache, it is serialized, and value of this field is omitted.
When you get this value from cache, this field is null, which causes the
NPE.

But actually this class should be serialized, using *writeReplace()*
method. It works fine if you change marshaller to Optimized. To do it, add
the following line to *CacheConfig#provideDevIgniteConfiguration():*

cfg.setMarshaller(new OptimizedMarshaller(false));

Note, that Optimized marshaller actually has a number of restrictions.
Features like IgniteCache.withKeepBinary(), .NET, C++, ODBC won't work with
it. It may also affect performance, especially if you use SQL.

I'll investigate this problem further. I hope, it will be fixed by 2.4
release.

Denis

вт, 19 дек. 2017 г. в 0:37, lukaszbyjos :

> I have created repo for this error to easier recreate.
>
> https://github.com/Mistic92/ignite-bug
>
> When using 2.2.0 everything is ok. But after update to 2.3.0 I get error
>
> Caused by: org.apache.ignite.binary.BinaryObjectException: Failed to read
> field [name=]
> at
>
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:168)
> ~[ignite-core-2.3.0.jar:2.3.0]
> at
>
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843)
> ~[ignite-core-2.3.0.jar:2.3.0]
> ... 135 more
> Caused by: java.lang.NullPointerException
> at
> com.google.common.collect.ImmutableList.hashCode(ImmutableList.java:571)
> ~[guava-20.0.jar:?]
> at java.util.Arrays.hashCode(Arrays.java:4146) ~[?:1.8.0_152]
> at java.util.Objects.hash(Objects.java:128) ~[?:1.8.0_152]
> at com.google.cloud.datastore.BaseKey.hashCode(BaseKey.java:204)
> ~[google-cloud-datastore-1.8.0.jar:1.8.0]
> at
>
> com.jmethods.catatumbo.DefaultDatastoreKey.hashCode(DefaultDatastoreKey.java:134)
> ~[catatumbo-catatumbo-2.4.0.jar:2.4.0]
> at java.util.HashMap.hash(HashMap.java:339) ~[?:1.8.0_152]
> at java.util.HashMap.put(HashMap.java:612) ~[?:1.8.0_152]
> at java.util.HashSet.add(HashSet.java:220) ~[?:1.8.0_152]
> at
>
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2093)
> ~[ignite-core-2.3.0.jar:2.3.0]
> at
>
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> ~[ignite-core-2.3.0.jar:2.3.0]
> at
>
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> ~[ignite-core-2.3.0.jar:2.3.0]
> at
>
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
> ~[ignite-core-2.3.0.jar:2.3.0]
> at
>
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:679)
> ~[ignite-core-2.3.0.jar:2.3.0]
> at
>
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164)
> ~[ignite-core-2.3.0.jar:2.3.0]
> at
>
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843)
> ~[ignite-core-2.3.0.jar:2.3.0]
> ... 135 more
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Upgrade from 2.2.0 to 2.3.0 problem with BinaryObjectException

[lukaszbyjos]

I have created repo for this error to easier recreate.

https://github.com/Mistic92/ignite-bug

When using 2.2.0 everything is ok. But after update to 2.3.0 I get error 

Caused by: org.apache.ignite.binary.BinaryObjectException: Failed to read
field [name=]
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:168)
~[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843)
~[ignite-core-2.3.0.jar:2.3.0]
... 135 more
Caused by: java.lang.NullPointerException
at 
com.google.common.collect.ImmutableList.hashCode(ImmutableList.java:571)
~[guava-20.0.jar:?]
at java.util.Arrays.hashCode(Arrays.java:4146) ~[?:1.8.0_152]
at java.util.Objects.hash(Objects.java:128) ~[?:1.8.0_152]
at com.google.cloud.datastore.BaseKey.hashCode(BaseKey.java:204)
~[google-cloud-datastore-1.8.0.jar:1.8.0]
at
com.jmethods.catatumbo.DefaultDatastoreKey.hashCode(DefaultDatastoreKey.java:134)
~[catatumbo-catatumbo-2.4.0.jar:2.4.0]
at java.util.HashMap.hash(HashMap.java:339) ~[?:1.8.0_152]
at java.util.HashMap.put(HashMap.java:612) ~[?:1.8.0_152]
at java.util.HashSet.add(HashSet.java:220) ~[?:1.8.0_152]
at
org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2093)
~[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
~[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
~[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
~[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:679)
~[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164)
~[ignite-core-2.3.0.jar:2.3.0]
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843)
~[ignite-core-2.3.0.jar:2.3.0]
... 135 more




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

Getting "BinaryObjectException: Failed to deserialize object" while trying to execute the application using multi node

[Rajarshi Pain]

Hi,

I am getting an exception while we are trying to check how it working on
ignite remote node (same physical server).

This application is working fine when we are running it on local node.
tried all possible way to fix it still not getting why we are getting this
exception.

Please help me to find out the root cause and fix it.

 Sorry can not share the code as it's on client machine ***

Sample Code used: (both Ignite node are using same config file)

IgniteCompute compute = ignite.compute(ignite.cluster().forRemotes());
compute.broadcast(() -> method_name());



Error Details:

class org.apache.ignite.binary.BinaryObjectException: Failed to deserialize
object
[typeName=org.apache.ignite.internal.processors.closure.GridClosureProcessor$C4]
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9795)
at
org.apache.ignite.internal.processors.job.GridJobWorker.initialize(GridJobWorker.java:438)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1109)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1913)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
deserialize object [typeName=java.lang.invoke.SerializedLambda]
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1799)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readObject(BinaryReaderExImpl.java:1329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C4.readBinary(GridClosureProcessor.java:1959)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:833)
... 16 more
Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
read field [name=capturedArgs]
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:168)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:843)
... 22 more
Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
deserialize object
[typeName=com.tcs.bancs.rtr.clearing.ifc.KafkaFileConsumer]
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1799)
at
org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2162)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadObjectArray(BinaryUtils.java:2021)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readObjectArray(BinaryReaderExImpl.java:1360)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readObjectArray(BinaryReaderExImpl.java:1353)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:842)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:679)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:164)
... 23 more
Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
read field [name=consumer]
at

Re: BinaryObjectException after Ignite restarts

[dmitry.parkhonin]

Vladislav,

Actually I don't know the exact object that causes the deserialization
problem. For me it looks like a remote call fails.
If I have to use some workaround, I prefer switching off the compact
footers.

Dmitry.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/BinaryObjectException-after-Ignite-restarts-tp9552p9596.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: BinaryObjectException after Ignite restarts

[dkarachentsev]

Hi,

This could be if in client discovery configuration only one server node
address set, that is restarted. In this case clients are unsuccessful in
connecting to stopped node and are shutting down.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/BinaryObjectException-after-Ignite-restarts-tp9552p9592.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: BinaryObjectException after Ignite restarts

[dmitry.parkhonin]

Hi val (valery? :)),

Thanks for reply.

Yes, switching off compact footer helped me in this case.
But the whole issue seems strange - my client stops working after a single
node cluster is restarted. To make the whole system working I have to
restart all my clients.
Is this the behavior that is expected?

Regards,
Dmitry.




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/BinaryObjectException-after-Ignite-restarts-tp9552p9588.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: BinaryObjectException after Ignite restarts

[vkulichenko]

Dmitry,

Basically this exception means that you tried to deserialize a binary object
that was never serialized on this cluster. When a type is serialized for the
first time, Ignite saves the meta data for this type in a system cache, so
once you deserialize this object (potentially on a different node), Ignite
can lookup this meta in this cache.

This exception usually happens when a serialized binary object is saved
somewhere externally (e.g., as a blob in database), then cluster is
restarted (all metadata in system cache is lost), object is loaded back and
deserialized. Since we loaded it in binary form, it was never serialized on
this brand new cluster and we don't have metadata, thus the error. If this
is your case, then this is expected behavior and switching off compact
footer is the correct way to fix it.

-val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/BinaryObjectException-after-Ignite-restarts-tp9552p9566.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: BinaryObjectException after Ignite restarts

[vdpyatkov]

Hi,

Could you please provide a reproduction example?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/BinaryObjectException-after-Ignite-restarts-tp9552p9558.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

BinaryObjectException after Ignite restarts

[dmitry.parkhonin]

Hi everyone!

I have the problem that is very similar to  IGNITE-3618
<https://issues.apache.org/jira/browse/IGNITE-3618>  . 
It is said that the issue was fixed in 1.8, but I still can see the problem
on the latest Ignite version.

The problem is that after the whole Ignite cluster is restarted I cannot
execute my compute task and get the following exception:



The workaround for this is to switch off compact footers in Ignite
configuration:


But I suppose it slows down the communication, right?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/BinaryObjectException-after-Ignite-restarts-tp9552.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: BinaryObjectException: Binary type has different field types

[vkulichenko]

Hi Yuci,

This is correct behavior, Ignite does not allow to change the type of
existing field. This is because you can have instances of two versions at
the same time, and after such change you will not be able to deserialize old
object on new node or other way around. You can add new fields though.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/BinaryObjectException-Binary-type-has-different-field-types-tp8287p8301.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.