Changelog History
Page 1
-
v6.1.1 Changes
๐ Fixed processing a subset of scheduled jobs.
-
v6.1.0 Changes
May 17, 2018You can process a subset of queues in a given Ironium process. ๐ See README for configuration.
-
v6.0.0 Changes
February 02, 2018๐ Now supporting AWS SQS.
๐ฐ Handlers now receive their own copy of the job payload.
๐ท We now debug-log the full job in case of error. When using SQS, this includes ๐ท the receipt handle, which can be used to delete the job.
โฑ Schedules now get their own queue.
โ IronMQ still supported, but untested, unless you bring your own
iron.json
. -
v5.0.0 Changes
Concurrency is now a global limit, shared by all queues.
๐ง Concurrency can be configured via the
IRONIUM_CONCURRENCY
environment 0๏ธโฃ variable. Default is 50.โ Delayed jobs can be tested by time traveling.
โฑ A scheduled job's time-to-live is equal to its interval. This better matches expectations on transient error conditions.
-
v4.1.3 Changes
Ironium will honor
BEANSTALKD_HOSTNAME
andBEANSTALKD_PORT
environment variables if present. -
v4.1.2 Changes
๐ Allow Ironium to be installed on newer versions of Node.
-
v4.1.1 Changes
๐ท Failed jobs were not being returned to the queue with a delay when using IronMQ.
-
v4.1.0 Changes
โฑ Minimum interval for scheduled jobs is one minute. Ironium was never designed for short intervals; this change only makes that explicit.
-
v4.0.0 Changes
โ Added processing concurrency. By default, Ironium will run 10 concurrent jobs. ๐ง This can be configured via the
concurrency
option.๐ท Multiple jobs can be queued in a single API call:
Queue#queueJobs(jobs)
.โฌ๏ธ Dropped support for callbacks and generator functions. Job handlers must return a promise now.
-
v3.2.2 Changes
๐ Fixed bug in error handling when queuing scheduled job.