PofExtractor encoder error when moving from Distributed to Replicated

Question

Hi All,
I have a piece of code which initially used the Distributed Caching scheme with the following configuration:
coherence-cache-config.xml
=================
<cache-mapping>
<cache-name>*</cache-name>
<scheme-name>example-distributed</scheme-name>
</cache-mapping>
<distributed-scheme>
<scheme-name>example-distributed</scheme-name>
<service-name>DistributedCache</service-name>
<serializer>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>tokens-pof-config.xml</param-value>
</init-param>
</init-params>
</serializer>
<backing-map-scheme>
<local-scheme>
<scheme-ref>example-binary-backing-map</scheme-ref>
<expiry-delay>100000s</expiry-delay>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
<thread-count>2500</thread-count>
"tokens-pof-config.xml"
===============
<?xml version="1.0"?>
<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof-config coherence-pof-config.xsd">
<user-type-list>
<!-- coherence POF user types -->
<include>coherence-pof-config.xml</include>
<!-- com.tangosol.examples package -->
<user-type>
<type-id>1001</type-id>
<class-name>oracle.communications.activation.asap.ace.Token</class-name>
</user-type>
<user-type>
<type-id>1002</type-id>
<class-name>oracle.communications.activation.asap.ace.Asdl</class-name>
</user-type>
</user-type-list>
<allow-interfaces>true</allow-interfaces>
<allow-subclasses>true</allow-subclasses>
</pof-config>
And everything works fine.
Then I changed the caching sheme to a replicated cache instead of a distributed caching scheme by changing the following configuration
<cache-mapping>
<cache-name>*</cache-name>
<scheme-name>example-replicated</scheme-name>
</cache-mapping>
<replicated-scheme>
<scheme-name>example-replicated</scheme-name>
<service-name>ReplicatedCache</service-name>
<serializer>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>tokens-pof-config.xml</param-value>
</init-param>
</init-params>
</serializer>
<backing-map-scheme>
<local-scheme>
<scheme-ref>unlimited-backing-map</scheme-ref>
</local-scheme>
</backing-map-scheme>
<thread-count>2500</thread-count>
<autostart>true</autostart>
</replicated-scheme>
Once I do this and run my piece of code I start seeing the following error message. Any ideas what i did wrong ?
java.lang.UnsupportedOperationException: PofExtractor must be used with POF-encoded Binary entries; the Map Entry is not a BinaryEntry.
Please help me :)

Answer 1

807103 wrote:
Thanks a ton Robert.
A follow up question, will it be fair to assume hence that a partitioned or distributed cache would be more performant for POF objects as compared to a replicated cache due to full serialization/de-serialization ?
Thanks,
AnkitNot really.
Provided that you have the same set of objects in both the replicated and the distributed cache, then there are a number of factors which are better for replicated cache and some which are better for distributed cache if only query performance is considered:
Replicated cache has all the data locally, hence there is no cost for retrieving data across the network.
If a query can executed completely based on index data, then it is usually faster to query it locally even if set operations for logical expressions in the filter may be more costly, because the number of index operations are the same, you just need to work with larger sets. Again, due to the data being available locally.
If you need to iterate through the entry-set to evaluate the filter one-by one, then distributed cache can do it in parallel on many nodes. On the other hand, since the data is available in Java object form, you usually do not have to pay the deserialization cost, and hence evaluating a ValueExtractor in a replicated cache is faster than evaluating POF-based extractors which have to read through the POF binary until they arrive to the value to extract (it helps to put these to the front by giving them a low property id). Even though you do not generate that much garbage and can break off when you reached the field you want, POF extraction does take some time.
So in general, if you can fit the data into replicated cache with the same indexes, then replicated cache will likely be faster for query performance.
The advantages of the distributed cache above replicated cache starts to become interesting when you want to scale out either your data or your nodes or both:
Data-set size cannot scale with a replicated cache for obvious reasons (it is limited by the smallest cluster node). In a distributed cache you can scale out with the number of nodes (you can have hundreds of nodes with the default configuration in Coherence and with tuning you can grow a bit more).
Cost of updating the data is linear with the number of nodes in a replicated cache and constant in a partitioned (distributed) cache.
It is an interesting fact, though, that most filter-based operations do not scale with increasing the number of nodes, as each node has to execute the operation (unless it is partition-filtered).
Best regards,
Robert