ah yea i get that, but if you have migrations in your DO, you always have stored data im assuming?
ah yea i get that, but if you have migrations in your DO, you always have stored data im assuming?
LYes, but part of your DO's functionality might not use stored data. A commonly accepted software engineering principle is to not do work until it's needed.
Ji see i see. thank you!
LExactly what @Larry said. I need to update the README of my library to explain this since many folks ask about it at this point. It seemed a bit obvious to me, but I was wrong assuming that.
JThe internals of the DO and when constructor gets called and stuff isnt so obvious
JThanks though, amazing library
DI'm still hoping one day we'll have DOs in all colos, even if storageless - the use case is for websocket handling and chat rooms where persistence is external anyways
ZIsn't storageless DO just a worker? 
Dyou can't use hibernation, connect multiple websockets to the same worker, so not quite
ZAh I see
Dbut I see where you're coming from, for a simple proxy, or maybe a filtering/logging service, yeah regular workers are just fine (even better for some things since no wall time charges)
LThe big benefit of DOs over workers even without storage is coordination due to the global uniqueness of the DO ID.
TWe just had a customer having an outage on an important realtime-flow because a DO was hanging for >1h - no requests timed out, they were hanging in pending state.
I'm a bit out of ideas here - since there are no errors, or no indicators on why this suddenly happened.
A re-deploy fixed this, and all connections were reset.
I'm a bit out of ideas here - since there are no errors, or no indicators on why this suddenly happened.
A re-deploy fixed this, and all connections were reset.
T(This wall time is from an alarm in a different DO that uses RPC to connect here)
TIn the morning we had requests erroring with an overload error - self-recovered just fine after the load was gone. But this time, we're a bit clueless - especially since there was no self recovery :/
TThe DB in the DO is still relatively small for DB standards, with just 50k records. Nothing that should hit the limit.
T@Sunil Pai - this was a partyserver DO with hibernation, not sure if you have seen this one before
Tjust happened again
TYes, the requests are simply not connecting from either outside w/ Websockets or inside with RPC
THey chaps, we've just started playing around with Sqlite Durable objects. We created a really simple alarm DO that wakes itself up every minute. The actual stored data is de minimis. Its a single column in a single row in a single table of ~100 bytes max. We've had this running for not very long - but our billable duration has already hit 1.6GB-s. I feel like that can't be right - do DOs have some fixed "base" storage associated with them?
TThis is not storage but rather a RAM-like billing
T1,6GB-secs mean your DO was active for about 12 secs
LIt's indeed confusing to calculate it, but 1.6GB-sec means it's 12.5 seconds of 128MB (the DO memory you are charged). As Tobias said.
TAh but I assumed the DO was loaded into memory and thus the 128MB was the “size” of the DO
LDurable Objects are code like Workers, and they have durable storage you can use up to 10GB. They don't load all that storage in memory. Your DO has 128MB to use for its normal code operations, and tha'ts what you are charged for duration. The durable storage itself is charged separately.
Read https://developers.cloudflare.com/durable-objects/platform/pricing/ if you haven't.
Read https://developers.cloudflare.com/durable-objects/platform/pricing/ if you haven't.
TAh thanks for the clarification
Banyone knows how long it takes to get into the realtimeSDK beta? I applied on the 17th of april and did not get in yet
SPlease do not post your question in multiple channels/post it multiple times per the rules at #
welcome-and-rules. It creates confusion for people trying to help you and doesn't get your issue or question solved any faster.
welcome-and-rules. It creates confusion for people trying to help you and doesn't get your issue or question solved any faster.FHey everyone!
I have a C++ application, that creates its own sqlite database for its internals. I want to use it in a Cloudflare Durable Object. I recompiled to Webassembly, created Emscripten bindings, so now I can trigger the creation of the aforementioned database from JS, in a Durable Object class.
Question:
https://developers.cloudflare.com/durable-objects/api/storage-api/#sql-api
Thanks
I have a C++ application, that creates its own sqlite database for its internals. I want to use it in a Cloudflare Durable Object. I recompiled to Webassembly, created Emscripten bindings, so now I can trigger the creation of the aforementioned database from JS, in a Durable Object class.
Question:
- is this setup taking advantage of the Durable Object setup ?
- or in other words, do I have to feed my query strings to
this.sql.exec(...) - or is the db created by my C++/WASM code is just as fast?
https://developers.cloudflare.com/durable-objects/api/storage-api/#sql-api
Thanks
Cloudflare Docs
The Durable Object Storage API allows Durable Objects to access transactional and strongly consistent storage. A Durable Object's attached storage is private to its unique instance and cannot be accessed by other objects.
LYour WASM database will definitely be slower. And unless you use the DO storage I don't see how your changes will be durably persisted if you only do them inside WASM.
Vwhen adding /
offset
LDepends on your queries, we have folks doing hundreds of thousands of rows read per second, and we have seen a few low millions too. It depends how many of these queries you have in parallel since your DO will be blocked for that amount of time per request.
A few low/single-digit thousands should be a good ballpark to start with to still stay within a few milliseconds.
A few low/single-digit thousands should be a good ballpark to start with to still stay within a few milliseconds.
Vyes i was planning on doing that but i thought saying limit/offset would get my point across better
Fi have singleton pubsub in cpp
I use emscripten::val to call js from c++
using QueryCallback = std::function<void(const std::string &)>;
c++ publishes and I in my bindings I subscribe with a function that calls into JS, and passes query string
val jsFunc = val::global("printName");
QueryCallback cb = [&jsFunc](const std::string &query) { jsFunc(query); };
pubsub_singleton.addListener(cb);
I use emscripten::val to call js from c++
using QueryCallback = std::function<void(const std::string &)>;
c++ publishes and I in my bindings I subscribe with a function that calls into JS, and passes query string
val jsFunc = val::global("printName");
QueryCallback cb = [&jsFunc](const std::string &query) { jsFunc(query); };
pubsub_singleton.addListener(cb);
Fi'd be a lot nicer with a C++ API 
AWhy is there no ability to list the DO instances (or at least the number of them) on the web dashboard? I get that it is accessible via the REST API, but it seems like something that should be on the dashboard... (unless I am missing something)
FHas anyone built a sharding library for DOs to grow dynamically once req/s or storage limits are hit? I remember seeing something like that at some point in this chat
Ahow much time after the last user disconnects will a DO spin down?
Ai need to know because we have some long-running async tasks to run
Awondering if we need e.g. in a DO
HIIRC doesn't give you more time in a DO
HThe request context for a Durable Objects extends at least 60 seconds after the last client disconnects. So waitUntil is not necessary. It remains part of the DurableObjectState interface to remain compatible with Workers Runtime APIs.
LI have that in progress for my own library (), but not ready yet for any external use. I haven't seen any other library providing that though already.
Aoh interesting. that makes me nervous though... i have some DO code that essentially works like a regular HTTP router and i'm using waitUntil for good measure
Awhy even expose that if it's truly a no-op?
HIt remains part of the DurableObjectState interface to remain compatible with Workers Runtime APIs.
HIIRC because many things built for Workers expect to exist