We are using a multi-threaded micro-service model and attempting to make several calls to Rollbase Private Cloud for retrieving object content via getPage. Our model requires up to about 20 threads based on the type of objects being retrieved.
When we get over 3 threads, we start getting 403 errors with "Session Expired" or "Invalid Credentials" as the response.
Is there a configuration parameter in the server that limits the number of requests per session like this?
In next release 4.0, we are adding a system setting which you can use to have multiple REST sessions for same user (only on Private Cloud).
So with 4.0, you will have the following options
1. Use Basic Auth
2. Use system setting to have multiple REST sessions for same user.
System does have throttling in place to prevent misuse of REST/SOAP APIs. System handling the load you have mentioned is a largely a function of Server Hardware resources.
I would recommend creating separate session ID for each thread.
It's my understanding that when I create a new session for a user id, it expires the prior session?
Each thread makes several calls to Rollbase, so the thread session is needed throughout the life of the thread. If a session request expires the prior user session, then this would still conflict.
Correct. For that reason you'll need separate user credentials for each thread.
And that becomes economically non-feasible. That would require one named user per thread per business process. Unless Progress is going to hand out free named-users, this is not a workable solution,
I believe the more feasible approach is using basic authentication and avoiding the entire use of sessionId in the API. We're trying the process - will report back our results.
In next release 4.0, we are adding a system setting which you can use to have multiple REST sessions for same user (only on Private Cloud).
So with 4.0, you will have the following options
1. Use Basic Auth
2. Use system setting to have multiple REST sessions for same user.
System does have throttling in place to prevent misuse of REST/SOAP APIs. System handling the load you have mentioned is a largely a function of Server Hardware resources.
Thanks Anoop! And, yes, the hardware setup is the core issue for performance on both ends.