Попытка обернуть Pheanstalk в моем базовом классе PHP. Я тестирую резервную копию и резервирую функцию задержки, и я обнаружил, что могу зарезервировать задание из вторых экземпляров моего базового класса без первого экземпляра, освобождающего задание или тайм-аут TTR. Это неожиданно, так как я думал, что это именно то, что должны помешать очереди заданий. Вот команды beanstalkd для первого put и первого резерва вместе с метками времени. Я также делаю запрос о задании статистики в конце:Beanstalkd (через pheanstalk), позволяющий дублировать, одновременные резервы?
01:40:15: Sending command: use QueuedCoreEvent
01:40:15: Got response: USING QueuedCoreEvent
01:40:15: Sending command: put 1024 0 300 233
a:4:{s:9:"eventName";s:21:"ReQueueJob_eawu7xr9bi";s:6:"params";a:2:{s:12:"InstanceName";s:21:"ReQueueJob_eawu7xr9bi";s:17:"aValueToIncrement";i:123456;}s:9:"behaviors";a:1:{i:0;s:22:"BehMCoreEventTestDummy";}s:12:"failureCount";i:0;}
01:40:15: Got response: INSERTED 10
01:40:15: Sending command: watch QueuedCoreEvent
01:40:15: Got response: WATCHING 2
01:40:15: Sending command: ignore default
01:40:15: Got response: WATCHING 1
01:40:15: Sending command: reserve-with-timeout 0
01:40:15: Got response: RESERVED 10 233
01:40:15: Data: a:4:{s:9:"eventName";s:21:"ReQueueJob_eawu7xr9bi";s:6:"params";a:2:{s:12:"InstanceName";s:21:"ReQueueJob_eawu7xr9bi";s:17:"aValueToIncrement";i:123456;}s:9:"behaviors";a:1:{i:0;s:22:"BehMCoreEventTestDummy";}s:12:"failureCount";i:0;}
01:40:15: Sending command: stats-job 10
01:40:15: Got response: OK 162
01:40:15: Data: ---
id: 10
tube: QueuedCoreEvent
state: reserved
pri: 1024
age: 0
delay: 0
ttr: 300
time-left: 299
file: 0
reserves: 1
timeouts: 0
releases: 0
buries: 0
kicks: 0
Пока что так хорошо. Теперь я делаю еще один запас из второго экземпляра моего базового класса, за которым следует другой запрос статистики. Обратите внимание, что отметки времени находятся в пределах одной секунды, нигде рядом с 300-секундным TTR, который я установил. Также обратите внимание, что в этой второй статистической распечатке задания есть 2 резерва этой работы с 0 тайм-аутами и 0 выпусками.
01:40:15: Sending command: watch QueuedCoreEvent
01:40:15: Got response: WATCHING 2
01:40:15: Sending command: ignore default
01:40:15: Got response: WATCHING 1
01:40:15: Sending command: reserve-with-timeout 0
01:40:15: Got response: RESERVED 10 233
01:40:15: Data: a:4:{s:9:"eventName";s:21:"ReQueueJob_eawu7xr9bi";s:6:"params";a:2:{s:12:"InstanceName";s:21:"ReQueueJob_eawu7xr9bi";s:17:"aValueToIncrement";i:123456;}s:9:"behaviors";a:1:{i:0;s:22:"BehMCoreEventTestDummy";}s:12:"failureCount";i:0;}
01:40:15: Sending command: stats-job 10
01:40:15: Got response: OK 162
01:40:15: Data: ---
id: 10
tube: QueuedCoreEvent
state: reserved
pri: 1024
age: 0
delay: 0
ttr: 300
time-left: 299
file: 0
reserves: 2
timeouts: 0
releases: 0
buries: 0
kicks: 0
У кого-нибудь есть идеи о том, что я могу делать неправильно? Есть ли что-то, что я должен сделать, чтобы сообщить в очередь, что я хочу, чтобы рабочие места были доступны только одному работнику за раз? Я делаю «unset» на экземпляре pheanstalk, как только получаю задание от очереди, которая, как я полагаю, завершает сеанс с beanstalkd. Может ли это быть причиной того, что рабочий умер и автоматически освобождает работу без тайм-аута? Я не уверен, сколько beanstalkd полагается на состояние сеанса, чтобы определить рабочее состояние. Я предполагал, что я мог бы безнаказанно открывать и закрывать заседания, и этот идентификатор работы был единственным, что beanstalkd заботился о том, чтобы связать операции по работе вместе, но это, возможно, было глупо с моей стороны ... Это мой первый выход в очереди заданий ,
Спасибо!
Я понятия не имею, что проблема, но я нашел его, пытаясь определить, почему мой 'pheanstalk-> резерв()' вызов тянул - то есть никогда не возвращается - причина моего Задача cron работать неограниченно до тех пор, пока Apache не умрет. Однако я бы сказал, что как только работа будет завершена, вы, скорее всего, захотите ее удалить. В противном случае он останется в очереди, а затем запустится каждые 300 (наилучший сценарий) до тех пор, пока у вас есть рабочие, выполняющие задания на очереди. Что касается сообщения btwn, то экземпляр pheanstalk не работает и освобождает задание, которое я не могу комментировать. –