Removing my own serializer yields:
org.apache.ignite.binary.BinaryObjectException: "Failed to serialize
object [typeName=org.apache.ignite.util.deque.FastSizeDeque]"
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:915)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:208)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:139)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:126)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
at
org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:81)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:50)
at org.apache.ignite.marshaller.Marshallers.marshal(Marshallers.java:102)
at
org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:6842)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1952)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1933)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1915)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendNotification(GridContinuousProcessor.java:1320)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.addNotification(GridContinuousProcessor.java:1257)
at
org.apache.ignite.internal.GridEventConsumeHandler$2$1.run(GridEventConsumeHandler.java:250)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
at java.lang.Thread.runWith(Thread.java:1487)
at java.lang.Thread.run(Thread.java:1474)
What happens?
1. GridContinuousProcessor collects the event in GridContinuousBatchAdapter.
2. batch.collect() returns FastSizeDeque.
3. Ignite tries to serialize FastSizeDeque. This involves serialization
of the internal LongAdder.
4. BinaryMarshaller tries to access LongAdder#writeReplace() using
reflection.
5. JDK denies access because of JPMS.
I do not want to include
"--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED" in my
application.
Would appreciate GridContinuousBatchAdapter#collect() to return a
serializable collection.
Am 18.09.25 um 19:53 schrieb Mathias Roeppischer:
Logs are attached including stacktrace.
Regarding code: The Ignite config is part of the logs. If possible ask
specific questions on a component of interest. Apart from that the
following key points might be relevant to the problem:
1.
The Ignite configuration is embedded as code in our application.
Each instance has the same code.
2.
Our binary configuration contains only one serializer. It converts
an object we want to cache to a byte array and let the raw binary
writer write it. The read operation works the other way around using
the raw reader.
3.
2 remote async listeners are registered
(EventType.EVT_CACHE_OBJ_READ, EventType.CACHE_ENTRY_EVICTED). This is
done after start of ignition when a spring bean gets initialized.
Prior to that IgniteEvents#enableLocal( int...) is called to enable
listening.
Notice on logs:
When instance 2 joins the cluster there seems to be some configuration
exchange with instance 1. 2 warnings are written saying that listeners
were registered despite disabled event types from above. This is
strange because it looks like Ignite expects us to define enabled
event types in its configuration before ignition. As already stated
each instance uses the same code and thus, instance 2 registers its
listeners just like instance 1 using IgniteEvents after ignition.
Notice on FastSizeDeque:
Debugging into our serializer when the exception happens reveals that
FastSizeDeque contains one CacheEvent of type
EventType.EVT_CACHE_OBJ_READ. As you can see in the logs the first
instance tried to send the event to the second one which started later.
---
Am 11.09.25 um 08:11 schrieb Ilya Shishkov:
Hi,
Is it full stacktrace?
Do you have full logs of your cluster and application?
Could you attach your code and configuration?
Best regards,
Ilya Shishkov
ср, 10 сент. 2025 г. в 21:43, Mathias Roeppischer <[email protected]>:
I experienced this issue with Ignite Core 2.17.0. The following
error log was written:
Failed to send event notification to node:
f9529bce-8137-4afb-b33e-5f3dc30eb6ab
The stacktrace points to the serializer registered in our binary
configuration:
class org.apache.ignite.IgniteCheckedException: Failed to serialize
object [typeName=org.apache.ignite.util.deque.FastSizeDeque]
at
org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10864)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1951)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1932)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1914)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendNotification(GridContinuousProcessor.java:1319)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.addNotification(GridContinuousProcessor.java:1256)
at
org.apache.ignite.internal.GridEventConsumeHandler$2$1.run(GridEventConsumeHandler.java:250)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: class org.apache.ignite.binary.BinaryObjectException:
Failed to serialize object
[typeName=org.apache.ignite.util.deque.FastSizeDeque]
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:916)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:237)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:170)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
at
org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:84)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
at
org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10858)
... 9 more
Caused by: java.lang.ClassCastException: class
org.apache.ignite.util.deque.FastSizeDeque cannot be cast to class
java.io.Serializable (org.apache.ignite.util.deque.FastSizeDeque is
in unnamed module of loader
org.apache.catalina.loader.ParallelWebappClassLoader @1af7f54a;
java.io.Serializable is in module java.base of loader 'bootstrap')
at com.example.MySerializer.writeBinary(MySerializer.java:16)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:826)
... 16 more
The error had no functional impact on us. Still, it raises the
question why a non-serializable object is supposed to be handled by
BinarySerializer. We would not have expected an Ignite utility type
(FastSizeDeque) to be passed in. The stacktrace implies that the
BinaryClassDescriptor had a BinaryWriteMode.BINARY in that case. But
even without a serializer it looks like the write process would not
have been successful because FastSizeDeque is not Binarylizable.
Could you please fix or clarify the issue?
