Good day everyone. I am just trying different crazy things with the examples/simple code. So I am wondering what is the intended behavior of txpublisher.py and txconsumer.py when you instruct them to connect to the wrong port?
In the case, where the port is not listened, everything goes clean, since twisted code still protects us from doing crazy things like talking to unconnected sockets. We simply get an exception: <class 'twisted.internet.error.ConnectionRefusedError'>: Connection was refused by other side: 111: Connection refused. Exception? Ok. Fine! But then, I try to connect to some wrong, but now open port, say to SSH Server, or HTTP Server, or HTTP Proxy. $ python txpublisher.py localhost 22 / guest guest ../../specs/standard/amqp0-8.xml hello 1 Connected to broker. and nothing happens then for a long period of time. Very long, I have waited for at least 20 minutes. The server usually closes the connection after some timeout, but the example code continue to wait for something else to happen. So I have to interrupt the txpublisher.py manually. The txconsumer.py is no different in that aspect: $ python txconsumer.py localhost 22 / guest guest ../../specs/standard/amqp0-8.xml Connected to broker. and no more. So what is the intended behavior of the library in such situations? How does it react? How do I detect that? AFAIK, the AMQP client waits for the correct server response, but does it last indefinitely? Does some code in txAMQP detect when the TCP connection closes during the initiation? The question is, should such cases be detected and handled by the txAMQP library internally (like twisted does on it's own layer) or should I implement my own timeout handling to interrupt the connection initiation process if it does not produce any positive result after some reasonable amount of time, nor does bail out with error? If the second is the option, how should I cleanup the resources used by the library, such as file descriptors and memory, when my program decide to stop connecting and, say, retry the process? In other words, how to eliminate the memory and system resources leakage in a long-running process caused by the indefinitely long hanging connections started by the txAMQP, when I try to emulate the proper error handling? (Consider a daemon, that continuosly receives a list of AMQP servers and tries to connect to them one after another. The list may contain errors and may partially consist of parts of SSH-servers list. :) ) If the first is the case, what is the current state of error-detection things in txAMQP? What is done, what is to be done? Is there anything missing in the code, but planned? Where is the plan? What is the conception, the main idea behind the error detection in txAMQP? I would like to produce some "improved" examples to demonstrate all possible error detection methods that are possible when interacting with txAMQP, and the correct mechanism of error handling, that eliminates the risk of resource leak. But for doing that I have too much questions... Is anybody interested in clarifying the error detection theme for the public? -- Alexey _______________________________________________ Mailing list: https://launchpad.net/~txamqp-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~txamqp-dev More help : https://help.launchpad.net/ListHelp
