SessionStatusListener.py, ResponseListener.py and TableManagerListener.py all have a hard-coded wait(30) in them. Under various circumstances, that wait can be exceeded. In such a case, the system can segfault and core-dump.
There are a number of issues here:
The end user is not given the option to set their own timeout for this value. This should be a parameter exposed in the constructor or other area that allows the user to set the value.
The segfault is not handled by the code in question.
Ideally, the error would be captured and sent back to the end user as an actionable message.
What should happen is:
Timeout -> 'Tablemanager timeout awaiting [possibly 5he callstack]. Waited ** seconds without response'
Now the client should be able to take that information and, increase the allowed timeout via the configurable value, re-evaluate the code their using to see if there is an issue, or reach out to FXCM to investigate issues with slow processing (in the case of things like orders).
SessionStatusListener.py, ResponseListener.py and TableManagerListener.py all have a hard-coded wait(30) in them. Under various circumstances, that wait can be exceeded. In such a case, the system can segfault and core-dump.
There are a number of issues here:
What should happen is: Timeout -> 'Tablemanager timeout awaiting [possibly 5he callstack]. Waited ** seconds without response' Now the client should be able to take that information and, increase the allowed timeout via the configurable value, re-evaluate the code their using to see if there is an issue, or reach out to FXCM to investigate issues with slow processing (in the case of things like orders).