[asterisk-bugs] [JIRA] (ASTERISK-26724) Hints appear to not expire properly resulting in duplicates

[Zach R (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234679#comment-234679 ] 

Zach R edited comment on ASTERISK-26724 at 1/17/17 12:10 PM:
-------------------------------------------------------------

Marked as duplicate by Joshua, was just wondering if I should upload the data attached to teh duplicate ticket as well


was (Author: zrothy):
Marked as duplicate by asteirsk, wasj ust wondering if I should upload the data attached to teh duplicate ticket as well

> Hints appear to not expire properly resulting in duplicates
> -----------------------------------------------------------
>
>                 Key: ASTERISK-26724
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26724
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_pubsub
>    Affects Versions: 13.0.0
>         Environment:  CentOS 6.6 Final 
>            Reporter: Zach R
>            Assignee: Unassigned
>            Severity: Minor
>         Attachments: set1-duplicates.txt, set1-hints.txt, set1-subscription_persistence.txt, set2-duplicates.txt, set2-hints.txt, set2-subscription_persistence.txt
>
>
> We have one serve that is running asterisk 13 in production. Once in the past we had noticed one day due to a reported trouble, that a couple hints were in the thousands for the number of watchers they had. This had been causing trouble due to maxing of bandwidth for this instance.
> Temporarily this was resolved by removing the hint and re-adding the hint with dialplan reloads, letting the endpoints resubscribe to bring it to the proper amount of watchers. Once this occurred we had set a shell script that dumps the subscriptions from the asterisk database as well as the hints via core show hints so we could see if it continued to increase again.
> Some of the subscriptions that were present in the database had been old, and duplicates of a present subscription based on the subscription persistence tokens. Basically for the duplicates there was one that would be expiring earlier than the second (though the timestamps did not appear to be updates as in issue ASTERISK-26696.
> Recently this started to happen again on the same server showing it slowly increased for two different sets of hints. The first set increased by 1 for each phone that the endpoint was watching and the subscription persistence showed duplicates for 1 endpoint having the 2nd subscription. The duplicates showed the first subscription was around 4 AM when we have our phones resync their configurations for Cisco SPA series phones. The second sub of the duplicate set was around 10 AM that morning and both appeared to be active.
> The second set had increased by two watchers for each. With the first 2 being ones that should have expired.
> I've attached the relevant files below. Each set has 3 files, with the first set being the hints that increased by one, and the second being the one that increased by two. 
> * hints - Contains the output of core show hints for with the set in question isolated. This is a diff of the files with the removed lines being the day before and the added lines being the day after it.
> * subscription_persistence - Contains the subscription_persistence tokens from the AST DB for the set which match up the hints
> * duplicates_subscriptions - Contains just the subscription_persistence tokens that appeared to be duplicate and active.
> If any additional logging is needed such as a sip debug to one of the duplicate subscriptions it can be gotten as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)