Interval override in worker constructor not working

[Peter Hanneman]

I've been trying to get my worker setup using:

new RSMQWorker('MyQueueName', {
  interval: [0.1, 0.2],
  defaultDelay: 0,
  maxReceiveCount: 10
  invisibletime: 30,
  autostart: false,
  timeout: 6000,
  alwaysLogErrors: false,
  host: '127.0.0.1'
  port: 6667,
  redisPrefix: 'queues',
}

I know the redis prefix and port get over-ridden from the defaults properly but the interval isn't. If I change my interval directly in the rsmq worker defaults it works fine and if I change the interval using the function changeInterval([0.1, 0.2]); it works fine. Didn't see any obvious problems from my cursory check of the worker code. I feel like I'm crazy since some of the properties work while interval doesn't.

One other note...why isn't pub/sub being used to prevent polling of the Redis server. If I have 10 workers polling every 0.1 seconds that's 8.64 millions requests if I didn't have a single incoming request. I am finding myself writing my own pub/sub wrapper around RSMQ worker to change the interval for a short burst then back to infinity to avoid the polling...

[M. Peter]

Hi, i fixed the interval bug caused by the the array merge through the extend module.

The pub/sub enhancement is a feature i thought about for a while, but not implemented yet.
To make sure it's working correctly it has to be a feature within rsmq to publish messages on every message write

[Peter Hanneman]

Thanks for the quick turn around. I have implemented a basic pub/sub wrapper where the producer publishes to all of my workers, which triggers a rsmqWorker.changeInterval([0, 60]). But I noticed that when the worker calls the changeInterval function that the setting wasn't immediately being applied. To make it take immediate effect I had to call rsmqWorker.interval(). I haven't gotten around to testing under heavy load yet but it appears to be working so far.

The main possible pitfall I can foresee would be if the producer flooded the queue with more tasks than the workers could immediately consume then they may reset their polling interval before clearing the backlog. This is a non-issue if next() triggers a fetch from the queue. Just a thought,