get_queue should handle < 1s's precision

DavidBM / rsmq-async-rs

RSMQ port to async rust. RSMQ is a simple redis queue system that works in any redis v2.6+

MIT License

43 stars 8 forks source link

get_queue should handle < 1s's precision #25

Open GopherJ opened 3 weeks ago

GopherJ commented 3 weeks ago

        let result: (Vec<Option<String>>, (u64, u64)) = pipe()
            .atomic()
            .cmd("HMGET")
            .arg(format!("{}{}:Q", self.ns, qname))
            .arg("vt")
            .arg("delay")
            .arg("maxsize")
            .cmd("TIME")
            .query(conn)?;

        let time_millis = (result.1).0 * 1000;

now get_queue just use seconds as queue.ts and uses that as a score for incoming message, we lose some precision here

GopherJ commented 3 weeks ago

Ref: https://github.com/smrchy/rsmq/blob/5c507c2ae97145fbdef7369da52dc69b105e0cc6/index.js#L44

GopherJ commented 3 weeks ago

https://github.com/smrchy/rsmq/blob/5c507c2ae97145fbdef7369da52dc69b105e0cc6/index.js#L175 here it throw away the milli seconds, but I feel we should be consistent

DavidBM commented 3 weeks ago

Hi! I'm happy to add that to the library.

Just two things:

Can you make an PR?
We should make it optional, as I want for it to still be compatible with the Nodejs version of it. So we can have a "js_compatible" feature that uses seconds, and have it disabled by default.

What do you think?

GopherJ commented 3 weeks ago

yes I'll make a PR

GopherJ commented 2 weeks ago

@DavidBM raised simple PR https://github.com/DavidBM/rsmq-async-rs/pull/26

DavidBM commented 2 days ago

@GopherJ The MR is good! But could you make it so the changes are under a feature flag?