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 <gal...@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 <ttarr...@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@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev@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@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev