**Exception: ('Connection aborted.', ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None))** happens 2 out of 5 times

[rdkworld]

I run a script daily and Rally connection (this statement) fails 2 out of 5 times weekly with below error

Statement - rally = Rally(server, apikey=apikey, workspace=workspace, project=project)

Traceback (most recent call last):
File "C:\python\lib\site-packages\pyral\restapi.py", line 249, in init
self.contextHelper.check(self.server, wksp, proj, self.isolated_workspace)
File "C:\python\lib\site-packages\pyral\context.py", line 162, in check
subscription = self._loadSubscription()
File "C:\python\lib\site-packages\pyral\context.py", line 287, in _loadSubscription
raise Exception(sub.errors[0])
Exception: ('Connection aborted.', ConnectionResetError(10054, 'An existing connection was forcibly closed by the remote host', None, 10054, None))

I have not figured a permanent solution. The workaround is I just try again after sometime and it works. Looking for some guidance. Anything would be appreciated @klehman-rally Thanks!

1. Can it be permanently resolved?
2. Do I need to close the Rally connection? If so, could you let me know how?

[klehman-rally]

There is no known current issue with generalized dropping connections from Rally WSAPI requests.

Are you using an HTTP/HTTPS proxy server? Many times when there is an inability to connect, or experiencing dropped connections there is a network proxy in the mix. When did this behavior start? Does it only occur in specific time periods? What is the frequency of the operation? (Is your script run every day, or hour or minute?). Did the host that you normally run the script on get updated with any OS elements or Python packages? Are you able to run the script using a different set of credentials or targeting alternate workspace/project?

[rdkworld]

Hi Kip,
Thank you for so much for taking your time to review issue I reported and sharing your thoughts. Yes, there is an HTTP/HTTPS proxy server and I am suspecting that as well. When I run the same from my machine (behind firewall, VPN connected), it works 100% of the time because outgoing connections are allowed. When I run the same from host - a windows server on network (also behind firewall & uses proxy), it works sometimes and sometimes it does not (If it didn't work 100% of time from host, then for sure there is some host/network issue).
With respect to other things,

• Script runs once a day on weekdays, if it is fails, I manually run until it is successful.
• I don't think OS got updated (or I may be unaware) because it was not working, I updated pyral to latest version (but again same result before and after update).
• I can try running with diff set of credentials/workspace and see but not sure if that would be issue since I would expect a different kind of error related to credentials or workspace if that is the issue unless the generic connection error is always through.
• I believe this intermittent issue has always been there. I used to just retry after 2-3 min and it used to work. Of late, it didn't work even after trying 5 times, I wait for few hours and try, again it is not consistent.

Thanks,
Raghu

[klehman-rally]

It sounds like proxy issues are the culprit rather that time-of-day, frequency, etc.
What HTTP/HTTPS proxy software/package is being used (and on what kind of platform)?
The testing I've done for releases since 2018 was limited to Squid proxy on Mac OSX and a Python hybrid on Linux (Ubuntu 18). Prior releases were run against a proxy on a Linux server (don't remember the distro/version and also don't know what proxy sw or version) and at times that used to have some failures when the proxy got into a bad state. The issue might be addressed by putting logic in pyral to retry some number of times when use of a proxy is detected, but I don't foresee doing that any time soon. Chasing down the proxy issues might be your better option.

[abuzafarhaqq]

From Stackoverflow, check out the solution, and please, take some medicine before checking the solution. The problem occurs with the proxy and it's the problem of the urllib3 connectionpool.