You are not logged in.
Pages: 1
Hi,
We're running 6.1.8-8RC, and logging in with an API key via the Core_LoginWithKey method, with persistent set to true.
In general, these sessions do appear to persist for long periods of time. However, when apache is restarted as part of the logrotate configs on the server, it appears that the persistent session keys are lost.
Is there any way you could persist these keys to disk somewhere so they aren't affected by an apache restart or a server outage? We had hoped that the addition of the persistent api-key-based login would prevent us from having to validate our session key with every call we make to the API, but with the persistence not being guaranteed, it seems we have to perform this validation.
Offline
Hi,
We think this maybe happening for a reason that is unrelated to a restart of Apache. Sessions should normally persist over a restart and are even able to persist over an upgrade of the software which entails restarting almost every component. Just to be sure, we did some extra testing on 6.1.8-8RC but were not able to replicate your findings. At this point it is a little difficult to suggest what other factors could be at play but if there is anything else you can tell us about your setup, that might help to generate a few more ideas.
Best Regards,
Steve
Offline
Hi Steve,
Thanks for checking into that for us. We will try to catch when this occurs again as it seems to be relatively random although at least once has correlated with an Apache restart, and get you some logs at that point.
Offline
Hi, thanks for your reply and email to the support desk. I've had a look - though there's not a huge amount to go on. But I did note that there are no sessions in the database set to be persistent at the moment. If this is unexpected, perhaps that is something for us to investigate. Alternatively, is it possible for you to trigger your script so that I can make sure that a persistent session is being added?
The timing mentioned in your support ticket regarding a session created at 2pm and becoming invalid by 9am is interesting because a non-persistent session has a max lifetime of 16 hrs.
Cheers
Ben
Offline
Yeah, that's definitely unexpected. At the moment, this is what the JSON looks like that we're POSTing:
{"apiVersion":"1.0","action":"Core.LoginWithKey","inParams":{"apikey":"<our api key here>","options":{"persistent":"true"}},"sessionId":null}
I'm not sure if perhaps sending a null sessionId with the request is causing problems?
I re-ran our process at 3:42PM mountain time, if you want to check if any persistent sessions have now been created.
Offline
To follow up for the benefit of anyone else reading:
We found that "persistent" sessions could be used indefinitely, but that inactive ones could still be cleaned up after around 9 hours [of inactivity]. As of IMS v6.1.8-13 this has been raised to two weeks.
This means that orphaned persistent sessions will still be cleaned up, but a single query per fortnight is sufficient to keep a session alive.
Offline
Pages: 1