Replies: 2 comments 2 replies
-
|
Hey, my first thought was that ODA may have restrictions about how many concurrent connections you can have, and or how much processing you can do. It's free, limited system that isn't for production use. So, maybe you're hitting some kind of issue with that. But, I don't know, so I've established 6 connections and am submitting 1 submit per connection every once in a while. So far, all 6 connections are successful and I've had them up and running for a couple hours so far. Just running a submit in each every once in a while while I'm working on other things. I haven't seen any disconnects as of yet. Just had an hour 14 min between submissions and all was well: Do you have any diagnostic logging in your application to show that it's doing the things you believe it is; regarding keeping each session active? I did check on the Inactive client timeout value, and it's set to 180 min. So, even without doing anything, it shouldn't disconnect in less than 2 hours. Since the interface to SAS is asynchronous, if the server terminates or disconnects, saspy can't know that until in tries to interact with it the next time. So, that part is to be expected. And, yes, along with the error about having terminated unexpectedly, the saspid value will be set to None as an indicator, as the SASsession object still exists; it's just no longer connected to a SAS session. Not much use anymore, but you can still see attributes. So, I'm not sure why this would be happening; maybe network issues? I know that's a bit of a cop-out guess. But, without knowing your application, and with what I'm trying, which sounds logically like what you're describing, I'm not coming up with a reason for that. Or, again, back to if there's somethin limiting you artificially on the ODA side. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @tomweber-sas , thanks for the replay! I sometimes have a hard time to reproduce it locally but I've seen it happened at some point, maybe a bit more rarely. I do have some logs around the app and I don't see anything too suspicious that could be disconnection the session soo far. The most constant disconnects happened when I try to host the script in an Azure container app or an Azure web app. Do you think it might be hitting some request time out time, thought I would imagine request timeout is pretty high while it Is waiting for a response from the SAS server |
Beta Was this translation helpful? Give feedback.
-
|
Actually this is from a local ran I just tested This is the code I execute every 180sec to renew sessions activity: And I can see in the logs after this was run the session pid was None:
I would imagine the submit that was just ran shouldn't pass if the session was disconnected already ,and the previous log that is
still has a sas process pid that is not None, so the submit must have cause the disconnect for some reason or am I missing something? |
Beta Was this translation helpful? Give feedback.
-
|
Well, it certainly seems to be something with your environment. I had 6 sessions with well over an hour between interacting with any of them and there was no issue. Running in azure sure multiplies the possibilities of more things causing some issue from your application side. I sure don't have enough information to guess. Here's from running what I had, long after the 120minute timeout; just for fyi - it's as expected since it's after the 2 hour timeout: the previous was: then: |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
It seems like every time I try to create a bunch of sas session in different threads and start to execute code the sessions disconnect randomly and silently! For example I would do a .submit() call for the session and when I print the session after that I get:
2023-12-18 20:09:07 Sas session to renew is : Access Method = IOM
2023-12-18 20:09:07 SAS Config name = oda
2023-12-18 20:09:07 SAS Config file = /app/sascfg_personal.py
2023-12-18 20:09:07 WORK Path = /saswork/SAS_work40BA00005125_odaws01-usw2-2.oda.sas.com/SAS_workFAA400005125_odaws01-usw2-2.oda.sas.com/
2023-12-18 20:09:07 SAS Version = 9.04.01M7P08062020
2023-12-18 20:09:07 SASPy Version = 5.4.4
2023-12-18 20:09:07 Teach me SAS = False
2023-12-18 20:09:07 Batch = False
2023-12-18 20:09:07 Results = Pandas
2023-12-18 20:09:07 SAS Session Encoding = utf-8
2023-12-18 20:09:07 Python Encoding value = utf-8
2023-12-18 20:09:07 SAS process Pid value = None
ValueError: invalid literal for int() with base 10: 'We failed in getConnection'
If I replace the session with a new one after I check that pid is None at that moment I might get a different exception if the operation is different. every 3 minutes I submit a empty string "" call to the sessions in the pool of threads I have so they are kept active but this disconnect behaviour seems to happen almost at random and it does happen silently. Is there a way to avoid this apart from retiring the call which would take significant time since creating the sas session takes at least a couple of seconds?
It seems like I get this fails due to the session disconnecting pretty often, maybe once in a 10-15 calls sometimes more, sometimes less often.
What I want to have is a long running app that would have a couple of sas sessions open constantly and each X minutes the connection will get refreshed so they don't get auto closed on the SAS side. Any ideas how I can handle this issue?
Beta Was this translation helpful? Give feedback.
All reactions