Skip to content
Snippets Groups Projects
  1. Nov 18, 2018
    • Joshua Colp's avatar
      stasis: Add internal filtering of messages. · 3077ad0c
      Joshua Colp authored
      This change adds the ability for subscriptions to indicate
      which message types they are interested in accepting. By
      doing so the filtering is done before being dispatched
      to the subscriber, reducing the amount of work that has
      to be done.
      
      This is optional and if a subscriber does not add
      message types they wish to accept and set the subscription
      to selective filtering the previous behavior is preserved
      and they receive all messages.
      
      There is also the ability to explicitly force the reception
      of all messages for cases such as AMI or ARI where a large
      number of messages are expected that are then generically
      converted into a different format.
      
      ASTERISK-28103
      
      Change-Id: I99bee23895baa0a117985d51683f7963b77aa190
      3077ad0c
  2. Oct 27, 2016
    • Corey Farrell's avatar
      Remove ASTERISK_REGISTER_FILE. · a6e5bae3
      Corey Farrell authored
      ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
      all traces of it.
      
      Previously exported symbols removed:
      * __ast_register_file
      * __ast_unregister_file
      * ast_complete_source_filename
      
      This also removes the mtx_prof static variable that was declared when
      MTX_PROFILE was enabled.  This variable was only used in lock.c so it
      is now initialized in that file only.
      
      ASTERISK-26480 #close
      
      Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
      a6e5bae3
  3. May 23, 2015
    • Corey Farrell's avatar
      Stasis: Fix unsafe use of stasis_unsubscribe in modules. · 50044fdc
      Corey Farrell authored
      Many uses of stasis_unsubscribe in modules can be reached through unload.
      These have been switched to stasis_unsubscribe_and_join.
      
      Some subscription callbacks do nothing, for these I've created a noop
      callback function in stasis.c.  This is used by some modules that monitor
      MWI topics in order to enable cache, since the callback does not become
      invalid after dlclose it is safe to use stasis_unsubscribe on these, even
      during module unload.
      
      ASTERISK-25121 #close
      
      Change-Id: Ifc2549fbd8eef7d703c222978e8f452e2972189c
      50044fdc
  4. Apr 24, 2015
    • Diederik de Groot's avatar
      Clang: Fix some more tautological-compare warnings. · f8e21a1a
      Diederik de Groot authored
      clang can warn about a so called tautological-compare, when it finds
      comparisons which are logically always true, and are therefor deemed
      unnecessary.
      
      Exanple:
      unsigned int x = 4;
      if (x > 0)    // x is always going to be bigger than 0
      
      Enum Case:
      Each enumeration is its own type. Enums are an integer type but they
      do not have to be *signed*. C leaves it up to the compiler as an
      implementation option what to consider the integer type of a particu-
      lar enumeration is. Gcc treats an enum without negative values as
      an int while clang treats this enum as an unsigned int.
      
      rmudgett & mmichelson: cast the enum to (unsigned int) in assert.
      The cast does have an effect. For gcc, which seems to treat all enums
      as int, the cast to unsigned int will eliminate the possibility of
      negative values being allowed. For clang, which seems to treat enums
      without any negative members as unsigned int, the cast will have no
      effect. If for some reason in the future a negative value is ever
      added to the enum the assert will still catch the negative value.
      
      ASTERISK-24917
      Change-Id: Ief23ef68916192b9b72dabe702b543ecfeca0b62
      f8e21a1a
  5. Apr 13, 2015
    • Matt Jordan's avatar
      git migration: Refactor the ASTERISK_FILE_VERSION macro · 4a582616
      Matt Jordan authored
      Git does not support the ability to replace a token with a version
      string during check-in. While it does have support for replacing a
      token on clone, this is somewhat sub-optimal: the token is replaced
      with the object hash, which is not particularly easy for human
      consumption. What's more, in practice, the source file version was often
      not terribly useful. Generally, when triaging bugs, the overall version
      of Asterisk is far more useful than an individual SVN version of a file. As a
      result, this patch removes Asterisk's support for showing source file
      versions.
      
      Specifically, it does the following:
      
      * Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
        remove passing the version in with the macro. Other facilities
        than 'core show file version' make use of the file names, such as
        setting a debug level only on a specific file. As such, the act of
        registering source files with the Asterisk core still has use. The
        macro rename now reflects the new macro purpose.
      
      * main/asterisk:
        - Refactor the file_version structure to reflect that it no longer
          tracks a version field.
        - Remove the "core show file version" CLI command. Without the file
          version, it is no longer useful.
        - Remove the ast_file_version_find function. The file version is no
          longer tracked.
        - Rename ast_register_file_version/ast_unregister_file_version to
          ast_register_file/ast_unregister_file, respectively.
      
      * main/manager: Remove value from the Version key of the ModuleCheck
        Action. The actual key itself has not been removed, as doing so would
        absolutely constitute a backwards incompatible change. However, since
        the file version is no longer tracked, there is no need to attempt to
        include it in the Version key.
      
      * UPGRADE: Add notes for:
        - Modification to the ModuleCheck AMI Action
        - Removal of the "core show file version" CLI command
      
      Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
      4a582616
  6. Sep 30, 2013
    • David M. Lee's avatar
      Multiple revisions 399887,400138,400178,400180-400181 · 2de42c2a
      David M. Lee authored
      ........
        r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
        
        Minor performance bump by not allocate manager variable struct if we don't need it
      ........
        r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
        
        Stasis performance improvements
        
        This patch addresses several performance problems that were found in
        the initial performance testing of Asterisk 12.
        
        The Stasis dispatch object was allocated as an AO2 object, even though
        it has a very confined lifecycle. This was replaced with a straight
        ast_malloc().
        
        The Stasis message router was spending an inordinate amount of time
        searching hash tables. In this case, most of our routers had 6 or
        fewer routes in them to begin with. This was replaced with an array
        that's searched linearly for the route.
        
        We more heavily rely on AO2 objects in Asterisk 12, and the memset()
        in ao2_ref() actually became noticeable on the profile. This was
        #ifdef'ed to only run when AO2_DEBUG was enabled.
        
        After being misled by an erroneous comment in taskprocessor.c during
        profiling, the wrong comment was removed.
        
        Review: https://reviewboard.asterisk.org/r/2873/
      ........
        r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
        
        Taskprocessor optimization; switch Stasis to use taskprocessors
        
        This patch optimizes taskprocessor to use a semaphore for signaling,
        which the OS can do a better job at managing contention and waiting
        that we can with a mutex and condition.
        
        The taskprocessor execution was also slightly optimized to reduce the
        number of locks taken.
        
        The only observable difference in the taskprocessor implementation is
        that when the final reference to the taskprocessor goes away, it will
        execute all tasks to completion instead of discarding the unexecuted
        tasks.
        
        For systems where unnamed semaphores are not supported, a really
        simple semaphore implementation is provided. (Which gives identical
        performance as the original taskprocessor implementation).
        
        The way we ended up implementing Stasis caused the threadpool to be a
        burden instead of a boost to performance. This was switched to just
        use taskprocessors directly for subscriptions.
        
        Review: https://reviewboard.asterisk.org/r/2881/
      ........
        r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
        
        Optimize how Stasis forwards are dispatched
        
        This patch optimizes how forwards are dispatched in Stasis.
        
        Originally, forwards were dispatched as subscriptions that are invoked
        on the publishing thread. This did not account for the vast number of
        forwards we would end up having in the system, and the amount of work it
        would take to walk though the forward subscriptions.
        
        This patch modifies Stasis so that rather than walking the tree of
        forwards on every dispatch, when forwards and subscriptions are changed,
        the subscriber list for every topic in the tree is changed.
        
        This has a couple of benefits. First, this reduces the workload of
        dispatching messages. It also reduces contention when dispatching to
        different topics that happen to forward to the same aggregation topic
        (as happens with all of the channel, bridge and endpoint topics).
        
        Since forwards are no longer subscriptions, the bulk of this patch is
        simply changing stasis_subscription objects to stasis_forward objects
        (which, admittedly, I should have done in the first place.)
        
        Since this required me to yet again put in a growing array, I finally
        abstracted that out into a set of ast_vector macros in
        asterisk/vector.h.
        
        Review: https://reviewboard.asterisk.org/r/2883/
      ........
        r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
        
        Remove dispatch object allocation from Stasis publishing
        
        While looking for areas for performance improvement, I realized that an
        unused feature in Stasis was negatively impacting performance.
        
        When a message is sent to a subscriber, a dispatch object is allocated
        for the dispatch, containing the topic the message was published to, the
        subscriber the message is being sent to, and the message itself.
        
        The topic is actually unused by any subscriber in Asterisk today. And
        the subscriber is associated with the taskprocessor the message is being
        dispatched to.
        
        First, this patch removes the unused topic parameter from Stasis
        subscription callbacks.
        
        Second, this patch introduces the concept of taskprocessor local data,
        data that may be set on a taskprocessor and provided along with the data
        pointer when a task is pushed using the ast_taskprocessor_push_local()
        call. This allows the task to have both data specific to that
        taskprocessor, in addition to data specific to that invocation.
        
        With those two changes, the dispatch object can be removed completely,
        and the message is simply refcounted and sent directly to the
        taskprocessor.
        
        Review: https://reviewboard.asterisk.org/r/2884/
      ........
      
      Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2de42c2a
  7. Aug 30, 2013
    • Kevin Harwell's avatar
      Fix various memory leaks · 16b8d0cb
      Kevin Harwell authored
      main/config.c - cleanup cache fie includes
      res/res_security_log.c - unregister logger level
      channesl/chan_sip.c - cleanup io context and notify_types
      main/translator.c - cleanup at shutdown
      main/named_acl.c - cleanup cli commands
      main/indications.c - ast_get_indication_tone() unref default_tone_zone if used
      
      (closes issues ASTERISK-22378)
      Reported by: Corey Farrell
      Patches:
           config_shutdown.patch uploaded by coreyfarrell (license 5909)
           res_security_log.patch uploaded by coreyfarrell (license 5909)
           chan_sip-11.patch uploaded by coreyfarrell (license 5909)
           indications_refleak.patch uploaded by coreyfarrell (license 5909)
           named_acl-cli_unreg-trunk.patch uploaded by coreyfarrell (license 5909)
           translate_shutdown.patch uploaded by coreyfarrell (license 5909)
      
      ........
      
      Merged revisions 398102 from http://svn.asterisk.org/svn/asterisk/branches/1.8
      ........
      
      Merged revisions 398103 from http://svn.asterisk.org/svn/asterisk/branches/11
      ........
      
      Merged revisions 398116 from http://svn.asterisk.org/svn/asterisk/branches/12
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      16b8d0cb
  8. Aug 17, 2013
    • Kinsey Moore's avatar
      Strip down the old event system · 59753b1e
      Kinsey Moore authored
      This removes unused code, event types, IE pltypes, and event IE types
      where possible and makes several functions private that were once
      public. This includes a renumbering of the remaining event and IE types
      which breaks binary compatibility with previous versions. The last
      remaining consumers of the old event system (or parts thereof) are
      main/security_events.c, res/res_security_log.c, tests/test_cel.c,
      tests/test_event.c, main/cel.c, and the CEL backends.
      
      Review: https://reviewboard.asterisk.org/r/2703/
      (closes issue ASTERISK-22139)
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      59753b1e
  9. May 17, 2013
  10. Jul 14, 2011
  11. Jul 11, 2009
    • Russell Bryant's avatar
      Add an API for reporting security events, and a security event logging module. · 4cf8a968
      Russell Bryant authored
      This commit introduces the security events API.  This API is to be used by
      Asterisk components to report events that have security implications.
      A simple example is when a connection is made but fails authentication.  These
      events can be used by external tools manipulate firewall rules or something
      similar after detecting unusual activity based on security events.
      
      Inside of Asterisk, the events go through the ast_event API.  This means that
      they have a binary encoding, and it is easy to write code to subscribe to these
      events and do something with them.
      
      One module is provided that is a subscriber to these events - res_security_log.
      This module turns security events into a parseable text format and sends them
      to the "security" logger level.  Using logger.conf, these log entries may be
      sent to a file, or to syslog.
      
      One service, AMI, has been fully updated for reporting security events.
      AMI was chosen as it was a fairly straight forward service to convert.
      The next target will be chan_sip.  That will be more complicated and will
      be done as its own project as the next phase of security events work.
      
      For more information on the security events framework, see the documentation
      generated from doc/tex/.  "make asterisk.pdf"
      
      Review: https://reviewboard.asterisk.org/r/273/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      4cf8a968
Loading