You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is more a help request than an issue.
I'm using this package in an AWS Lambda function and such function has to be really responsive.
Since different keys have to be locked by different calls to my function, each time I:
instantiate a client;
request a lock on the desired key;
of course, perform DB operations;
release the lock;
close the client.
The problem is that executing client.close() takes more or less 4 seconds, which is too much for the responsivity constraints I have to fulfill.
So, I was wondering whether I can have a large enough thread pool that I would like to pass as app_callback_executor parameter when instantiating the client so that I wouldn't need invoking client.close(), still avoiding to reach the maximum number of threads allowed for my lambda function (which, indeed, happens if I don't call close()).
Would it be possible?
The text was updated successfully, but these errors were encountered:
Description
This is more a help request than an issue.
I'm using this package in an AWS Lambda function and such function has to be really responsive.
Since different keys have to be locked by different calls to my function, each time I:
The problem is that executing
client.close()
takes more or less 4 seconds, which is too much for the responsivity constraints I have to fulfill.So, I was wondering whether I can have a large enough thread pool that I would like to pass as
app_callback_executor
parameter when instantiating the client so that I wouldn't need invokingclient.close()
, still avoiding to reach the maximum number of threads allowed for my lambda function (which, indeed, happens if I don't callclose()
).Would it be possible?
The text was updated successfully, but these errors were encountered: