[asterisk-dev] [Code Review] 3723: RLS: NOTIFY generation + structural refactor

[Mark Michelson]

> On Aug. 5, 2014, 3:57 p.m., Matt Jordan wrote:
> > /team/group/rls/res/res_pjsip_pubsub.c, lines 1091-1105
> > <https://reviewboard.asterisk.org/r/3723/diff/3/?file=65309#file65309line1091>
> >
> >     This is really more of a general question then a specific finding, however:
> >     
> >     What is the threading model for updating/iterating/destroying children in a tree? What all threads can access a subscription's children? Does a subscription need to be locked?

{quote}
What is the threading model for updating/iterating/destroying children in a tree?
{quote}

The tree, after creation, is immutable by convention. Children are never updated/added/destroyed after the initial tree creation.


{quote}
What all threads can access a subscription's children?
{quote}

Since the tree is immutable, any thread may access the subscription's children, so long as they have a reference to the tree root. If we switched to a model where changes to list configuration could allow for the tree to be altered mid-subscription, we would force any tasks that modified the tree or iterated over it to be pushed to the subscription's serializer. Currently, most iterations are performed in the serializer anyway. The exceptions are iterations that occur due to certain callbacks from PJSIP that terminate the subscription (such as a subscription timeout). The AMI command that shows subscriptions may also eventually iterate over child subscriptions, too. It does not, currently though.

{quote}
Does a subscription need to be locked?
{quote}

Nope. The tree structure is immutable, and any other subscription data is altered only in the subscription's serializer, so there is no need for a lock.


- Mark


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


On July 25, 2014, 8:57 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3723/
> -----------------------------------------------------------
> 
> (Updated July 25, 2014, 8:57 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23869
>     https://issues.asterisk.org/jira/browse/ASTERISK-23869
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This adds NOTIFY support for resource list subscriptions. The way this works is as follows:
> 
> When an initial SUBSCRIBE arrives and the subscription tree is built, all leaf nodes are called into in order to generate their initial NOTIFY bodies and store these on their respective subscription nodes.
> 
> Sending a NOTIFY requires traversing the tree. List subscriptions will generate a multipart/related body with an RLMI part and parts corresponding to the leaves of the list (at least they will eventually. ASTERISK-23867 involves doing this part). Single-resource subscriptions read the stored body on the subscription and uses that to populate the NOTIFY body.
> 
> Leaf nodes in the subscription tree, when they have a state change occur, call ast_sip_subscription_notify(), as they previously did. ast_sip_subscription_notify() creates the NOTIFY body for the subscription and stores that on the subscription in the body_text ast_str field. The subscription tree is then told to send a NOTIFY if no batching is enabled or to start a batched NOTIFY if batching is enabled.
> 
> When a resource resubscribes or terminates their subscription, a NOTIFY is now automatically generated by the pubsub core instead of calling into subscription handlers. The NOTIFY is built the same way as previously, using stored NOTIFY bodies on the subscription. This NOTIFY can also cause batched notification, when the timer fires, not to actually send their batch since it would be redundant.
> 
> You'll notice the code has been refactored slightly, and a new struct, sip_subscription_tree, has invaded res_pjsip_pubsub. This is because, as I was separating the "real" and "virtual" parts of ast_sip_subscriptions out, I realized that I essentially had two distinct structures. Thus, I separated the real/meta/base elements of a subscription into the sip_subscription_tree, and the resource-specific parts into the ast_sip_subscription struct. sip_subscription_tree is used more heavily in the pubsub core now, whereas ast_sip_subscription acts as a handle for subscription handlers to use plus a repository for resource-specific data.
> 
> 
> Diffs
> -----
> 
>   /team/group/rls/res/res_pjsip_pubsub.c 418321 
>   /team/group/rls/res/res_pjsip_mwi.c 418321 
>   /team/group/rls/res/res_pjsip_exten_state.c 418321 
>   /team/group/rls/include/asterisk/res_pjsip_pubsub.h 418321 
> 
> Diff: https://reviewboard.asterisk.org/r/3723/diff/
> 
> 
> Testing
> -------
> 
> With this set of changes, I'm still not able to perform RLS-specific tests since there is still no method of generating multipart/related or RLMI bodies. However, with these changes, I did run the gamut of subscription tests in the testsuite and they all pass. This at least means that there are no detectable regressions at this point.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140805/11f34e30/attachment-0001.html>