I already explained in another email thread, but let me make it explicit here:
The way compatibility mode works has a big influence on how useful redeploying marshallers
is.
If compatibility is lazy, redeployment of marshaller could be useful since all the
conversions happen lazily. So, conversions would only happen when data is requested. So,
if data comes from Hot Rod in byte[], only when reading it might be converted into a POJO.
If data comes as POJO, say from embedded, you'd keep it as is, and only when read from
Hot Rod you'd convert to binary.
If compatibility is eager, the conversion happens on write, and that can be have negative
impact if marshaller is redeployed. If data has been unmarshalled with marshaller A, and
then you deploy marshaller B, it might result in converting the unmarshalled POJO into a
binary format that the client can't understand.
So, IMO, if compat mode is lazy, redeployment could work... but I think redeployments add
a layer of complexity that users might not really need it. I'd rather not have
redeployments and instead of focus on rolling upgrade or freezing capabilities like
Tristan mention to be able to bring a server down and up wo/ issues for the user.
Cheers,
--
Galder Zamarreño
Infinispan, Red Hat
On 3 Jul 2017, at 09:52, Tristan Tarrant <ttarrant(a)redhat.com>
wrote:
I like it a lot.
To follow up on my comment on the PR, but to get a wider distribution,
we really need to think about how to deal with redeployments and
resource restarts.
I think restarts are unavoidable: a redeployment means dumping and
replacing a classloader with all of its classes. There are two
approaches I can think of:
- "freezing" and "thawing" a cache via some form of persistence
(which
could also mean adding a temporary cache store
- separate the wildfly service lifecycle from the cache lifecycle,
detaching/reattaching a cache without stopping when the wrapping service
is restarted.
Tristan
On 6/29/17 5:20 PM, Adrian Nistor wrote:
> People, don't be shy, the PR is in now, but things can still change
> based on you feedback. We still have two weeks until we release the Final.
>
> On 06/29/2017 03:45 PM, Adrian Nistor wrote:
>> This pr [1] adds a new approach for defining the compat marshaller class
>> and the indexed entity classes (in server), and the same approach could
>> be used in future for deployment of encoders, lucene analyzers and
>> possilby other code bits that a user would want to add a server in order
>> to implement an extension point that we support.
>>
>> Your feedback is wellcome!
>>
>> [1]
https://github.com/infinispan/infinispan/pull/5233
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev