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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
