-
Bug
-
Resolution: Done
-
Medium
-
El Alto Release
Although there is a provision for timeout (180 sec by default) in applyNB in AbstractComponentFunction, in practice, it didn't work.
We have identified the following sequence of events.
- Client was running a python script inside command executor that was doing HTTP connect using 'requests' library. By default, the connect method has timeout of NONE. The client script didn't specify a timeout. Hence the connect method was hanging.
- command executor (and I think py-executor may suffer from the same issue, I'll check later) doesn't check for timeout, hence the python script will keep running
- Blueprintsprocessor has the provision for 180 second timeout by default, but it's not wrapped in proper execution hence that timeout is not respected.. We have tested that it will keep running..
When this happens, we end up with starvation of BP processor threads.