Child pages
  • Session management in XNAT scripts
Skip to end of metadata
Go to start of metadata

Large data processing tasks often require scripts of some sort to pull large quantities of data, push synthetic resources back into the system, perform searches or other queries, and so on. These scripts work well to automate processing tasks but face certain issues that usually are not present with user interface actions. The most common issue is managing user sessions on the server.

There is a hard limit to the number of active sessions a particular account can have on an XNAT server. This value is set with the property security.sessions.concurrent_max in the configuration file The default value is 1,000. Attempting to authenticate once you already have the maximum number of active sessions will result in a failed authentication. And, even before you reach the point where authentication fails due to over-allocation, having too many active connections to your server can result in performance degradation.

You can change the number of concurrent sessions on your server by changing the value of security.sessions.concurrent_max in the configuration file This requires a server restart. There is also a limit to the number of concurrent sessions enforced at the application server level, but this value is dependent on the server type, version, and platform on which you're running.

Usually, this session proliferation is driven not by the need to actually have so many sessions but simply by the need to make many requests to the server, but without properly managing the sessions. Properly managing your XNAT sessions can go a long way to mitigating these negative effects. Proper management comes down to the following principles:

  • Reuse of sessions
  • Monitoring of session usage
  • Closing sessions when done

Step-by-step guide

This describes a best practice for creating, re-using, monitoring, and releasing XNAT sessions:

  1. Create a new session by calling /data/JSESSION on the server:

     >> curl –u ambite:password
  2. Now make your curl call (or whatever tool you’re using to access Central, XDC?) passing the JSESSIONID as a cookie:

    >> curl -b "JSESSIONID=B43AB8A989E3A026E5E539DF09A01B0B"
    {"items":[{"children":[],"data_fields":{"secondary_ID":"RixSharingTestSource","description":"The source folder to test session sharing issue.","name":"Rix Sharing Test Source","ID":"rixsrc"},"meta":{"isHistory":false,"xsi:type":"xnat:projectData"}}]}
  3. You can check how many sessions you have open at any given time using the /data/user/{USER_ID}/sessions call:

    >> curl -b "JSESSIONID=B43AB8A989E3A026E5E539DF09A01B0B"
  4. Once you’re done with all of the stuff you want to do in a particular transaction, close your session:

    >> curl -b "JSESSIONID=B43AB8A989E3A026E5E539DF09A01B0B" -X DELETE

    Note that further calls with that JSESSIONID will fail:

    >> curl -b "JSESSIONID=B43AB8A989E3A026E5E539DF09A01B0B"
    <title>Status page</title>
    <h3>The server has not found anything matching the request URI</h3><p>You can get technical details <a href="">here</a>.<br>
    Please continue your visit at our <a href="/">home page</a>.