Hello @darkweak ,

For the wasm plugin middlewares, it works with a pool so it's possible that when the second request happens, the first middleware was not yet back in the pool.

You can see in your logs that the third request does not call the "INIT".

Hey @juliens, do you have clues to prevent that?

Do you have a reason to prevent this?

It's designed to handle multiple requests in parallel. The pool should be populated over time, and once it's filled, it shouldn't call INIT anymore.

I'm migrating the HTTP cache from go middleware to the WASM middleware (due to limitations from yægi).
It tries to recreate more and more instances, so I think the pool resize itself, kill the previous instances and recreate the middleware when a new request comes.

The pool may remove some instances from the pool, I believe to refresh old instances, but it doesn't instantiate for each requests.

With your example middleware:
With an hey command
703091 responses
I only have
322 INIT

That means, it could create so much connections to the storage provider (e.g. redis/etcd) and there is no way to avoid reinitialization.
If there is a reset (another init) when using an in-memory storage, that will result a miss and reach the upstream server too often.

Yes, the current implementation of the WASM plugin middleware in Traefik does have some limitations, particularly regarding the instance pool and initialization behavior you're observing. Each middleware instance may get reinitialized more frequently than desired, especially with external connections like Redis or etcd and with shared-memory cache.

However, as there is a pool, the situation is not as dramatic as it might sound. The pool is designed to manage multiple requests in parallel and, over time, it should stabilize, reducing the frequency of initialization calls. This helps mitigate the performance impact to some extent.

Moreover, there are ways to improve this situation that we could try in the futur:

Shared In-Memory Objects: One potential improvement is to add support for shared objects in memory. This would allow instances to share certain data, reducing the need to reinitialize connections or cache data on each request.

Enhanced Pool Management: Enhancing the pool's management strategies to improve instance lifetime can help mitigate excessive reinitialization. This includes better handling of pool resizing and more stable instance retention policies.

Clean callback: In the Yaegi middleware, when a middleware is not used anymore, the context used in the instanciation is Done, it's not the case in wasm plugin, so it could be a good idea to have a callback to free resource like ecxternal connection to avoid infinite connection.

Thank you for taking in consideration this feedback. I hope the Shared In-Memory Objects could solve this problem.
In the main, we retrieve the configuration. Maybe Træfik could export a function GetWasmShared(), a SharedObjects property or something like that, and that will basically be a KV store. What do you think?