Re: QPID: Connection failed when connecting to remote QPIDD
Hi, There is a PPA that includes more recent versions of Qpid stuff: sudo apt-add-repository ppa:qpid/released See https://launchpad.net/~qpid for all the gory details. The intent is to provide the latest release of the upstream Qpid releases. There's been efforts to get newer packages into the official repos, but that's going slowly. On Wed, Jul 12, 2017 at 3:18 PM, msingman <matt.sing...@indepth.com> wrote: > It was related to the qpidc.conf file in /etc/qpid. I must have uncommented > that for some reason and not noticed that it broke what I was trying to do. > > Just for reference, the uncommented line was > "protocol-defaults=amqp1.0,amqp0-10", so I also don't know why it didn't try > 0-10 after failing with 1.0 > > To prevent other people from having problems of this kind, are there any > plans to update the version of QPID on Ubuntu's repository? It's pretty > heavily out of date from what I can see. > > Thanks again for the help... > > From: Gordon Sim [via Qpid] [mailto:ml+s2158936n7664743...@n2.nabble.com] > Sent: Wednesday, July 12, 2017 15:05 > To: Matt Singman <matt.sing...@indepth.com> > Subject: Re: QPID: Connection failed when connecting to remote QPIDD > > On 12/07/17 18:44, msingman wrote: > >> Does the "INIT(0-0)" indicate that the message sender wants to use AMQP 1.0? >> Assuming that is the case, how can I get the C++ code I have to use 0-10 >> (for what it's worth, qpid::messaging is being used)? >> >> On the documentation for QPID 1.36.0 (which is the version that is used on >> the host machine, not the container; >> http://qpid.apache.org/releases/qpid-cpp-1.36.0/messaging-api/book/connections.html#connection-options >> ), it states in Table 1.4 that 0-10 is the default version that is used. >> Further, when I attempt to manually set the protocol >> ("connection.setOption("protocol", "amqp0-10");"), the code compiles but I >> get the following runtime error: >> >> terminate called after throwing an instance of >> 'qpid::messaging::MessagingException' >>what(): Invalid option: protocol not recognised >> (/builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/messaging/ConnectionOptions.cpp:140) >> >> Am I misreading the documentation in some way? > > No, but it appears that the protocol option can only be set when > creating the connection, e.g. Connection("myhost", > "{protocol:amqp0-10}"). (qpid-send and qpid-receive take a > connection-options argument e.g. qpid-send --connection-options > '{protocol:amqp0-10}' --address foo etc). > > The order the protocols are tried in can be controlled in the qpidc.conf > file or via QPID_PROTOCOLS env var. The default is actually to try 0-10 > first, then 1.0, so I suspect in your environment the conf file entry to > reverse that is uncommented. > > The 0.16 broker doesn't have 1.0 support. I can't quite understand why > the client is not retrying with 0-10 though. > > - > To unsubscribe, e-mail: [hidden > email] > For additional commands, e-mail: [hidden > email] > > > > If you reply to this email, your message will be added to the discussion > below: > http://qpid.2158936.n2.nabble.com/QPID-Connection-failed-when-connecting-to-remote-QPIDD-tp7664740p7664743.html > To unsubscribe from QPID: Connection failed when connecting to remote QPIDD, > click > here<http://qpid.2158936.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=7664740=bWF0dC5zaW5nbWFuQGluZGVwdGguY29tfDc2NjQ3NDB8NTQ0MjMwNzQ2>. > NAML<http://qpid.2158936.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > > > > > -- > View this message in context: > http://qpid.2158936.n2.nabble.com/QPID-Connection-failed-when-connecting-to-remote-QPIDD-tp7664740p7664744.html > Sent from the Apache Qpid users mailing list archive at Nabble.com. -- -K - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: QPID: Connection failed when connecting to remote QPIDD
It was related to the qpidc.conf file in /etc/qpid. I must have uncommented that for some reason and not noticed that it broke what I was trying to do. Just for reference, the uncommented line was "protocol-defaults=amqp1.0,amqp0-10", so I also don't know why it didn't try 0-10 after failing with 1.0 To prevent other people from having problems of this kind, are there any plans to update the version of QPID on Ubuntu's repository? It's pretty heavily out of date from what I can see. Thanks again for the help... From: Gordon Sim [via Qpid] [mailto:ml+s2158936n7664743...@n2.nabble.com] Sent: Wednesday, July 12, 2017 15:05 To: Matt Singman <matt.sing...@indepth.com> Subject: Re: QPID: Connection failed when connecting to remote QPIDD On 12/07/17 18:44, msingman wrote: > Does the "INIT(0-0)" indicate that the message sender wants to use AMQP 1.0? > Assuming that is the case, how can I get the C++ code I have to use 0-10 > (for what it's worth, qpid::messaging is being used)? > > On the documentation for QPID 1.36.0 (which is the version that is used on > the host machine, not the container; > http://qpid.apache.org/releases/qpid-cpp-1.36.0/messaging-api/book/connections.html#connection-options > ), it states in Table 1.4 that 0-10 is the default version that is used. > Further, when I attempt to manually set the protocol > ("connection.setOption("protocol", "amqp0-10");"), the code compiles but I > get the following runtime error: > > terminate called after throwing an instance of > 'qpid::messaging::MessagingException' >what(): Invalid option: protocol not recognised > (/builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/messaging/ConnectionOptions.cpp:140) > > Am I misreading the documentation in some way? No, but it appears that the protocol option can only be set when creating the connection, e.g. Connection("myhost", "{protocol:amqp0-10}"). (qpid-send and qpid-receive take a connection-options argument e.g. qpid-send --connection-options '{protocol:amqp0-10}' --address foo etc). The order the protocols are tried in can be controlled in the qpidc.conf file or via QPID_PROTOCOLS env var. The default is actually to try 0-10 first, then 1.0, so I suspect in your environment the conf file entry to reverse that is uncommented. The 0.16 broker doesn't have 1.0 support. I can't quite understand why the client is not retrying with 0-10 though. - To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] If you reply to this email, your message will be added to the discussion below: http://qpid.2158936.n2.nabble.com/QPID-Connection-failed-when-connecting-to-remote-QPIDD-tp7664740p7664743.html To unsubscribe from QPID: Connection failed when connecting to remote QPIDD, click here<http://qpid.2158936.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=7664740=bWF0dC5zaW5nbWFuQGluZGVwdGguY29tfDc2NjQ3NDB8NTQ0MjMwNzQ2>. NAML<http://qpid.2158936.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> -- View this message in context: http://qpid.2158936.n2.nabble.com/QPID-Connection-failed-when-connecting-to-remote-QPIDD-tp7664740p7664744.html Sent from the Apache Qpid users mailing list archive at Nabble.com.
Re: QPID: Connection failed when connecting to remote QPIDD
On 12/07/17 18:44, msingman wrote: Does the "INIT(0-0)" indicate that the message sender wants to use AMQP 1.0? Assuming that is the case, how can I get the C++ code I have to use 0-10 (for what it's worth, qpid::messaging is being used)? On the documentation for QPID 1.36.0 (which is the version that is used on the host machine, not the container; http://qpid.apache.org/releases/qpid-cpp-1.36.0/messaging-api/book/connections.html#connection-options ), it states in Table 1.4 that 0-10 is the default version that is used. Further, when I attempt to manually set the protocol ("connection.setOption("protocol", "amqp0-10");"), the code compiles but I get the following runtime error: terminate called after throwing an instance of 'qpid::messaging::MessagingException' what(): Invalid option: protocol not recognised (/builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/messaging/ConnectionOptions.cpp:140) Am I misreading the documentation in some way? No, but it appears that the protocol option can only be set when creating the connection, e.g. Connection("myhost", "{protocol:amqp0-10}"). (qpid-send and qpid-receive take a connection-options argument e.g. qpid-send --connection-options '{protocol:amqp0-10}' --address foo etc). The order the protocols are tried in can be controlled in the qpidc.conf file or via QPID_PROTOCOLS env var. The default is actually to try 0-10 first, then 1.0, so I suspect in your environment the conf file entry to reverse that is uncommented. The 0.16 broker doesn't have 1.0 support. I can't quite understand why the client is not retrying with 0-10 though. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: QPID: Connection failed when connecting to remote QPIDD
Does the "INIT(0-0)" indicate that the message sender wants to use AMQP 1.0? Assuming that is the case, how can I get the C++ code I have to use 0-10 (for what it's worth, qpid::messaging is being used)? On the documentation for QPID 1.36.0 (which is the version that is used on the host machine, not the container; http://qpid.apache.org/releases/qpid-cpp-1.36.0/messaging-api/book/connections.html#connection-options ), it states in Table 1.4 that 0-10 is the default version that is used. Further, when I attempt to manually set the protocol ("connection.setOption("protocol", "amqp0-10");"), the code compiles but I get the following runtime error: terminate called after throwing an instance of 'qpid::messaging::MessagingException' what(): Invalid option: protocol not recognised (/builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/messaging/ConnectionOptions.cpp:140) Am I misreading the documentation in some way? -- View this message in context: http://qpid.2158936.n2.nabble.com/QPID-Connection-failed-when-connecting-to-remote-QPIDD-tp7664740p7664742.html Sent from the Apache Qpid users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: QPID: Connection failed when connecting to remote QPIDD
Everything is the same… except for the version of qpid ;-) It may be that the Ubuntu version doesn’t support AMQP 1.0 and that’s what ActiveMQ is asking for. Qpid is responding with 0-10. -Steve > On Jul 12, 2017, at 12:55 PM, Matt Singmanwrote: > > I have a QPID daemon running inside of a Docker container. I have C++ code > that should connect to this daemon, and in the past, it was able to, but it > suddenly stopped being able to connect when the C++ code was run on the host > machine. > > Trying to connect to the daemon on the container from the host throws a > qpid::messaging::TransportFailure expection. When I launch qpidd with -t for > trace level logging, I see the following each time a connection is attempted: > > 2017-07-12 15:59:33 debug RECV [172.17.0.2:5672-172.17.0.1:37696]: INIT(0-0) > 2017-07-12 15:59:33 debug SENT [172.17.0.2:5672-172.17.0.1:37696]: INIT(0-10) > > I would guess that this has something to do with the ActiveMQ protocol, but I > am not sure. > > I don't think the fault lies with the code, because the exact same code > running on the same container as the broker is able to connect to the QPID > broker. I know that the daemon is visible from the host machine because curl > finds the daemon > > Why can I not connect to the daemon from the host, even though I can from the > container that the daemon is running in? > > It may be worth noting that the versions of QPID on the host are different > than the container. The host has the latest version on CentOS 7 (1.36.0) > while the container has the latest version on Ubuntu 16.04 (0.16). > > Thanks > > Matt