We use a node.js middleware API. Among other things, our users upload files into container fields in our FM app. The API uses an OttoFMS API key for authentication against the FMS DataAPI.
When files are uploaded, the RAM consumption of the fmwipd process increases and is not freed up afterwards.
Is it true that OttoFMS keeps one or more DataAPI sessions open in the background so that it does not always have to log in again? Is there a way to release the RAM after file uploads? Or is it better in this case to integrate DataAPI authentication into the middleware API and use FMS native authentication and end the session with a DELETE session request after uploads?
Actually, I’m not sure whether the RAM consumption comes from keeping up the session by OttoFMS…
OttoFMS doesn’t “keep a session open”, but it doesn’t delete it either. The data api itself will leave the session open for 15 minutes. That might be what’s causing your issue. Does the memory usage go away when the session ends? If so you could add a logout at the end off the process.
The other thing you could do is use OttoFMS Webhook File Uploads. In the process the uploaded file is never loaded into memory, it is stream directly to disk, when the process is done, the webhook payload gets a path to the file on disk, which you can use from a fileMaker script to insert the file into a container field.
But we need to get a document published on how to do that. We haven’t made it clear. Stay tuned for FileUpload docs.
Created a DataAPI Key, used it for a DataAPI request (get all records) and then logged out. Afterwards the get all records request failed with error code 500 and Json-Body
{
“error”: “Error calling data api proxy: Request failed with status code 401”
}
Then I found the returnExisting option, but I can retrieve the first DataAPI key only. We’ve got multiple APIKeys for one generic FM-User, each assigned to a user and individual permissions.
So, if I had the keys dk_123 and dk_456 I’d like to be able to relogin with either dk_123 OR dk_456, not just the oldest one. Is this possible somehow?
Would be easy, if I could send the APIKey along with the DataAPI-Key creation request to retrieve an existing key, instead of using the “returnExisting” option…
I’m not sure how the useExisting option comes in here, why are you retrieving the Data API Keys using the credentials like this? Data API Keys are intended to be used instead of the credentials, the “useExisting” option is intended for a situation where you might want to store a data api key in a database for a user who logs in with their credentials. Data API keys are made to get around the issue of manual session management, so you shouldn’t need to do the login/logout flow outside of testing.
I’m not sure the Data API Session is the thing that is causing your RAM utilization increase here. A couple tests to run:
If you upload a file, then don’t touch the Data API for 20 minutes, does the RAM get freed up?
If you upload a file under two different FileMaker accounts (and therefore make 2 sessions) is there a larger increase in the RAM than there was with a single account?
If you make a request to the Data API without uploading a file is there a RAM increase?
#1 will tell us if the session getting released releases the RAM #2 will tell us if multiple sessions compounds the problem #3 will tell us if it is a Data API request issue or a file upload issue.
If you’re using this primarily for file uploads I would recommend using OttoFMS webhooks to upload the files rather than the Data API. I’ll see if I can get a document together for that today.