fast-serialization icon indicating copy to clipboard operation
fast-serialization copied to clipboard

Serializing a sublist leads to a concurrent modification exception

Open DavidRigglemanININ opened this issue 7 years ago • 3 comments

I was able to create a simple test case to prove that FST has problems serializing/deserializing sublists. I've got code to easily flip between FST and Jackson and Jackson can handle this case perfectly fine. The issue seems to be that with setForceSerializable = true, it doesn't work on sublists.

import org.junit.Test;
import org.nustaq.serialization.FSTConfiguration;

import java.util.ArrayList;
import java.util.List;

public class FstBugTest {
    @Test
    public void bug() {
        FSTConfiguration conf = FSTConfiguration.createDefaultConfiguration().setForceSerializable(true);
        List<Double> list = new ArrayList<Double>();
        list.add(1.0);
        list.add(2.0);
        Foo foo = new Foo();
        foo.items = list.subList(0, 1);
        byte[] bytes = conf.asByteArray(foo);
        Foo obj = (Foo) conf.asObject(bytes);
        System.out.println(obj.items.size());
    }

    class Foo {
        public List<Double> items;
    }
}

DavidRigglemanININ avatar Feb 15 '18 15:02 DavidRigglemanININ

forceserializable is an unsupported hack. usually there is a reason a class does not implement Serializable. Probably a serializer can be added for sublists instead.

RuedigerMoeller avatar Feb 15 '18 17:02 RuedigerMoeller

Thanks. I did not realize the option was unsupported. What made this bug tricky was that it didn't surface on the write/read but on a later access of a property of the deserialized class. If it would have just thrown immediately, that would have been much better and more obvious. Also even without use of that option, I think this case is still problematic because a List is considered serializable, so it would not cause any compile time errors. I believe the runtime error would just surface quicker and probably have a more clear description

DavidRigglemanININ avatar Feb 16 '18 15:02 DavidRigglemanININ

I think I'm having the same issue but I don't use setForceSerializable(true) but createAndroidDefaultConfiguration.

Here is my stack-trace. Note: the stack-trace was obfuscated and I only de-obfuscated the class names and not the methods names:

java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:757) at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:790) at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:788) at FSTMapSerializer.a(SourceFile:44) at FSTObjectOutput.a(SourceFile:476) at FSTObjectOutput.a(SourceFile:327) at FSTObjectOutput.a(SourceFile:294) at FSTObjectOutput.writeObject(SourceFile:204) at FSTConfiguration.b(SourceFile:1182) at bot.a(SourceFile:471) at bot.lambda$OKX1FfX-ZleYOm7etNoHkXyQ4TQ(Unknown Source:0) at -$$Lambda$bot$OKX1FfX-ZleYOm7etNoHkXyQ4TQ.run(Unknown Source:4) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.lang.Thread.run(Thread.java:764)

What is the recommended solution? Also, this exception seems to be random on my case.

codeskraps avatar Feb 15 '19 19:02 codeskraps