You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Jeremy Wagner <co...@yahoo.com> on 2012/10/25 21:30:13 UTC
C++ clients unable to communicate with Java broker
Hello,
I have been unable to get the C++ clients (i.e. spout/drain) to successfully connect to the Java broker. Even though, I can get the Java clients to connect to the Java broker as well both the C++ and Java clients to connect to the C++ broker. The Java broker is running with the default configuration as I'm trying to establish a working connection between the C++ clients and the Java broker before making configuration changes. I did look through the archives of this mailing list and it has been mentioned that this should be possible as long the username/password was provided as well. So this is what I did with no success.
Terminal 1:
qpid-server -- this starts the Java broker - this uses the default config.xml/virtualhosts.xml files so the named 'queue' is already defined
Terminal 2:
./spout -c 1 -b guest/guest@localhost queue
Output was:
<timestamp> [Client] warning Connection [127.0.0.1:xxx-127.0.0.1:5672] closed
Failed to connect (reconnect disabled)
Terminal 3:
./drain -c 1 -f -b guest/guest@localhost queue
Output was:
<timestamp> [Client] warning Connection [127.0.0.1:xxx-127.0.0.1:5672] closed
Failed to connect (reconnect disabled)
I would appreciate any guidance to get the C++ clients working with the Java broker. Thank you.
Jeremy
---------------------------------------------------------------------
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,
I forgot to mention that I'm running with Qpid 0.18 on Red Hat Linux (64 bits) where the Qpid cpp component was compiled as 32 bits (CFLAGS, CXXFLAGS, and LDFLAGS). Thank you.
Jeremy
----- Original Message -----
From: Jeremy Wagner <co...@yahoo.com>
To: "users@qpid.apache.org" <us...@qpid.apache.org>
Cc:
Sent: Thursday, October 25, 2012 12:30 PM
Subject: C++ clients unable to communicate with Java broker
Hello,
I have been unable to get the C++ clients (i.e. spout/drain) to successfully connect to the Java broker. Even though, I can get the Java clients to connect to the Java broker as well both the C++ and Java clients to connect to the C++ broker. The Java broker is running with the default configuration as I'm trying to establish a working connection between the C++ clients and the Java broker before making configuration changes. I did look through the archives of this mailing list and it has been mentioned that this should be possible as long the username/password was provided as well. So this is what I did with no success.
Terminal 1:
qpid-server -- this starts the Java broker - this uses the default config.xml/virtualhosts.xml files so the named 'queue' is already defined
Terminal 2:
./spout -c 1 -b guest/guest@localhost queue
Output was:
<timestamp> [Client] warning Connection [127.0.0.1:xxx-127.0.0.1:5672] closed
Failed to connect (reconnect disabled)
Terminal 3:
./drain -c 1 -f -b guest/guest@localhost queue
Output was:
<timestamp> [Client] warning Connection [127.0.0.1:xxx-127.0.0.1:5672] closed
Failed to connect (reconnect disabled)
I would appreciate any guidance to get the C++ clients working with the Java broker. Thank you.
Jeremy
---------------------------------------------------------------------
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 Oleksandr Rudyy <or...@gmail.com>.
Hi,
Can you change java broker log level to debug and provide the broker
logs for c++ client connect?
You need to change in ${QPID_HOME}/etc/log4j.xml the following logger
configuration
<logger additivity="true" name="org.apache.qpid">
<level value="debug"/>
</logger>
By default, the log level is set to "warn".
Also, could you try to run spout/drain examples by specifying sasl
mechanism as PLAIN with "connection-options" argument?
The following worked for me with client being compiled without SASL dependencies
./spout -c 1 -b guest/guest@localhost --connection-options
{sasl-mechanism:PLAIN} queue
./drain -c 1 -b guest/guest@localhost --connection-options
{sasl-mechanism:PLAIN} queue
Kind Regards,
Alex
---------------------------------------------------------------------
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 am not sure what happenned before -- but now the java client can
connect to the c++ broker and receive the helloworld message from the
c++ topic producer.
I changed the helloworld message to only publish, and modified the
java topic consumer to receive.
the only issue was that the java consumer thought it might get a
TextMessage class type, but it was a JMSBytesMessage instead.
On Mon, Oct 29, 2012 at 11:28 PM, Gordon Sim <go...@gmail.com> wrote:
> On 10/29/2012 10:45 PM, Sean K wrote:
>>
>> I am getting similar if not exact situation.
>>
>> I am using 0.18 c++ bundle, and the 0.18 java bundle.
>>
>> When I try to mix the two together, they do not work -- attempting to
>> connect to localhost.
>>
>> They work separately in their own language enclave.
>
>
> Are there any errors on the broker? Did you try java-client->c++-server and
> c++-client->java-server or just one of them?
>
> Can you log a protocol trace for a failed example? (E.g. on c++ client
> export QPID_LOG_ENABLE=trace+:amqp_0_10 or on qpidd use '--log-enable
> trace+:amqp_0_10 --log-enable info+').
>
>
>
> ---------------------------------------------------------------------
> 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 Gordon Sim <go...@gmail.com>.
On 10/29/2012 10:45 PM, Sean K wrote:
> I am getting similar if not exact situation.
>
> I am using 0.18 c++ bundle, and the 0.18 java bundle.
>
> When I try to mix the two together, they do not work -- attempting to
> connect to localhost.
>
> They work separately in their own language enclave.
Are there any errors on the broker? Did you try java-client->c++-server
and c++-client->java-server or just one of them?
Can you log a protocol trace for a failed example? (E.g. on c++ client
export QPID_LOG_ENABLE=trace+:amqp_0_10 or on qpidd use '--log-enable
trace+:amqp_0_10 --log-enable info+').
---------------------------------------------------------------------
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 am getting similar if not exact situation.
I am using 0.18 c++ bundle, and the 0.18 java bundle.
When I try to mix the two together, they do not work -- attempting to
connect to localhost.
They work separately in their own language enclave.
On Sun, Oct 28, 2012 at 11:57 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 10/26/2012 11:00 AM, Rob Godfrey wrote:
>>
>> OK... I think I know what the problem is now - the machine on which
>> you built the C++ client almost certainly doesn't have the SASL
>> libraries installed.
>>
>> When I build on a CentOS machine without SASL installed then I see
>> exactly the issue you are reporting.
>
>
> Can you get a protocol trace for that (e.g. set
> QPID_LOG_ENABLE=trace+:amqp_0_10 on the client)?
>
> The cyrus integration is supposed to be optional and if not available a
> default implementation that supports only ANONYMOUS and PLAIN *should* be
> built in.
>
> You can explicitly control the SASL mechanism used through the connection
> options e.g. --connection-options '{sasl_mechanisms:PLAIN}'.
>
> (You can if desired also specify the username and password in the connection
> options instead of in the URL e.g. --connection-options
> '{sasl_mechanisms:PLAIN,username:guest,password:guest}')
>
>
>> If I install the SASL libraries and rebuild the C++ client then it all
>> works fine
>
>
>
> ---------------------------------------------------------------------
> 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
Re: C++ clients unable to communicate with Java broker
Posted by Robbie Gemmell <ro...@gmail.com>.
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 Sean K <sk...@gmail.com>.
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 Gordon Sim <go...@gmail.com>.
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
Re: C++ clients unable to communicate with Java broker
Posted by Rob Godfrey <ro...@gmail.com>.
On 31 October 2012 07:32, Gordon Sim <go...@gmail.com> wrote:
> On 10/31/2012 12:14 AM, Sean K wrote:
>>
>> Interestingly, the c++ client (specifically the helloworld) does not
>> connect to the Java broker.
>>
>> I added this line to my .bash_profile
>>
>> export QPID_LOG_ENABLE=trace+:amqp_0_10
>>
>> and I turned up the logging on the java broker as Oleksandr Rudyy
>> ("Alex") had suggested.
>>
>> There is no additional logging activity in the java broker console,
>> nor is there any log files generated that I noticed.
>
>
> Sorry, that was my stupidity! The log setting above only does the right
> thing on the broker. On the client, export QPID_LOG_ENABLE=trace+ would be
> sufficient. Apologies again for sending you on a wild goose chase there!
>
>
>> When I run the c++ client helloworld on the, I only see this:
>>
>> [sean@fedora16 messaging]$ ./hello_world
>> Failed to connect (reconnect disabled)
>>
>> I ran the spout and drain (c++ client) as Alex had suggested, and they
>> worked with the java broker. (interesting).
>>
>> [sean@fedora16 messaging]$ ./spout -c 1 -b guest/guest@localhost
>> --connection-options {sasl-mechanism:PLAIN} queue
>> [sean@fedora16 messaging]$ ./drain -c 1 -b guest/guest@localhost
>> --connection-options {sasl-mechanism:PLAIN} queue
>> Message(properties={spout-id:74c4541b-f57b-44ec-b229-9300b4c972c8:0,
>> x-amqp-0-10.routing-key:queue}, content='')
>
>
> I think the issue is the SASL mechanism chosen. If no details are specified
> (as in helloworld), then ANONYMOUS is being chosen which is not enabled by
> default on the java broker.
>
> It would certainly be nice if the client actually logged something about
> this though, and it would appear it does not. With cyrus sasl integration,
> there is a message about no suitable mechanism being found but in the simple
> default impl there is no checking, it just takes whatever is configured.
>
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.
-- Rob
>
>
> ---------------------------------------------------------------------
> 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 Gordon Sim <go...@gmail.com>.
On 10/31/2012 12:14 AM, Sean K wrote:
> Interestingly, the c++ client (specifically the helloworld) does not
> connect to the Java broker.
>
> I added this line to my .bash_profile
>
> export QPID_LOG_ENABLE=trace+:amqp_0_10
>
> and I turned up the logging on the java broker as Oleksandr Rudyy
> ("Alex") had suggested.
>
> There is no additional logging activity in the java broker console,
> nor is there any log files generated that I noticed.
Sorry, that was my stupidity! The log setting above only does the right
thing on the broker. On the client, export QPID_LOG_ENABLE=trace+ would
be sufficient. Apologies again for sending you on a wild goose chase there!
> When I run the c++ client helloworld on the, I only see this:
>
> [sean@fedora16 messaging]$ ./hello_world
> Failed to connect (reconnect disabled)
>
> I ran the spout and drain (c++ client) as Alex had suggested, and they
> worked with the java broker. (interesting).
>
> [sean@fedora16 messaging]$ ./spout -c 1 -b guest/guest@localhost
> --connection-options {sasl-mechanism:PLAIN} queue
> [sean@fedora16 messaging]$ ./drain -c 1 -b guest/guest@localhost
> --connection-options {sasl-mechanism:PLAIN} queue
> Message(properties={spout-id:74c4541b-f57b-44ec-b229-9300b4c972c8:0,
> x-amqp-0-10.routing-key:queue}, content='')
I think the issue is the SASL mechanism chosen. If no details are
specified (as in helloworld), then ANONYMOUS is being chosen which is
not enabled by default on the java broker.
It would certainly be nice if the client actually logged something about
this though, and it would appear it does not. With cyrus sasl
integration, there is a message about no suitable mechanism being found
but in the simple default impl there is no checking, it just takes
whatever is configured.
---------------------------------------------------------------------
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>.
Interestingly, the c++ client (specifically the helloworld) does not
connect to the Java broker.
I added this line to my .bash_profile
export QPID_LOG_ENABLE=trace+:amqp_0_10
and I turned up the logging on the java broker as Oleksandr Rudyy
("Alex") had suggested.
There is no additional logging activity in the java broker console,
nor is there any log files generated that I noticed.
When I run the c++ client helloworld on the, I only see this:
[sean@fedora16 messaging]$ ./hello_world
Failed to connect (reconnect disabled)
I ran the spout and drain (c++ client) as Alex had suggested, and they
worked with the java broker. (interesting).
[sean@fedora16 messaging]$ ./spout -c 1 -b guest/guest@localhost
--connection-options {sasl-mechanism:PLAIN} queue
[sean@fedora16 messaging]$ ./drain -c 1 -b guest/guest@localhost
--connection-options {sasl-mechanism:PLAIN} queue
Message(properties={spout-id:74c4541b-f57b-44ec-b229-9300b4c972c8:0,
x-amqp-0-10.routing-key:queue}, content='')
On Sun, Oct 28, 2012 at 11:57 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 10/26/2012 11:00 AM, Rob Godfrey wrote:
>>
>> OK... I think I know what the problem is now - the machine on which
>> you built the C++ client almost certainly doesn't have the SASL
>> libraries installed.
>>
>> When I build on a CentOS machine without SASL installed then I see
>> exactly the issue you are reporting.
>
>
> Can you get a protocol trace for that (e.g. set
> QPID_LOG_ENABLE=trace+:amqp_0_10 on the client)?
>
> The cyrus integration is supposed to be optional and if not available a
> default implementation that supports only ANONYMOUS and PLAIN *should* be
> built in.
>
> You can explicitly control the SASL mechanism used through the connection
> options e.g. --connection-options '{sasl_mechanisms:PLAIN}'.
>
> (You can if desired also specify the username and password in the connection
> options instead of in the URL e.g. --connection-options
> '{sasl_mechanisms:PLAIN,username:guest,password:guest}')
>
>
>> If I install the SASL libraries and rebuild the C++ client then it all
>> works fine
>
>
>
> ---------------------------------------------------------------------
> 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 Gordon Sim <gs...@redhat.com>.
On 10/26/2012 11:00 AM, Rob Godfrey wrote:
> OK... I think I know what the problem is now - the machine on which
> you built the C++ client almost certainly doesn't have the SASL
> libraries installed.
>
> When I build on a CentOS machine without SASL installed then I see
> exactly the issue you are reporting.
Can you get a protocol trace for that (e.g. set
QPID_LOG_ENABLE=trace+:amqp_0_10 on the client)?
The cyrus integration is supposed to be optional and if not available a
default implementation that supports only ANONYMOUS and PLAIN *should*
be built in.
You can explicitly control the SASL mechanism used through the
connection options e.g. --connection-options '{sasl_mechanisms:PLAIN}'.
(You can if desired also specify the username and password in the
connection options instead of in the URL e.g. --connection-options
'{sasl_mechanisms:PLAIN,username:guest,password:guest}')
> If I install the SASL libraries and rebuild the C++ client then it all
> works fine
---------------------------------------------------------------------
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 Rob Godfrey <ro...@gmail.com>.
Hi Jeremy,
OK... I think I know what the problem is now - the machine on which
you built the C++ client almost certainly doesn't have the SASL
libraries installed.
When I build on a CentOS machine without SASL installed then I see
exactly the issue you are reporting.
If I install the SASL libraries and rebuild the C++ client then it all
works fine
(I did yum install cyrus-sasl-devel which seemed to pull in all the
necessary dependencies).
Cheers,
Rob
On 26 October 2012 03:34, Rob Godfrey <ro...@gmail.com> wrote:
> Hi Jeremy,
>
> does the Java Broker log contain any useful information (it should
> appear in ${QPID_HOME}/log).
>
> I just built the 0.18 C++ clients on 32-bit Ubuntu 12.04 and ran the
> example against the 0.18 Java Broker with no issue.
>
> The only other avenue to potentially explore is some sort of firewall
> / other security mechanism which is stopping you connecting to port
> 5672 (which you could verify by trying to telnet to that port on your
> local machine).
>
> Cheers,
> Rob
> On 25 October 2012 21:30, Jeremy Wagner <co...@yahoo.com> wrote:
>> Hello,
>>
>> I have been unable to get the C++ clients (i.e. spout/drain) to successfully connect to the Java broker. Even though, I can get the Java clients to connect to the Java broker as well both the C++ and Java clients to connect to the C++ broker. The Java broker is running with the default configuration as I'm trying to establish a working connection between the C++ clients and the Java broker before making configuration changes. I did look through the archives of this mailing list and it has been mentioned that this should be possible as long the username/password was provided as well. So this is what I did with no success.
>>
>> Terminal 1:
>> qpid-server -- this starts the Java broker - this uses the default config.xml/virtualhosts.xml files so the named 'queue' is already defined
>>
>> Terminal 2:
>> ./spout -c 1 -b guest/guest@localhost queue
>> Output was:
>> <timestamp> [Client] warning Connection [127.0.0.1:xxx-127.0.0.1:5672] closed
>> Failed to connect (reconnect disabled)
>>
>> Terminal 3:
>> ./drain -c 1 -f -b guest/guest@localhost queue
>> Output was:
>> <timestamp> [Client] warning Connection [127.0.0.1:xxx-127.0.0.1:5672] closed
>> Failed to connect (reconnect disabled)
>>
>> I would appreciate any guidance to get the C++ clients working with the Java broker. Thank you.
>>
>> Jeremy
>>
>> ---------------------------------------------------------------------
>> 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 Rob Godfrey <ro...@gmail.com>.
Hi Jeremy,
does the Java Broker log contain any useful information (it should
appear in ${QPID_HOME}/log).
I just built the 0.18 C++ clients on 32-bit Ubuntu 12.04 and ran the
example against the 0.18 Java Broker with no issue.
The only other avenue to potentially explore is some sort of firewall
/ other security mechanism which is stopping you connecting to port
5672 (which you could verify by trying to telnet to that port on your
local machine).
Cheers,
Rob
On 25 October 2012 21:30, Jeremy Wagner <co...@yahoo.com> wrote:
> Hello,
>
> I have been unable to get the C++ clients (i.e. spout/drain) to successfully connect to the Java broker. Even though, I can get the Java clients to connect to the Java broker as well both the C++ and Java clients to connect to the C++ broker. The Java broker is running with the default configuration as I'm trying to establish a working connection between the C++ clients and the Java broker before making configuration changes. I did look through the archives of this mailing list and it has been mentioned that this should be possible as long the username/password was provided as well. So this is what I did with no success.
>
> Terminal 1:
> qpid-server -- this starts the Java broker - this uses the default config.xml/virtualhosts.xml files so the named 'queue' is already defined
>
> Terminal 2:
> ./spout -c 1 -b guest/guest@localhost queue
> Output was:
> <timestamp> [Client] warning Connection [127.0.0.1:xxx-127.0.0.1:5672] closed
> Failed to connect (reconnect disabled)
>
> Terminal 3:
> ./drain -c 1 -f -b guest/guest@localhost queue
> Output was:
> <timestamp> [Client] warning Connection [127.0.0.1:xxx-127.0.0.1:5672] closed
> Failed to connect (reconnect disabled)
>
> I would appreciate any guidance to get the C++ clients working with the Java broker. Thank you.
>
> Jeremy
>
> ---------------------------------------------------------------------
> 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