Namespaces

What it is

Every Redis and RabbitMQ component keeps its keys, queues and channels under a prefix, the app’s namespace. The default is gq. A queue named default is really gq:queue:default in Redis or gq.queue.default in RabbitMQ.

When to use it

Always set one in production. You must use distinct namespaces when two apps share a Redis database or RabbitMQ vhost. On a shared namespace:

each app’s workers take the other app’s tasks,
only one of the two beats runs (they share the beat lock),
dedupe keys and control broadcasts collide.

When not to use it

Namespaces don’t isolate security. They are naming, not access control. For untrusted neighbours use separate Redis databases (/1, /2), Redis ACL users, or separate vhosts.

How it works

GisilaQueue.redis(namespace: 'billing') sets the prefix on every component it builds.
When you build components yourself, give each the same prefix:. GisilaQueue(...) and Beat(...) throw ArgumentError if their components disagree, so a half-configured app fails at startup.
The CLIs and Rose take --namespace=billing (alias --prefix).
A worker or beat on gq logs a warning at startup.
A worker that receives a task name it doesn’t know puts the message back with a growing delay (1 s doubling up to a minute) instead of failing it, in case another worker (a newer deploy, or the app it belongs to) can run it. After maxRequeues (10) it is failed and dead-lettered. If you see “unknown task” warnings, check the namespace first.

Producers, workers, beat and Rose of one app must all use the same namespace.

Example

import 'package:gisila_queue/gisila_queue.dart';

final billing = GisilaQueue.redis(namespace: 'billing', host: 'redis');
final shop = GisilaQueue.redis(namespace: 'shop', host: 'redis');

// This throws ArgumentError: broker="shop", backend="gq".
GisilaQueue(
  broker: RedisBroker(host: 'redis', prefix: 'shop'),
  backend: RedisResultBackend(host: 'redis'),
);