02-04-2016 10:17 AM - edited 02-04-2016 10:22 AM
Hi, I'm using SAS 9.4 M2 and I have the following problem. I'm running the below code and I cannot get the stpsrv_session -function to return (set) the variable values for _THISSESSION and _SESSIONID.
file _webout;* html output;
if libref('SAVE') ne 0 then rc = stpsrv_session('create');
%put THISSESSION = &_THISSESSION;
%put SESSIONID = &_SESSIONID;
--> The variable values are not set and I get:
WARNING: Apparent symbolic reference _SESSIONID not resolved. _SESSIONID = "&_SESSIONID."
WARNING: Apparent symbolic reference _THISSESSION not resolved. _THISSESSION = "&_THISSESSION."
I'm running the above code as a stored process with the code below. And I am not getting any error messages (except for the mentioned warnings).
proc stp program='/example_directory/stpsrv_session';
outputfile _webout = '/example_directory/webout.html';
02-04-2016 11:06 AM
02-05-2016 05:20 PM
My first thought is try moving your %PUT statements after the RUN; statement that ends your DATA step. As written, the %PUT statement is executed before the data step code to create the session is executed.
You can also create a session with just the macro language, e.g.:
%let rc=%sysfunc(stpsrv_session(create)); %put &_ThisSession;
Yes, looks like stored process sessions are only available on the stored process server, not the workspace server. See e.g. : http://support.sas.com/documentation/cdl/en/stpug/68399/HTML/default/viewer.htm#p1lxbssuprk9vln17qbw...
06-06-2017 04:02 AM
I have the same problem. How can i know if STP running in stored process server, not the workspace server?
I start my stp whith IHM(URL).
07-07-2017 08:48 AM
Quentin is correct about the placement of the %PUT statements:
data _null_; if (libref('SAVE') ne 0) then rc = stpsrv_session('create'); run; %put &=_THISSESSION; %put &=_SESSIONID;
His code should work, too.
He's also correct about sessions not being supported by the SAS Workspace Server. These messages are written to the SAS log when you run the test code on a workspace server:
ERROR: STP No session scope available.
NOTE: STP sessions cannot be used with Workspace servers.
Check the value of the SYSPROCESSMODE macro variable to determine the type of server. The variable has a value of either Stored Process Server or SAS Workspace Server.
07-16-2017 06:24 PM
Sorry to hijack this thread but I think this question is relevant enough for the OP. It's also one I've been arguing about with a colleague for a couple of weeks now, but haven't got round to testing yet. The documentation on this subject states the following:
A session exists in the server process where it was created. All stored processes that access that session must execute in the same server process. Load balancing and other execution dispatching features are typically ignored when using sessions that might have an impact on application performance and scalability.
Does this mean that when a session is created when a particular client executes a session-using STP, the normal load balancing for subsequent requests is ignored and some kind of session affinity for that multibridge process takes precedence over the LB for connections from that client? Or does the client continue to get redirected to available multibridge processes by the spawner as usual depending on the configured load balancing algorithm, and the session will only be reused if the request lands on the same multibridge process where the session was initially saved?
Hope that makes sense. Maybe it's just me but the way that paragraph is worded could suggest either of those...
07-17-2017 08:36 AM
Your first interpretation is correct. Because requests must return to the same server to read the stored session data, the request is sent to that server, even if it's busy, and other servers are available.