On 14 Dec 2012, at 13:56, Tristan Tarrant ttarr...@redhat.com wrote:
Let's think about data typing: a string is a string is a string, and not
some weirdly marshalled byte array (which may be influenced by Marshaller,
protocol value wrapper, phase of the moon, etc). Protocols would say
On Dec 14, 2012, at 2:56 PM, Tristan Tarrant ttarr...@redhat.com wrote:
I would really like ISPN-2281 to be solved by the proper solution, i.e.
attach any additional metadata required by the servers (or any other data
enricher) to the InternalCacheEntry and not as part of the value itself.
Even then, #2 would only be a temporary solution until we have #4, right?
Would https://issues.jboss.org/browse/ISPN-2281 help in any way?
- M
On 11 Dec 2012, at 17:37, Dennis Reed der...@redhat.com wrote:
I don't like #1. Seems more complicated, harder to maintain debug than the
others.
I would really like ISPN-2281 to be solved by the proper solution, i.e.
attach any additional metadata required by the servers (or any other
data enricher) to the InternalCacheEntry and not as part of the value
itself. Metadata would be some kind of sparse structure whose values
could also be
So,
I thought we had everything ready to go for HotRod rolling upgrades:
* have HotRod server full of data (the source)
* configure a new HotRod server (the target) with a RemoteCacheStore
pointing to the source (using rawValues)
* clients switch over to the target server which on cache
+1 to eliminate the value wrappers.
-1 to adding a dependency from core to server-core, if you feel creating
and maintaining a separate MigrationRemoteCacheStore is too much work I'd
rather we moved CacheValue to core.
If we move CacheValue to core, I think we can do the re-wrapping on the
On 12/11/2012 02:35 PM, Dan Berindei wrote:
+1 to eliminate the value wrappers.
-1 to adding a dependency from core to server-core, if you feel
creating and maintaining a separate MigrationRemoteCacheStore is too
much work I'd rather we moved CacheValue to core.
The dependency would only be
