Thats not slow and the worker being the producer and consumer of it wont affect the speed in any way

Thats not slow and the worker being the producer and consumer of it wont affect the speed in any way. A queue has a specific location and workers run in every datacenter cloudflare has

Kaique Nunes•9/17/23, 8:15 PM

Got it. I thought each queue ran in the same worker region.

UnsmartOP•9/17/23, 8:19 PM

theres like 300 regions that run workers that would be way too many and wouldnt actually be a queue at that point unless your users all happen to be the same region

Kaique Nunes•9/17/23, 8:29 PM

Assuming there was no need to share context between workers, would it be possible to currently run one queue per region, thus reducing latency?

UnsmartOP•9/17/23, 8:30 PM

No queues dont even have the capability to run in a majority of datacenters

UnsmartOP•9/17/23, 8:31 PM

At that point though you might as well not have a queue unless you have like thousands of requests per second because chances are there are an insanely small amount of your traffic sharing the same dc

Kaique Nunes•9/17/23, 8:40 PM

In this specific case where I think 160 ms is too much, I use the queue to guarantee writing to D1 without compromising the original request, returning success in the shortest possible time.

I'm using Durable Objects, but since the DB needs to be SQL, I didn't see any other way. Despite this, in my tests delegating writing to a queue reduced the response by up to 100ms.

UnsmartOP•9/17/23, 8:44 PM

I mean you can probably do the same number of rps to D1 that you can to Queues given they both use durable objects under the hood so might as well just write to D1 directly instead of queue

Kaique Nunes•9/17/23, 8:48 PM

Yes, but my rps is extremely low. What matters most is responding in the shortest possible time.

Kaique Nunes•9/17/23, 10:37 PM

I just found a better way calling D1 directly without compromising the request. Since, DO still live 10 seconds after the request, I can call save without awaiting. But just to ensure I am using waintUntilwaintUntil. As long as there is no possibility of the write failing, there is no need to use a queue.

UnsmartOP•9/17/23, 10:41 PM

waitUntil does nothing in DOs and it can still fail

UnsmartOP•9/17/23, 10:42 PM

better off not using DOs and just using waitUntil in a normal worker at that point

UnsmartOP•9/17/23, 10:42 PM

an alarm at the very least would retry like 3 times I think but you would need to save the value in the DO storage first

UUnsmart waitUntil does nothing in DOs and it can still fail

Kaique Nunes•9/17/23, 10:44 PM

actually I made some tests and it does. They limited the in-memory to 10 seconds. With waitUntil I made it live for 30 seconds. Not sure if it's possible to live more time, I will test

UUnsmart better off not using DOs and just using waitUntil in a normal worker at that poi...

Kaique Nunes•9/17/23, 10:45 PM

Yes, but I use the DO storage

UnsmartOP•9/17/23, 10:49 PM

The documentation got changed due to moving to its own section and some stuff seems to be forgotten/i cant find but as you can see from this message on the old docs: durable-objects

waitUntil in durable objects does nothing.

UnsmartOP•9/17/23, 10:53 PM

waitUntil/non awaited DO promises also has 0 guarentees of the promise actually completing and it does not retry any operations so there is a chance you return a success to the user but it does not succeed

Kaique Nunes•9/17/23, 10:57 PM

Not sure what is happening, but I created a simple counter that I can already persist in-memory for at least 2 minutes when using waintUntil with setTimeout. I am not persisting on storage. After 2 minutes it is cleaned.

UnsmartOP•9/17/23, 10:59 PM

any requests that happen to the DO will extend how long it lives and if there are any unfulfilled promises it might stay longer than the 10s documented time but having an unfulfilled promise wont guarantee it will eventually get fulfilled/rejected

Kaique Nunes•9/17/23, 11:03 PM

true! DO is awaiting independently of waitUntil.

KKaique Nunes actually I made some tests and it does. They limited the in-memory to 10 seconds...

Kaique Nunes•9/17/23, 11:05 PM

Well, but if it waits for the promise to complete, why would I use the alarm??

UnsmartOP•9/17/23, 11:06 PM

it waits but it doesnt guarantee it will actually finish... and it doesnt retry on any errors

Kaique Nunes•9/17/23, 11:07 PM

wow, great! thank you very much! I will do some tests

=HT=Chief•9/18/23, 8:51 PM

are there any plans to offer amqp support for remote integration with queues? I'd love to use this as an alternative to RabbitMQ.

CCharlie @htchief being able to consume from a Queue directly via API is on the roadmap. ...

=HT=Chief•9/18/23, 8:59 PM

right, but my understanding is that the protocol for that would be http, not amqp (Advanced Message Queuing Protocol)

=HT=Chief•9/18/23, 9:01 PM

the core difference to my understanding is that it's essentially single-socket-per-connection based, meaning that you can reduce the amount of requests / responses between endpoints

=HT=Chief•9/18/23, 9:02 PM

but the fact that there's already libraries across multiple languages which support the protocol is also nice

CCharlie Walk me through what you’re looking for here?

=HT=Chief•9/19/23, 12:45 AM

Apologies for the late response. From my understanding, the product that you're offering is very similar in functionality to RabbitMQ, which is a product that I use a lot. I would love to be able to use your product (when it is ready for this kind of testing) as a drop-in replacement - especially in the scenario of using an edge worker to enqueue messages to the queue for asynchronous processing.

UnsmartOP•9/19/23, 12:47 AM

Its meant to replicate AWS SQS rather than RabbitMQ technically. What specifically from RabbitMQ do you want? Not sure what all it offers

=HT=Chief•9/19/23, 12:48 AM

i'm not as familiar with SQS, but from a quick search, the functional difference between SQS and RabbitMQ is the hosting

=HT=Chief•9/19/23, 12:50 AM

otherwise they're similar products. The big appeal of RabbitMQ for me is the amqp protocol which is essentially socket based, so a new connection doesn't need to be made every time messages need to be fetched by the consumer (or the injestor)

UnsmartOP•9/19/23, 12:51 AM

afaik the only thing AWS SQS has over cloudflare queues is FIFO (first in first out) and HTTP api. SQS doesnt have any websockets afaik only http

=HT=Chief•9/19/23, 12:51 AM

and support for the amqp protocol would mean that i could use an existing library instead of having to write a whole new one (even if it is provided by as SDK)

=HT=Chief•9/19/23, 12:52 AM

ah, yes, RabbitMQ is FIFO out of the box. Also, i don't care for "websockets" - just a socket connection

=HT=Chief•9/19/23, 1:02 AM

here's a quick illustration of what i'm currently dealing with. What i'd like (in order to reduce the # of "subrequests") is to be able to route from a worker into a queue, and then to be able to consume the queue from my applications which are not workers (and are too complicated to be re-built in that environment)

=HT=Chief•9/19/23, 1:05 AM

again - as a "make a wish" for this product, i'd love it if i could use amqp as the protocol, not just HTTP. Here's more information about it:

https://www.amqp.org/

The rest of the product seems like it has a lot of potential and i'm looking forward to seeing how i can utilize it.

MetalGear•9/19/23, 12:52 PM

Is there a way to consume an event after a 10 minute delay instead of right away. I’m communicating with an iot device api and sometimes the third party is unreliable or down for couple hours so I have to retry every 30 min

CCharlie Not necessarily a solution to this problem, but have you looked into our PubSub ...

MetalGear•9/20/23, 12:33 AM

I actually have not because I thought queue was the reccomeneded solution for simply processing events. I just need a way to send a command to a iot device. If the consumer worker fails sending the fetch api call then I just want it to retry. Do you think I should look at it ? If so why? Thank you. I dont really understand the major difference between queues and pub/sub besides that pub sub has topics and subscribers and queues is just a linear stack that has events in order waiting for them to be consumed

==HT=Chief ah, yes, RabbitMQ is FIFO out of the box. Also, i don't care for "websockets" - ...

Kai•9/21/23, 8:58 AM

I just want to point out that HTTP requests beyond HTTP 1.1 are also kept alive if the implementation is decent. I would think that a future queue HTTP API will even support HTTP 3 which would allow you to pull a lot of messages over a single udp "connection". I highly doubt you'll have performance problems that aren't solved by a better HTTP implementation.

CCharlie Both can be great choices, depends on what your needs are. PubSub is based on th...

MetalGear•9/21/23, 1:32 PM

Is pub sub like queues in the sense that it’s guaranteed delivery at least once and rarely more then once?

zegevlier•9/21/23, 1:52 PM

No, as per https://developers.cloudflare.com/pub-sub/platform/mqtt-compatibility/, pubsub currently only supports at most once delivery, not at least once.

KKai I just want to point out that HTTP requests beyond HTTP 1.1 are also kept alive ...

=HT=Chief•9/21/23, 6:28 PM

That is very interesting (i learned something new - thank you), but at the end of the day doesn't really answer on the ability to use pre-existing SDK's / libraries to integrate with queues. Its the difference between being able to use queues as a drop-in replacement vs having to build a completely new integration to work with it.

Zzegevlier No, as per <https://developers.cloudflare.com/pub-sub/platform/mqtt-compatibilit...

MetalGear•9/22/23, 1:36 AM

what i really dont understand is how are developers okay with at most once. Like who is okay with missing an event

Saifulapm•9/22/23, 8:10 AM

Can we use service binding in queue ? If yes, then what request should pass in fetch ??

Thats not slow and the worker being the producer and consumer of it wont affect the speed in any way

Similar Threads

Similar Threads

Similar Threads