FST (de)serializes well to JSON, however has issues with default configuration

Question

We are using FST (fast-serialization) to put on a disk large volumes of objects concurrently and then read them. Objects their selves are of complex structure and contain what not: primitives, complex types, arrays and sets of them. The issue is, that with default FST configuration (FSTConfiguration.createDefaultConfiguration()) we experience deserialization exceptions like following:

java.lang.reflect.InvocationTargetException: null
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_91]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_91]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_91]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_91]
at org.nustaq.serialization.FSTObjectInput.readObjectCompatibleRecursive(FSTObjectInput.java:609) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.readObjectCompatibleRecursive(FSTObjectInput.java:598) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.readObjectCompatible(FSTObjectInput.java:574) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.instantiateAndReadNoSer(FSTObjectInput.java:559) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.readObjectWithHeader(FSTObjectInput.java:374) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.readObjectInternal(FSTObjectInput.java:331) ~[fst-2.55.jar:na]
at org.nustaq.serialization.serializers.FSTCollectionSerializer.instantiate(FSTCollectionSerializer.java:92) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.instantiateAndReadWithSer(FSTObjectInput.java:501) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.readObjectWithHeader(FSTObjectInput.java:370) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.readObjectFields(FSTObjectInput.java:712) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.instantiateAndReadNoSer(FSTObjectInput.java:566) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.readObjectWithHeader(FSTObjectInput.java:374) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.readObjectInternal(FSTObjectInput.java:331) ~[fst-2.55.jar:na]
at org.nustaq.serialization.FSTObjectInput.readObject(FSTObjectInput.java:311) ~[fst-2.55.jar:na]
at com.agilertech.graph.dao.disk.readers.EntityStorageReader.readObject(EntityStorageReader.java:21) ~[main/:na]
...our code there...
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_91]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[na:1.8.0_91]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[na:1.8.0_91]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[na:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_91]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_91]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_91]
Caused by: java.io.InvalidObjectException: can't deserialize enum
at java.lang.Enum.readObject(Enum.java:251) ~[na:1.8.0_91]
... 35 common frames omitted

This happens in around 5 times out of 100. Although, if switched to JSON configuration (FSTConfiguration.createJsonConfiguration()), all issues disappear -- no exceptions during (de)serialization at all.

I tried to find a root cause with debug, it looks like in some cases FST switches to useCompatibleMode for some reason and then tries to instantiate Enum by deserializing it. I also tried to reproduce this issue as a test, but didn't get any luck with it -- comparable data structures that I'm creating aren't cause such issues.

Is there an issue in our domain structure / improper use of FST, or might be a bug?

As a note, all domain classes we're using, are properly implementing Serializable.

Did you ever figure out what the root issues was or how to work around it? — 11101101b, Jun 12 '18 at 18:43
@11101101b unfortunately no, sorry. We've just switched to Kryo which works quite stable till now. — Vladimir Salin, Jun 14 '18 at 06:40

score 2 · Answer 1 · answered Jun 13 '18 at 21:08

I was getting a similar error when I was sending serialized objects over a socket. I found the following documetation which solved my issues (basically sending the size, then the object).

Huge Objects / chunked, streaming I/O:

The encoded Objects are written to the underlying stream once you close/flush the FSTOutputStream. Vice versa, the FSTInput reads the underlying stream in chunks until it starts decoding. This means you cannot read directly from blocking streams (e.g. as returned by a Socket). Example on how to solve this.

I know of users still preferring FST for very large object graphs. Maximum size is then determined by int index, so an object graph has a max size of ~1.5 GB.

FST (de)serializes well to JSON, however has issues with default configuration

1 Answers1