Hi Krzysztof! welcome back.
I think that's a bug, please report it on JIRA. I guess there might be situations in which dealing with MarshalledValue could be more efficient, but we should at the very least have an option for it (if there really was need for), and by default I agree this would not be expected.
I'm curious about your interest in memory consumption: are you getting strong benefits from storing each entry in its marshalled form?
Thanks, I'll investigate more closely and maybe even prepare a test case
Yes, the memory consumption benefits of storing entries in marshaled form are quite significant. It depends on the object and the marshaled form, of course. We are even so not concerned with performance that we're compressing the marshaled byte array But even then it could be improved further on the Infinispan's side. Since we're trying to keep millions of entries in memory, we'd like to see fewer objects per entry in the internal data structures - there is the entry object, then there is the MarshalledValue for both the key and the value, and then there are the fixed/variable length byte array wrappers... It all adds up to lots of overhead.
Hm, there is a test:
that explicitly inserts MarshalledValue into a CacheStore. (JdbcStringBasedCacheStoreTest overrides it to declare that it is expected that it throws UnsupportedKeyTypeException for JdbcStringBasedCacheStore.) Added by 44e92d025e6cad76070723cb8fcf4920da9433b8 in response to ISPN-1653 (CacheLoader with BdbjeCacheStore throws NotSerializableException: org.infinispan.marshall.MarshalledValue). So I'm confused. From the discussion under ISPN-1653 it looks like it's intentional that MarshalledValued is passed to cache stores (and hence to the Key2StringMapper) when storeAsBinary is enabled. I still don't like it but if that's final then I can somehow live with it
I created ISPN-3468 for the map-reduce bug I mentioned. It's more limited than I thought and is clearly a bug.