← Back to team overview

txamqp-dev team mailing list archive

What is the intended behavior of the examples/simple code?

 

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