Essayer d'enchaîner Pheanstalk dans ma classe de base de travail PHP. Je teste la réserve et la réserve avec la fonctionnalité de délai et j'ai constaté que je peux réserver un travail à partir d'une deuxième instance de ma classe de base sans que la première instance ne libère le travail ou que le délai de temporisation ne soit écoulé. C'est inattendu puisque je pensais que c'est exactement ce que les files d'attente sont censées empêcher. Voici les commandes beanstalkd pour le premier put et la première réserve avec les horodatages. Je fais aussi une demande de stats-travail à la fin:Beanstalkd (via pheanstalk) permettant des doublons, des réserves simultanées?
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
Jusqu'ici, tout va bien. Maintenant, je fais une autre réserve à partir d'une deuxième instance de ma classe de base suivie d'une autre demande de statistiques-travail. Notez que les horodatages sont dans la même seconde, loin du TTR de 300 secondes que j'ai défini. Notez également dans cette deuxième impression de statistiques-emplois qu'il y a 2 réserves de ce travail avec 0 délais d'attente et 0 sortie.
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
Quelqu'un a des idées sur ce que je pourrais faire mal? Y a-t-il quelque chose que je dois faire pour dire à la file d'attente que je veux que les travaux ne soient accessibles que par un seul travailleur à la fois? Je fais un "unset" sur l'instance de pheanstalk dès que je reçois le travail de la file d'attente qui, je crois, termine la session avec beanstalkd. Cela pourrait-il amener beanstalkd à décider que le travailleur est mort et à libérer automatiquement le travail sans délai? Je ne sais pas exactement combien beanstalkd compte sur l'état de la session pour déterminer l'état du travail. Je supposais que je pouvais ouvrir et fermer des sessions en toute impunité et que l'identification de travail était la seule chose que beanstalkd se souciait de lier les opérations de travail, mais cela pouvait être idiot de ma part ... C'est ma première incursion dans les files d'attente .
Merci!
Je ne sais pas ce que la question est, mais je l'ai trouvé tout en essayant de déterminer pourquoi 'appel a été ma réserve' pheanstalk->() Calage - à savoir ne jamais revenir - l'origine de mes cron travail pour fonctionner indéfiniment jusqu'à Apache effectivement mort. Ce que je dirais cependant c'est qu'une fois le travail terminé, vous voudrez probablement le supprimer. Dans le cas contraire, il restera dans la file d'attente et s'exécutera à nouveau tous les 300 (dans le meilleur des cas) tant que des travailleurs exécuteront des travaux de file d'attente. Pour ce qui est de la communication entre l'instance de pheanstalk et sa libération, je ne peux pas commenter. –