Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
proton-c-0.35.0
-
None
-
None
Description
My python-qpid-proton 0.35.0 client hangs for about four seconds on every new connection operation to my broker. The problem is that the client tries to look up its own hostname's A and AAAA DNS records before completing the SASL exchange (and my DNS server takes a while for missing records.)
Steps to reproduce:
- Set up a CentOS 8 or 9 host.
- Install cyrus-sasl-devel
- Install python-qpid-proton. Ensure it's dynamically linked to cyrus-sasl (/lib64/libsasl2.so.3).
- Ensure the unqualified (short) hostname from the "hostname" command is not present in /etc/hosts.
- Connect to a broker with ANONYMOUS SASL and no SSL.
Actual results:
Immediately after Proton receives the sasl.mechanisms message, but before Proton sends the sasl.init / sasl.outcome AMQP messages, it makes two DNS queries (A and AAAA) for my host's unqualified hostname.
The AAAA request takes a while to answer (3.5 seconds). This makes makes the pn_transport_push() call hang here:
-> exec(cmd, globals, locals) <string>(1)<module>() /home/vagrant/dns.py(51)<module>() -> Container(HelloWorld()).run() /usr/lib64/python3.6/site-packages/proton/_reactor.py(180)run() -> while self.process(): /usr/lib64/python3.6/site-packages/proton/_reactor.py(245)process() -> event.dispatch(self._global_handler) /usr/lib64/python3.6/site-packages/proton/_events.py(162)dispatch() -> _dispatch(handler, type.method, self) /usr/lib64/python3.6/site-packages/proton/_events.py(125)_dispatch() -> handler.on_unhandled(method, *args) /usr/lib64/python3.6/site-packages/proton/_reactor.py(876)on_unhandled() -> event.dispatch(self.base) /usr/lib64/python3.6/site-packages/proton/_events.py(162)dispatch() -> _dispatch(handler, type.method, self) /usr/lib64/python3.6/site-packages/proton/_events.py(123)_dispatch() -> m(*args) /usr/lib64/python3.6/site-packages/proton/_handlers.py(1241)on_selectable_readable() -> n = t.push(b) /usr/lib64/python3.6/site-packages/proton/_transport.py(304)push() -> n = self._check(pn_transport_push(self._impl, binary))
Expected Results:
proton with cyrus-sasl should behave the same way it does without cyrus-sasl: it should authenticate quickly, without looking up the IP address of its own short hostname.
Extra information:
This only happens when I build against cyrus-sasl-devel. When I do not have cyrus-sasl-devel available, then the package from PyPI does not link against cyrus-sasl, and there is no DNS request. (The qpid-proton package in EPEL is built against cyrus-sasl, and that is where I discovered this bug.)
If the client can resolve its unqualified (short) hostname to an IP, then there is no delay. For example, if my Proton client's hostname is myclient.example.com, I can fix the delay by adding the following entry to /etc/hosts:
127.0.0.1 myclient localhost
or by ensuring my DNS server will immediately return A or AAAA records for the unqualified "myclient" name.