[asterisk-app-dev] channel origination race condition discussion

[David M. Lee]

On Dec 4, 2013, at 4:12 PM, Matt DiMeo <mdimeo at digium.com> wrote:

> Regarding the "Originate/Channel Creation as a two step proces" thread:
>>> Another option would be to allow the user to specify the unique id of the
>>> channel. This seems a bit frightening, but might be worth pursuing.
> 
> I kinda like this idea too, if I could ask asterisk to allocate me a valid channel id I could then use with an originate.

Functionally, this is very similar to the two-step origination process.

> I've had a similar worry with PlaybackStopped.  In that case I wored around the race condition by doing a GET on the playbackID as soon as I get one back, and then treating a failed GET as a stopped playback.
> 
> This is all another reason I hate having requests and events going through different pipes.  If I could send the request down the websocket, and asterisk promised to give me the channel id response on the websocket before sending me any events about it, there'd be no race condition.  But I guess that ship has sailed.

We could do something similar to SwaggerSocket[1] to synchronize all communication over a single connection. Then responses and events would be serialized, avoiding the reordering issue.

That has its own problems, though. AMI works in a very similar manner (events and action/response multiplexed on the same socket). As with most things, there are tradeoffs. When the system starts to see high loads, the increased latency having responses interleaved with events starts to cause problems.

 [1]: https://github.com/wordnik/swaggersocket/wiki/SwaggerSocket-Protocol

-- 
David M. Lee
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org