proletarian.job
enqueue!clj
(enqueue! conn job-type payload)(enqueue! conn
job-type
payload
{:proletarian/keys [queue job-table serializer uuid-fn clock]
:or {queue db/DEFAULT_QUEUE
job-table db/DEFAULT_JOB_TABLE
serializer (transit/create-serializer)
uuid-fn (fn [] (UUID/randomUUID))
clock (Clock/systemUTC)}})Enqueue a job in the Proletarian job queue.
Arguments
conn– a [[java.sql.Connection]] database connection.job-type– a keyword that identifies the job type. The job type will be passed to your handler function (see second argument toproletarian.worker/create-queue-worker) as the first argument. Optionally implement theretry-strategymultimethod for this keyword to describe the retry strategy for this job type.payload– the data that the job needs. It will be encoded and decoded using the serializer (see Options, below). The payload will be passed to your handler function as the second argument.options– an optional map describing configuration options, see below.
Options
The optional fourth argument is an options map with the following keys, all optional with default values:
:queue– a keyword with the name of the queue. The default value is:proletarian/default.:job-table– which PostgreSQL table to write the job to. The default isproletarian.job. You should only have to override this if you changed the default table name during installation.:serializer– a n implementation of theproletarian.protocols/Serializerprotocol. The default is a Transit serializer (seeproletarian.transit/create-serializer). If you override this, you should use the same serializer forproletarian.worker/create-queue-worker.:uuid-fn– a function for generating UUIDs. Used in testing. The default is [[java.util.UUID/randomUUID]].:clock– the [[java.time.Clock]] to use for getting the current time. Used in testing. The default is [[java.time.Clock/systemUTC]].
Enqueue a job in the Proletarian job queue.
### Arguments
* `conn` – a [[java.sql.Connection]] database connection.
* `job-type` – a keyword that identifies the job type. The job type will be passed to your handler function (see
second argument to [[proletarian.worker/create-queue-worker]]) as the first argument. Optionally implement the
[[retry-strategy]] multimethod for this keyword to describe the retry strategy for this job type.
* `payload` – the data that the job needs. It will be encoded and decoded using the serializer (see Options, below).
The payload will be passed to your handler function as the second argument.
* `options` – an optional map describing configuration options, see below.
### Options
The optional fourth argument is an options map with the following keys, all optional with default values:
* `:queue` – a keyword with the name of the queue. The default value is `:proletarian/default`.
* `:job-table` – which PostgreSQL table to write the job to. The default is `proletarian.job`. You should only have
to override this if you changed the default table name during installation.
* `:serializer` – a n implementation of the [[proletarian.protocols/Serializer]] protocol. The default is a Transit
serializer (see [[proletarian.transit/create-serializer]]). If you override this, you should use the same
serializer for [[proletarian.worker/create-queue-worker]].
* `:uuid-fn` – a function for generating UUIDs. Used in testing. The default is [[java.util.UUID/randomUUID]].
* `:clock` – the [[java.time.Clock]] to use for getting the current time. Used in testing. The default is
[[java.time.Clock/systemUTC]].retry-strategycljmultimethod
When a job throws an exception, it is caught by the Proletarian poller. This function is then called with the job and the caught exception. This multimethod dispatches on the job type. You can implement this method for your job type to have it retry any way you want based on the information in the job record and the caught exception.
It should return a map that specifies the retry strategy:
:retries The number of retries (note that the total number of attempts will
be one larger than this number).
:delays A vector of numbers of milliseconds to wait between retries.
Do consider the polling interval and the job queue contention when planning your retry strategy. The retry delay should be thought of as the earliest time that the job will be retried. The actual retry time might be a little, or much, later, depending on the polling interval and what other jobs are in the queue before this one.
Examples:
{:retries 2
:delays [1000 5000]}
This will retry two times. The first time after 1 second and the second after 5 seconds.
{:retries 4
:delays [2000 10000]}
This will retry four times. The first time after 2 seconds, and the last three times after 10 seconds.
When a job throws an exception, it is caught by the Proletarian poller.
This function is then called with the job and the caught exception. This
multimethod dispatches on the job type. You can implement this method for
your job type to have it retry any way you want based on the information in
the job record and the caught exception.
It should return a map that specifies the retry strategy:
`:retries` The number of retries (note that the total number of attempts will
be one larger than this number).
`:delays` A vector of numbers of milliseconds to wait between retries.
Do consider the polling interval and the job queue contention when planning
your retry strategy. The retry delay should be thought of as the earliest
time that the job will be retried. The actual retry time might be a little,
or much, later, depending on the polling interval and what other jobs are in
the queue before this one.
Examples:
```clojure
{:retries 2
:delays [1000 5000]}
```
This will retry two times. The first time after 1 second and the second
after 5 seconds.
```clojure
{:retries 4
:delays [2000 10000]}
```
This will retry four times. The first time after 2 seconds, and the last
three times after 10 seconds.cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close