Process flex counters requests in separate thread #483
Conversation
|
@wendani , can you take a look? |
| { | ||
| // event was not successfully processed, put it again to the queue | ||
|
|
||
| pushFlexCounterEvent(kco); |
There was a problem hiding this comment.
This may upset the event sequence in the processing failure case. The processing failure case, however, is the problem you would like to solve.
For the flex counter table in particular, it typically contains the counter id list that is expected to remain static and unchanged after SET. We should not see any two operations on the same key in the queue at the same time, although there leaves the possibility of running into such a sequence problem.
If we enqueue at the front and retry, we can avoid the event sequence problem. However, we may experience head of line blocking until the event processing retry succeeds.
There was a problem hiding this comment.
i don't get the problem you described here, all those issues with counters are present here which we want to workaround because they are executed on the same channel and can be picked up by select independently, and i stated at the beginning that subscribe to the counter is broken design and of course you can came up with scenario that can break even this workaround, since you need to wait for RIF to be created and for example potentially not destroyed and created again, which all would be solved when syncd would become synchronous on which i already send PR
| } | ||
| } | ||
|
|
||
| sleep(1); |
There was a problem hiding this comment.
Can we wake up every 1 second only if there is a processing event failure? In other cases, we wake up on an enqueue event. Flex counter table event should be very rare after the initialization.
There was a problem hiding this comment.
this is actually overkill to make other thread and condition variable to wait for specific event, also making that event, also don't guarantee that this event will be processed after second select will create rif port, so there must be wait somewhere anyway.
Even if those counter events are rare, this is generic case, i don't know whether orchagent will want to create/destroy next counter in 2 days of running or any other time
|
@kcudnik , can you resolve the conflict? |
No description provided.