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.
>
