{ "id": "dotnet", "title": "Redis job queue with StackExchange.Redis", "url": "https://redis.io/docs/latest/develop/use-cases/job-queue/dotnet/", "summary": "Implement a Redis job queue in C# with StackExchange.Redis", "tags": [ "docs", "develop", "stack", "oss", "rs", "rc" ], "last_updated": "2026-05-14T08:58:05-05:00", "children": [], "page_type": "content", "content_hash": "6176eae382d9d8492603c21a8c101958ec0434c88a3b6cefe7763c2e17e48441", "sections": [ { "id": "overview", "title": "Overview", "role": "overview", "text": "This guide shows you how to implement a Redis-backed job queue in C# with [StackExchange.Redis](https://stackexchange.github.io/StackExchange.Redis/). It includes a small ASP.NET Core minimal-API web server so you can enqueue jobs, watch a pool of workers drain them, and see the reclaimer recover jobs from a simulated worker crash." }, { "id": "overview", "title": "Overview", "role": "overview", "text": "A job queue lets your application offload background work — sending email, processing payments, image transcoding, ML inference, webhooks — from the request path. Producers enqueue jobs in milliseconds and return to the user; workers pull from the queue and process them on their own schedule.\n\nThat gives you:\n\n* Low-latency user-facing requests, even when downstream work is slow or bursty\n* Horizontal scale across many worker processes that share one Redis instance\n* At-least-once delivery so a worker crash doesn't lose work\n* Visibility-timeout reclaim that returns stuck jobs to the queue automatically\n* Job metadata, retry counts, and completion results in Redis hashes with TTL\n\nIn this example, each job is identified by a random hex ID and its payload, status, and result live in a Redis hash under `queue:jobs:job:{id}`. Pending IDs sit in a list, claimed IDs move atomically to a *processing* list, and completed or failed IDs land in short history lists." }, { "id": "how-it-works", "title": "How it works", "role": "content", "text": "The flow looks like this:\n\n1. The application calls `queue.Enqueue(payload)`\n2. The helper writes the job metadata hash and `LPUSH`es the job ID onto the pending list\n3. A worker calls `queue.Claim(timeoutMs)`\n4. The helper runs a non-blocking `RPOPLPUSH` (via `ListRightPopLeftPush`) to atomically move the next pending ID into the processing list, then writes a per-claim `claim_token` plus `claimed_at_ms` on the hash. StackExchange.Redis intentionally does not expose blocking variants such as `BRPOPLPUSH`, so the demo polls on a 50 ms interval until either a job arrives or the timeout elapses.\n5. The worker runs the job and calls `queue.Complete(job, result)` or `queue.Fail(job, error)`\n6. `Complete` removes the job from the processing list, writes the result, and `LPUSH`es the ID onto the completed history (with `LTRIM` and an `EXPIRE` on the hash for cleanup)\n7. `Fail` either retries the job (back to pending) or moves it to the failed list once retries are exhausted\n\nIf a worker dies before completing a job, the job sits in the processing list with a `claimed_at_ms` older than the visibility timeout. A periodic call to `queue.ReclaimStuck()` finds those jobs and moves them back to pending so another worker can pick them up.\n\nEvery state change holds the token: a worker that has been reclaimed cannot later complete or fail a job another worker has already claimed." }, { "id": "the-job-queue-helper", "title": "The job queue helper", "role": "content", "text": "The `RedisJobQueue` class wraps the queue operations\n([source](https://github.com/redis/docs/blob/main/content/develop/use-cases/job-queue/dotnet/RedisJobQueue.cs)):\n\n[code example]\n\nThe demo helper is synchronous to keep the code compact. A production helper would expose `EnqueueAsync`, `ClaimAsync`, and so on, using `HashSetAsync`, `ScriptEvaluateAsync`, and `await Task.Delay` — see the *Production usage* section below." }, { "id": "data-model", "title": "Data model", "role": "content", "text": "Each job's state lives in a Redis hash plus a position in one of four lists:\n\n[code example]\n\nA job's hash carries:\n\n[code example]\n\nThe implementation uses:\n\n* [`LPUSH`](https://redis.io/docs/latest/commands/lpush) to add new job IDs to the pending list\n* [`RPOPLPUSH`](https://redis.io/docs/latest/commands/rpoplpush) (via `IDatabase.ListRightPopLeftPush`) to atomically claim a job into the processing list. StackExchange.Redis does not expose the blocking [`BRPOPLPUSH`](https://redis.io/docs/latest/commands/brpoplpush) variant, so the helper polls.\n* [`LREM`](https://redis.io/docs/latest/commands/lrem) to remove a claimed job from the processing list on complete or fail\n* [`LTRIM`](https://redis.io/docs/latest/commands/ltrim) to cap the completed and failed history lists\n* [`HSET`](https://redis.io/docs/latest/commands/hset) / [`HGETALL`](https://redis.io/docs/latest/commands/hgetall) for job metadata\n* [`EXPIRE`](https://redis.io/docs/latest/commands/expire) on completed and failed hashes for automatic cleanup\n* [`PUBLISH`](https://redis.io/docs/latest/commands/publish) on `queue:jobs:events` for completion signalling\n* [Lua scripting](https://redis.io/docs/latest/develop/programmability/eval-intro) ([`EVALSHA`](https://redis.io/docs/latest/commands/evalsha)) for the complete, fail, and reclaim flows so each runs atomically against the processing list and metadata hash" }, { "id": "enqueueing-jobs", "title": "Enqueueing jobs", "role": "content", "text": "`Enqueue()` writes the metadata hash and pushes the job ID onto the pending list in one batch:\n\n[code example]\n\nThe payload is serialised to JSON with `System.Text.Json` so the queue can carry arbitrary nested structures without forcing every field into a hash. A batch is the StackExchange.Redis equivalent of a Redis pipeline — it groups commands into one round trip but does not wrap them in `MULTI`/`EXEC` (no atomicity is needed here: a writer can't race itself)." }, { "id": "claiming-jobs", "title": "Claiming jobs", "role": "content", "text": "A worker tries to atomically pop the next pending job onto the processing list. The Python and Node ports use the blocking `BRPOPLPUSH`/`BLMOVE` variants; StackExchange.Redis ships only the non-blocking `ListRightPopLeftPush`, so the helper polls on a 50 ms interval until either a job arrives or the per-call timeout elapses:\n\n[code example]\n\n`Environment.TickCount64` is used for deadline arithmetic to avoid the 24.9-day overflow of the 32-bit `Environment.TickCount`.\n\nThe `claim_token` is the worker's proof of ownership for this attempt. Every subsequent state change (complete, fail) checks it before touching the processing list, so a worker that hung past the visibility timeout cannot interfere with the new claimant." }, { "id": "completing-jobs", "title": "Completing jobs", "role": "content", "text": "`Complete()` runs a Lua script so the processing-list removal, the metadata write, and the history push happen atomically:\n\n[code example]\n\n`IDatabase.ScriptEvaluate` ships the script body on first use and switches to `EVALSHA` automatically for subsequent calls — you don't have to manage the SHA yourself in StackExchange.Redis. The Lua script checks the token first and returns `0` if the worker no longer owns the job (because the reclaimer moved it back to pending). The metadata hash also gets an `EXPIRE` so completed jobs are cleaned up automatically." }, { "id": "failing-and-retrying", "title": "Failing and retrying", "role": "content", "text": "`Fail()` either retries the job (back to pending) or moves it to the failed list once retries are exhausted:\n\n[code example]\n\nThe attempt counter is incremented on every `Claim()`, so a job that fails three times is moved to the failed list with `attempts = 3` and the final `last_error` preserved." }, { "id": "reclaiming-stuck-jobs", "title": "Reclaiming stuck jobs", "role": "content", "text": "If a worker dies mid-job — the process is killed, the host loses power, the network partitions — the job sits in the processing list with a `claimed_at_ms` that never advances. A periodic call to `ReclaimStuck()` walks the processing list and moves any job past the visibility timeout back to pending:\n\n[code example]\n\nThe Lua script also handles a narrower race: a worker that crashed between the claim's `RPOPLPUSH` and writing `claimed_at_ms`. Those jobs are reclaimed after `2 × visibility_ms` using `enqueued_at_ms` as a fallback timer, so they aren't stranded forever." }, { "id": "stats-and-history", "title": "Stats and history", "role": "content", "text": "`Stats()` reports queue depth plus per-process counters:\n\n[code example]\n\nThe completed and failed lists are capped via `LTRIM` so they never grow unbounded; a real deployment would also write completion events to a longer-term audit log if needed." }, { "id": "prerequisites", "title": "Prerequisites", "role": "content", "text": "* Redis 6.2 or later running locally on the default port (6379). Earlier versions still work, since the helper only uses commands that have existed since Redis 2.6.\n* .NET 8 SDK or later.\n* The `StackExchange.Redis` client at version 2.7 or newer. The demo project references `StackExchange.Redis` 2.7.33 in its `.csproj`." }, { "id": "running-the-demo", "title": "Running the demo", "role": "content", "text": "" }, { "id": "get-the-source-files", "title": "Get the source files", "role": "content", "text": "The demo consists of five files. Download them from the [`dotnet` source folder](https://github.com/redis/docs/tree/main/content/develop/use-cases/job-queue/dotnet) on GitHub, or grab them with `curl`:\n\n[code example]" }, { "id": "start-the-demo-server", "title": "Start the demo server", "role": "content", "text": "From that directory:\n\n[code example]\n\nYou should see:\n\n[code example]\n\nOpen [http://127.0.0.1:8795](http://127.0.0.1:8795) in a browser. You can:\n\n* Enqueue jobs of different kinds (email, webhook, thumbnail, invoice) in batches.\n* Start a pool of workers with configurable size, work latency, and *failure* / *hang* rates. A non-zero hang rate simulates worker crashes.\n* Click **Run reclaim sweep** to move any timed-out processing jobs back to pending.\n* Watch pending / processing / completed / failed lists update every 800 ms.\n\nIf your Redis server is running elsewhere, start the demo with `--redis-host` and `--redis-port`. You can also tune the visibility timeout with `--visibility-ms` and the bind address with `--host` / `--port`. Set the `QUEUE_NAME` environment variable to use a different queue prefix." }, { "id": "the-mock-worker-pool", "title": "The mock worker pool", "role": "content", "text": "The demo includes a small `JobWorker` and `WorkerPool` ([`JobWorker.cs`](https://github.com/redis/docs/blob/main/content/develop/use-cases/job-queue/dotnet/JobWorker.cs), [`WorkerPool.cs`](https://github.com/redis/docs/blob/main/content/develop/use-cases/job-queue/dotnet/WorkerPool.cs)) that stands in for whatever real background work your application would run. Each worker is a dedicated background `Thread` that:\n\n* Polls `queue.Claim(500)` for new jobs.\n* `Thread.Sleep(workLatencyMs)` to simulate doing the work.\n* Either completes successfully, fails (calling `queue.Fail()`), or *hangs* — returning without completing or failing the job so the reclaimer has to recover it.\n\nThe `FailRate` and `HangRate` knobs let you watch the at-least-once delivery and reclaim behaviours from the UI without writing test code.\n\n`Program.cs` calls `ThreadPool.SetMinThreads(64, 64)` at startup so concurrent claims, batch awaits, and HTTP handlers don't starve each other while the pool grows on demand." }, { "id": "production-usage", "title": "Production usage", "role": "content", "text": "" }, { "id": "choose-a-visibility-timeout-that-matches-your-worst-case-job-latency", "title": "Choose a visibility timeout that matches your worst-case job latency", "role": "content", "text": "The visibility timeout has to exceed the longest real job time, with margin. If it's too short, a healthy worker that's running a slow job will get its work duplicated when the reclaimer fires. If it's too long, a real crash takes longer to detect. Most production deployments use a per-queue value tuned to the 99th-percentile job latency — for example, 2 minutes for email and 30 minutes for video transcoding." }, { "id": "run-the-reclaimer-on-a-schedule", "title": "Run the reclaimer on a schedule", "role": "content", "text": "The demo only reclaims when you click the button. In production, run `ReclaimStuck()` from a periodic task (an `IHostedService` running on a `PeriodicTimer` for fast queues, or a separate scheduler process for slow ones), or from each worker before it polls on `Claim()`. Both patterns work as long as *someone* runs the sweep." }, { "id": "make-the-helper-async-in-production", "title": "Make the helper async in production", "role": "content", "text": "To keep the demo readable, the helper here is fully synchronous. In a real ASP.NET Core service you should use the async overloads — `HashSetAsync`, `ListLeftPushAsync`, `ScriptEvaluateAsync`, `HashGetAllAsync` — and `await Task.Delay` in the claim polling loop. That frees the calling thread while round trips are in flight, which matters a lot when many handlers share the multiplexer's single command pipeline." }, { "id": "use-a-separate-redis-database-or-key-prefix-per-queue", "title": "Use a separate Redis database or key prefix per queue", "role": "content", "text": "The helper takes a `queueName` constructor argument so you can run multiple independent queues against one Redis instance — for example, one queue per priority level, or one per job kind. Keep queue keys under a clearly-namespaced prefix (here, `queue:jobs:*`) so they're easy to inspect and easy to clear without touching application data." }, { "id": "cap-the-completed-and-failed-history", "title": "Cap the completed and failed history", "role": "content", "text": "The demo keeps the last 50 completed and 50 failed job IDs via `LTRIM`. If you need longer history for audit purposes, write completion events to a separate Redis Stream (or to an external store) and keep the in-queue history short. Stream consumer groups give you the same fan-out semantics with a much richer history." }, { "id": "tune-maxattempts-per-job-kind", "title": "Tune `maxAttempts` per job kind", "role": "content", "text": "A blanket `maxAttempts = 3` is a reasonable default for transient failures (network timeouts, rate limits). Jobs that talk to non-idempotent external systems — for example, posting a Stripe charge — need either application-level idempotency keys or a much lower retry count. The helper exposes `maxAttempts` so each queue can pick its own policy." }, { "id": "poll-instead-of-blocking-and-watch-out-for-the-multiplexer", "title": "Poll instead of blocking — and watch out for the multiplexer", "role": "content", "text": "StackExchange.Redis [intentionally does not expose blocking commands](https://stackexchange.github.io/StackExchange.Redis/PipelinesMultiplexers#fundamentally-blocking-operations) such as `BLPOP`, `BRPOPLPUSH`, or `BLMOVE`. The multiplexer interleaves all commands from all callers onto one TCP connection, so a long blocking call would stall every other request on the same connection. The helper therefore calls the non-blocking `ListRightPopLeftPush` and polls — at 50 ms it remains responsive without flooding Redis. If you really want a single connection dedicated to a blocking pop (a less common pattern in C#), spin up a second `ConnectionMultiplexer` configured with `AllowAdmin = true` and a separate database, and run the blocking call through its dedicated socket; this demo intentionally does not." }, { "id": "bump-the-minimum-thread-pool-size-in-long-running-services", "title": "Bump the minimum thread-pool size in long-running services", "role": "content", "text": ".NET's thread pool grows by ~2 threads per second under load, which can starve concurrent workers when a burst of jobs arrives. The demo calls `ThreadPool.SetMinThreads(64, 64)` at startup. In a real service set the values to match the maximum number of simultaneous outstanding Redis calls plus the size of your HTTP thread pool." }, { "id": "use-environment-tickcount64-for-deadline-arithmetic", "title": "Use `Environment.TickCount64` for deadline arithmetic", "role": "content", "text": "`Environment.TickCount` is a 32-bit signed integer in milliseconds and overflows after roughly 24.9 days. For visibility-timeout and claim-poll deadlines, always use `Environment.TickCount64` (or `Stopwatch.GetTimestamp`) instead — see the `Claim` implementation above." }, { "id": "inspect-queue-state-directly-in-redis", "title": "Inspect queue state directly in Redis", "role": "content", "text": "Because the queue is just lists and hashes, you can inspect it with `redis-cli`:\n\n[code example]" }, { "id": "learn-more", "title": "Learn more", "role": "related", "text": "This example uses the following Redis commands:\n\n* [`LPUSH`](https://redis.io/docs/latest/commands/lpush) to enqueue a job ID.\n* [`RPOPLPUSH`](https://redis.io/docs/latest/commands/rpoplpush) to atomically claim a job into the processing list (the non-blocking variant of [`BRPOPLPUSH`](https://redis.io/docs/latest/commands/brpoplpush), used because StackExchange.Redis doesn't expose blocking pops).\n* [`LREM`](https://redis.io/docs/latest/commands/lrem) to remove a job from the processing list on complete or fail.\n* [`LRANGE`](https://redis.io/docs/latest/commands/lrange) and [`LLEN`](https://redis.io/docs/latest/commands/llen) to read queue depth and list contents.\n* [`LTRIM`](https://redis.io/docs/latest/commands/ltrim) to cap the completed and failed history.\n* [`HSET`](https://redis.io/docs/latest/commands/hset) and [`HGETALL`](https://redis.io/docs/latest/commands/hgetall) for job metadata.\n* [`HINCRBY`](https://redis.io/docs/latest/commands/hincrby) for the attempt counter.\n* [`EXPIRE`](https://redis.io/docs/latest/commands/expire) for automatic cleanup of completed and failed jobs.\n* [`PUBLISH`](https://redis.io/docs/latest/commands/publish) for job-completion notifications.\n* [`EVALSHA`](https://redis.io/docs/latest/commands/evalsha) for atomic complete, fail, and reclaim flows.\n\nSee the [StackExchange.Redis documentation](https://stackexchange.github.io/StackExchange.Redis/) for the full client reference." } ], "examples": [ { "id": "the-job-queue-helper-ex0", "language": "csharp", "code": "using StackExchange.Redis;\nusing JobQueueDemo;\n\nvar redis = ConnectionMultiplexer.Connect(\"localhost:6379\");\nvar queue = new RedisJobQueue(redis, visibilityMs: 5000);\n\nvar jobId = queue.Enqueue(new Dictionary\n{\n [\"kind\"] = \"email\",\n [\"recipient\"] = \"alice@example.com\",\n});\n\n// In a worker thread:\nvar job = queue.Claim(timeoutMs: 1000);\nif (job is not null)\n{\n try\n {\n // ... run the job ...\n queue.Complete(job, new Dictionary { [\"sent_at\"] = \"2026-05-11T15:00:00Z\" });\n }\n catch (Exception ex)\n {\n queue.Fail(job, ex.Message);\n }\n}\n\n// In a periodic sweeper:\nvar reclaimed = queue.ReclaimStuck();", "section_id": "the-job-queue-helper" }, { "id": "data-model-ex0", "language": "text", "code": "queue:jobs:pending (list) pending job IDs, oldest at the right\nqueue:jobs:processing (list) claimed but not yet completed\nqueue:jobs:completed (list) recent successes (LTRIM-capped history)\nqueue:jobs:failed (list) terminally failed jobs\nqueue:jobs:job:{id} (hash) per-job metadata\nqueue:jobs:events (pubsub) completion notifications", "section_id": "data-model" }, { "id": "data-model-ex1", "language": "text", "code": "queue:jobs:job:9a4f...\n id = 9a4f...\n payload = {\"kind\":\"email\",\"recipient\":\"alice@example.com\"}\n status = pending | processing | completed | failed\n attempts = 1\n enqueued_at_ms = 1715441000000\n claimed_at_ms = 1715441000123\n claim_token = b3c0d1e2... (per-claim random token)\n completed_at_ms = 1715441000456\n result = {\"sent_at\":\"...\"}\n last_error = \"smtp timeout\"", "section_id": "data-model" }, { "id": "enqueueing-jobs-ex0", "language": "csharp", "code": "public string Enqueue(IDictionary payload)\n{\n var jobId = RandomTokenHex(8);\n var nowMs = NowMs();\n var metaKey = MetaKey(jobId);\n\n var hashEntries = new[]\n {\n new HashEntry(\"id\", jobId),\n new HashEntry(\"payload\", JsonSerializer.Serialize(payload)),\n new HashEntry(\"status\", \"pending\"),\n new HashEntry(\"attempts\", 0),\n new HashEntry(\"enqueued_at_ms\", nowMs),\n new HashEntry(\"claim_token\", \"\"),\n };\n\n var batch = _db.CreateBatch();\n var hashTask = batch.HashSetAsync(metaKey, hashEntries);\n var pushTask = batch.ListLeftPushAsync(_pendingKey, jobId);\n batch.Execute();\n Task.WaitAll(hashTask, pushTask);\n\n lock (_statsLock) { _enqueued++; }\n return jobId;\n}", "section_id": "enqueueing-jobs" }, { "id": "claiming-jobs-ex0", "language": "csharp", "code": "public ClaimedJob? Claim(int timeoutMs = 1000)\n{\n var deadline = Environment.TickCount64 + Math.Max(0, timeoutMs);\n const int pollIntervalMs = 50;\n\n RedisValue popped;\n while (true)\n {\n popped = _db.ListRightPopLeftPush(_pendingKey, _processingKey);\n if (!popped.IsNull) break;\n var remaining = deadline - Environment.TickCount64;\n if (remaining <= 0) return null;\n Thread.Sleep((int)Math.Min(pollIntervalMs, remaining));\n }\n\n var jobId = (string)popped!;\n var token = RandomTokenHex(8);\n var nowMs = NowMs();\n var metaKey = MetaKey(jobId);\n\n var batch = _db.CreateBatch();\n var hashSetTask = batch.HashSetAsync(metaKey, new[]\n {\n new HashEntry(\"status\", \"processing\"),\n new HashEntry(\"claimed_at_ms\", nowMs),\n new HashEntry(\"claim_token\", token),\n });\n var incrTask = batch.HashIncrementAsync(metaKey, \"attempts\", 1);\n var hgetallTask = batch.HashGetAllAsync(metaKey);\n batch.Execute();\n Task.WaitAll(hashSetTask, incrTask, hgetallTask);\n\n var meta = ToDictionary(hgetallTask.Result);\n var payload = ParseJsonObject(meta.GetValueOrDefault(\"payload\", \"{}\"));\n var attempts = int.TryParse(meta.GetValueOrDefault(\"attempts\", \"1\"), out var a) ? a : 1;\n return new ClaimedJob(jobId, payload, attempts, token);\n}", "section_id": "claiming-jobs" }, { "id": "completing-jobs-ex0", "language": "csharp", "code": "public bool Complete(ClaimedJob job, IDictionary result)\n{\n var keys = new RedisKey[] { _metaPrefix, _processingKey, _completedKey };\n var args = new RedisValue[]\n {\n job.Id, job.ClaimToken, \"completed\", NowMs(),\n JsonSerializer.Serialize(result), _completedTtl, _completedHistory,\n };\n\n var raw = _db.ScriptEvaluate(CompleteScript, keys, args);\n var ok = !raw.IsNull && (long)raw == 1;\n if (!ok) return false;\n\n _db.Publish(\n RedisChannel.Literal(_eventsChannel),\n JsonSerializer.Serialize(new Dictionary\n {\n [\"id\"] = job.Id,\n [\"status\"] = \"completed\",\n }));\n\n lock (_statsLock) { _completed++; }\n return true;\n}", "section_id": "completing-jobs" }, { "id": "failing-and-retrying-ex0", "language": "csharp", "code": "public bool Fail(ClaimedJob job, string error)\n{\n var retry = job.Attempts < _maxAttempts;\n var keys = new RedisKey[]\n {\n _metaPrefix, _processingKey, _pendingKey, _failedKey,\n };\n var args = new RedisValue[]\n {\n job.Id, job.ClaimToken, error, NowMs(),\n _completedTtl, _completedHistory, retry ? \"1\" : \"0\",\n };\n\n var raw = _db.ScriptEvaluate(FailScript, keys, args);\n if (raw.IsNull || (long)raw == 0) return false;\n // ... publish event, bump counter if final failure ...\n return true;\n}", "section_id": "failing-and-retrying" }, { "id": "reclaiming-stuck-jobs-ex0", "language": "csharp", "code": "public IReadOnlyList ReclaimStuck()\n{\n var keys = new RedisKey[] { _pendingKey, _processingKey, _metaPrefix };\n var args = new RedisValue[] { NowMs(), _visibilityMs };\n var raw = _db.ScriptEvaluate(ReclaimScript, keys, args);\n if (raw.IsNull) return Array.Empty();\n var reclaimedArray = (RedisResult[])raw!;\n return reclaimedArray.Select(r => (string)r!).ToList();\n}", "section_id": "reclaiming-stuck-jobs" }, { "id": "stats-and-history-ex0", "language": "csharp", "code": "public IDictionary Stats()\n{\n var batch = _db.CreateBatch();\n var pendingTask = batch.ListLengthAsync(_pendingKey);\n var processingTask = batch.ListLengthAsync(_processingKey);\n var completedTask = batch.ListLengthAsync(_completedKey);\n var failedTask = batch.ListLengthAsync(_failedKey);\n batch.Execute();\n Task.WaitAll(pendingTask, processingTask, completedTask, failedTask);\n\n lock (_statsLock)\n {\n return new Dictionary\n {\n [\"enqueued_total\"] = _enqueued,\n [\"completed_total\"] = _completed,\n [\"failed_total\"] = _failed,\n [\"reclaimed_total\"] = _reclaimed,\n [\"pending_depth\"] = pendingTask.Result,\n [\"processing_depth\"] = processingTask.Result,\n [\"completed_depth\"] = completedTask.Result,\n [\"failed_depth\"] = failedTask.Result,\n [\"visibility_ms\"] = _visibilityMs,\n };\n }\n}", "section_id": "stats-and-history" }, { "id": "get-the-source-files-ex0", "language": "bash", "code": "mkdir job-queue-demo && cd job-queue-demo\nBASE=https://raw.githubusercontent.com/redis/docs/main/content/develop/use-cases/job-queue/dotnet\ncurl -O $BASE/RedisJobQueue.cs\ncurl -O $BASE/JobWorker.cs\ncurl -O $BASE/WorkerPool.cs\ncurl -O $BASE/Program.cs\ncurl -O $BASE/JobQueueDemo.csproj", "section_id": "get-the-source-files" }, { "id": "start-the-demo-server-ex0", "language": "bash", "code": "dotnet run", "section_id": "start-the-demo-server" }, { "id": "start-the-demo-server-ex1", "language": "text", "code": "Connected to Redis at localhost:6379\nRedis job-queue demo server listening on http://127.0.0.1:8795\nUsing Redis at localhost:6379\nVisibility timeout: 5000 ms", "section_id": "start-the-demo-server" }, { "id": "inspect-queue-state-directly-in-redis-ex0", "language": "bash", "code": "# How many pending jobs?\nredis-cli LLEN queue:jobs:pending\n\n# Look at the next 5 jobs to be picked up.\nredis-cli LRANGE queue:jobs:pending -5 -1\n\n# Read a job's metadata.\nredis-cli HGETALL queue:jobs:job:9a4f0d1c\n\n# How many jobs are currently being processed?\nredis-cli LLEN queue:jobs:processing\n\n# Clear everything for this queue (be careful — this deletes work).\nredis-cli --scan --pattern 'queue:jobs:*' | xargs redis-cli DEL", "section_id": "inspect-queue-state-directly-in-redis" } ] }