Stored process session terminated unexpectedly

[TomDR]

Hi,

We have 'some' custom stored processes in our company, launched in a browser. We use html, java-script and ajax-calls to get those stored processes present the data (dashboards, graphs, tables, ...).

Users have to log in using their Windows-credentials, and once logged in, users can launch -depending on their user-rights- several stored processes.

The stored process session they get after logging in normally remains active for an hour, but sometimes the session is terminated unexpectedly much earlier and requires the user to log in again.

This isn't a really big deal for a normal stored process. But it's mainly a problem with an ajax-call which isn't capable in getting the data as expected, because it gets a http302-status code, followed by a redirect to the SASLogon-page (which isn't visible for the user...)

I have 2 questions:

Is there any way in tracking down the reason for the termination of these stored process sessions? I already checked the stored process serverlogs, but I can't find anything.

Is it possible to check the status of a session before an ajax-call is made?

SAS-version we use is 9.2 (by the end of the year we upgrade to 9.4)

Thanks in advance!

[boemskats]

Hi Tom,

I know this is a really old post but this might be useful to you anyway. There could be a few reasons why your users sessions are terminating early, most it's most likely to do with the 'sticky sessions' setting on the load balancer that sits in front of your JVMs. The load balancer is redirecting the same clients to different JVMs, and you're having to log on again (with a new JSESSIONID) whenever the JVM changes from the previous call.

We recently opensourced a library we've been working on for a long time, that ultimately manages your app's AJAX calls back to SAS. One of the relevant things it does is detect the 302 redirects on timeout back to the SASLogon app and lets your app (page) prompt your user without redirecting the whole page to SASLogon/do. It might be of interest to you if you're already working with AJAX-based applications, as it simplifies everything quite dramatically. 

Hope that helps

Nik

[JuanS_OCS]

Hi, what @boemskats says it is interesting. 

Even though, not usre if you felt that your got the answer you need.

As some background:

In a stored process you will finf different level of sessions: the session of the SAS process (stored process), the web sever session, and the SASLogon session.

For the last one: http://support.sas.com/documentation/cdl/en/bimtag/68217/HTML/default/viewer.htm#p12gmxy6s5hazln1kog...

Now, answering to your question:

The session of the StoredProcess you can find it on the Object Spawner logs.

The sessions of the SAS web server, you can find in on the logs of the SAS Web Server.

And the sessions of the SASLogon, you can find them on the SASLogon app logs.

With this it should be enough for you. Some additional information you can find in the Cache Locator logs (gemfire), but I don;t think they would be interesting to you.

[TomDR]

Thanks for trying to answer my question, this certainly clarifies my understanding of the whole sessions-story.

But it wasn't relevant anymore as we upgraded quite recently to SAS 9.4, with our new servers we can't reproduce the erroneous behaviour anymore.