You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2012/11/01 00:09:56 UTC
Re: C++ clients unable to communicate with Java broker
The log line below seems to suggest it is the same issue Jeremy was seeing,
that the client is not selecting a SASL mechanism during connection and the
broker is ultimately killing it as a result. Alex mentioned in a discussion
about this that its actually NPEing on the broker side in this situation,
so we can/should make the broker handle that with a little more grace to
make the problem more, although it is really the client at fault. It isnt
entirely clear to me from your replies whether you tried the two
solution/workarounds mentioned already in the mail thread, can you clarify?
[[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; }]
Robbie
On 31 October 2012 17:18, Sean K <sk...@gmail.com> wrote:
> 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 <go...@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
>
>
Re: C++ clients unable to communicate with Java broker
Posted by Robbie Gemmell <ro...@gmail.com>.
On 1 November 2012 08:20, Gordon Sim <go...@gmail.com> wrote:
> On 10/31/2012 11:09 PM, Robbie Gemmell wrote:
>
>> The log line below seems to suggest it is the same issue Jeremy was
>> seeing,
>> that the client is not selecting a SASL mechanism during connection and
>> the
>> broker is ultimately killing it as a result.
>>
>
> Agreed. It seems a little odd that the conversation gets as far as it does
> though. The mechanism is left unspecified on the connection-start-ok, the
> broker responds with connection-tune and the handshake gets as far as the
> broker sending a connection-open-ok... does the java broker only do
> authentication after it has sent the connection-open-ok?
>
>
You are right, it shouldnt have got that far, good catch. (Yes, I stopped
reading the log once I saw the missing mechanisms).
Authentication is performed at connection-start-ok, but looking into the
process there is a bit of crufty old code that long predating the brokers
use of it for 0-10 support that is causing it to respond incorrectly in
this situation, sending a connection-tune it shouldnt have and ultimately
allowing it to get as far as then causing the NPE because the mechanism
wasnt set. Instead it should be responding by immediately killing the
connection deliberately rather than just as a side effect.So thats
definitely a bit of broker side fixup required too it seems.
>
> Alex mentioned in a discussion
>> about this that its actually NPEing on the broker side in this situation,
>> so we can/should make the broker handle that with a little more grace to
>> make the problem more, although it is really the client at fault.
>>
>
> Agreed. The client should pick one of the offered mechanisms or fail with
> a message if it doesn't support any of them. I've created a JIRA:
> https://issues.apache.org/**jira/browse/QPID-4407<https://issues.apache.org/jira/browse/QPID-4407>
> .
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<us...@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: C++ clients unable to communicate with Java broker
Posted by Gordon Sim <go...@gmail.com>.
On 10/31/2012 11:09 PM, Robbie Gemmell wrote:
> The log line below seems to suggest it is the same issue Jeremy was seeing,
> that the client is not selecting a SASL mechanism during connection and the
> broker is ultimately killing it as a result.
Agreed. It seems a little odd that the conversation gets as far as it
does though. The mechanism is left unspecified on the
connection-start-ok, the broker responds with connection-tune and the
handshake gets as far as the broker sending a connection-open-ok... does
the java broker only do authentication after it has sent the
connection-open-ok?
> Alex mentioned in a discussion
> about this that its actually NPEing on the broker side in this situation,
> so we can/should make the broker handle that with a little more grace to
> make the problem more, although it is really the client at fault.
Agreed. The client should pick one of the offered mechanisms or fail
with a message if it doesn't support any of them. I've created a JIRA:
https://issues.apache.org/jira/browse/QPID-4407.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ clients unable to communicate with Java broker
Posted by Robbie Gemmell <ro...@gmail.com>.
Hi Jeremy,
I raised https://issues.apache.org/jira/browse/QPID-4419 and committed a
change on trunk to improve how the Java broker handles the original
situation you encountered with the C++ client failing to send a sasl
mechanism during the connection process.
I have also tried some of the combinations you have mentioned using the
latest revision of trunk, on an old VM running Fedora 12 with the
cyrus-sasl, cyrus-sasl-devel, cyrus-sasl-lib, cyrus-sasl-md5, and
cyrus-sasl-plain packages installed. Comments inline.
On 1 November 2012 18:44, Jeremy Wagner <co...@yahoo.com> wrote:
> Hello all,
>
> Prior to sasl installation, the only way I could get the C++ clients
> (spout/drain) to work with the Java broker was only if I added in the
> "--connection-options={sasl_mechanisms:PLAIN,username:guest,password:guest}"
> as Gordon suggested.
>
> Now, however, after installing sasl, this is what I saw.
>
> 1) C++ clients -> C++ broker - did not work initially, but with a key
> modification, it works - see below
> I initially tried with these commands:
> ./drain -f -c 1 --connection-options
> '{sasl_mechanims:PLAIN,username:guest,password:guest}' queue
> ./spout -c 1 --connection-options
> '{sasl_mechanisms:PLAIN,username:guest,password:guest}' queue
> This did not work as it did prior to the sasl installation, the
> following error was received from the C++ client:
> <timestamp> [Client] warning Closing connection due to Desired
> mechanism(s) not valid: PLAIN (supported: ANONYMOUS)
> (qpid/client/ConnectionHandler.cpp:256)
>
> So I tried this again, but using the ANONYMOUS mechanism and it
> worked, see below:
> ./drain -f -c 1 --connection-options '{sasl_mechanisms:ANONYMOUS}'
> queue
> ./spout -c 1 --connection-options '{sasl_mechanisms:ANONYMOUS}'
> queue
>
> So it appears that the C++ broker is not behaving correctly in this
> instance as it should be able to support PLAIN as well as others have
> mentioned in this e-mail thread?
>
>
Starting the C++ broker with authentication enabled and then running the
commands after changing the mechanism in the connection options to MADEUP
(i.e deliberately asking for something that was unsupported) got me the
following:
Desired mechanism(s) not valid: MADEUP (supported: LOGIN DIGEST-MD5
ANONYMOUS CRAM-MD5 PLAIN) (qpid/client/ConnectionHandler.cpp:258)
>From this we can see that my broker supported a wider range of mechanisms
than yours, leading me to think that perhaps you dont have some relevant
packages installed (cyrus-sasl-plain etc). Can you confirm if that is the
case, and if so whether installing them helps you get this all working?
> 2) Java clients -> Java broker - worked fine with no issues and didn't
> even need to supply username/password as the defaults worked (guest/guest).
>
> 3) Java clients -> C++ broker - did not work initially, but with a key
> modification, it works - see below
> I initially tried with these commands:
> java org.apache.qpid.example.Drain -f -c=1 queue (with the
> classpath set as appropriate) -- this uses guest/guest as the default
> java org.apache.qpid.example.Spout -c=1 queue (with the classpath
> set as appropriate) -- this uses guest/guest as the default
>
> I got the following error from the Java broker when running Spout
> only, not the Drain (there were no errors with Drain):
> <timestamp> [Protocol] error Execution exception:
> unauthorized-access: authorised user id : anonymous@QPID but user id in
> message declared as guest (qpid/broker/SemanticState.cpp:484)
>
I believe this is because although you are specifying guest:guest as the
credentials, rom the above it seems your broker is only capable of
ANONYMOUS and so that has to be what was used, resulting in you being
logged in as anonymous. This then results in a mismatch between your
authorized user id (anonymous) and what the produced messages had indicated
for their user id (guest), such that when the broker inspected the messages
to verify they were produced by the expected user it found they weren't.
Getting the broker to actually authenticate via use of an appropriate sasl
mechanism rather than using ANONYMOUS seems like it should resolve that.
> So I tried this again but using anonymous as the username/password.
> java org.apache.qpid.example.Drain -f -c 1 queue (with the
> classpath set as appropriate) -- this uses guest/guest as the default
> java org.apache.qpid.example.Spout -c=1
> -b=anonymous:anonymous@localhost:5672 queue (with the classpath set as
> appropriate)
>
> This finally worked with no issues.
>
> However, I decided to try this again but only using guest/guest
> instead of anonymous/anonymous as shown below.
> java org.apache.qpid.example.Drain -f -c=1 queue (with the
> classpath set as appropriate) -- this uses guest/guest as the default
> java org.apache.qpid.example.Spout -c=1 -b=guest:guest@localhost:5672
> queue (with the classpath set as appropriate)
>
> Spout appears to have sent the message, but Drain never got it? So it
> appears that anonymous/anonymous works, but guest/guest does not? Although,
> this is what Drain is using as the default?
>
I'd guess Drain is getting away with guest/guest credentials (whilst
actuallly being logged in as 'anonymous' due to the apparent sole support
of the ANONYMOUS mechanism as noted above) because it is only receiving
messages, whereas Spout isnt able to as the messages it produces are being
inspected and found to have a mismatch between the user ids.
> Also, why were there no error messages when Spout tries to communicate
> with the C++ broker as I got on my initial attempt?
>
> 4) C++ clients -> Java broker - does not work no matter what I did - I get
> the following error from the C++ clients:
> <timestamp> [Client] warning Closing connection due to
> internal-error: Sasl error: SASL(-4): no mechanism available: No worthy
> mechs found (qpid/SaslFactory.cpp:280)
>
> Even though, I am running with the sasl_mechanisms option as shown
> below:
> ./drain -f -c 1 --connection-options
> '{sasl_mechanisms:PLAIN,username:guest,password:guest}' queue
> ./spout -c 1 --connection-options
> '{sasl_mechanisms:PLAIN,username:guest,password:guest}' queue
>
I was able to send messages to the Java broker using the C++ Spout
regardless of whether I specified the sasl_mechanism connection option (and
also if I specified it as CRAM-MD5).
I believe the issue here is that your installed sasl packages arent
permitting the C++ client to support any of the mechanisms being offereed
by the broker, so it fails to choose one and thus cant continue.
>
> I also tried the following, which is essentially the same as above and
> got the same error as above:
> ./drain -f -c 1 -b guest/guest@localhost --connection-options
> '{sasl_mechanisms:PLAIN}' queue
> ./spout -c 1 -b guest/guest@localhost --connection-options
> '{sasl_mechanisms:PLAIN}' queue
>
> So I decided to try the ANONYMOUS mechanism as shown below:
> ./drain -f -c 1 --connection-options '{sasl_mechanisms:ANONYMOUS}'
> queue
> ./spout -c 1 --conneciton-options '{sasl_mechanisms:ANONYMOUS}'
> queue
>
> I got the following error:
> <timestamp> [Client] warning Closing connection due to Desired
> mechanism(s) not valid: ANONYMOUS (supported: AMQPLAIN PLAIN CRAM-MD5)
> (qpid/client/ConnectionHandler.cpp:256)
>
> This is bizarre because the PLAIN did not work as shown above. So I
> tried it with both AMQPLAIN and CRAM-MD5 using guest/guest as well
> anonymous/anonymous and still got the same initial error (SASL(-4)).
>
The Java broker doenst support ANONYMOUS by default, whereas using that
last command means your C++ client is being told to choose ANONYMOUS, which
can only result in what you are seeing; the broker offered 3 mechanisms
(AMQPLAIN PLAIN CRAM-MD5) but the client explicitly desired something which
wasnt one of them an so couldnt proceed.
You can turn on ANONYMOUS support on the Java broker, which did allow the
above to work when I tried it. (You could for example replace the
<pd-auth-manager>...</pd-auth-manager> section in etc/config.xml with
simply <anonymous-auth-manager/>)
> I'm hoping that it's something that I didn't do after installing sasl that
> could solve all of these problems? I understand that it is a challenge to
> keep both the C++/Java brokers/clients in sync with each other. Thank you.
>
> Regards,
> Jeremy
>
>
>
> ----- Original Message -----
> From: Sean K <sk...@gmail.com>
> To: users@qpid.apache.org
> Cc:
> Sent: Wednesday, October 31, 2012 5:02 PM
> Subject: Re: C++ clients unable to communicate with Java broker
>
> I used the spout and drain example apps and used the --connection-options
> {sasl-mechanism:PLAIN}
>
> Using the connection-options allows the c++ example app to work.
>
> Omitting it with the spout and drain app results in the same result as the
> helloworld (invoked without any command line options.)
>
>
>
>
> On Wed, Oct 31, 2012 at 4:09 PM, Robbie Gemmell <robbie.gemmell@gmail.com
> >wrote:
>
> > The log line below seems to suggest it is the same issue Jeremy was
> seeing,
> > that the client is not selecting a SASL mechanism during connection and
> the
> > broker is ultimately killing it as a result. Alex mentioned in a
> discussion
> > about this that its actually NPEing on the broker side in this situation,
> > so we can/should make the broker handle that with a little more grace to
> > make the problem more, although it is really the client at fault. It isnt
> > entirely clear to me from your replies whether you tried the two
> > solution/workarounds mentioned already in the mail thread, can you
> clarify?
> >
> > [[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; }]
> >
> > Robbie
> >
> > On 31 October 2012 17:18, Sean K <sk...@gmail.com> wrote:
> >
> > > 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 <go...@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
> > >
> > >
> >
>
>
>
> --
> Sean
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: C++ clients unable to communicate with Java broker
Posted by Jeremy Wagner <co...@yahoo.com>.
Hello all,
Prior to sasl installation, the only way I could get the C++ clients (spout/drain) to work with the Java broker was only if I added in the "--connection-options={sasl_mechanisms:PLAIN,username:guest,password:guest}" as Gordon suggested.
Now, however, after installing sasl, this is what I saw.
1) C++ clients -> C++ broker - did not work initially, but with a key modification, it works - see below
I initially tried with these commands:
./drain -f -c 1 --connection-options '{sasl_mechanims:PLAIN,username:guest,password:guest}' queue
./spout -c 1 --connection-options '{sasl_mechanisms:PLAIN,username:guest,password:guest}' queue
This did not work as it did prior to the sasl installation, the following error was received from the C++ client:
<timestamp> [Client] warning Closing connection due to Desired mechanism(s) not valid: PLAIN (supported: ANONYMOUS) (qpid/client/ConnectionHandler.cpp:256)
So I tried this again, but using the ANONYMOUS mechanism and it worked, see below:
./drain -f -c 1 --connection-options '{sasl_mechanisms:ANONYMOUS}' queue
./spout -c 1 --connection-options '{sasl_mechanisms:ANONYMOUS}' queue
So it appears that the C++ broker is not behaving correctly in this instance as it should be able to support PLAIN as well as others have mentioned in this e-mail thread?
2) Java clients -> Java broker - worked fine with no issues and didn't even need to supply username/password as the defaults worked (guest/guest).
3) Java clients -> C++ broker - did not work initially, but with a key modification, it works - see below
I initially tried with these commands:
java org.apache.qpid.example.Drain -f -c=1 queue (with the classpath set as appropriate) -- this uses guest/guest as the default
java org.apache.qpid.example.Spout -c=1 queue (with the classpath set as appropriate) -- this uses guest/guest as the default
I got the following error from the Java broker when running Spout only, not the Drain (there were no errors with Drain):
<timestamp> [Protocol] error Execution exception: unauthorized-access: authorised user id : anonymous@QPID but user id in message declared as guest (qpid/broker/SemanticState.cpp:484)
So I tried this again but using anonymous as the username/password.
java org.apache.qpid.example.Drain -f -c 1 queue (with the classpath set as appropriate) -- this uses guest/guest as the default
java org.apache.qpid.example.Spout -c=1 -b=anonymous:anonymous@localhost:5672 queue (with the classpath set as appropriate)
This finally worked with no issues.
However, I decided to try this again but only using guest/guest instead of anonymous/anonymous as shown below.
java org.apache.qpid.example.Drain -f -c=1 queue (with the classpath set as appropriate) -- this uses guest/guest as the default
java org.apache.qpid.example.Spout -c=1 -b=guest:guest@localhost:5672 queue (with the classpath set as appropriate)
Spout appears to have sent the message, but Drain never got it? So it appears that anonymous/anonymous works, but guest/guest does not? Although, this is what Drain is using as the default?
Also, why were there no error messages when Spout tries to communicate with the C++ broker as I got on my initial attempt?
4) C++ clients -> Java broker - does not work no matter what I did - I get the following error from the C++ clients:
<timestamp> [Client] warning Closing connection due to internal-error: Sasl error: SASL(-4): no mechanism available: No worthy mechs found (qpid/SaslFactory.cpp:280)
Even though, I am running with the sasl_mechanisms option as shown below:
./drain -f -c 1 --connection-options '{sasl_mechanisms:PLAIN,username:guest,password:guest}' queue
./spout -c 1 --connection-options '{sasl_mechanisms:PLAIN,username:guest,password:guest}' queue
I also tried the following, which is essentially the same as above and got the same error as above:
./drain -f -c 1 -b guest/guest@localhost --connection-options '{sasl_mechanisms:PLAIN}' queue
./spout -c 1 -b guest/guest@localhost --connection-options '{sasl_mechanisms:PLAIN}' queue
So I decided to try the ANONYMOUS mechanism as shown below:
./drain -f -c 1 --connection-options '{sasl_mechanisms:ANONYMOUS}' queue
./spout -c 1 --conneciton-options '{sasl_mechanisms:ANONYMOUS}' queue
I got the following error:
<timestamp> [Client] warning Closing connection due to Desired mechanism(s) not valid: ANONYMOUS (supported: AMQPLAIN PLAIN CRAM-MD5) (qpid/client/ConnectionHandler.cpp:256)
This is bizarre because the PLAIN did not work as shown above. So I tried it with both AMQPLAIN and CRAM-MD5 using guest/guest as well anonymous/anonymous and still got the same initial error (SASL(-4)).
I'm hoping that it's something that I didn't do after installing sasl that could solve all of these problems? I understand that it is a challenge to keep both the C++/Java brokers/clients in sync with each other. Thank you.
Regards,
Jeremy
----- Original Message -----
From: Sean K <sk...@gmail.com>
To: users@qpid.apache.org
Cc:
Sent: Wednesday, October 31, 2012 5:02 PM
Subject: Re: C++ clients unable to communicate with Java broker
I used the spout and drain example apps and used the --connection-options
{sasl-mechanism:PLAIN}
Using the connection-options allows the c++ example app to work.
Omitting it with the spout and drain app results in the same result as the
helloworld (invoked without any command line options.)
On Wed, Oct 31, 2012 at 4:09 PM, Robbie Gemmell <ro...@gmail.com>wrote:
> The log line below seems to suggest it is the same issue Jeremy was seeing,
> that the client is not selecting a SASL mechanism during connection and the
> broker is ultimately killing it as a result. Alex mentioned in a discussion
> about this that its actually NPEing on the broker side in this situation,
> so we can/should make the broker handle that with a little more grace to
> make the problem more, although it is really the client at fault. It isnt
> entirely clear to me from your replies whether you tried the two
> solution/workarounds mentioned already in the mail thread, can you clarify?
>
> [[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; }]
>
> Robbie
>
> On 31 October 2012 17:18, Sean K <sk...@gmail.com> wrote:
>
> > 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 <go...@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
> >
> >
>
--
Sean
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ clients unable to communicate with Java broker
Posted by Sean K <sk...@gmail.com>.
I used the spout and drain example apps and used the --connection-options
{sasl-mechanism:PLAIN}
Using the connection-options allows the c++ example app to work.
Omitting it with the spout and drain app results in the same result as the
helloworld (invoked without any command line options.)
On Wed, Oct 31, 2012 at 4:09 PM, Robbie Gemmell <ro...@gmail.com>wrote:
> The log line below seems to suggest it is the same issue Jeremy was seeing,
> that the client is not selecting a SASL mechanism during connection and the
> broker is ultimately killing it as a result. Alex mentioned in a discussion
> about this that its actually NPEing on the broker side in this situation,
> so we can/should make the broker handle that with a little more grace to
> make the problem more, although it is really the client at fault. It isnt
> entirely clear to me from your replies whether you tried the two
> solution/workarounds mentioned already in the mail thread, can you clarify?
>
> [[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; }]
>
> Robbie
>
> On 31 October 2012 17:18, Sean K <sk...@gmail.com> wrote:
>
> > 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 <go...@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
> >
> >
>
--
Sean