Mourits de Beer
Mourits de Beer
> Ah…this is the issue you thought was resolved with the last Askar updates. I don’t think the follow up Askar changes would have impacted this, but who knows. Indeed...
Note: in my latest runs, I see this askar warning log pops up just before the exceptions occur: ``` 2025-02-06 11:47:06,893 aries_askar.native.sqlx.pool.acquire WARNING /cargo/registry/src/index.crates.io-6f17d22bba15001f/sqlx-core-0.8.3/src/pool/inner.rs:308 | acquired connection, but time to...
Ok. After adding debug logs to the opening and closing of Askar sessions, I can see that the Issuer tenant's session that gets absolutely spammed with open-close requests. AskarProfile _setup...
Ah, I see now why sessions are recreated. I missed that in askar.profile, `session` returns a new instance every time: ```py class AskarProfile(Profile): ... def session(self, context: Optional[InjectionContext] = None)...
Caching the session (when context = None) speeds up live/status checks by ~40ms 👀 since `_setup` and `_teardown` aren't called every time
It's proving quite tricky for me to refactor, because there's a (classic) trade off between keeping too many connections open, and opening/closing too frequently. For this particular issue, it's mostly...
The answer is with the `max_connections` config, e.g.: ``` ACAPY_WALLET_STORAGE_CONFIG: '{ "max_connections":10, "min_idle_count":10, "url":"cloudapi-postgresql:5432" }' ``` We were running with 10 as the max_connections, and that's why things start acting...
One thing worth mentioning, that I noticed in the didexchange methods, is that there is an `async with session` block (opening up one session) and then within that block, more...
Ready for review! I wanted to test compatibility with ACA-Py, but building and installing the python wrapper from my local branch, and running pytest in ACA-Py, gives me: ``` ......
A logical extension would be to add the custom ordering option to "fetch all" queries as well (in a future PR)