I have been seeing a lot of these shutdown messages in the C2 signal response. The systemid doesn’t appear to be one of the ones I subscribe to so I’m wondering why its there?
06:15:59:871: TabCollective2.reqSignals(): <shutdownall>0</shutdownall>
06:15:59:871: TabCollective2.reqSignals(): <shutdownsystems>
06:15:59:874: TabCollective2.reqSignals(): <systemid>78062017</systemid>
06:15:59:874: TabCollective2.reqSignals(): </shutdownsystems>
Could it have anything to do with why I am also getting a lot of connection refused errors?
Hi, Greg:
When you upgraded your protocol to 10.0, you suddenly began to see some new XML nodes that were not present in the older protocol. Cleverly, to keep developers on their toes, I completely neglected to explain these nodes in the documentation you had access to.
The shutdownsystems node simply reports to you the fact that the customer (you) stopped autotrading a system. This can be useful information in some cases, for it can allow you to do special things with positions left open, etc.
To make these shutdown reports go away, you need to acknowledge seeing them, as follows:
?cmd=ackshutdown&systemid=[allnnnn]
where nnnn is the specific system id, or you can just use ‘all’ to globally acknowledge all nodes.
Once you do this, shutdown information will be removed from the user roster.
This has nothing to do with the connection-refused instances you experienced.
Now, regarding these connection timeouts/refusals, I don’t have a definite answer. It is possible – possible – they were caused by the new functionality in the new protocol you are using. I have added better logging and error trapping to see if this is the case (and also hopefully to prevent it from recurring). So my suggestion is to continue to use the new protocol as we discussed in email, and to report to me any subsequent new timeouts that are more than transient.
MK
MK,
Thanks for the explanation.
Here is some more info on the connection refusal problem. It just happened again this morning just as an option trade came in from the Spiderman system. Since I know my software has correctly responded to that system’s signals in the past using protocol 8.2, it appears that the problem is indeed related to new code in protocol 10.
I will send you a separate email with the log info as the problem occurred since your forum software will hose up the syntax.
Greg
