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.
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.

Please correct me if I am wrong.  

Regards,
Somashekhar

-----Original Message-----
From: Robert Varga [mailto:[email protected]] 
Sent: Monday, January 21, 2019 4:17 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 21/01/2019 11:28, SOMASHEKHAR MANOHARA JAVALAGI wrote:
> Hi Anil

Hello,

> Referring to the comments of jira
> https://jira.opendaylight.org/browse/OPNFLWPLUG-1060
> 
>  
> 
> We have received two events for the same flow-id in below order.
> 
> ADD event:           ADD flow with priority = 9
> 
>  
> 
> UPDATE event :   DELETE flow with priority = 9
> 
>  
> 
>                               ADD flow with priority = 6.
> 
>  
> 
>  
> 
> But the UPDATE event is processed first before ADD event.
> 
> Which is first trying to DELETE flow which doesn't exist followed by 
> adding both the flows, though we received DataTreeChangeNotification 
> in proper order.
> 
>  
> 
> Earlier we were handling flow mod requests in JobQueueHandler of 
> NodeConfiguratorImpl, which was ensuring ordered processing.
> 
> With recent changes, we are using
> org.opendaylight.yangtools.util.concurrent.QueuedNotificationManager 
> for request queue handling, which in this case is not ensuring the order.

That is quite weird, because QueuedNotificationManager's sole purpose is to 
deliver events in order (for the specified key).

Can you run this case with https://git.opendaylight.org/gerrit/79790 and 
log:set trace 
org.opendaylight.openflowplugin.applications.frm.nodeconfigurator.NodeConfiguratorImpl


This should show the order of enqueue/dispatch of events for each key.

Thanks,
Robert

_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to