Fix ttl increase after delay

olegrok commented 6 years ago

Close: https://github.com/tarantool/queue/issues/80

Totktonada commented 6 years ago

@olegrok touch method need to be changed accordingly, yep?

Can you add a test case for both *ttl queue drivers (tests seems to be quite straighforward and that should not be a problem).

olegrok commented 6 years ago

@Totktonada No, touch works correctly. I sought correct behavior using touch before release.

I hope I can add tests a bit later

Totktonada commented 6 years ago

touch has increment (delta) argument in seconds according to README and now it is just added to the ttl value of a task. release after your patch adds seconds * 10^6 to ttl value of a task. I think external API should use seconds and internal representation should use microseconds.

olegrok commented 6 years ago

@Totktonada I added tests

Yes, internal representation of touch uses microseconds. And touch works correctly. See line 116 in abstract.lua

Totktonada commented 6 years ago

@olegrok Thanks! I got it, touch really works correctly. Now we have seconds for delay in release and microseconds for delta in touch in an API for drivers, but seconds everywhere in user-visible API. I think possible refactoring can go outside of scope on this PR.

LGTM. @olegrok, please proceed with merging it into master (squash + fast-forward / no squash + fast-forward / squash + merge commit / no squash + merge commit as you wish).

There are things I want to bring into focus as outcome:

Drivers API is unchanged with cost of non-uniform drivers API (sec / microsec).
External queue API was changed, but in the manner that the documentation already stated.
It seems that the change does not need to involve data migration for old tasks (because we anyway cannot extract previous delays from ttl).

tarantool / queue

Fix ttl increase after delay #81