ExRedisPool v0.2.1 ExRedisPool
Summary
Functions
Start a new redis connection pool within ExRedisPools own supervision tree
Run a synchronous redis query
Like q/3 except returns the result directly or raises an error
Run an asynchronous redis query
Run a synchronous query pipeline
Like qp/3 except returns the result directly or raises an error
Run an asynchronous query pipeline
Called when an application is started
Start a new redis connection pool client linked to the caller
Types
redis_pool_option :: {:host, binary} | {:port, integer} | {:database, binary} | {:password, binary} | {:reconnect_sleep, reconnect_sleep} | {:sync_pool_size, integer} | {:sync_pool_max_overflow, integer} | {:async_pool_size, integer} | {:async_pool_max_overflow, integer}
Functions
Start a new redis connection pool within ExRedisPools own supervision tree..
q(pool, redis_query, integer) :: {:ok, redis_result} | {:error, reason}
Run a synchronous redis query.
Like q/3 except returns the result directly or raises an error.
Run an asynchronous redis query.
This function takes the requested query and queues it in a separate pool from the synchronous queries so bulk asynchronous queries do not degrade quality of service for synchronous queries.
qp(atom, [redis_query], integer) :: [{:ok, redis_result}] | {:error, reason}
Run a synchronous query pipeline.
qp!(pool, [redis_query], integer) :: [redis_result] | no_return
Like qp/3 except returns the result directly or raises an error.
Run an asynchronous query pipeline.
This function takes the requested query pipeline and queues it in a separate pool from the synchronous query pipelines so bulk asynchronous query pipelines do not degrade quality of service for synchronous query pipelines.
Called when an application is started.
This function is called when an the application is started using
Application.start/2
(and functions on top of that, such as
Application.ensure_started/2
). This function should start the top-level
process of the application (which should be the top supervisor of the
application’s supervision tree if the application follows the OTP design
principles around supervision).
start_type
defines how the application is started:
:normal
- used if the startup is a normal startup or if the application is distributed and is started on the current node because of a failover from another mode and the application specification key:start_phases
is:undefined
.{:takeover, node}
- used if the application is distributed and is started on the current node because of a failover on the nodenode
.{:failover, node}
- used if the application is distributed and is started on the current node because of a failover on nodenode
, and the application specification key:start_phases
is not:undefined
.
start_args
are the arguments passed to the application in the :mod
specification key (e.g., mod: {MyApp, [:my_args]}
).
This function should either return {:ok, pid}
or {:ok, pid, state}
if
startup is successful. pid
should be the PID of the top supervisor. state
can be an arbitrary term, and if omitted will default to []
; if the
application is later stopped, state
is passed to the stop/1
callback (see
the documentation for the c:stop/1
callback for more information).
use Application
provides no default implementation for the start/2
callback.
Callback implementation for Application.start/2
.
Start a new redis connection pool client linked to the caller.