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, Вячеслав Коптилин <slava.kopti...@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 <xxt...@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.kopti...@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.
>>
>
