Hi Robert, Thanks for the clarification. Yes, I see the listenerCache which stores the executing entry for a particular key(NodeRef). Even I tested the same with 10k flow mod entries. It works perfectly fine. I have already asked in jira to reproduce the issue by enabling the logs.
Regards, Somashekhar -----Original Message----- From: Robert Varga [mailto:[email protected]] Sent: Tuesday, January 22, 2019 10:29 PM To: SOMASHEKHAR MANOHARA JAVALAGI <[email protected]>; Anil Vishnoi <[email protected]>; openflowplugin-dev <[email protected]> Subject: Re: (OPNFLWPLUG-1060) instance not able to curl metadata On 22/01/2019 08:02, SOMASHEKHAR MANOHARA JAVALAGI wrote: > Hi Robert, > > I agree that the below mentioned log prints the events in order as per the > enqueued order while enqueuing events. > But the QueuedNotificationManager adds requests into the queue and feeds them > to the syncThreadPool to execute. > The syncThreadPool threads can orderly take the jobs, but individual thread > can take its own time to finish the job. That is not the correct description of what QueuedNotificationManager does, as in that case there would be no value in it -- any old threadpool could do that. It adds *one* task for each key, which then continues to consume the associated queue until it is empty, at which point it terminates. If there is an existing task, we do not submit a new one, but continue feeding it with more notifications. This matches the semantics defined in NodeConfigurator: jobs for a particular key have to be delivered in-order, but there is no requirement to retain ordering of events between two keys. > It can also happen, so that the earlier job in the queue may end up finishing > its execution after the recently added jobs, which may happen very rarely. > But the earlier implementation was ensuring the order, by marking executing > task and unmarking the same after execution completes and fetching the new > task. As noted above, QNM achieves this in a different, more scalable. Can I suggest you repreduce the issue with traces on CMI and QNM and share the logs in the JIRA issue? Thanks, Robert _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
