You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Вячеслав Коптилин <sl...@gmail.com> on 2021/07/13 12:48:57 UTC
Cache group re-encryption and exception handling (IGNITE-14424)
Hello Pavel,
Could you please assist me in understanding the fix that was implemented
under https://issues.apache.org/jira/browse/IGNITE-14424
In particular, it seems odd to me, just logging an exception in case
starting re-encryption failed with an error/exception.
Please take a look at
https://github.com/apache/ignite/pull/9036/files#diff-1c3291a1d6cee3ec3184b99547a0f49b815d64c2ba88f3471c98116c1a49bcfeR1123
I think it would be nice to propagate this exception to the FailureHandler
(except NodeStoppingException).
Perhaps, I am missing something. Is it assumed that the process of
re-encryption can result in an error and it is ok? And in this case, the
re-encryption should be triggered later by the end-user.
Thanks,
S.
Re: Cache group re-encryption and exception handling (IGNITE-14424)
Posted by Вячеслав Коптилин <sl...@gmail.com>.
By the way, we already fixed the issue
https://issues.apache.org/jira/browse/IGNITE-14248 that looks very close to
what we are discussing now.
Thanks,
S.
чт, 15 июл. 2021 г. в 11:17, Вячеслав Коптилин <sl...@gmail.com>:
> Hi Pavel,
>
> >As for handling the exception in this case, from my point of view, the
> impossibility of starting re-encryption is not critical for the node
> Ok, got it. Thanks for the clarification.
>
> > in this particular case, only one checked exception is possible - if
> re-encryption is started when the node is stopped
> It is always possible that an instance of RuntimeException will be thrown
> anyway, and so the caller's thread is responsible for exception handling.
> The funny edge case that I can imagine is the followng: one node cluster
> and startReencryption throws NullPointerException, for instance. It seems,
> that this exception will not trigger the FailureHandler at all.
> (Perhaps, this issue relates to exchnage future and not a problem of
> reecnryption itself).
>
> Thanks,
> S.
>
> вт, 13 июл. 2021 г. в 16:19, Pavel Pereslegin <xx...@gmail.com>:
>
>> Hello, Slava.
>>
>> This fix is required to fix the problem described in the ticket
>> description ("Cache group re-encryption does not start after cluster
>> secondary activation").
>> As for handling the exception in this case, from my point of view, the
>> impossibility of starting re-encryption is not critical for the node
>> (these are not caching operations, detection, etc.), but perhaps I am
>> wrong here. Also, in this particular case, only one checked exception
>> is possible - if re-encryption is started when the node is stopped (I
>> think handling it with a failure handler is redundant).
>>
>> вт, 13 июл. 2021 г. в 15:49, Вячеслав Коптилин <slava.koptilin@gmail.com
>> >:
>> >
>> > Hello Pavel,
>> >
>> > Could you please assist me in understanding the fix that was
>> implemented under https://issues.apache.org/jira/browse/IGNITE-14424
>> > In particular, it seems odd to me, just logging an exception in case
>> starting re-encryption failed with an error/exception.
>> > Please take a look at
>> https://github.com/apache/ignite/pull/9036/files#diff-1c3291a1d6cee3ec3184b99547a0f49b815d64c2ba88f3471c98116c1a49bcfeR1123
>> > I think it would be nice to propagate this exception to the
>> FailureHandler (except NodeStoppingException).
>> >
>> > Perhaps, I am missing something. Is it assumed that the process of
>> re-encryption can result in an error and it is ok? And in this case, the
>> re-encryption should be triggered later by the end-user.
>> >
>> > Thanks,
>> > S.
>>
>
Re: Cache group re-encryption and exception handling (IGNITE-14424)
Posted by Вячеслав Коптилин <sl...@gmail.com>.
Hi Pavel,
>As for handling the exception in this case, from my point of view, the
impossibility of starting re-encryption is not critical for the node
Ok, got it. Thanks for the clarification.
> in this particular case, only one checked exception is possible - if
re-encryption is started when the node is stopped
It is always possible that an instance of RuntimeException will be thrown
anyway, and so the caller's thread is responsible for exception handling.
The funny edge case that I can imagine is the followng: one node cluster
and startReencryption throws NullPointerException, for instance. It seems,
that this exception will not trigger the FailureHandler at all.
(Perhaps, this issue relates to exchnage future and not a problem of
reecnryption itself).
Thanks,
S.
вт, 13 июл. 2021 г. в 16:19, Pavel Pereslegin <xx...@gmail.com>:
> Hello, Slava.
>
> This fix is required to fix the problem described in the ticket
> description ("Cache group re-encryption does not start after cluster
> secondary activation").
> As for handling the exception in this case, from my point of view, the
> impossibility of starting re-encryption is not critical for the node
> (these are not caching operations, detection, etc.), but perhaps I am
> wrong here. Also, in this particular case, only one checked exception
> is possible - if re-encryption is started when the node is stopped (I
> think handling it with a failure handler is redundant).
>
> вт, 13 июл. 2021 г. в 15:49, Вячеслав Коптилин <sl...@gmail.com>:
> >
> > Hello Pavel,
> >
> > Could you please assist me in understanding the fix that was implemented
> under https://issues.apache.org/jira/browse/IGNITE-14424
> > In particular, it seems odd to me, just logging an exception in case
> starting re-encryption failed with an error/exception.
> > Please take a look at
> https://github.com/apache/ignite/pull/9036/files#diff-1c3291a1d6cee3ec3184b99547a0f49b815d64c2ba88f3471c98116c1a49bcfeR1123
> > I think it would be nice to propagate this exception to the
> FailureHandler (except NodeStoppingException).
> >
> > Perhaps, I am missing something. Is it assumed that the process of
> re-encryption can result in an error and it is ok? And in this case, the
> re-encryption should be triggered later by the end-user.
> >
> > Thanks,
> > S.
>
Re: Cache group re-encryption and exception handling (IGNITE-14424)
Posted by Pavel Pereslegin <xx...@gmail.com>.
Hello, Slava.
This fix is required to fix the problem described in the ticket
description ("Cache group re-encryption does not start after cluster
secondary activation").
As for handling the exception in this case, from my point of view, the
impossibility of starting re-encryption is not critical for the node
(these are not caching operations, detection, etc.), but perhaps I am
wrong here. Also, in this particular case, only one checked exception
is possible - if re-encryption is started when the node is stopped (I
think handling it with a failure handler is redundant).
вт, 13 июл. 2021 г. в 15:49, Вячеслав Коптилин <sl...@gmail.com>:
>
> Hello Pavel,
>
> Could you please assist me in understanding the fix that was implemented under https://issues.apache.org/jira/browse/IGNITE-14424
> In particular, it seems odd to me, just logging an exception in case starting re-encryption failed with an error/exception.
> Please take a look at https://github.com/apache/ignite/pull/9036/files#diff-1c3291a1d6cee3ec3184b99547a0f49b815d64c2ba88f3471c98116c1a49bcfeR1123
> I think it would be nice to propagate this exception to the FailureHandler (except NodeStoppingException).
>
> Perhaps, I am missing something. Is it assumed that the process of re-encryption can result in an error and it is ok? And in this case, the re-encryption should be triggered later by the end-user.
>
> Thanks,
> S.