[infinispan-dev] Feedback for PR 5233 needed

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Feedback for PR 5233 needed

Adrian Nistor
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Feedback for PR 5233 needed

Adrian Nistor
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Feedback for PR 5233 needed

Tristan Tarrant-2
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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Feedback for PR 5233 needed

Galder Zamarreño
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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Feedback for PR 5233 needed

Gustavo Fernandes-2
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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...