This policy is from memory, so I might be off on some of the details. You might check the docs in revent. What I'll say here might be a bit conservative.
Handlers have a priority, and they're called in that order. Handlers of the same priority are called in unspecified order. A handler registered without specifying a priority is called in unspecified order. A handler can return a Halt value which will prevent further handlers from being called for that event. It makes no sense to have l2_learning and l2_pairs running for the same physical switch. Actually doing this will result in strange behavior at best. You *could* set up your controller to have one of those running on some switches and the other running on others. Most of the components aren't really set up for this, but it should be possible. It's also possible to create multiple Nexus objects (core.openflow is the default OpenFlow Nexus, but not necessarily the only one) and assign different physical switches to them using an Arbiter, but this is even less supported. What's your use case? -- Murphy On Jan 31, 2013, at 4:04 PM, Weiyang Mo wrote: > Hi, > > I'm currently interested in that how POX handle the ordering of event, I > think I missed such basic knowledge in the past. For example, if module 1 > (l2_learning) and module 2(l2_pairs) are running at the same time. > > Which will be executed? I think both modules will listen to the packet_in and > only the first one I type (l2_learning) will respond, right? > > For instance,run ./pox.py l2_learning l2_paris. When I ping hosts, some > errors will generate (bad_request). I think the errors are related how > modules handle the packet_in, any advice? > > Thanks > > Weiyang
