Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
I'd like to reopen this, as the topic title exactly tells my problem.
I often see my queues (max 5 entries) marked as full on admin/content/nodequeue, but when I click the corresponding view link, there seems to be only 1, 2 or sometimes 0 nodes in the queue.
I do have a custom module running that calls nodequeue_queue_back($subQ,1); every now and then, but i can't figure out why that would be a problem.
Edit:
I've been looking in my database, I'll give some additional info.
I wrote a custom module, which cycles through nodequeues at an interval which can be set by administrative users. This 'cycling' is done by putting the node that is in front of the queue in the back of the queue using the call mentioned above. This cycling has to be done too often to be done in a cron, so the call is made in the hook_init and sometimes called more than once (if the last cycle was 2 minutes ago and the interval is set at 30 seconds, it will cycle 4 times, or less if there aren't more than 4 items in the queue). I'm not using any other nodequeue based module.
Now, when I look into the database I find some records that look like this:
qid sqid nid position timestamp
Edit Delete 0 1 0 2 0
Edit Delete 0 2 0 1 0
Edit Delete 0 2 0 2 0
Edit Delete 0 2 0 2 0
Edit Delete 0 2 0 4 0
Edit Delete 0 2 0 4 0
Edit Delete 0 3 0 1 0
Edit Delete 0 3 0 2 0
Edit Delete 0 3 0 3 0
These are all subqueues that are being cycled by my custom module. My custom module is not doing anything else with the queues, so the core problem probably has to do with the query execution in nodequeue_queue_back, it doesn't check integrity of the table at all.
I do realize that the problem could very well be that a new (let's call it second) page call is made before my custom module registers it has cycled the queue, then in the second page call my module sees a queue that needs to be cycled and goes ahead and tries to cycle it. At that point I have 2 php-processes running, which makes the order of mysql queries unpredictable.
The fact that there might be a problem in my custom module doesn't fix the lack of an integrity check in functions such as nodequeue_node_back though.
It seems like you have something of an edge case. However, making sure that $entry is valid before continuing with the queries in nodequeue_queue_back() and nodequeue_queue_front() seems like a good idea. Care you submit a patch?
Recently, I've cleared all nodequeues and refilled them. Since then, the problem never occured again, so I won't be writing a patch until the problem occurs again.
Comments
Comment #1
(not verified) commentedComment #2
Anonymous (not verified) commentedI'd like to reopen this, as the topic title exactly tells my problem.
I often see my queues (max 5 entries) marked as full on admin/content/nodequeue, but when I click the corresponding view link, there seems to be only 1, 2 or sometimes 0 nodes in the queue.
I do have a custom module running that calls nodequeue_queue_back($subQ,1); every now and then, but i can't figure out why that would be a problem.
Edit:
I've been looking in my database, I'll give some additional info.
I wrote a custom module, which cycles through nodequeues at an interval which can be set by administrative users. This 'cycling' is done by putting the node that is in front of the queue in the back of the queue using the call mentioned above. This cycling has to be done too often to be done in a cron, so the call is made in the hook_init and sometimes called more than once (if the last cycle was 2 minutes ago and the interval is set at 30 seconds, it will cycle 4 times, or less if there aren't more than 4 items in the queue). I'm not using any other nodequeue based module.
Now, when I look into the database I find some records that look like this:
qid sqid nid position timestamp
Edit Delete 0 1 0 2 0
Edit Delete 0 2 0 1 0
Edit Delete 0 2 0 2 0
Edit Delete 0 2 0 2 0
Edit Delete 0 2 0 4 0
Edit Delete 0 2 0 4 0
Edit Delete 0 3 0 1 0
Edit Delete 0 3 0 2 0
Edit Delete 0 3 0 3 0
These are all subqueues that are being cycled by my custom module. My custom module is not doing anything else with the queues, so the core problem probably has to do with the query execution in nodequeue_queue_back, it doesn't check integrity of the table at all.
I do realize that the problem could very well be that a new (let's call it second) page call is made before my custom module registers it has cycled the queue, then in the second page call my module sees a queue that needs to be cycled and goes ahead and tries to cycle it. At that point I have 2 php-processes running, which makes the order of mysql queries unpredictable.
The fact that there might be a problem in my custom module doesn't fix the lack of an integrity check in functions such as nodequeue_node_back though.
Comment #3
ezra-g commentedIt seems like you have something of an edge case. However, making sure that $entry is valid before continuing with the queries in nodequeue_queue_back() and nodequeue_queue_front() seems like a good idea. Care you submit a patch?
Comment #4
Anonymous (not verified) commentedRecently, I've cleared all nodequeues and refilled them. Since then, the problem never occured again, so I won't be writing a patch until the problem occurs again.
Comment #5
amateescu commentedMarking as a duplicate of #1168228: Nodes may be ranked on the same position in queue because there's a patch in that issue.