ReflectionPofSerializer has been laying around without significant changes about a year and a half. Though I'm actively using it across projects, it was just working. But recently I decided to make few important functional improvements and extend capabilities of ReflectionPofSerializer.
Advanced support for collections
A few complains I was hearing about ReflectionPofSerializer were bad support for collections. Actually these complains should have been addressed to POF protocol itself, ReflectionPofSerializer just were using it as is. POF has a bad habit to substitute collections and maps with its own implementations, which may not necessary be compatible application needs (i.e. you have a good chance for HashSet to be replaced by list, and TreeMap by HashMap). If you are writing POF serializer by hand you can easily fix it, but for automatic serialization it may be a serious issue.
How new version of ReflectionPofSerializer is handling this problem?
If you have problem with collection classes being converted during serialization and this is breaking your application, you can force Coherence to use ReflectionPofSerializer for that specific collection class. This will require you to add standard (or your custom) collection classes to POF config.
| <user-type> <type-id>2000type-id> <class-name>java.util.ArrayListclass-name> <serializer> <class-name>org.gridkit.coherence.utils.pof.ReflectionPofSerializerclass-name> serializer> user-type> <user-type> <type-id>2001type-id> <class-name>java.util.LinkedListclass-name> <serializer> <class-name>org.gridkit.coherence.utils.pof.ReflectionPofSerializerclass-name> serializer> user-type> <user-type> <type-id>2002type-id> <class-name>java.util.TreeMapclass-name> <serializer> <class-name>org.gridkit.coherence.utils.pof.ReflectionPofSerializerclass-name> serializer> user-type> <user-type> <type-id>2003type-id> <class-name>java.util.HashSetclass-name> <serializer> <class-name>org.gridkit.coherence.utils.pof.ReflectionPofSerializerclass-name> serializer> user-type> <user-type> <type-id>2004type-id> <class-name>java.util.TreeSetclass-name> <serializer> <class-name>org.gridkit.coherence.utils.pof.ReflectionPofSerializerclass-name> serializer> user-type> |
That is it. ReflectionPofSerializer now knows how to properly serialize/deserialize collection classes.
Using POF without POF config
Using POF drastically improves Coherence performance for most applications. Unfortunately you have to register all your classes in pof-config.xml and provide serializers. Even through you can avoid writing serialization/deserialization code, you still have to maintain pof-config.xml (and it may be hundreds of classes). Could we just generate pof-config.xml in run-time on demand? Well, all nodes should use same pof-config.xml (or at least same class to ID mapping), so it is problematic. But wait, we already have a Coherence which can easily keep such mapping in sync across all nodes! That is the idea behind AutoPofSerializer.
AutoPofSerializer manages shared class to ID mapping (using Coherence cache) and automatically adds new classes to that mapping. It also automatically chooses to use ReflectionPofSerializer if object is not implementing PortableObject interface.
So now, you just need to configure AutoPofSerializer for cache and it will just work without need for pof-config.xml (actually it may look at pof-config.xml, but if class is not in there, it will be added automatically).
| <distributed-scheme> <scheme-name>simple-distributed-schemescheme-name> <serializer> <class-name>org.gridkit.coherence.utils.pof.AutoPofSerializerclass-name> serializer> ... distributed-scheme> |
AutoPofSerializer is still experimental and I would probably not recommend it to be used in production. But it is very useful for development, prototyping and evaluating POF performance. You can make sure what your code is solving problem and only then do boiler plate work of configuring POF.
See more information of ReflectionPofSerializer page at GridKit.
Posts
Hi Alexey, I was trying out your AutoPofSerializer for the last couple of days. It works well in a TCMP cluster. But, is it possible to use it in Coherence*Extend mode? Also, you have mentioned in your post that it is not recommended to be used in production. Is there any specific issue or something, to avoid it's use in production?
ReplyDeleteAutoPofSerializer is using cache locks as far as I remember, which may not work in *Extend.
DeleteAutoPofSerializer just saves you from listing your classes in config, so for PROD I would recommend you use ReflectionPofSerializer and map classes to ID explicitly.
Thanks for your reply. In our company, multiple micro services are planning to use coherence caches. It is very inconvenient to add class references to caching nodes and restart, every time a new micro service gets deployed. Do you have any suggestions to solve this problem?
ReplyDeleteYou will still have to add classes to Coherence node classpath, do you?
ReplyDeletePlease take a look at another my article on this topic http://blog.ragozin.info/2012/03/coherence-how-to-get-rid-of-domain.html