AppSync would be more expensive though

But still cheaper

The sockets themselves dont hold any specific pricing at all. A socket just keeps a durable object active. While a durable object is active it accumulates a duration charge. Even if you have 100 sockets connected to a single object the object doesnt somehow have more active time because many people are connected to it.

ok

The good part is that you can use the same DO for control more than one room... In this example you can put more rooms per DO. 50 per/do will cost something like 0,27c, But yes, will need at least 500 rooms / DO like that to beat the AppSync.

Sure you could have more than one room per DO but a DO can only handle so much scale. Pubsub would really be better for chat rooms but pubsub is still in beta and the limits arent up to par yet

Hello I have one query. Is there is way to create queue inside Durable Object?

@ruttvikkheni yes of sorts - you can store data with a lexically ordered key, and use an alarm to process them

https://github.com/evanderkoogh/do-taskmanager also helps - it's a wrapper around alarms with an interface

@ehesp I have one worker with web socket pair and I need

web socket server(pain[1])

inside queue consumer, so how I can manage DO here? end goal, when consumer queue finish execution at that time I need to send message using

web socket server(pain[1])

.

Folks, do you know whether Durable Objects with live websocket connections will stay active when a new version is published?

I believe they do, but double checking

my understanding is the opposite (see https://github.com/cloudflare/miniflare/issues/178 for example), but not sure.

sockets are definitely closed when a DO eviction occurs, fwiw: https://discord.com/channels/595317990191398933/773219443911819284/930976111310032937

Does anyone know why one of my DOs is getting persistent storage wiped when publishing updates from wrangler, while other DO class's objects are maintaining their state.storage across deployments?

Appreciate this, thank you!

Something that I didn’t know before trial and error is using Wrangler dev will load the existing data of live DOs and any storage changes are made on top of it. When dev resets, the data resets back to what is live. I don’t know if this could be your issue since you didn’t mention you were in dev mode, but it threw me.

Can you tell me how long sessions are stored in this object? How much data can I store here at most? I just want to store chat information (chat type, user data, etc) here

Any variable that is part of your Durable Object exists as long as it is alive(may be 30 seconds, may be an hour, may be more). You have the standard 128 mb memory limit to contend with, although note that this includes all of the data in your DO, not just

this.sessions

.

thanks!

Please also note that your DO may get destroyed at any time, e.g. when the CF team is updating the runtime behind it.

So you may want to store the data externally from your DO, in cache, etc.

I am not in dev mode that I know of, however my DO is called [worker]_production_[ClassName] and is taking no hits in the metrics, so I suspect I am accessing this DO in dev environment. How did this happen, when it's not the case for my other DO on the same Worker?

Hi @kenton and #773219443911819284, one of my clients using DO happened to see this issure pop out again. Read messages for context and see if you can replicate it again: https://discord.com/channels/595317990191398933/773219443911819284/931230846017470474

It seems like the timeout is now 3-4 minutes instead of the initial time.

The DOs are evicted even with client events.

Except when DO code is deployed, they are force evicted, correct?

Haven't tested it yet. The WS connection is made, the DO gets called once, then after 3 minutes the DO is gone.

Are you not sending any messages over that connection in those 3 minutes?

Just the WS connection sends pings and receives pongs, but no DO invocation is done in the meanwhile.