qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gordon Sim (Resolved) (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (QPID-3832) Qpid 0.14 broke transport connection setting
Date Thu, 01 Mar 2012 06:42:10 GMT

     [ https://issues.apache.org/jira/browse/QPID-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Gordon Sim resolved QPID-3832.

       Resolution: Fixed
    Fix Version/s: 0.15

Change made as suggested by Paul.
> Qpid 0.14 broke transport connection setting
> --------------------------------------------
>                 Key: QPID-3832
>                 URL: https://issues.apache.org/jira/browse/QPID-3832
>             Project: Qpid
>          Issue Type: Bug
>          Components: C++ Client
>    Affects Versions: 0.14
>            Reporter: Paul Colby
>            Assignee: Gordon Sim
>              Labels: SSL
>             Fix For: 0.15
> The transport connection setting was broken in r1156262.
> Consider the following test code:
> {code}
> #include <qpid/messaging/Connection.h>
> int main(int argc, char *argv[]) {
>     qpid::types::Variant::Map options;
>     options["transport" ] = "ssl";
>     qpid::messaging::Connection connection("localhost:5671", options);
>     connection.open();
>     return 0;
> }
> {code}
> Using Qpid 0.12 client libraries, the above code would use SSL.  But with Qpid 0.14,
the code will *not* use SSL.
> The change in behaviour is a result of code changes to the {{ConnectionImpl::tryConnect}}
function in {{cpp/src/qpid/client/amqp0_10/ConnectionImpl.cpp}} in r1156262
> Prior to that revision, the {{SimpleUrlParser}} was used, and {{settings}} passed to
a {{Connection::open}} overload directly.  This worked fine.
> Post that revision, the code looks like this:
> {code}
> Url url(*i);
> if (url.getUser().size()) settings.username = url.getUser();
> if (url.getPass().size()) settings.password = url.getPass();
> QPID_LOG(debug, *i << " " << settings.protocol);
> QPID_LOG(debug, url);
> connection.open(url, settings);
> {code}
> (I added the {{QPID_LOG}} calls).
> The {{QPID_LOG}} calls produce output like:
> {code}
> localhost:5671 ssl
> amqp:tcp:localhost:5671
> {code}
> The problem is that the {{Url}} constructor is defaulting the protocol to TCP (via {{UrlParser::protocolAddr}}).
 Then, when the {{Connection::open}} overload is called, the {{Url}} object's defaulted-but-now-explicit
{{protocol}} value (TCP) is used in preference to the {{settings.protocol}} value (SSL).
> I think the correct solution here, thought it would be non-trivial, would be to pass
{{settings}} (or at least {{settings.protocol}}) to the {{Url}} constructor as an optional
default protocol.  Then the {{Url}} class should use that default protocol instead of TCP
when the address string does not include an explicit protocol.
> Another option would be to provide some sort of {{Url::protocolWasDefaulted}} flag so
that the {{ConnectionImpl::tryConnect}} function could override from {{settings}} when appropriate
- this would be less code change, but the above solution would be more elegant IMO.
> Note, the obvious workaround is to always use explicit protocols in URLs.  That is, always
use "ssl:hostname" instead of "hostname".

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message