Skip to content

Clump the delay to maxPossibleDelay#1

Open
erlichmen wants to merge 5 commits intopurposeindustries:masterfrom
sambame:master
Open

Clump the delay to maxPossibleDelay#1
erlichmen wants to merge 5 commits intopurposeindustries:masterfrom
sambame:master

Conversation

@erlichmen
Copy link
Copy Markdown

according to https://www.rabbitmq.com/ttl.html the max value for x-expires is 2^32-1.
Make sure that we don't overflow the value as it will throw precondition_failed error.

according to https://www.rabbitmq.com/ttl.html the max value for x-expires is 2^32-1.
Make sure that we don't overflow the value as it will throw precondition_failed error.
@oroce
Copy link
Copy Markdown
Member

oroce commented Sep 15, 2014

first of all: thanks for your contribution

yes we are aware of that.
we never put bigger value than 2^32-1 in case we have to (for example we want to schedule something for 30 days) we do it in two steps (20 days + 10 days delay).

I think we shouldn't silently change the delay but should throw an error.

@madbence?

@erlichmen
Copy link
Copy Markdown
Author

I got the actual problem from the retry packages that uses schedule for the backoff delay.
The problem is that if the error is not catch here it will throw an error on the amqp connection and most probably crash your application.

I don't think that the schedule module should handle splitting the tasks since that might cause different problems (what happens if someone by mistake schedule something for a millions years away?)

error can be nice but how would a user handle it?, most likely the user would not handle it and we are back to square one (app crashing).

most certainly the retry package needs to be fixed as well, but this is a one size fits all solution that at least doesn't crash the apps for existing users.

@madbence
Copy link
Copy Markdown
Contributor

You're right, amqp-schedule should not handle task-splitting, but it should also not modify the delay silently. The best solution would be an exception. I will look into this problem this evening.

@oroce
Copy link
Copy Markdown
Member

oroce commented Sep 15, 2014

sure scheduler shouldn't handle splitting the task, we are using an internal module for that.

I think we could do something like this:

...
return function publish(exchange, route, message, delay, options, fn) {
   if(delay instanceof Date) {
     delay = delay.getTime() - Date.now();
   }

  if (delay + opt.threshold > maxPossibleDelay) {
    var err = new Error('Delay is bigger than 2^32-1');
    if (fn) {
      return fn(err);
    } else {
      return conn.emit('error', err);
    }
  }
....

Basically we can reuse fn or emit an error on connection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants