On 16-May-16 7:04 AM, minh chau wrote:
> Hi Praveen,
>
> Please see comments in line.
>
> Thanks,
> Minh
>
> On 13/05/16 17:17, praveen malviya wrote:
>> Hi Minh,
>>
>> I am trying to understand the problem.
>>
>> As per these ntfd traces, in the down event at below at 3) ntfd clears
>> the client data so subsequent requests for Unsubscribe() and
>> Finalize() for same client will surely fail with reported error.
>> One question : Why the down event at 3) below is coming before the
>> unsubscribe() and Finalize() requests keeping in mind that both
>> Unsubscribe() and Finalize() are sync calls.
> [Minh]: The down event comes from mds thread, and unsubcribed() &
> finalize() come from client threads, so there could be a chance those
> events come in unexpected order.
[Praveen] Both Unsubscribe and Finalize() are sync call. So ntftest will
call finalize() and when it completes then only mds thread will exit and
down event will be generated. In that case only for Unsubsribe() such
error can come as it may get timed in separate thread after completion
of Finalize().
Thanks,
Praveen
In mds_mcm_user_event_callback() the
> callback are sent with priority MDS_SEND_PRIORITY_MEDIUM while NTF agent
> is sending msg with MDS_SEND_PRIORITY_HIGH. I'm not familiar with mds
> code but the msg priority doesn't look right here.
> As in patch description, this patch is not complete solution, it just
> lowers the initialize msg than the others, that means the other msgs
> which are in handle's life cycle are prioritized than starting
> initializing new handles. I think this doesn't cause any harm to agent's
> way of working. Or do you (and Lennart) see any side effect of this patch?
>
>>
>> I have run suite 2 and got the same error. But that error comes when
>> ntfd gets Unsubscribe() request after Finalize() request.In that
>> situation this is an acceptable error.
>>
>> Messages from NTFD traces:
>>
>> 1)Client came up at:
>> Mar 10 14:53:01.402362 osafntfd [463:ntfs_mds.c:0078] T8
>> NTFSV_INITIALIZE_REQ
>> Mar 10 14:53:01.402493 osafntfd [463:ntfs_evt.c:0263] >>
>> proc_initialize_msg: dest 2010f00000331
>> Mar 10 14:53:01.402515 osafntfd [463:NtfClient.cc:0043] T3
>> NtfClient::NtfClient NtfClient 28 created mdest: 564113889559345
>>
>> 2)Its subscription request comes at :
>> Mar 10 14:53:01.403921 osafntfd [463:ntfs_evt.c:0315] >>
>> proc_subscribe_msg
>> Mar 10 14:53:01.403929 osafntfd [463:ntfs_evt.c:0318] T4
>> subscriptionId: 111
>> Mar 10 14:53:01.403992 osafntfd [463:NtfSubscription.cc:0045] T2
>> Subscription 111 created for client_id 28
>>
>> 3) Then came the down event for the same client at (2 times):
>> Mar 10 14:53:01.405487 osafntfd [463:ntfs_evt.c:0101] >>
>> proc_ntfa_updn_mds_msg
>> Mar 10 14:53:01.405495 osafntfd [463:NtfAdmin.cc:0504] >>
>> clientRemoveMDS: REMOVE mdsDest: 564113889559345
>> Mar 10 14:53:01.405583 osafntfd [463:ntfs_evt.c:0101] >>
>> proc_ntfa_updn_mds_msg
>> Mar 10 14:53:01.405591 osafntfd [463:NtfAdmin.cc:0504] >>
>> clientRemoveMDS: REMOVE mdsDest: 564113889559345
>> Mar 10 14:53:01.405598 osafntfd [463:NtfAdmin.cc:0521] << clientRemoveMDS
>>
>> 4)After this reported error got in syslog during Unsubscribe() and
>> Finalize() requests as the clinet was removed already:
>> Mar 10 14:53:01.405862 osafntfd [463:ntfs_mds.c:0105] T8
>> NTFSV_FINALIZE_REQ
>> Mar 10 14:53:01.405875 osafntfd [463:ntfs_evt.c:0338] >>
>> proc_unsubscribe_msg: client_id 28, subscriptionId 111
>> Mar 10 14:53:01.406044 osafntfd [463:NtfAdmin.cc:0553] ER
>> NtfAdmin::subscriptionRemoved client 28 not found
>> Mar 10 14:53:01.406061 osafntfd [463:ntfs_evt.c:0341] <<
>> proc_unsubscribe_msg
>> Mar 10 14:53:01.406079 osafntfd [463:ntfs_evt.c:0291] >>
>> proc_finalize_msg: client_id 28
>> Mar 10 14:53:01.406088 osafntfd [463:NtfAdmin.cc:0480] T2
>> NtfAdmin::clientRemoved client 28 not found
>> Mar 10 14:53:01.406095 osafntfd [463:ntfs_com.c:0074] >>
>> client_removed_res_lib: clientId: 28, rv: 1
>>
>>
>> Thanks,
>> Praveen
>>
>>
>>
>>
>> On 11-May-16 7:36 PM, Minh Hon Chau wrote:
>>> osaf/libs/agents/saf/ntfa/ntfa_mds.c | 9 ++++++++-
>>> 1 files changed, 8 insertions(+), 1 deletions(-)
>>>
>>>
>>> When running ntftest suite, there's an issue that the messages of
>>> previous test
>>> coming after some of messages of current test. This issue can also
>>> happen in
>>> real application.
>>>
>>> The patch lowers mds priority of initialize msg so that the other
>>> messages have
>>> a chance to reach ntf server earlier. This is not a complete
>>> solution, since
>>> there could be a race condition between the other messages not just
>>> only with
>>> initialize messages. If it happens, priority of those messages can be
>>> considered
>>> in which race condition happens.
>>>
>>> diff --git a/osaf/libs/agents/saf/ntfa/ntfa_mds.c
>>> b/osaf/libs/agents/saf/ntfa/ntfa_mds.c
>>> --- a/osaf/libs/agents/saf/ntfa/ntfa_mds.c
>>> +++ b/osaf/libs/agents/saf/ntfa/ntfa_mds.c
>>> @@ -1177,7 +1177,14 @@ uint32_t ntfa_mds_msg_sync_send(ntfa_cb_
>>> mds_info.info.svc_send.i_msg = (NCSCONTEXT)i_msg;
>>> mds_info.info.svc_send.i_to_svc = NCSMDS_SVC_ID_NTFS;
>>> mds_info.info.svc_send.i_sendtype = MDS_SENDTYPE_SNDRSP;
>>> - mds_info.info.svc_send.i_priority = MDS_SEND_PRIORITY_HIGH;
>>> /* fixme? */
>>> + /* initialize_msg is lower priority than the others so that
>>> + * life cycle of agent will be pritorized to complete
>>> + */
>>> + if (i_msg->info.api_info.type == NTFSV_INITIALIZE_REQ) {
>>> + mds_info.info.svc_send.i_priority = MDS_SEND_PRIORITY_MEDIUM;
>>> + } else {
>>> + mds_info.info.svc_send.i_priority =
>>> MDS_SEND_PRIORITY_HIGH; /* fixme? */
>>> + }
>>> /* fill the sub send rsp strcuture */
>>> mds_info.info.svc_send.info.sndrsp.i_time_to_wait = timeout;
>>> /* timeto wait in 10ms FIX!!! */
>>> mds_info.info.svc_send.info.sndrsp.i_to_dest = cb->ntfs_mds_dest;
>>>
>>
>
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
