Currently the "pending_list" - which is a list of stored bundles requiring evaluation for possible state change (e.g. if a timer ran out or CLA came up, etc) - is processed as part of the periodic maintenance task. This means that items placed on this list will be evaluated by the maintenance task at the next poll cycle.
However, the size of this queue becomes limited by the RAM pool size (e.g. 1M in bpcat) and in cases where the pool becomes empty this means that the entire system becomes inoperative until the polling cycle runs and moves the buffers along.
This could be addressed using the job scheduling for this purpose, which is currently only used for internal bundle queues right now. Using this facility should allow processing the pending_list to occur without waiting for the next polling cycle.
Currently the "pending_list" - which is a list of stored bundles requiring evaluation for possible state change (e.g. if a timer ran out or CLA came up, etc) - is processed as part of the periodic maintenance task. This means that items placed on this list will be evaluated by the maintenance task at the next poll cycle.
However, the size of this queue becomes limited by the RAM pool size (e.g. 1M in bpcat) and in cases where the pool becomes empty this means that the entire system becomes inoperative until the polling cycle runs and moves the buffers along.
This could be addressed using the job scheduling for this purpose, which is currently only used for internal bundle queues right now. Using this facility should allow processing the pending_list to occur without waiting for the next polling cycle.