Permalink
Browse files

Major Change! Priority is no longer like 'nice'-ness -- a higher numb…

…er means it gets popped earlier.
  • Loading branch information...
1 parent ba743e1 commit c4c875ad137744be045e68651dab11800f033b03 Dan Lecocq committed May 18, 2012
Showing with 7 additions and 7 deletions.
  1. +1 −1 complete.lua
  2. +2 −2 peek.lua
  3. +2 −2 pop.lua
  4. +1 −1 put.lua
  5. +1 −1 retry.lua
View
2 complete.lua
@@ -153,7 +153,7 @@ if nextq then
redis.call('hset', 'ql:j:' .. jid, 'state', 'depends')
return 'depends'
else
- redis.call('zadd', 'ql:q:' .. nextq .. '-work', priority + (now / 10000000000), jid)
+ redis.call('zadd', 'ql:q:' .. nextq .. '-work', priority - (now / 10000000000), jid)
return 'waiting'
end
end
View
4 peek.lua
@@ -73,7 +73,7 @@ if #keys < count then
-- Now, if a delay was provided, and if it's in the future,
-- then we'll have to schedule it. Otherwise, we're just
-- going to add it to the work queue.
- redis.call('zadd', key .. '-work', priority + (now / 10000000000), jid .. '-' .. count)
+ redis.call('zadd', key .. '-work', priority - (now / 10000000000), jid .. '-' .. count)
redis.call('zincrby', key .. '-recur', interval, jid)
end
@@ -112,7 +112,7 @@ if #keys < count then
-- And now we should get up to the maximum number of requested
-- work items from the work queue.
- for index, jid in ipairs(redis.call('zrange', key .. '-work', 0, (count - #keys) - 1)) do
+ for index, jid in ipairs(redis.call('zrevrange', key .. '-work', 0, (count - #keys) - 1)) do
table.insert(keys, jid)
end
end
View
4 pop.lua
@@ -136,7 +136,7 @@ if #keys < count then
-- Now, if a delay was provided, and if it's in the future,
-- then we'll have to schedule it. Otherwise, we're just
-- going to add it to the work queue.
- redis.call('zadd', key .. '-work', priority + (now / 10000000000), jid .. '-' .. count)
+ redis.call('zadd', key .. '-work', priority - (now / 10000000000), jid .. '-' .. count)
redis.call('zincrby', key .. '-recur', interval, jid)
end
@@ -170,7 +170,7 @@ if #keys < count then
-- And now we should get up to the maximum number of requested
-- work items from the work queue.
- for index, jid in ipairs(redis.call('zrange', key .. '-work', 0, (count - #keys) - 1)) do
+ for index, jid in ipairs(redis.call('zrevrange', key .. '-work', 0, (count - #keys) - 1)) do
table.insert(keys, jid)
end
end
View
2 put.lua
@@ -138,7 +138,7 @@ else
redis.call('zadd', 'ql:q:' .. queue .. '-depends', now, jid)
redis.call('hset', 'ql:j:' .. jid, 'state', 'depends')
else
- redis.call('zadd', 'ql:q:' .. queue .. '-work', priority + (now / 10000000000), jid)
+ redis.call('zadd', 'ql:q:' .. queue .. '-work', priority - (now / 10000000000), jid)
end
end
View
2 retry.lua
@@ -65,7 +65,7 @@ else
redis.call('zadd', 'ql:q:' .. queue .. '-scheduled', now + delay, jid)
redis.call('hset', 'ql:j:' .. jid, 'state', 'scheduled')
else
- redis.call('zadd', 'ql:q:' .. queue .. '-work', priority + (now / 10000000000), jid)
+ redis.call('zadd', 'ql:q:' .. queue .. '-work', priority - (now / 10000000000), jid)
redis.call('hset', 'ql:j:' .. jid, 'state', 'waiting')
end
end

0 comments on commit c4c875a

Please sign in to comment.