[asterisk-dev] [Code Review] New AMI Command LocalOptimizeAway

[Russell Bryant]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/732/#review2248
-----------------------------------------------------------



http://svn.asterisk.org/svn/asterisk/trunk/channels/chan_local.c
<https://reviewboard.asterisk.org/r/732/#comment4757>

    Reading chan->name is not safe without holding the channel lock.  However, to get this channel lock, you'll have to do some deadlock avoidance, since you can't directly lock the local_pvt and then the ast_channel.  The defined locking order is the other way around.


- Russell


On 2010-06-22 16:46:59, tim_ringenbach wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/732/
> -----------------------------------------------------------
> 
> (Updated 2010-06-22 16:46:59)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Adds a new manager command LocalOptimizeAway. It clears the flag on a local channel that says not to optimize it away.
> 
> General use case: You need the behavior of "/n" for a while, but then something else happens (typically a transfer) and you no longer desire that behavior.
> 
> Specific Use case: Using local channels as queue members without stateinterface, using /n to keep the local channel up so the agent doesn't get another call, then on transfer issuing this manager command so the local channel goes away and the agent can get another call.
> 
> 
> Diffs
> -----
> 
>   http://svn.asterisk.org/svn/asterisk/trunk/channels/chan_local.c 271972 
> 
> Diff: https://reviewboard.asterisk.org/r/732/diff
> 
> 
> Testing
> -------
> 
> We have the 1.4 version of the patch in production at several sites. The trunk version actually submitted here has only minimal testing: I logged into the manager once and issued the command and observed that it worked as expected.
> 
> 
> Thanks,
> 
> tim_ringenbach
> 
>