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.
