qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean K <sk92...@gmail.com>
Subject Re: C++ clients unable to communicate with Java broker
Date Wed, 31 Oct 2012 17:18:39 GMT
Here is the debug trace from the helloworld.

I put in a few extra std::cout statements before and after each line
in the hello_world.cpp main.   This is the helloworld attempting to
createSession from the connection.createSession() statement.   It
fails at that point.  the Java broker (0.18) is running.    (the
hello_world works with the 0.18 cpp broker)



[sean@fedora16 messaging]$ ./hello_world
opening connection to localhost:5672
2012-10-31 10:14:32 [Client] debug Created connection localhost:5672 with {}
2012-10-31 10:14:32 [Client] debug Starting connection, urls=[localhost:5672]
2012-10-31 10:14:32 [Client] info Trying to connect to localhost:5672...
2012-10-31 10:14:32 [Client] debug Created IO thread: 0
2012-10-31 10:14:32 [Network] debug TCPConnector created for 0-10
2012-10-31 10:14:32 [System] info Connecting: 127.0.0.1:5672
2012-10-31 10:14:32 [Network] debug RECV
[[127.0.0.1:47701-localhost:5672]]: INIT(0-10)
2012-10-31 10:14:32 [Network] trace RECV
[[127.0.0.1:47701-localhost:5672]]: Frame[BEbe; channel=0;
{ConnectionStartBody:
server-properties={qpid.features:[{V2:17:str16(qpid.jms-selector)}]list([{V2:17:str16(qpid.jms-selector)}]),qpid.federation_tag:V2:36:str16(f0e33709-93f0-4147-a818-af0d46a524bb)};
mechanisms=str16{V2:8:str16(AMQPLAIN), V2:5:str16(PLAIN),
V2:8:str16(CRAM-MD5)}; locales=str16{V2:5:str16(en_US)}; }]
2012-10-31 10:14:32 [Network] trace SENT
[[127.0.0.1:47701-localhost:5672]]: Frame[BEbe; channel=0;
{ConnectionStartOkBody:
client-properties={qpid.client_pid:F4:int32(18032),qpid.client_ppid:F4:int32(13132),qpid.client_process:V2:14:str16(lt-hello_world),qpid.session_flow:F4:int32(1)};
mechanism=; response=xxxxxx; locale=en_US; }]
2012-10-31 10:14:32 [Network] trace RECV
[[127.0.0.1:47701-localhost:5672]]: Frame[BEbe; channel=0;
{ConnectionTuneBody: channel-max=256; max-frame-size=65535;
heartbeat-min=0; heartbeat-max=0; }]
2012-10-31 10:14:32 [Network] trace SENT
[[127.0.0.1:47701-localhost:5672]]: Frame[BEbe; channel=0;
{ConnectionTuneOkBody: channel-max=256; max-frame-size=65535;
heartbeat=0; }]
2012-10-31 10:14:32 [Network] trace SENT
[[127.0.0.1:47701-localhost:5672]]: Frame[BEbe; channel=0;
{ConnectionOpenBody: virtual-host=; capabilities=void{}; insist=1; }]
2012-10-31 10:14:32 [Network] trace RECV
[[127.0.0.1:47701-localhost:5672]]: Frame[BEbe; channel=0;
{ConnectionOpenOkBody: known-hosts=void{}; }]
2012-10-31 10:14:32 [Client] info Connection
[127.0.0.1:47701-localhost:5672] connected to tcp:localhost:5672
2012-10-31 10:14:32 [Client] debug Connection
[127.0.0.1:47701-localhost:5672] no security layer in place
2012-10-31 10:14:32 [Client] info Connected to localhost:5672
2012-10-31 10:14:32 [Client] debug Added known-hosts,
reconnect-urls=[localhost:5672]
2012-10-31 10:14:32 [Client] debug Connection successful, urls=[localhost:5672]
opened connection
2012-10-31 10:14:32 [Broker] debug SessionState::SessionState .: 0x114e0d0
2012-10-31 10:14:32 [Client] debug Known-brokers for connection:
2012-10-31 10:14:32 [Network] trace SENT
[[127.0.0.1:47701-localhost:5672]]: Frame[BEbe; channel=1;
{SessionAttachBody: name=7b3d9881-c7a6-43a6-abb1-396cb0917bcc; }]
2012-10-31 10:14:32 [Client] warning Connection
[127.0.0.1:47701-localhost:5672] closed
2012-10-31 10:14:32 [System] debug Exception constructed: Connection
[127.0.0.1:47701-localhost:5672] closed
Failed to connect (reconnect disabled)
2012-10-31 10:14:32 [System] debug Exception constructed: Connection
[127.0.0.1:47701-localhost:5672] closed
[sean@fedora16 messaging]$


On Wed, Oct 31, 2012 at 1:38 AM, Gordon Sim <gordon.r.sim@gmail.com> wrote:
> On 10/31/2012 08:20 AM, Rob Godfrey wrote:
>>
>> So, if cyrus is integrated then drain and spout worked for me simply
>> by adding the username/password on the command line (e.g. with the
>> original command line that Jeremy provided), without the need to
>> specify the connection properties... is it not possible for the
>> non-cyrus implementation to work the same way (since with the extra
>> hint in the connection properties it is obviously *capable* of PLAIN
>> authentication).  The difference in behaviour seems odd.
>
>
> Yes it is odd and I would go as far as to say the default implementation is
> broken (there is a helpful 'TODO' comment in the code suggesting that the
> mechanisms actually offered be checked!).
>
> Let's raise a JIRA and if there are no other takers, I'm happy to have it
> added to my list.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message