Tylr (Dec 04 2024 at 23:16): Tylr (Dec 04 2024 at 23:16):[Im trying to better understand use cases behind the jco serve command and the wasmtime serve command. It seems like wasmtime creates a new memory block for each request https://github.com/bytecodealliance/wasmtime/blob/main/src/commands/serve.rs#L485 while jco serve wraps the incoming request handler from the component in a new wasm and keeps the memory around because the wasm is still using the same 'store' while running.
While this seems to conflict with this statement about isolated requests. I can imagine how persisting some memory between requests is beneficial, for example aws lambdas do this while they are 'hot', losing memory once the vm is terminated or a new one instantiated.
Was this the intended case behind jco serve command persisting state between requests, that having some memory in place is beneficial? Or was to defer other setup to the wasm runtime and avoid including an http server library with the jco library?
Guy Bedford (Dec 04 2024 at 23:24):This is today, just an implementation shortcut for Jco serve, and we should probably be following Wasmtime behaviour of per-request isolation.
Guy Bedford (Dec 04 2024 at 23:24):or at the very least making that configurable
Guy Bedford (Dec 04 2024 at 23:25):Mostly though, it is better to use wasmtime serve and Jco serve is merely a proof of implementation of another approach, that may also be useful in environments Wasmtime can't run
Guy Bedford (Dec 04 2024 at 23:26):we should probably warn that it's mostly good for testing as opposed to production workflows
Tylr (Dec 04 2024 at 23:32):Are there examples or discussions around snapshotting the state up to a point and answering new requests from this previous snapshot point? For example a configuration / setup step where you want to allow the first request to define 'state' or behavior, and subsequent requests to always start from that post-setup state?
Like combining the initialization from wizer. I imagine something like jco run or jco serve with --save-snapshot-on-exit and output a new memory state component to resume from?
Guy Bedford (Dec 04 2024 at 23:57):a dynamic snapshotting framework is certainly a common discussion, but no one has put forward a complete approach yet. @Joel Dice has a piece of this picture in https://github.com/dicej/component-init which could in theory plug into Jco as its execution environment due to it allowing the interpreter to be implemented as a trait.
Tylr (Dec 05 2024 at 00:03):Thanks for the link, ill read through their approach
Last updated: Dec 23 2024 at 12:05 UTC