Vivek, See the attached modifications that work. There were a couple of problems. First, since your class extends LinkedHashMap, it is treated by default as a Map by kryo for serialization and uses the internal MapSerializer to only serialize the keys and values in the map, so your field capacity doesn't even get serialized. Maybe there is a better way to handle this but for now, I got around this by using a custom serializer that extends the MapSerializer. Second, the removeEldestEntry method will also be called during deserialization as the map is being populated with entries. However, by this time, the capacity may not have been deserialized and it's value would be 0, resulting in removeEldestEntry returning true and entries being removed. This can be solved by checking if capacity is initalized or not. You can see the modifications in the code.
Thanks On Fri, Aug 11, 2017 at 5:13 PM, Vivek Bhide <vivek.bh...@target.com> wrote: > Hi Pramod and Thomas > > Below are my findings till now on this issue > > 1. Fix suggested by Pramod and fix made as apart of > https://issues.apache.org/jira/browse/APEXMALHAR-2526 are doing the same > thing > 2. In the comments for https://issues.apache.org/ > jira/browse/APEXMALHAR-2526 > I found that, the new class KryoJavaSerializer.java is created to fix the > problem but kryo has already fixed this issue at their end too (in Dec > 2016) > 3. When checked the kryo version from apex-core, I found that it is > expecting version 2.24 which is quite old and latest kryo version (4.0.1) > has the fix included > 4. So at the end only changes I needed were to update kryo version to > latest > and continue using a JavaSerializer. On implementing these, Issue with > application recovery has resolved > > I see that story https://issues.apache.org/jira/browse/APEXCORE-768 is > already created to update the kryo version and remove class > KryoJavaSerializer.java > > Again this still doesn't answer the question that why kryo is not > serializing the custom implementation of LinkedHashMap at first place with > its default serialization > > Regards > Vivek > > > > -- > View this message in context: http://apache-apex-users-list. > 78494.x6.nabble.com/How-the-application-recovery-works- > when-its-started-with-originalAppId-tp1821p1840.html > Sent from the Apache Apex Users list mailing list archive at Nabble.com. >
Description: Binary data