there was a discussion a long time ago about isolation of server modules

https://docspace.corp.redhat.com/docs/DOC-70171

last time we left the isolation to be done by using different cache managers for each server module, but I guess that's kinda outdated, I don't think we wanna have separate cache manager for each server module anymore.

the problem is that since we solved JBPAPP-5277, REST and memcached modules aren't isolated anymore

Link: Added: This issue relates to ISPN-1206

I think this issue can be better phrased as 'REST server cannot access the entries written by other protocol servers'.  Can the REST server access the entries written via Hot Rod or direct calls?

No, all server modules are basically isolated. 
HotRod is isolated from others by means of different key "encoding". All keys are stored as ByteArrayKey. In memcached and REST they are stored as plain String.

It would be cool if we were able to share data between server modules, but there is one fundamental problem. All three server modules store different metadata with the entry. We would have to unite the way how the metadata is stored for each module and define "conversions" and default values for metadata that isn't written by one but read by the other.

E.g. REST module writes mime type of the entry on PUT operation. HotRod doesn't. What kind of mime would be supplied to a value written by hotrod and read by REST ?

I'm all for starting a design document on this, but so far the consensus I think was to isolate the server modules (via isolating their keyspaces).

What does isolating keyspace really mean?  Is it having a different EmbeddedCacheManager?  Then does that mean we have to create three cache manager in a single VM?

By keyspace separation I meant wrapping the key of each server module to a different class, and therefore one module wouldn't be able to retrieve keys of other module.
IMHO a bit better than having cache managers for each server module. And easily revertable if we create a concept of sharing data among server modules.

Of course there are memory consumption implicatons, a small research would be good, which approach is more efficient in terms of memory - different cachemanagers or keyspace separation.

Different cache managers of keyspace separation is maybe a bit too much. As noted in https://issues.jboss.org/browse/ISPN-1206, Memcached clients can only write to the default cache, so either renaming the default memcached or REST cache should be more than enough to get around the issue. Personally I'd go for renaming the default REST cache as suggested in ISPN-1206, thoughts?

I like this approach - using different cache, it's actually very straightforward, I wonder why it didin't occur to me :-)

and rest server using different cache than default (as in DefaultCacheManager.getCache()) solves it perfectly:
hotrod is isolated from it by keyspace isolation - even if we picked it via it's name
memcache is isolated from it by not being able to pick named cache

good.

Actually, changing the default cache in REST is probably a bad idea. Even though we don't seem to specify it in the docu, there's a inherent link between sending a request to "__defaultcache" cache and the expectations you have (it maps to <default> cache in the config). So, if we change that name, you need to keep the mapping to the <default> cache which effectively breaks the protocol that has been in place since the 4.0 days.

It's actually much easier to change the default Memcached cache because there's no link to a protocol. There's only one cache which can be any. The only thing you need to maintain is that the new default cache for Memcached uses a clone configuration of the <default> cache. This breaks no protocol at all.

Docs QE Status: Removed: NEW