Hi,
If there is no way to get admin owner or object implementer in middle of one
CCB many operations.
Then a "unknown" invoker is better than keep restarting by each operation of
that CCB.
Best Regards,
ThuanTr
-----Original Message-----
From: Thang Duc Nguyen <thang.d.ngu...@dektech.com.au>
Sent: Tuesday, April 21, 2020 8:39 AM
To: Thang Duc Nguyen <thang.d.ngu...@dektech.com.au>; Minh Hon Chau
<minh.c...@dektech.com.au>; Thuan Tran <thuan.t...@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]
Update.
If we accept to avoid coredump, there is @operation_invoke_name that needs to
be freed before exit?
[Thang]: as above can fill invoke_name as unknown in this case to avoid the
coredump.
And free in applyccbcb.
-----Original Message-----
From: Thang Duc Nguyen <thang.d.ngu...@dektech.com.au>
Sent: Tuesday, April 21, 2020 8:29 AM
To: Minh Hon Chau <minh.c...@dektech.com.au>; Thuan Tran
<thuan.t...@dektech.com.au>
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 1/1] ntf: restart ntfimcnd if it fails to get
operation invoke name [#3178]
Hi Minh,
See my command inline.
-----Original Message-----
From: Minh Hon Chau <minh.c...@dektech.com.au>
Sent: Monday, April 20, 2020 5:24 PM
To: Thang Duc Nguyen <thang.d.ngu...@dektech.com.au>; Thuan Tran
<thuan.t...@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,
I understand the invoke_name is only present in the first callback, thus
ntfimcn must memorize it in the userdata. My question is, is it ok that this
userdata being lost because ntfimcn restart? I think it is, since the ccb has
not committed.
[Thang]: can accept it and fill invoke_name as unknown instead of do nothing.
If we accept the userdata being lost, then we can look at to avoid the
coredump, otherwise Thuan can give an idea if it is imm issue that causes the
lost userdata.
If we accept to avoid coredump, there is @operation_invoke_name that needs to
be freed before exit?
[Thang]: as above can fill invoke_name as unknown in this case to avoid the
coredump.
thanks
Minh
On 20/4/20 6:30 pm, Thang Duc Nguyen wrote:
> 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
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
