Just a head-up, compat mode is being deprecated and will be replaced by on
demand cache conversions (aka cache.getAdvancedCache.withEncodig(...))
Gustavo
On Mon, Jul 3, 2017 at 3:27 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev