Stop overriding GOMAXPROCS within the program,
recent golang releases will set this to the number of CPUs (by default) automatically.
(And some users may want to override the environment variable manually)
The most recent versions of golang will use the number of available CPUs
automatically (for GOMAXPROC), instead of a single CPU.
What uniqush did before is no longer recommended.
Not sure if the singleton for initializing push service managers is necessary
(done once on startup), but keeping it
Allow tracking additional fields about subscriptions.
If /subscriptions is called with include_delivery_point_ids=1, this
will return unique identifiers for each delivery point.
This allows you to implement custom logic in clients of uniqush-push,
e.g. to push different payloads (or not push at all)
to endpoints running app_version 1.2.3 of your app or newer.
/push accepts a parameter delivery_point_id with a comma separated list of
delivery point ids to push to, e.g.
delivery_point_id="apns:abcdef0123456777777777"
to push to a single delivery point id
Add an optional slave_host and slave_port to the uniqush config.
If these are set, then uniqush will perform redis read operations against
the slave instead of the master.
This may help with scaling if the redis master
(or the collection of sharded redis masters) has high load.
Make the APNS pool size configurable at runtime.
Stop overriding GOMAXPROCS within the program, recent golang releases will set this to the number of CPUs (by default) automatically. (And some users may want to override the environment variable manually)
The most recent versions of golang will use the number of available CPUs automatically (for GOMAXPROC), instead of a single CPU.
What uniqush did before is no longer recommended.
Not sure if the singleton for initializing push service managers is necessary (done once on startup), but keeping it
Allow tracking additional fields about subscriptions.
include_delivery_point_ids=1
, this will return unique identifiers for each delivery point.This allows you to implement custom logic in clients of uniqush-push, e.g. to push different payloads (or not push at all) to endpoints running
app_version
1.2.3 of your app or newer./push
accepts a parameter delivery_point_id with a comma separated list of delivery point ids to push to, e.g.delivery_point_id="apns:abcdef0123456777777777"
to push to a single delivery point idAdd an optional
slave_host
andslave_port
to the uniqush config. If these are set, then uniqush will perform redis read operations against the slave instead of the master. This may help with scaling if the redis master (or the collection of sharded redis masters) has high load.