Re: [devel] [PATCH 1/1] amfnd: Buffered not-ack susi assignment response after both SC go down [#2105]

2017-05-18 Thread praveen malviya
Hi Minh, I had analysed the traces you attached. Based on that I am able to test that. When MDS returns success patch works fine. Minor correction is needed when MDS return failure. I think susi message should be kept independent of no. of tries in avnd_diq_del(). Thanks Praveen On 18-May-17

Re: [devel] [PATCH 1/1] amfnd: Buffered not-ack susi assignment response after both SC go down [#2105]

2017-05-18 Thread minh chau
Hi Praveen, Some comments in line with [Minh] thanks, Minh On 18/05/17 14:54, praveen malviya wrote: > Hi Minh, > > In the description of the ticket there is a log which is : > " > Oct 7 18:31:41 SYSTEST-PLD-1 osafamfnd[12467]: NO Assigned > 'safSi=TestApp_SI4,safApp=TestApp_TwoN' ACTIVE to >

Re: [devel] [PATCH 1/1] amfnd: Buffered not-ack susi assignment response after both SC go down [#2105]

2017-05-17 Thread praveen malviya
Hi Minh, In the description of the ticket there is a log which is : " Oct 7 18:31:41 SYSTEST-PLD-1 osafamfnd[12467]: NO Assigned 'safSi=TestApp_SI4,safApp=TestApp_TwoN' ACTIVE to 'safSu=TestApp_SU1,safSg=TestApp_SG1,safApp=TestApp_TwoN' Oct 7 18:31:41 SYSTEST-PLD-1 osafamfnd[12467]: NO

Re: [devel] [PATCH 1/1] amfnd: Buffered not-ack susi assignment response after both SC go down [#2105]

2017-05-17 Thread minh chau
Hi Praveen, Do you have any idea why @is_avd_down was false that made amfnd to send susi_resp at 12:37:20.453974? It should be true by the end of avnd_evt_mds_avd_dn_evh() at 12:37:16.741518, is it right? Thanks, Minh On 17/05/17 21:31, minh chau wrote: > Hi Praveen, > > Thanks for looking at

Re: [devel] [PATCH 1/1] amfnd: Buffered not-ack susi assignment response after both SC go down [#2105]

2017-05-17 Thread minh chau
Hi Praveen, Thanks for looking at the issue. Here is what I am observing amfnd-PL3 received NCSMDS_DOWN indicating no active amfd May 17 12:37:16.741308 osafamfnd [8141:8141:src/amf/amfnd/di.cc:0629] >> avnd_evt_mds_avd_dn_evh May 17 12:37:16.741342 osafamfnd

Re: [devel] [PATCH 1/1] amfnd: Buffered not-ack susi assignment response after both SC go down [#2105]

2017-05-17 Thread praveen malviya
What I see is avnd_diq_del() is called as soon as system becomes headless. This will delete all pending messages. But when component will respond during SCs absence a new message will be generated and buffered. For node_up AMFD will ack the message, but amfnd calls avnd_diq_rec_del() (not

Re: [devel] [PATCH 1/1] amfnd: Buffered not-ack susi assignment response after both SC go down [#2105]

2017-05-17 Thread praveen malviya
Hi Minh, While testing this, I am observing that amfd is dropping the assignment message because of message id mismatch: May 17 12:37:39.522117 osafamfd [7686:7686:src/amf/amfd/sgproc.cc:1171] >> avd_su_si_assign_evh: id:1, node:2030f, act:5, 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1', '',

Re: [devel] [PATCH 1/1] amfnd: Buffered not-ack susi assignment response after both SC go down [#2105]

2017-05-16 Thread Gary Lee
Hi Minh Ack (review only) On 15/5/17, 5:36 pm, "Minh Chau" wrote: When amfnd-payload responds susi assignment response just before both SC go down, and that response message does not come to director. Therefore, the status of that assignment could be seen

Re: [devel] [PATCH 1/1] amfnd: Buffered not-ack susi assignment response after both SC go down [#2105]

2017-05-15 Thread praveen malviya
Hi Minh, I am reviewing this patch. Thanks, Praveen On 15-May-17 1:06 PM, Minh Chau wrote: > When amfnd-payload responds susi assignment response just before both SC > go down, and that response message does not come to director. Therefore, > the status of that assignment could be seen as

[devel] [PATCH 1/1] amfnd: Buffered not-ack susi assignment response after both SC go down [#2105]

2017-05-15 Thread Minh Chau
When amfnd-payload responds susi assignment response just before both SC go down, and that response message does not come to director. Therefore, the status of that assignment could be seen as "modifying" in IMM. When SC comes back, active amfd will be waiting for that response forever. Patch