Hi Minh,

See my  comment inline.

-----Original Message-----
From: Minh Hon Chau <minh.c...@dektech.com.au> 
Sent: Monday, April 20, 2020 11:51 AM
To: Thuan Tran <thuan.t...@dektech.com.au>; Thang Duc Nguyen 
<thang.d.ngu...@dektech.com.au>
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1/1] ntf: restart ntfimcnd if it fails to get operation 
invoke name [#3178]

Hi,

One similarity to #2859 is that the invoke_name is only present in the first 
callback, so ntfimcn must memorize it in ccb userdata.

But after ntfimcn calls ccbutil_ccbAddModifyOperation, this userdata is not 
written to immnd and sync across the other immnd(s)? 
Meanings the userdata is only stored in imm agent? So after switchover, the 
next ccb callback does not have the invoke_name, and ntfimcn has lost its user 
data since restart.

[Thang]: with a ccb with multi ops. The invoke_name, in this case only the 
first op contain the adminOwnername. And after ntfimcnd restarts, it received 
the seond or larger op modify. And this modify callback does not contain any 
more about this invoke_name.
Maybe we can retrieve the invoke_name from imm db but we can not got all info 
about all ops in that ccb.

Thanks

Minh

On 16/4/20 3:32 pm, Thuan Tran wrote:
> Hi,
>
> I think this is just enhancement, not an urgent fix.
> Then we should make it better if possible.
>
> About #2859, I am not reviewer at that time.
> But I would not agree that solution as we can see service keep restart 
> if service still start in middle of one CCB many operations.
>
> Best Regards,
> ThuanTr
>
> -----Original Message-----
> From: Thang Duc Nguyen <thang.d.ngu...@dektech.com.au>
> Sent: Thursday, April 16, 2020 10:51 AM
> To: Thuan Tran <thuan.t...@dektech.com.au>; Minh Hon Chau 
> <minh.c...@dektech.com.au>
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: RE: [PATCH 1/1] ntf: restart ntfimcnd if it fails to get 
> operation invoke name [#3178]
>
> Hi Thuan,
>
> Thanks for your comment.
> First this issue happen only in specific situation. And I think restart it is 
> no cause big issue.
> And the ccb is internal data based mange by ntf/ntfimcnd. After 
> ntfimcnd restart, it reinitialize CcbUtilCcbData and operation invoke name is 
> empty.
>
> Moreover, in current code in ntfimcn_imm.c, there are many place use 
> imcn_exit(EXIT_FAILURE) when detect the error. Example for this is #2859.
> We consider to open a new ticket to consider your suggestion by 
> refactor/change current behavior of ntfimcnd.
>
> B.R/Thang
>
> -----Original Message-----
> From: Thuan Tran <thuan.t...@dektech.com.au>
> Sent: Thursday, April 16, 2020 10:16 AM
> To: Thang Duc Nguyen <thang.d.ngu...@dektech.com.au>; Minh Hon Chau 
> <minh.c...@dektech.com.au>
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: RE: [PATCH 1/1] ntf: restart ntfimcnd if it fails to get 
> operation invoke name [#3178]
>
> Hi Thang,
>
>  From reproduce method, with solution after exit (instead of crash), user 
> continue input another operation then service exit again.
> The point is why we cannot get admin owner or object implementer via 2nd imm 
> modify callback in this scenario?
> Is it an IMM limit that don't include admin owner or object implementer from 
> 2nd modify callback?
>
> If limit, can we use another way to get admin owner or object implementer 
> base on object name?
> By this, we can avoid continuous exit if user keep going on operations by 
> same CCB.
>
> Best Regards,
> ThuanTr
>
> -----Original Message-----
> From: Thang Duc Nguyen <thang.d.ngu...@dektech.com.au>
> Sent: Wednesday, April 15, 2020 3:43 PM
> To: Minh Hon Chau <minh.c...@dektech.com.au>; Thuan Tran 
> <thuan.t...@dektech.com.au>
> Cc: opensaf-devel@lists.sourceforge.net; Thang Duc Nguyen 
> <thang.d.ngu...@dektech.com.au>
> Subject: [PATCH 1/1] ntf: restart ntfimcnd if it fails to get 
> operation invoke name [#3178]
>
> If ntfimcnd is restarted during ccb modify, it will initialize ccbUtilCcbData 
> that not contain operation invoke name.
> This causes ntfimcnd crashed due to operation invoke name not existed.
>
> The fix is to restart ntfimcnd instead of raising the coredump.
> ---
>   src/ntf/ntfimcnd/ntfimcn_imm.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/ntf/ntfimcnd/ntfimcn_imm.c 
> b/src/ntf/ntfimcnd/ntfimcn_imm.c index 3c0a8c02a..3563a2264 100644
> --- a/src/ntf/ntfimcnd/ntfimcn_imm.c
> +++ b/src/ntf/ntfimcnd/ntfimcn_imm.c
> @@ -376,9 +376,9 @@ get_operation_invoke_name_modify(SaImmOiCcbIdT ccbId,
>                       goto done;
>               }
>       }
> -     /* If we get here no name is found! */
> +     /* ntfimcnd was restarted during ccb midify */
>       LOG_ER("%s no name was found", __FUNCTION__);
> -     osafassert(0);
> +     imcn_exit(EXIT_FAILURE);
>   
>   done:
>       TRACE_LEAVE();
> --
> 2.17.1
>

_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Reply via email to