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 <sk92...@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.gemm...@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 <sk92...@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 <gordon.r....@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-unsubscr...@qpid.apache.org
> > > For additional commands, e-mail: users-h...@qpid.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> >
> >
>
--
Sean
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
