| Age | Commit message (Collapse) | Author |
|---|
|
When built-in components of Asterisk fail to start they cause the
Asterisk startup to abort. In these cases only the most critical
cleanup should be performed - closing databases and terminating
proceses. These cleanups are registered using ast_register_atexit, all
other cleanups should not be run during startup abort.
The main reason for this change is that these cleanup procedures are
untestable from the partially initialized states, if they fail it could
prevent us from ever running the critical cleanup with ast_run_atexits.
Create separate initialization for dns_core.c to be run unconditionally
during startup instead of being initialized by the first dns resolver to
be registered. This ensures that 'sched' is initialized before it can be
potentially used.
Replace ast_register_atexit with ast_register_cleanup in media_cache.c.
There is no reason for this cleanup to happen unconditionally.
Change-Id: Iecc2df98008b21509925ff16740bd5fa29527db3
|
|
This uses AO2_STRING_FIELD_HASH_FN and AO2_STRING_FIELD_CMP_FN where
possible in the Asterisk core.
This removes CMP_STOP from the result of CMP_FN callbacks for the
following structure types:
* ast_bucket_metadata
* ast_bucket_scheme
* generic_monitor_instance_list (ccss.c)
* ast_bucket_file (media_cache.c)
* named_acl
Change-Id: Ide4c1449a894bce70dea1fef664dade9b57578f1
|
|
Change-Id: Icc0dc6e61b2e68d5cdcb74b016b2726a388c7def
|
|
In the event that a cache file is removed out from under us, we should
treat the cache entry as stale and force a refresh.
ASTERISK-26774 #close
Reported by: Igor Gamayunov
Change-Id: I3b1bd0c999d59d18664ef73a29823bc5b431dc52
|
|
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
|
|
The file playback system will now query the media cache and then
the old file functionality. Under normal conditions this will result
in the cache failing to retrieve a file causing a warning message
to get output each time a file is played back.
This change demotes this warning to a debug message.
Change-Id: Ib72246ba300b5cce32774bfb3c26634bfb708624
|
|
This patch does the following:
First, it addresses file extension handling in the media cache. The media core
in Asterisk is a bit interesting in that it wants:
* A file to have an extension on it. That extension is used to associate the
file with a defined format module.
* The filename passed to the core to not have an extension on it. This allows
the core to match the available file formats with the format a channel
is capable of handling.
Unfortunately, this makes the current implementation a bit lacking in the media
cache. By default, we do not store the extension of a retrieved URI on the
local file that is created. As a result, the media core does not know what
format the file is, and the file is ignored. Modifying the file outside of the
media core is bad, as we would not be able to update the internal
ast_bucket_file's path.
At the same time, we do not want to pass the extension out in the file_path
parameter in ast_media_cache_retrieve. This parameter is intended to be fed
into the media core; if we passed the extension, all callers would have to
strip it off.
Thus, this patch does the following:
* If there is an extension specified in the URL, we append it to the local
file name (if a preferred file name isn't specified), and we store that
in the local file path.
* The extension, however, is stripped off of the file_path parameter passed
back out of ast_media_cache_retrieve.
Second, this patch causes stale items to be completely removed from the system.
Prior to this patch, sound files could be orphaned due to the bucket
referencing the file being deleted, but the file itself not being removed. This
is now addressed by explicitly calling ast_bucket_file_delete on the
bucket_file when it is deemed to be stale. Note that this only happen when we
know we will attempt to retrieve the resource again.
Finally, this patch changes the AO2 container holding media items to just use
a regular mutex. The usage for this container already assumed it was a plain
mutex, and - given that retrieval of an item can cause it to be replaced in
the container - a mutex makes more sense than a read/write lock.
Change-Id: I51667fff86ae8d2e4a663555dfa85b11e935fe0f
|
|
This patch adds five CLI commands for the media cache:
* 'media cache show all' - display a summary of all items in the media
cache.
* 'media cache show <uri>' - display detailed information about a
single item in the media cache.
* 'media cache delete <uri>' - remove an item from the media cache, and
inform the bucket backend for the URI scheme to remove the item as
well.
* 'media cache refresh <uri>' - refresh a URI. If the item does not
exist in the media cache, the bucket backend will pull down the media
associated with the URI and create the item in the cache.
* 'media cache create <uri>' - create an item in the media cache from
some local media storage. Note that the bucket backend for the URI
scheme must still permit the item creation.
Change-Id: Id1c5707a3b8e2d96b56e4691a46a936cd171f4ae
|
|
This patch adds a new API to the Asterisk core that acts as a media
cache. The core API itself is mostly a thin wrapper around some bucket
API provided implementation that itself acts as the mechanism of
retrieval for media. The media cache API in the core provides the
following:
* A very thin in-memory cache of the active bucket_file items. Unlike a
more traditional cache, it provides no expiration mechanisms. Most
queries that hit the in-memory cache will also call into the bucket
implementations as well. The bucket implementations are responsible
for determining whether or not the active record is active and valid.
This makes sense for the most likely implementation of a media cache
backend, i.e., HTTP. The HTTP layer itself is the actual arbiter of
whether or not a record is truly active; as such, the in-memory cache
in the core has to defer to it.
* The ability to create new items in the media cache from local
resources. This allows for re-creation of items in the cache on
restart.
* Synchronization of items in the media cache to the AstDB. This
also includes various pieces of important metadata.
The API provides sufficient access that higher level APIs, such as the
file or app APIs, do not have to worry about the semantics of the bucket
APIs when needing to playback a resource.
In addition, this patch provides unit tests for the media cache API. The
unit tests use a fake bucket backend to verify correctness.
Change-Id: I11227abbf14d8929eeb140ddd101dd5c3820391e
|
