<div dir="ltr"><div><div><div>Just a head-up, compat mode is being deprecated and will be replaced by on demand cache conversions (aka cache.getAdvancedCache.withEncodig(...))<br></div></div></div><br><div><div><div><div><div>Gustavo<br></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 3, 2017 at 3:27 PM, Galder Zamarreño <span dir="ltr"><<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I already explained in another email thread, but let me make it explicit here:<br>
<br>
The way compatibility mode works has a big influence on how useful redeploying marshallers is.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
--<br>
Galder Zamarreño<br>
Infinispan, Red Hat<br>
<div class="m_-4715395970002184510HOEnZb"><div class="m_-4715395970002184510h5"><br>
> On 3 Jul 2017, at 09:52, Tristan Tarrant <<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>> wrote:<br>
><br>
> I like it a lot.<br>
> To follow up on my comment on the PR, but to get a wider distribution,<br>
> we really need to think about how to deal with redeployments and<br>
> resource restarts.<br>
> I think restarts are unavoidable: a redeployment means dumping and<br>
> replacing a classloader with all of its classes. There are two<br>
> approaches I can think of:<br>
><br>
> - "freezing" and "thawing" a cache via some form of persistence (which<br>
> could also mean adding a temporary cache store<br>
> - separate the wildfly service lifecycle from the cache lifecycle,<br>
> detaching/reattaching a cache without stopping when the wrapping service<br>
> is restarted.<br>
><br>
> Tristan<br>
><br>
> On 6/29/17 5:20 PM, Adrian Nistor wrote:<br>
>> People, don't be shy, the PR is in now, but things can still change<br>
>> based on you feedback. We still have two weeks until we release the Final.<br>
>><br>
>> On 06/29/2017 03:45 PM, Adrian Nistor wrote:<br>
>>> This pr [1] adds a new approach for defining the compat marshaller class<br>
>>> and the indexed entity classes (in server), and the same approach could<br>
>>> be used in future for deployment of encoders, lucene analyzers and<br>
>>> possilby other code bits that a user would want to add a server in order<br>
>>> to implement an extension point that we support.<br>
>>><br>
>>> Your feedback is wellcome!<br>
>>><br>
>>> [1] <a href="https://github.com/infinispan/infinispan/pull/5233" rel="noreferrer" target="_blank">https://github.com/infinispan/<wbr>infinispan/pull/5233</a><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> infinispan-dev mailing list<br>
>>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
>><br>
><br>
> --<br>
> Tristan Tarrant<br>
> Infinispan Lead<br>
> JBoss, a division of Red Hat<br>
> ______________________________<wbr>_________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a></div></div></blockquote></div><br></div></div></div></div></div></div></div>