[infinispan-dev] Feedback for PR 5233 needed

Gustavo Fernandes gustavo at infinispan.org
Thu Jul 6 04:41:22 EDT 2017


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 at 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 at 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 at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170706/18206794/attachment.html 


More information about the infinispan-dev mailing list