beanstalkd/roadmap/epics/02-ownership.md

02. Владение Динамическими Tubes

Статус: не начат. Зависимости: 01.

Цель

Однозначно назначать процесс всем возможным именам tubes без постоянного реестра самих очередей и без конкурентного claim при каждом создании.

Контракт

partition = stable_hash(validated_tube_name) % PARTITION_COUNT
owner_slot = partition_map[partition]

• Hash работает с точными байтами имени по протоколу: без изменения регистра, locale-зависимой обработки и рандомизации между процессами.
• PARTITION_COUNT фиксирован и не равен числу живых процессов по определению. Число разделов, алгоритм и карта выбираются в 01.
• Owner slot не является PID. Перезапуск процесса не меняет принадлежность имён.
• Все процессы подтверждают одинаковые fingerprint/version топологии до обслуживания запросов.
• Данные с несовместимой картой не открываются для записи. Отсутствующая или повреждённая метаинформация не должна вызывать создание новой карты поверх существующих данных.
• Без WAL карта всё равно должна быть единой для живого логического сервера. При полном запуске без сохранённых данных допустима новая явно заданная конфигурация.

Задачи

1. Реализовать проверку и загрузку карты разделов, стабильный router и тестовые векторы hash.
2. Отделить разрешение владельца от локального поиска/создания объекта. find не имеет побочного эффекта create.
3. Оставить tube_find_or_make или его минимально изменённый эквивалент внутри владельца. Реестр локальных tubes содержит только его объекты.
4. Обрабатывать use, watch, ignore и disconnect через ссылки логических сессий. Подтверждать изменение клиентского состояния после корректного изменения ссылок; предусмотреть rollback частичного attach.
5. Сохранять tube пока есть job любого живого состояния или удерживающая клиентская/системная ссылка. Удалять после освобождения последней ссылки без изменения карты.
6. Определить default: одна логическая tube на всём сервере у вычисленного владельца, не отдельная пользовательская очередь в каждом процессе. Сохранить штатную системную ссылку, если она нужна для эквивалентности текущему prot_init.
7. При WAL replay создавать tubes у соответствующего владельца; чужое имя в WAL должно выявлять неверную топологию/раскладку данных, а не тихо создавать вторую tube.

Сценарий Одновременного Создания

Два frontend получают use emails и watch emails. Оба вычисляют один slot. Его event loop обрабатывает сообщения последовательно: первое создаёт tube, второе находит ту же tube и добавляет свою ссылку. Дополнительная distributed lock или таблица claims на имя не нужна.

Эксклюзивный claim требуется для самого owner slot и обеспечивается supervisor из эпика 06.

Приёмка

• Hash-векторы одинаковы между процессами и перезапусками; тесты включают допустимые граничные имена, регистр и максимальную длину.
• Параллельные use/watch одной новой tube через разные frontend создают один объект у одного владельца и корректные счётчики ссылок.
• stats-tube/pause-tube несуществующего имени возвращают NOT_FOUND и не оставляют объект.
• Tube с reserved job не удаляется после ухода остальных клиентов.
• Пустая обычная tube удаляется после последней ссылки; повторное создание попадает в тот же slot.
• default представлен один раз в list-tubes; подключения не создают локальные копии в остальных owners.
• Авария frontend освобождает его ссылки; запоздалый attach старого поколения не воскрешает сессию.
• Подмена hash, карты или числа разделов при существующих данных приводит к безопасному отказу запуска, а не перемаршрутизации.

Не Делать

Никакого hash(name) % live_owners, переноса очередей при сбое, автоматического распределения новых tubes по текущей нагрузке или долговечного каталога пустых tubes.

Точки Кода

tube.c, conn.c:on_watch/on_ignore, prot.c:prot_init/dispatch_cmd/prot_replay, dat.h:Tube, новый минимальный модуль топологии при необходимости.