Discussion:
[asterisk-dev] [Code Review] app_queue: Don't log PAUSEALL/UNPAUSEALL for an interface if it doesn't exist in any queue when pause
jrose
2012-08-17 21:32:58 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2079/
-----------------------------------------------------------

Review request for Asterisk Developers, Jason Parker, jbigelow, and Matt Jordan.


Summary
-------

When pause or unpause to an interface for a queue either through manager or the CLI command 'queue pause <interface>' without specifying a specific queue, Asterisk will currently write the following to the queue log:

<epoch>|NONE|NONE|<interface>|PAUSEALL
- or UNPAUSEALL in the case of unpausing.

This will happen regardless of whether the interface is actually a member of any queue.

If the interface is a member of any queue, the following events will be issued for each queue the interface is a member of:

<epoch>|NONE|<queuename>|<interface>|PAUSE
- or UNPAUSE in the case of uspausing.

This patch changes the behavior of logging the PAUSEALL/UNPAUSEALL events so that they are only written once a queue has been found for which the interface is a member. Our current concensus is that having the PAUSEALL/UNPAUSEALL events displayed when no members are actually affected is confusing and unnecessary.


NOTE:
We are currently unsure of which branches this patch should go into. The discovery was made against 1.8, but this does introduce a slight behavior change to queue logging. We'd appreciate some feedback from the community indicating if anyone feels strongly for or against including this patch in 1.8.


Diffs
-----

/branches/1.8/apps/app_queue.c 371481

Diff: https://reviewboard.asterisk.org/r/2079/diff


Testing
-------

Issued the commands mentioned above against interfaces which were either included or not included against a number of queues. Situations included interfaces that were a member of 0, 1, and 2 queues.


Thanks,

jrose
Mark Michelson
2012-09-04 18:35:43 UTC
Permalink
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2079/#review7007
-----------------------------------------------------------

Ship it!


I'm of the opinion that this isn't necessarily a bug and should not go into Asterisk 1.8. To me, the queue log entry just indicates the command was issued. The lack of individual queue entries afterward is a good indicator that the interface did not actually get removed from any queues.

- Mark
Post by jrose
-----------------------------------------------------------
https://reviewboard.asterisk.org/r/2079/
-----------------------------------------------------------
(Updated Aug. 17, 2012, 4:32 p.m.)
Review request for Asterisk Developers, Jason Parker, jbigelow, and Matt Jordan.
Summary
-------
<epoch>|NONE|NONE|<interface>|PAUSEALL
- or UNPAUSEALL in the case of unpausing.
This will happen regardless of whether the interface is actually a member of any queue.
<epoch>|NONE|<queuename>|<interface>|PAUSE
- or UNPAUSE in the case of uspausing.
This patch changes the behavior of logging the PAUSEALL/UNPAUSEALL events so that they are only written once a queue has been found for which the interface is a member. Our current concensus is that having the PAUSEALL/UNPAUSEALL events displayed when no members are actually affected is confusing and unnecessary.
We are currently unsure of which branches this patch should go into. The discovery was made against 1.8, but this does introduce a slight behavior change to queue logging. We'd appreciate some feedback from the community indicating if anyone feels strongly for or against including this patch in 1.8.
Diffs
-----
/branches/1.8/apps/app_queue.c 371481
Diff: https://reviewboard.asterisk.org/r/2079/diff
Testing
-------
Issued the commands mentioned above against interfaces which were either included or not included against a number of queues. Situations included interfaces that were a member of 0, 1, and 2 queues.
Thanks,
jrose
Loading...