Why I need the same pof conf on client+srver if Coherence is used as cache?

Question

Hi,
I have first defined my own pof-config.xml only on my client.
And Coherence wrote me a very ackward msg: "StreamCorruptedException unknown user type 6" !!!????
I have made another try, while defining my own pof-config.xml on my servers too !
Then, Coherence has worked smoothly, as expected.
QUESTION: as I use Coherence as a cache, using no index, no EP... I expect Coherence is not going to dig into my byte[] for the 'server' nodes.
Then, I expect only the clients have to serialize/deserialize, I expect they send the byte[], and the servers store only them, that is, without needing any pof config.
If it works as I have written, why Coherence is not working ("StreamCorruptedException unknown user type 6"), if I define my own pof-config.xml only on my client ?
Thanks.
Regards,
Dominique

Answer 1

Hi Dominique,
user4947403 wrote:
Hi Robert,
robvarga wrote:
Hi Dominique,
Coherence does not know what you will do with the data. It has to assume that you may want to send an entry-processor or entry aggregator or query the items with a filter, or you may simply want to get the item from the cache WITHIN the cluster not only via Extend. imho, I feel it as counter-intuitive.
I have expected something like: as far as no EP is run, no pof config is searched+if no pof config exists in order to deserialize when needed, raise an exception.
1. There is no such thing as no config. If you don't specify an explicit configuration, default configuration is used, which (depending on whether POF is globally enabled or not) is either a DefaultSerializer, or a ConfigurablePofContext loading stuff from pof-config.xml.
2. If some data travels across the proxy connection, it has to travel in the serialization format configured for the proxy service. If you put data into a cache, it has to travel on the network in the serialization format configured for the cache service of the cache. Period.
If this rule was not followed, Coherence would not know what serialization format any piece of data has. Therefore as mentioned below, if the proxy service serialization configuration differs from the cache service serialization configuration, data has to be de- and reserialized on the proxy.
Again, imagine the case if your logic were followed: Just because you used some service to put data into the cache, Coherence cannot know that you will use the same service to get the data back. If some code inside the cluster tried to deserialize it, it would fail as it has no idea, that it was serialized with the proxy serialization format. It actually doesn't even have an idea that the data came from the proxy, or even that there is a proxy. Also, if you used some other code to put data into the cache which is not coming via the proxy, you would have another piece of data sitting in the cache which was not serialized by the proxy serialization format. If you tried to retrieve that via the TCP*Extend, you could not deserialize it on the client as it is not in the serialization format used by the proxy. Moreover, the client does not even have any chance of even knowing what it was serialized with as the client does not even see the serialization configuration of services inside the cluster.
Because of this it has to ensure that it can deserialize it with the serializer configured for the cache service within the cluster, so not with the one used for TCP*Extend.Well, in my case, my client is a cluster node+localstorage=false => are the explanations you wrote ok for this case too ?
It does not matter how your cluster looks like at the moment when you consider consistency checks. Nothing prevents you to start another cluster node, therefore Coherence cannot be lenient in the service configuration consistency checks just before .
By the way, if you have only a single storage-disabled cluster node (and that means that no cache server node is running) and you tried to put something into a distributed cache then if the serialization error did not happen because you have correct configuration, then you would have received a Storage not configured error instead, as no cache server node is running to actually store your data.
So if you did not get any errors, then you were either putting the data into a replicated cache where being storage-disabled is not relevant as that is a distributed cache setting, or you had a cache server node running or you only believed that the node was storage disabled.
Best regards,
Robert