You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Brandon Pedersen <bp...@gmail.com> on 2012/02/10 07:20:51 UTC
problems using cqpid with java broker
Hi, I am currently using the C++ broker with the python cqpid client
and it is running smoothly. However, after reading through this
http://qpid.2158936.n2.nabble.com/DerbyDB-vs-BerkeleyDB-using-the-Java-Broker-tp7056640p7155540.html
I thought it would be best to switch to the Java broker instead. I am
currently using 0.12 but am testing out the 0.14 java broker (though
the same problem I am having exists with 0.12). When I try to use the
cqpid client with the Java broker it does not work. My python program
spits out a ton of messages like "warning Connection
[127.0.0.1:48782-localhost:5672] closed" and basically hangs...I have
to force kill it. And on the server it outputs the following over and
over again:
2012-02-08 22:22:53,592 INFO [IoReceiver - /127.0.0.1:33357]
logging.Log4jMessageLogger (Log4jMessageLogger.java:72) -
[con:458(/127.0.0.1:33357)] CON-1001 : Open : Protocol Version : 0-10
2012-02-08 22:22:53,592 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - RECV: [conn:5dfa490] AMQP.1 0-10
2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - SEND: [conn:5dfa490] AMQP.1 0-10
2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
ConnectionStart(serverProperties={qpid.federation_tag=957f527c-dfa5-4192-8160-9f092b31b303},
mechanisms=[AMQPLAIN, PLAIN, CRAM-MD5], locales=[en_US])
2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
ConnectionStartOk(clientProperties={qpid.client_pid=18119,
qpid.client_ppid=28800, qpid.client_process=python,
qpid.session_flow=1}, mechanism=, response=[B@1dacecf3, locale=en_US)
2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
ConnectionTune(channelMax=256, maxFrameSize=65535, heartbeatMin=0,
heartbeatMax=0)
2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
2012-02-08 22:22:53,595 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
ConnectionTuneOk(channelMax=256, maxFrameSize=65535, heartbeat=0)
2012-02-08 22:22:53,595 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
ConnectionOpen(virtualHost=, capabilities=[], insist=true)
2012-02-08 22:22:53,596 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
ConnectionOpenOk(knownHosts=[])
2012-02-08 22:22:53,596 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
2012-02-08 22:22:53,597 INFO [IoReceiver - /127.0.0.1:33357]
logging.Log4jMessageLogger (Log4jMessageLogger.java:72) -
[con:458(/127.0.0.1:33357)] CON-1001 : Open : Client ID : null :
Protocol Version : 0-10
2012-02-08 22:22:53,597 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=1
SessionAttach(name=[B@64836727)
2012-02-08 22:22:53,597 DEBUG [IoReceiver - /127.0.0.1:33357]
util.Logger (Logger.java:54) - connection closed: conn:5dfa490
Any idea what might be wrong here? Is this a bug or am I potentially
doing something wrong?
Thanks,
-Brandon
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Brandon Pedersen <bp...@gmail.com>.
Forgot to mention also that the regular python qpid.messaging library
works fine, but I actually have a need to use the c bindings.
On Fri, Feb 10, 2012 at 11:11 AM, Brandon Pedersen <bp...@gmail.com> wrote:
> On Fri, Feb 10, 2012 at 10:40 AM, Robbie Gemmell
> <ro...@gmail.com> wrote:
>> Hi Brandon,
>>
>> The python client is admitedly mostly used with the C++ broker
>> currently, but there shouldnt be anything inherantly stopping its use
>> with the Java broker given they both speak AMQP 0-10, and we would
>> want to resolve it if there is. We do run the Python client tests and
>> python based AMQP 0-10 broker tests against the Java broker on CI
>> instances on a daily basis now (though my memory is fuzzy on if or how
>> long we had before the 0.14 release initially branched ).
>
> I just want to point out that I am using the C bindings in Python, not
> the basic qpid.messaging Python library
>
>> If you can possibly send the code you are having issue using (or a
>> stripped down example based on it if its in any way sensitive), I will
>> take a look if there is anything I can spot either in there or on the
>> broker side while running it.
>
> Here is a very stripped down example that produces the problem:
> from cqpid import Connection
> conn = Connection("localhost", username="admin", password="admin",
> reconnect=True)
> conn.open()
> session = conn.session()
>
>> With regards to the brokers log output, did you happen to turn on
>> debug logging for analysis, or possibly somehow havent provided the
>> default logging config we ship in the package? Almost none of that
>> output should be displayed by default.
>
> Yes, I used the debug.log4j.xml so I could see if there were any
> problems and pasted it here since I thought it might help.
>
> Thanks,
>
> -Brandon
>
>> Regards,
>> Robbie
>>
>> On 10 February 2012 06:20, Brandon Pedersen <bp...@gmail.com> wrote:
>>> Hi, I am currently using the C++ broker with the python cqpid client
>>> and it is running smoothly. However, after reading through this
>>> http://qpid.2158936.n2.nabble.com/DerbyDB-vs-BerkeleyDB-using-the-Java-Broker-tp7056640p7155540.html
>>> I thought it would be best to switch to the Java broker instead. I am
>>> currently using 0.12 but am testing out the 0.14 java broker (though
>>> the same problem I am having exists with 0.12). When I try to use the
>>> cqpid client with the Java broker it does not work. My python program
>>> spits out a ton of messages like "warning Connection
>>> [127.0.0.1:48782-localhost:5672] closed" and basically hangs...I have
>>> to force kill it. And on the server it outputs the following over and
>>> over again:
>>>
>>> 2012-02-08 22:22:53,592 INFO [IoReceiver - /127.0.0.1:33357]
>>> logging.Log4jMessageLogger (Log4jMessageLogger.java:72) -
>>> [con:458(/127.0.0.1:33357)] CON-1001 : Open : Protocol Version : 0-10
>>> 2012-02-08 22:22:53,592 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] AMQP.1 0-10
>>> 2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] AMQP.1 0-10
>>> 2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
>>> ConnectionStart(serverProperties={qpid.federation_tag=957f527c-dfa5-4192-8160-9f092b31b303},
>>> mechanisms=[AMQPLAIN, PLAIN, CRAM-MD5], locales=[en_US])
>>> 2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
>>> 2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
>>> ConnectionStartOk(clientProperties={qpid.client_pid=18119,
>>> qpid.client_ppid=28800, qpid.client_process=python,
>>> qpid.session_flow=1}, mechanism=, response=[B@1dacecf3, locale=en_US)
>>> 2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
>>> ConnectionTune(channelMax=256, maxFrameSize=65535, heartbeatMin=0,
>>> heartbeatMax=0)
>>> 2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
>>> 2012-02-08 22:22:53,595 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
>>> ConnectionTuneOk(channelMax=256, maxFrameSize=65535, heartbeat=0)
>>> 2012-02-08 22:22:53,595 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
>>> ConnectionOpen(virtualHost=, capabilities=[], insist=true)
>>> 2012-02-08 22:22:53,596 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
>>> ConnectionOpenOk(knownHosts=[])
>>> 2012-02-08 22:22:53,596 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
>>> 2012-02-08 22:22:53,597 INFO [IoReceiver - /127.0.0.1:33357]
>>> logging.Log4jMessageLogger (Log4jMessageLogger.java:72) -
>>> [con:458(/127.0.0.1:33357)] CON-1001 : Open : Client ID : null :
>>> Protocol Version : 0-10
>>> 2012-02-08 22:22:53,597 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=1
>>> SessionAttach(name=[B@64836727)
>>> 2012-02-08 22:22:53,597 DEBUG [IoReceiver - /127.0.0.1:33357]
>>> util.Logger (Logger.java:54) - connection closed: conn:5dfa490
>>>
>>> Any idea what might be wrong here? Is this a bug or am I potentially
>>> doing something wrong?
>>>
>>> Thanks,
>>>
>>> -Brandon
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Brandon Pedersen <bp...@gmail.com>.
On Fri, Feb 10, 2012 at 10:40 AM, Robbie Gemmell
<ro...@gmail.com> wrote:
> Hi Brandon,
>
> The python client is admitedly mostly used with the C++ broker
> currently, but there shouldnt be anything inherantly stopping its use
> with the Java broker given they both speak AMQP 0-10, and we would
> want to resolve it if there is. We do run the Python client tests and
> python based AMQP 0-10 broker tests against the Java broker on CI
> instances on a daily basis now (though my memory is fuzzy on if or how
> long we had before the 0.14 release initially branched ).
I just want to point out that I am using the C bindings in Python, not
the basic qpid.messaging Python library
> If you can possibly send the code you are having issue using (or a
> stripped down example based on it if its in any way sensitive), I will
> take a look if there is anything I can spot either in there or on the
> broker side while running it.
Here is a very stripped down example that produces the problem:
from cqpid import Connection
conn = Connection("localhost", username="admin", password="admin",
reconnect=True)
conn.open()
session = conn.session()
> With regards to the brokers log output, did you happen to turn on
> debug logging for analysis, or possibly somehow havent provided the
> default logging config we ship in the package? Almost none of that
> output should be displayed by default.
Yes, I used the debug.log4j.xml so I could see if there were any
problems and pasted it here since I thought it might help.
Thanks,
-Brandon
> Regards,
> Robbie
>
> On 10 February 2012 06:20, Brandon Pedersen <bp...@gmail.com> wrote:
>> Hi, I am currently using the C++ broker with the python cqpid client
>> and it is running smoothly. However, after reading through this
>> http://qpid.2158936.n2.nabble.com/DerbyDB-vs-BerkeleyDB-using-the-Java-Broker-tp7056640p7155540.html
>> I thought it would be best to switch to the Java broker instead. I am
>> currently using 0.12 but am testing out the 0.14 java broker (though
>> the same problem I am having exists with 0.12). When I try to use the
>> cqpid client with the Java broker it does not work. My python program
>> spits out a ton of messages like "warning Connection
>> [127.0.0.1:48782-localhost:5672] closed" and basically hangs...I have
>> to force kill it. And on the server it outputs the following over and
>> over again:
>>
>> 2012-02-08 22:22:53,592 INFO [IoReceiver - /127.0.0.1:33357]
>> logging.Log4jMessageLogger (Log4jMessageLogger.java:72) -
>> [con:458(/127.0.0.1:33357)] CON-1001 : Open : Protocol Version : 0-10
>> 2012-02-08 22:22:53,592 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] AMQP.1 0-10
>> 2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] AMQP.1 0-10
>> 2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
>> ConnectionStart(serverProperties={qpid.federation_tag=957f527c-dfa5-4192-8160-9f092b31b303},
>> mechanisms=[AMQPLAIN, PLAIN, CRAM-MD5], locales=[en_US])
>> 2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
>> 2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
>> ConnectionStartOk(clientProperties={qpid.client_pid=18119,
>> qpid.client_ppid=28800, qpid.client_process=python,
>> qpid.session_flow=1}, mechanism=, response=[B@1dacecf3, locale=en_US)
>> 2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
>> ConnectionTune(channelMax=256, maxFrameSize=65535, heartbeatMin=0,
>> heartbeatMax=0)
>> 2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
>> 2012-02-08 22:22:53,595 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
>> ConnectionTuneOk(channelMax=256, maxFrameSize=65535, heartbeat=0)
>> 2012-02-08 22:22:53,595 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
>> ConnectionOpen(virtualHost=, capabilities=[], insist=true)
>> 2012-02-08 22:22:53,596 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
>> ConnectionOpenOk(knownHosts=[])
>> 2012-02-08 22:22:53,596 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
>> 2012-02-08 22:22:53,597 INFO [IoReceiver - /127.0.0.1:33357]
>> logging.Log4jMessageLogger (Log4jMessageLogger.java:72) -
>> [con:458(/127.0.0.1:33357)] CON-1001 : Open : Client ID : null :
>> Protocol Version : 0-10
>> 2012-02-08 22:22:53,597 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=1
>> SessionAttach(name=[B@64836727)
>> 2012-02-08 22:22:53,597 DEBUG [IoReceiver - /127.0.0.1:33357]
>> util.Logger (Logger.java:54) - connection closed: conn:5dfa490
>>
>> Any idea what might be wrong here? Is this a bug or am I potentially
>> doing something wrong?
>>
>> Thanks,
>>
>> -Brandon
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Robbie Gemmell <ro...@gmail.com>.
Hi Brandon,
The python client is admitedly mostly used with the C++ broker
currently, but there shouldnt be anything inherantly stopping its use
with the Java broker given they both speak AMQP 0-10, and we would
want to resolve it if there is. We do run the Python client tests and
python based AMQP 0-10 broker tests against the Java broker on CI
instances on a daily basis now (though my memory is fuzzy on if or how
long we had before the 0.14 release initially branched ).
If you can possibly send the code you are having issue using (or a
stripped down example based on it if its in any way sensitive), I will
take a look if there is anything I can spot either in there or on the
broker side while running it.
With regards to the brokers log output, did you happen to turn on
debug logging for analysis, or possibly somehow havent provided the
default logging config we ship in the package? Almost none of that
output should be displayed by default.
Regards,
Robbie
On 10 February 2012 06:20, Brandon Pedersen <bp...@gmail.com> wrote:
> Hi, I am currently using the C++ broker with the python cqpid client
> and it is running smoothly. However, after reading through this
> http://qpid.2158936.n2.nabble.com/DerbyDB-vs-BerkeleyDB-using-the-Java-Broker-tp7056640p7155540.html
> I thought it would be best to switch to the Java broker instead. I am
> currently using 0.12 but am testing out the 0.14 java broker (though
> the same problem I am having exists with 0.12). When I try to use the
> cqpid client with the Java broker it does not work. My python program
> spits out a ton of messages like "warning Connection
> [127.0.0.1:48782-localhost:5672] closed" and basically hangs...I have
> to force kill it. And on the server it outputs the following over and
> over again:
>
> 2012-02-08 22:22:53,592 INFO [IoReceiver - /127.0.0.1:33357]
> logging.Log4jMessageLogger (Log4jMessageLogger.java:72) -
> [con:458(/127.0.0.1:33357)] CON-1001 : Open : Protocol Version : 0-10
> 2012-02-08 22:22:53,592 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] AMQP.1 0-10
> 2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] AMQP.1 0-10
> 2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
> ConnectionStart(serverProperties={qpid.federation_tag=957f527c-dfa5-4192-8160-9f092b31b303},
> mechanisms=[AMQPLAIN, PLAIN, CRAM-MD5], locales=[en_US])
> 2012-02-08 22:22:53,593 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
> 2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
> ConnectionStartOk(clientProperties={qpid.client_pid=18119,
> qpid.client_ppid=28800, qpid.client_process=python,
> qpid.session_flow=1}, mechanism=, response=[B@1dacecf3, locale=en_US)
> 2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
> ConnectionTune(channelMax=256, maxFrameSize=65535, heartbeatMin=0,
> heartbeatMax=0)
> 2012-02-08 22:22:53,594 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
> 2012-02-08 22:22:53,595 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
> ConnectionTuneOk(channelMax=256, maxFrameSize=65535, heartbeat=0)
> 2012-02-08 22:22:53,595 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=0
> ConnectionOpen(virtualHost=, capabilities=[], insist=true)
> 2012-02-08 22:22:53,596 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - SEND: [conn:5dfa490] ch=0
> ConnectionOpenOk(knownHosts=[])
> 2012-02-08 22:22:53,596 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - FLUSH: [conn:5dfa490]
> 2012-02-08 22:22:53,597 INFO [IoReceiver - /127.0.0.1:33357]
> logging.Log4jMessageLogger (Log4jMessageLogger.java:72) -
> [con:458(/127.0.0.1:33357)] CON-1001 : Open : Client ID : null :
> Protocol Version : 0-10
> 2012-02-08 22:22:53,597 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - RECV: [conn:5dfa490] ch=1
> SessionAttach(name=[B@64836727)
> 2012-02-08 22:22:53,597 DEBUG [IoReceiver - /127.0.0.1:33357]
> util.Logger (Logger.java:54) - connection closed: conn:5dfa490
>
> Any idea what might be wrong here? Is this a bug or am I potentially
> doing something wrong?
>
> Thanks,
>
> -Brandon
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Robbie Gemmell <ro...@gmail.com>.
On 14 February 2012 06:44, Brandon Pedersen <bp...@gmail.com> wrote:
> On Mon, Feb 13, 2012 at 3:20 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
>> Thanks to Gordon for stepping in here and helping out with the C++
>> client/python bindings side of things, I had admittedly missed that
>> point and wouldn't have had much of a clue on that front :)
>>
>> On the below, it would appear that the commands you are using are
>> resulting in the client trying to declare an existing exchange (e.g.
>> amq.topic) with a different exchange type than it exists with already
>> (i.e not topic). I'm rather entrenched in JMS land and dont have that
>> good an idea of the Address Strings, but I guess I would maybe be
>> taking a look at the arguments you are feeding to Spout in that case.
>
> The format of the address string is correct (supposedly). If I use the
> same address with the python spout example, it works.
>
>> I have updated the message of the session execution exception the Java
>> broker emits when this occurs to list the exchange name and the two
>> conflicting exchange types in question. I forced an early build of the
>> nightly trunk Java release job, so you should now be able to get the
>> updated broker artifact here if you dont want to build your own:
>> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release/lastSuccessfulBuild/artifact/trunk/qpid/java/broker/release/
>
Updated again to log the types string name...knew I should have tried it ;)
> Thanks. I ran both the C++ and python spout examples again. The python
> spout works while the C++ one fails. It appears as though the C++
> client is running some sort of ExchangeBound query and the server
> responds that the queue and key is not found so it tries to create the
> exchange. The python spout on the other hand does an ExchangeQuery and
> it find the exchange (so it doesn't try to re-declare it).
>
My understanding of the Address syntax implementation is that the
clients query the broker to determine if a node is a queue or a topic
(implemented via an exchange and routing key combination), which is
what the python version below seems to be doing with its ExchangeQuery
to see if the test.topic exchange exists folloed by a QueueQuery to
see if the test.topic queue exists, with the broker replying that the
exchange does and the queue doesnt. The client then proceeded to
simply use the exchange and send the message, which wasnt delivered
because there was no queue bound to the exchange for the routing key
used.
The C++ client on the other hand is asking the broker via a
ExchangeBound command if there is a queue called test.topic which
happens to bound to an exchange called test.topic, and the broker is
replying that there isnt because there is no such queue. It didnt
indicate the exchange didnt exist, and thus implicitly confimed that
it did. The client then decided to re-declare the exchange anyway
despite this, and in doing so seemed to neglect to send any exchange
type (or possibly the empty string), which the java broker interpreted
as an attempt to redeclare it with a different exchange type as it
doesnt match the existing one.
I cant really comment about the C++ client behaviour further than that
as I dont have any experience with it. Gordon, can you shed any light?
Robbie
> Here is the output with the C++ spout:
>
> 2012-02-13 21:48:14,072 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=0
> ConnectionOpenOk(knownHosts=[])
> 2012-02-13 21:48:14,072 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,073 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
> SessionAttach(name=[B@47d978ea)
> 2012-02-13 21:48:14,073 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionAttached(name=[B@47d978ea)
> 2012-02-13 21:48:14,074 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,074 INFO [IoReceiver - /127.0.0.1:37964]
> logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
> [con:2(null@/127.0.0.1:37964/traacerlink)/ch:1] CHN-1001 : Create
> 2012-02-13 21:48:14,074 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
> SessionRequestTimeout(timeout=0)
> 2012-02-13 21:48:14,075 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionTimeout(timeout=0)
> 2012-02-13 21:48:14,075 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
> SessionCommandPoint(commandId=0, commandOffset=0)
> 2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1 [S]
> ExecutionSync()
> 2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - ID: [1] 0
> 2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" synced to 0
> 2012-02-13 21:48:14,077 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" processed([0,0]) 0 -1
> 2012-02-13 21:48:14,077 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - {}
> 2012-02-13 21:48:14,077 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionCompleted(commands={[0, 0]})
> 2012-02-13 21:48:14,078 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,078 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionCompleted(commands={[0, 0]})
> 2012-02-13 21:48:14,078 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,079 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1 [S]
> ExchangeBound(exchange=test.topic, queue=test.topic, bindingKey=,
> arguments={})
> 2012-02-13 21:48:14,079 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - ID: [1] 1
> 2012-02-13 21:48:14,079 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionCommandPoint(commandId=0, commandOffset=0)
> 2012-02-13 21:48:14,080 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,080 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1 id=0
> ExecutionResult(commandId=1,
> value=ExchangeBoundResult(queueNotFound=true, keyNotMatched=true))
> 2012-02-13 21:48:14,080 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,081 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionFlush(completed=true)
> 2012-02-13 21:48:14,081 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,081 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" processed([1,1]) 0 0
> 2012-02-13 21:48:14,082 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - {[0, 0]}
> 2012-02-13 21:48:14,082 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionCompleted(commands={[0, 1]})
> 2012-02-13 21:48:14,082 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1 [S]
> ExchangeDeclare(exchange=test.topic, type=, alternateExchange=,
> passive=true, arguments={})
> 2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - ID: [1] 2
> 2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1 id=1
> ExecutionException(errorCode=NOT_ALLOWED, commandId=2,
> description=Attempt to redeclare exchange: test.topic of type
> org.apache.qpid.server.exchange.TopicExchange$1@3fcac3fa to .)
> 2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,084 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - Closing
> [ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21"] in state [OPEN]
> 2012-02-13 21:48:14,084 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionRequestTimeout(timeout=0)
> 2012-02-13 21:48:14,084 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,085 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionDetach(name=[B@262f4813)
> 2012-02-13 21:48:14,085 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,086 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" processed([2,2]) 1 1
> 2012-02-13 21:48:14,086 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - {[0, 1]}
> 2012-02-13 21:48:14,086 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
> SessionCompleted(commands=[0, 0], timelyReply=true)
> 2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" complete(0, 0)
> 2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" commands remaining: 2
> 2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionKnownCompleted(commands=[0, 0])
> 2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,088 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=0
> ConnectionClose(replyCode=NORMAL, replyText=OK)
>
> And the broker outputs the following with the python spout example:
>
> 2012-02-13 21:48:05,825 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> ConnectionOpenOk(knownHosts=[])
> 2012-02-13 21:48:05,825 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,827 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
> SessionAttach(name=[B@6d352447)
> 2012-02-13 21:48:05,827 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionAttached(name=[B@6d352447)
> 2012-02-13 21:48:05,828 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,828 INFO [IoReceiver - /127.0.0.1:37963]
> logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
> [con:1(null@/127.0.0.1:37963/traacerlink)/ch:0] CHN-1001 : Create
> 2012-02-13 21:48:05,829 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
> SessionCommandPoint(commandId=0, commandOffset=0)
> 2012-02-13 21:48:05,829 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0 [S]
> ExchangeQuery(name=test.topic)
> 2012-02-13 21:48:05,829 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - ID: [0] 0
> 2012-02-13 21:48:05,830 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionCommandPoint(commandId=0, commandOffset=0)
> 2012-02-13 21:48:05,831 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,831 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0 id=0
> ExecutionResult(commandId=0, value=ExchangeQueryResult(type=topic))
> 2012-02-13 21:48:05,831 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionFlush(completed=true)
> 2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) -
> ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" processed([0,0]) -1 -1
> 2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - {}
> 2012-02-13 21:48:05,833 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionCompleted(commands={[0, 0]})
> 2012-02-13 21:48:05,833 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,834 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0 [S]
> QueueQuery(queue=test.topic)
> 2012-02-13 21:48:05,834 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - ID: [0] 1
> 2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0 id=1
> ExecutionResult(commandId=1, value=QueueQueryResult())
> 2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) -
> ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" processed([1,1]) 0 0
> 2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - {[0, 0]}
> 2012-02-13 21:48:05,836 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionCompleted(commands={[0, 1]})
> 2012-02-13 21:48:05,836 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,836 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
> SessionCompleted(commands=[0, 0])
> 2012-02-13 21:48:05,837 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) -
> ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" complete(0, 0)
> 2012-02-13 21:48:05,837 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) -
> ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" commands remaining: 2
> 2012-02-13 21:48:05,840 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0 [S]
> MessageTransfer(destination=test.topic)
> DeliveryProperties(routingKey=test)
> MessageProperties(applicationHeaders={qpid.subject=test,
> spout-id=d9e8264e-887e-40b4-8215-663ca774123c:0})
> 2012-02-13 21:48:05,840 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - ID: [0] 2
> 2012-02-13 21:48:05,843 INFO [IoReceiver - /127.0.0.1:37963]
> exchange.TopicExchange (TopicExchange.java:248) - Message routing key:
> test No routes.
> 2012-02-13 21:48:05,844 INFO [IoReceiver - /127.0.0.1:37963]
> logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
> [con:1(null@/127.0.0.1:37963/traacerlink)/ch:0] EXH-1003 : Discarded
> Message : Name: test.topic Routing Key: test
> 2012-02-13 21:48:05,845 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) -
> ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" processed([2,2]) 1 1
> 2012-02-13 21:48:05,845 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - {[0, 1]}
> 2012-02-13 21:48:05,846 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionCompleted(commands={[0, 2]})
> 2012-02-13 21:48:05,846 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,847 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
> SessionDetach(name=[B@58ee21f5)
> 2012-02-13 21:48:05,848 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionDetached(name=[B@58ee21f5, code=NORMAL)
> 2012-02-13 21:48:05,849 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,849 INFO [IoReceiver - /127.0.0.1:37963]
> logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
> [con:1(null@/127.0.0.1:37963/traacerlink)/ch:0]
> [con:1(null@/127.0.0.1:37963/traacerlink)/ch:0] CHN-1003 : Close
> 2012-02-13 21:48:05,850 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
> ConnectionClose(replyCode=NORMAL)
>
> Thanks,
>
> -Brandon
>
>
>> Regards,
>> Robbie
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Robbie Gemmell <ro...@gmail.com>.
On 14 February 2012 15:27, Gordon Sim <gs...@redhat.com> wrote:
> On 02/14/2012 03:06 PM, Gordon Sim wrote:
>>
>> The declare sent has the passive flag set to true.
>>
>> I would argue that in the spirit of that flag, it should be perfectly
>> valid not to specify the type since we are simply asserting that it
>> exists, not trying to create it if it does not. I couldn't find anything
>> one way or the other in the specification however. (Attached patch to
>> relax the check in the java broker along these lines for consideration).
>
>
> Doh! Patch corrected, I am suitably mortified at my stupid mistake...
>
> Once I tested against the right broker I discovered that I wasn't even
> fixing the correct codepath. The corrected patch makes the change to bothe
> 0-8/0-9 and 0-10, but obviously the 0-10 case is the relevant one in this
> case.
>
Woops, I had missed the passive flag:P
The patch seems reasonable, I'll apply it when I'm home later.
Robbie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Brandon Pedersen <bp...@gmail.com>.
On Tue, Feb 14, 2012 at 8:27 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 02/14/2012 03:06 PM, Gordon Sim wrote:
>>
>> The declare sent has the passive flag set to true.
>>
>> I would argue that in the spirit of that flag, it should be perfectly
>> valid not to specify the type since we are simply asserting that it
>> exists, not trying to create it if it does not. I couldn't find anything
>> one way or the other in the specification however. (Attached patch to
>> relax the check in the java broker along these lines for consideration).
>
>
> Doh! Patch corrected, I am suitably mortified at my stupid mistake...
>
> Once I tested against the right broker I discovered that I wasn't even
> fixing the correct codepath. The corrected patch makes the change to bothe
> 0-8/0-9 and 0-10, but obviously the 0-10 case is the relevant one in this
> case.
You guys are awesome! Applied the patch to 0.14 and it works (both in
spout and in my python cqpid program). Thanks for all your help!
-Brandon
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Gordon Sim <gs...@redhat.com>.
On 02/14/2012 03:06 PM, Gordon Sim wrote:
> The declare sent has the passive flag set to true.
>
> I would argue that in the spirit of that flag, it should be perfectly
> valid not to specify the type since we are simply asserting that it
> exists, not trying to create it if it does not. I couldn't find anything
> one way or the other in the specification however. (Attached patch to
> relax the check in the java broker along these lines for consideration).
Doh! Patch corrected, I am suitably mortified at my stupid mistake...
Once I tested against the right broker I discovered that I wasn't even
fixing the correct codepath. The corrected patch makes the change to
bothe 0-8/0-9 and 0-10, but obviously the 0-10 case is the relevant one
in this case.
Re: problems using cqpid with java broker
Posted by Gordon Sim <gs...@redhat.com>.
On 02/14/2012 11:34 AM, Robbie Gemmell wrote:
> The C++ client on the other hand is asking the broker via a
> ExchangeBound command if there is a queue called test.topic which
> happens to bound to an exchange called test.topic, and the broker is
> replying that there isnt because there is no such queue. It didnt
> indicate the exchange didnt exist, and thus implicitly confimed that
> it did. The client then decided to re-declare the exchange anyway
> despite this, and in doing so seemed to neglect to send any exchange
> type (or possibly the empty string), which the java broker interpreted
> as an attempt to redeclare it with a different exchange type as it
> doesnt match the existing one.
The declare sent has the passive flag set to true.
I would argue that in the spirit of that flag, it should be perfectly
valid not to specify the type since we are simply asserting that it
exists, not trying to create it if it does not. I couldn't find anything
one way or the other in the specification however. (Attached patch to
relax the check in the java broker along these lines for consideration).
One could of course also question the need to do the declare. In the
case of a queue it is useful to do so as you don't get any error
otherwise. Though the resolution does determine whether a queue or
exchange of the specified name exists, that phase can be skipped by
explicitly specifying the type. (And of course the declaration in any
case does not prevent the node in question being deleted while in use).
Re: problems using cqpid with java broker
Posted by Robbie Gemmell <ro...@gmail.com>.
On 14 February 2012 06:44, Brandon Pedersen <bp...@gmail.com> wrote:
> On Mon, Feb 13, 2012 at 3:20 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
>> Thanks to Gordon for stepping in here and helping out with the C++
>> client/python bindings side of things, I had admittedly missed that
>> point and wouldn't have had much of a clue on that front :)
>>
>> On the below, it would appear that the commands you are using are
>> resulting in the client trying to declare an existing exchange (e.g.
>> amq.topic) with a different exchange type than it exists with already
>> (i.e not topic). I'm rather entrenched in JMS land and dont have that
>> good an idea of the Address Strings, but I guess I would maybe be
>> taking a look at the arguments you are feeding to Spout in that case.
>
> The format of the address string is correct (supposedly). If I use the
> same address with the python spout example, it works.
>
>> I have updated the message of the session execution exception the Java
>> broker emits when this occurs to list the exchange name and the two
>> conflicting exchange types in question. I forced an early build of the
>> nightly trunk Java release job, so you should now be able to get the
>> updated broker artifact here if you dont want to build your own:
>> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release/lastSuccessfulBuild/artifact/trunk/qpid/java/broker/release/
>
Updated again to log the types string name...knew I should have tried it ;)
> Thanks. I ran both the C++ and python spout examples again. The python
> spout works while the C++ one fails. It appears as though the C++
> client is running some sort of ExchangeBound query and the server
> responds that the queue and key is not found so it tries to create the
> exchange. The python spout on the other hand does an ExchangeQuery and
> it find the exchange (so it doesn't try to re-declare it).
>
My understanding of the Address syntax implementation is that the
clients query the broker to determine if a node is a queue or a topic
(implemented via an exchange and routing key combination), which is
what the python version below seems to be doing with its ExchangeQuery
to see if the test.topic exchange exists folloed by a QueueQuery to
see if the test.topic queue exists, with the broker replying that the
exchange does and the queue doesnt. The client then proceeded to
simply use the exchange and send the message, which wasnt delivered
because there was no queue bound to the exchange for the routing key
used.
The C++ client on the other hand is asking the broker via a
ExchangeBound command if there is a queue called test.topic which
happens to bound to an exchange called test.topic, and the broker is
replying that there isnt because there is no such queue. It didnt
indicate the exchange didnt exist, and thus implicitly confimed that
it did. The client then decided to re-declare the exchange anyway
despite this, and in doing so seemed to neglect to send any exchange
type (or possibly the empty string), which the java broker interpreted
as an attempt to redeclare it with a different exchange type as it
doesnt match the existing one.
I cant really comment about the C++ client behaviour further than that
as I dont have any experience with it. Gordon, can you shed any light?
Robbie
> Here is the output with the C++ spout:
>
> 2012-02-13 21:48:14,072 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=0
> ConnectionOpenOk(knownHosts=[])
> 2012-02-13 21:48:14,072 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,073 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
> SessionAttach(name=[B@47d978ea)
> 2012-02-13 21:48:14,073 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionAttached(name=[B@47d978ea)
> 2012-02-13 21:48:14,074 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,074 INFO [IoReceiver - /127.0.0.1:37964]
> logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
> [con:2(null@/127.0.0.1:37964/traacerlink)/ch:1] CHN-1001 : Create
> 2012-02-13 21:48:14,074 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
> SessionRequestTimeout(timeout=0)
> 2012-02-13 21:48:14,075 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionTimeout(timeout=0)
> 2012-02-13 21:48:14,075 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
> SessionCommandPoint(commandId=0, commandOffset=0)
> 2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1 [S]
> ExecutionSync()
> 2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - ID: [1] 0
> 2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" synced to 0
> 2012-02-13 21:48:14,077 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" processed([0,0]) 0 -1
> 2012-02-13 21:48:14,077 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - {}
> 2012-02-13 21:48:14,077 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionCompleted(commands={[0, 0]})
> 2012-02-13 21:48:14,078 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,078 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionCompleted(commands={[0, 0]})
> 2012-02-13 21:48:14,078 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,079 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1 [S]
> ExchangeBound(exchange=test.topic, queue=test.topic, bindingKey=,
> arguments={})
> 2012-02-13 21:48:14,079 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - ID: [1] 1
> 2012-02-13 21:48:14,079 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionCommandPoint(commandId=0, commandOffset=0)
> 2012-02-13 21:48:14,080 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,080 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1 id=0
> ExecutionResult(commandId=1,
> value=ExchangeBoundResult(queueNotFound=true, keyNotMatched=true))
> 2012-02-13 21:48:14,080 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,081 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionFlush(completed=true)
> 2012-02-13 21:48:14,081 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,081 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" processed([1,1]) 0 0
> 2012-02-13 21:48:14,082 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - {[0, 0]}
> 2012-02-13 21:48:14,082 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionCompleted(commands={[0, 1]})
> 2012-02-13 21:48:14,082 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1 [S]
> ExchangeDeclare(exchange=test.topic, type=, alternateExchange=,
> passive=true, arguments={})
> 2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - ID: [1] 2
> 2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1 id=1
> ExecutionException(errorCode=NOT_ALLOWED, commandId=2,
> description=Attempt to redeclare exchange: test.topic of type
> org.apache.qpid.server.exchange.TopicExchange$1@3fcac3fa to .)
> 2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,084 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - Closing
> [ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21"] in state [OPEN]
> 2012-02-13 21:48:14,084 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionRequestTimeout(timeout=0)
> 2012-02-13 21:48:14,084 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,085 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionDetach(name=[B@262f4813)
> 2012-02-13 21:48:14,085 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,086 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" processed([2,2]) 1 1
> 2012-02-13 21:48:14,086 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - {[0, 1]}
> 2012-02-13 21:48:14,086 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
> SessionCompleted(commands=[0, 0], timelyReply=true)
> 2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" complete(0, 0)
> 2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) -
> ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" commands remaining: 2
> 2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
> SessionKnownCompleted(commands=[0, 0])
> 2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
> 2012-02-13 21:48:14,088 DEBUG [IoReceiver - /127.0.0.1:37964]
> util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=0
> ConnectionClose(replyCode=NORMAL, replyText=OK)
>
> And the broker outputs the following with the python spout example:
>
> 2012-02-13 21:48:05,825 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> ConnectionOpenOk(knownHosts=[])
> 2012-02-13 21:48:05,825 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,827 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
> SessionAttach(name=[B@6d352447)
> 2012-02-13 21:48:05,827 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionAttached(name=[B@6d352447)
> 2012-02-13 21:48:05,828 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,828 INFO [IoReceiver - /127.0.0.1:37963]
> logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
> [con:1(null@/127.0.0.1:37963/traacerlink)/ch:0] CHN-1001 : Create
> 2012-02-13 21:48:05,829 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
> SessionCommandPoint(commandId=0, commandOffset=0)
> 2012-02-13 21:48:05,829 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0 [S]
> ExchangeQuery(name=test.topic)
> 2012-02-13 21:48:05,829 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - ID: [0] 0
> 2012-02-13 21:48:05,830 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionCommandPoint(commandId=0, commandOffset=0)
> 2012-02-13 21:48:05,831 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,831 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0 id=0
> ExecutionResult(commandId=0, value=ExchangeQueryResult(type=topic))
> 2012-02-13 21:48:05,831 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionFlush(completed=true)
> 2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) -
> ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" processed([0,0]) -1 -1
> 2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - {}
> 2012-02-13 21:48:05,833 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionCompleted(commands={[0, 0]})
> 2012-02-13 21:48:05,833 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,834 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0 [S]
> QueueQuery(queue=test.topic)
> 2012-02-13 21:48:05,834 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - ID: [0] 1
> 2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0 id=1
> ExecutionResult(commandId=1, value=QueueQueryResult())
> 2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) -
> ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" processed([1,1]) 0 0
> 2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - {[0, 0]}
> 2012-02-13 21:48:05,836 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionCompleted(commands={[0, 1]})
> 2012-02-13 21:48:05,836 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,836 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
> SessionCompleted(commands=[0, 0])
> 2012-02-13 21:48:05,837 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) -
> ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" complete(0, 0)
> 2012-02-13 21:48:05,837 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) -
> ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" commands remaining: 2
> 2012-02-13 21:48:05,840 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0 [S]
> MessageTransfer(destination=test.topic)
> DeliveryProperties(routingKey=test)
> MessageProperties(applicationHeaders={qpid.subject=test,
> spout-id=d9e8264e-887e-40b4-8215-663ca774123c:0})
> 2012-02-13 21:48:05,840 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - ID: [0] 2
> 2012-02-13 21:48:05,843 INFO [IoReceiver - /127.0.0.1:37963]
> exchange.TopicExchange (TopicExchange.java:248) - Message routing key:
> test No routes.
> 2012-02-13 21:48:05,844 INFO [IoReceiver - /127.0.0.1:37963]
> logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
> [con:1(null@/127.0.0.1:37963/traacerlink)/ch:0] EXH-1003 : Discarded
> Message : Name: test.topic Routing Key: test
> 2012-02-13 21:48:05,845 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) -
> ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" processed([2,2]) 1 1
> 2012-02-13 21:48:05,845 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - {[0, 1]}
> 2012-02-13 21:48:05,846 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionCompleted(commands={[0, 2]})
> 2012-02-13 21:48:05,846 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,847 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
> SessionDetach(name=[B@58ee21f5)
> 2012-02-13 21:48:05,848 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
> SessionDetached(name=[B@58ee21f5, code=NORMAL)
> 2012-02-13 21:48:05,849 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
> 2012-02-13 21:48:05,849 INFO [IoReceiver - /127.0.0.1:37963]
> logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
> [con:1(null@/127.0.0.1:37963/traacerlink)/ch:0]
> [con:1(null@/127.0.0.1:37963/traacerlink)/ch:0] CHN-1003 : Close
> 2012-02-13 21:48:05,850 DEBUG [IoReceiver - /127.0.0.1:37963]
> util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
> ConnectionClose(replyCode=NORMAL)
>
> Thanks,
>
> -Brandon
>
>
>> Regards,
>> Robbie
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Brandon Pedersen <bp...@gmail.com>.
On Mon, Feb 13, 2012 at 3:20 PM, Robbie Gemmell
<ro...@gmail.com> wrote:
> Thanks to Gordon for stepping in here and helping out with the C++
> client/python bindings side of things, I had admittedly missed that
> point and wouldn't have had much of a clue on that front :)
>
> On the below, it would appear that the commands you are using are
> resulting in the client trying to declare an existing exchange (e.g.
> amq.topic) with a different exchange type than it exists with already
> (i.e not topic). I'm rather entrenched in JMS land and dont have that
> good an idea of the Address Strings, but I guess I would maybe be
> taking a look at the arguments you are feeding to Spout in that case.
The format of the address string is correct (supposedly). If I use the
same address with the python spout example, it works.
> I have updated the message of the session execution exception the Java
> broker emits when this occurs to list the exchange name and the two
> conflicting exchange types in question. I forced an early build of the
> nightly trunk Java release job, so you should now be able to get the
> updated broker artifact here if you dont want to build your own:
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release/lastSuccessfulBuild/artifact/trunk/qpid/java/broker/release/
Thanks. I ran both the C++ and python spout examples again. The python
spout works while the C++ one fails. It appears as though the C++
client is running some sort of ExchangeBound query and the server
responds that the queue and key is not found so it tries to create the
exchange. The python spout on the other hand does an ExchangeQuery and
it find the exchange (so it doesn't try to re-declare it).
Here is the output with the C++ spout:
2012-02-13 21:48:14,072 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=0
ConnectionOpenOk(knownHosts=[])
2012-02-13 21:48:14,072 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,073 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
SessionAttach(name=[B@47d978ea)
2012-02-13 21:48:14,073 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
SessionAttached(name=[B@47d978ea)
2012-02-13 21:48:14,074 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,074 INFO [IoReceiver - /127.0.0.1:37964]
logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
[con:2(null@/127.0.0.1:37964/traacerlink)/ch:1] CHN-1001 : Create
2012-02-13 21:48:14,074 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
SessionRequestTimeout(timeout=0)
2012-02-13 21:48:14,075 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
SessionTimeout(timeout=0)
2012-02-13 21:48:14,075 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
SessionCommandPoint(commandId=0, commandOffset=0)
2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1 [S]
ExecutionSync()
2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - ID: [1] 0
2012-02-13 21:48:14,076 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) -
ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" synced to 0
2012-02-13 21:48:14,077 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) -
ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" processed([0,0]) 0 -1
2012-02-13 21:48:14,077 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - {}
2012-02-13 21:48:14,077 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
SessionCompleted(commands={[0, 0]})
2012-02-13 21:48:14,078 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,078 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
SessionCompleted(commands={[0, 0]})
2012-02-13 21:48:14,078 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,079 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1 [S]
ExchangeBound(exchange=test.topic, queue=test.topic, bindingKey=,
arguments={})
2012-02-13 21:48:14,079 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - ID: [1] 1
2012-02-13 21:48:14,079 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
SessionCommandPoint(commandId=0, commandOffset=0)
2012-02-13 21:48:14,080 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,080 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1 id=0
ExecutionResult(commandId=1,
value=ExchangeBoundResult(queueNotFound=true, keyNotMatched=true))
2012-02-13 21:48:14,080 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,081 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
SessionFlush(completed=true)
2012-02-13 21:48:14,081 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,081 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) -
ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" processed([1,1]) 0 0
2012-02-13 21:48:14,082 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - {[0, 0]}
2012-02-13 21:48:14,082 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
SessionCompleted(commands={[0, 1]})
2012-02-13 21:48:14,082 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1 [S]
ExchangeDeclare(exchange=test.topic, type=, alternateExchange=,
passive=true, arguments={})
2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - ID: [1] 2
2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1 id=1
ExecutionException(errorCode=NOT_ALLOWED, commandId=2,
description=Attempt to redeclare exchange: test.topic of type
org.apache.qpid.server.exchange.TopicExchange$1@3fcac3fa to .)
2012-02-13 21:48:14,083 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,084 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - Closing
[ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21"] in state [OPEN]
2012-02-13 21:48:14,084 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
SessionRequestTimeout(timeout=0)
2012-02-13 21:48:14,084 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,085 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
SessionDetach(name=[B@262f4813)
2012-02-13 21:48:14,085 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,086 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) -
ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" processed([2,2]) 1 1
2012-02-13 21:48:14,086 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - {[0, 1]}
2012-02-13 21:48:14,086 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=1
SessionCompleted(commands=[0, 0], timelyReply=true)
2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) -
ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" complete(0, 0)
2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) -
ssn:"5e1ce183-f778-4e2b-8177-90fdbf617a21" commands remaining: 2
2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - SEND: [conn:4d811e2c] ch=1
SessionKnownCompleted(commands=[0, 0])
2012-02-13 21:48:14,087 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - FLUSH: [conn:4d811e2c]
2012-02-13 21:48:14,088 DEBUG [IoReceiver - /127.0.0.1:37964]
util.Logger (Logger.java:54) - RECV: [conn:4d811e2c] ch=0
ConnectionClose(replyCode=NORMAL, replyText=OK)
And the broker outputs the following with the python spout example:
2012-02-13 21:48:05,825 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
ConnectionOpenOk(knownHosts=[])
2012-02-13 21:48:05,825 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
2012-02-13 21:48:05,827 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
SessionAttach(name=[B@6d352447)
2012-02-13 21:48:05,827 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
SessionAttached(name=[B@6d352447)
2012-02-13 21:48:05,828 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
2012-02-13 21:48:05,828 INFO [IoReceiver - /127.0.0.1:37963]
logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
[con:1(null@/127.0.0.1:37963/traacerlink)/ch:0] CHN-1001 : Create
2012-02-13 21:48:05,829 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
SessionCommandPoint(commandId=0, commandOffset=0)
2012-02-13 21:48:05,829 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0 [S]
ExchangeQuery(name=test.topic)
2012-02-13 21:48:05,829 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - ID: [0] 0
2012-02-13 21:48:05,830 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
SessionCommandPoint(commandId=0, commandOffset=0)
2012-02-13 21:48:05,831 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
2012-02-13 21:48:05,831 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0 id=0
ExecutionResult(commandId=0, value=ExchangeQueryResult(type=topic))
2012-02-13 21:48:05,831 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
SessionFlush(completed=true)
2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) -
ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" processed([0,0]) -1 -1
2012-02-13 21:48:05,832 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - {}
2012-02-13 21:48:05,833 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
SessionCompleted(commands={[0, 0]})
2012-02-13 21:48:05,833 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
2012-02-13 21:48:05,834 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0 [S]
QueueQuery(queue=test.topic)
2012-02-13 21:48:05,834 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - ID: [0] 1
2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0 id=1
ExecutionResult(commandId=1, value=QueueQueryResult())
2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) -
ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" processed([1,1]) 0 0
2012-02-13 21:48:05,835 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - {[0, 0]}
2012-02-13 21:48:05,836 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
SessionCompleted(commands={[0, 1]})
2012-02-13 21:48:05,836 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
2012-02-13 21:48:05,836 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
SessionCompleted(commands=[0, 0])
2012-02-13 21:48:05,837 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) -
ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" complete(0, 0)
2012-02-13 21:48:05,837 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) -
ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" commands remaining: 2
2012-02-13 21:48:05,840 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0 [S]
MessageTransfer(destination=test.topic)
DeliveryProperties(routingKey=test)
MessageProperties(applicationHeaders={qpid.subject=test,
spout-id=d9e8264e-887e-40b4-8215-663ca774123c:0})
2012-02-13 21:48:05,840 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - ID: [0] 2
2012-02-13 21:48:05,843 INFO [IoReceiver - /127.0.0.1:37963]
exchange.TopicExchange (TopicExchange.java:248) - Message routing key:
test No routes.
2012-02-13 21:48:05,844 INFO [IoReceiver - /127.0.0.1:37963]
logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
[con:1(null@/127.0.0.1:37963/traacerlink)/ch:0] EXH-1003 : Discarded
Message : Name: test.topic Routing Key: test
2012-02-13 21:48:05,845 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) -
ssn:"e66d69f1-15dd-4b67-9af1-779bdf46a806:0" processed([2,2]) 1 1
2012-02-13 21:48:05,845 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - {[0, 1]}
2012-02-13 21:48:05,846 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
SessionCompleted(commands={[0, 2]})
2012-02-13 21:48:05,846 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
2012-02-13 21:48:05,847 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
SessionDetach(name=[B@58ee21f5)
2012-02-13 21:48:05,848 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - SEND: [conn:28294f62] ch=0
SessionDetached(name=[B@58ee21f5, code=NORMAL)
2012-02-13 21:48:05,849 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - FLUSH: [conn:28294f62]
2012-02-13 21:48:05,849 INFO [IoReceiver - /127.0.0.1:37963]
logging.Log4jMessageLogger (Log4jMessageLogger.java:73) -
[con:1(null@/127.0.0.1:37963/traacerlink)/ch:0]
[con:1(null@/127.0.0.1:37963/traacerlink)/ch:0] CHN-1003 : Close
2012-02-13 21:48:05,850 DEBUG [IoReceiver - /127.0.0.1:37963]
util.Logger (Logger.java:54) - RECV: [conn:28294f62] ch=0
ConnectionClose(replyCode=NORMAL)
Thanks,
-Brandon
> Regards,
> Robbie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Robbie Gemmell <ro...@gmail.com>.
Thanks to Gordon for stepping in here and helping out with the C++
client/python bindings side of things, I had admittedly missed that
point and wouldn't have had much of a clue on that front :)
On the below, it would appear that the commands you are using are
resulting in the client trying to declare an existing exchange (e.g.
amq.topic) with a different exchange type than it exists with already
(i.e not topic). I'm rather entrenched in JMS land and dont have that
good an idea of the Address Strings, but I guess I would maybe be
taking a look at the arguments you are feeding to Spout in that case.
I have updated the message of the session execution exception the Java
broker emits when this occurs to list the exchange name and the two
conflicting exchange types in question. I forced an early build of the
nightly trunk Java release job, so you should now be able to get the
updated broker artifact here if you dont want to build your own:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release/lastSuccessfulBuild/artifact/trunk/qpid/java/broker/release/
Regards,
Robbie
On 13 February 2012 19:29, Brandon Pedersen <bp...@gmail.com> wrote:
> On Mon, Feb 13, 2012 at 11:35 AM, Gordon Sim <gs...@redhat.com> wrote:
>> try username/password@localhost as the broker
>
> whoops, yeah, forgot the syntax of the spout command :) it is working
> now...except I still have one problem, I cannot create a sender to a
> topic exchange...the spout program works fine for a direct
> queue/exchange, but when I try to use a topic exchange it tells me
> "not-allowed: Cannot redeclare with a different exchange type" (and I
> get this same error message now from my python cqpid code).
>
> Here is the command and output I am getting with spout:
> $ ./spout -b admin/admin@localhost -c 1 amq.topic/test
> 2012-02-13 12:25:24 warning Exception received from broker:
> not-allowed: Cannot redeclare with a different exchange type [caused
> by 2 \x00:\x00]
> not-allowed: Cannot redeclare with a different exchange type
>
> And my python cqpid stuff is just opening the connection and a session
> and then doing 'sender = session.sender("test.topic")' and gets the
> same error.
>
> Thanks for your help,
>
> -Brandon
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Brandon Pedersen <bp...@gmail.com>.
On Mon, Feb 13, 2012 at 11:35 AM, Gordon Sim <gs...@redhat.com> wrote:
> try username/password@localhost as the broker
whoops, yeah, forgot the syntax of the spout command :) it is working
now...except I still have one problem, I cannot create a sender to a
topic exchange...the spout program works fine for a direct
queue/exchange, but when I try to use a topic exchange it tells me
"not-allowed: Cannot redeclare with a different exchange type" (and I
get this same error message now from my python cqpid code).
Here is the command and output I am getting with spout:
$ ./spout -b admin/admin@localhost -c 1 amq.topic/test
2012-02-13 12:25:24 warning Exception received from broker:
not-allowed: Cannot redeclare with a different exchange type [caused
by 2 \x00:\x00]
not-allowed: Cannot redeclare with a different exchange type
And my python cqpid stuff is just opening the connection and a session
and then doing 'sender = session.sender("test.topic")' and gets the
same error.
Thanks for your help,
-Brandon
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Gordon Sim <gs...@redhat.com>.
On 02/13/2012 06:12 PM, Brandon Pedersen wrote:
> On Sun, Feb 12, 2012 at 6:19 AM, Gordon Sim<gs...@redhat.com> wrote:
>> On 02/11/2012 10:07 PM, Brandon Pedersen wrote:
>>>
>>> On Sat, Feb 11, 2012 at 11:05 AM, Gordon Sim<gs...@redhat.com> wrote:
>>>>
>>>> On 02/10/2012 11:38 PM, Brandon Pedersen wrote:
>>>> Try export QPID_LOG_ENABLE=trace+ in the client console before you run
>>>> your
>>>> test... it may be some simple error that isn't getting handled cleanly.
>>>
>>>
>>> Here is the output from running with that:
>>> 2012-02-11 14:53:38 info Trying to connect to localhost...
>>> 2012-02-11 14:53:38 debug TCPConnector created for 0-10
>>> 2012-02-11 14:53:38 info Connecting: 127.0.0.1:5672
>>> 2012-02-11 14:53:38 debug RECV [[127.0.0.1:50491-localhost:5672]]:
>>> INIT(0-10)
>>> 2012-02-11 14:53:38 trace RECV [[127.0.0.1:50491-localhost:5672]]:
>>> Frame[BEbe; channel=0; {ConnectionStartBody:
>>>
>>> server-properties={qpid.federation_tag:V2:36:str16(997761a1-4009-442f-8500-850a18324403)};
>>> mechanisms=str16{V2:8:str16(AMQPLAIN), V2:5:str16(PLAIN),
>>> V2:8:str16(CRAM-MD5)}; locales=str16{V2:5:str16(en_US)}; }]
>>> 2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
>>> Frame[BEbe; channel=0; {ConnectionStartOkBody:
>>>
>>> client-properties={qpid.client_pid:F4:int32(13708),qpid.client_ppid:F4:int32(2345),qpid.client_process:V2:6:str16(python),qpid.session_flow:F4:int32(1)};
>>> mechanism=; response=xxxxxx; locale=en_US; }]
>>
>>
>> The line above is odd. The mechanism is not specified. It looks like the
>> cyrus sasl integration is not built into your libs. However, it does seem
>> that the broker responds to this which would indicate that for whatever
>> reason it did authenticate successfully, so this may not be relevant to the
>> issue.
>>
>> I have cyrus enabled and see something different. I also see clear errors
>> being sent in a connection-close for any authentication related problems,
>> which again suggests the oddness above is not the issue here.
>>
>>
>>> 2012-02-11 14:53:38 trace RECV [[127.0.0.1:50491-localhost:5672]]:
>>> Frame[BEbe; channel=0; {ConnectionTuneBody: channel-max=256;
>>> max-frame-size=65535; heartbeat-min=0; heartbeat-max=0; }]
>>> 2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
>>> Frame[BEbe; channel=0; {ConnectionTuneOkBody: channel-max=256;
>>> max-frame-size=65535; heartbeat=0; }]
>>> 2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
>>> Frame[BEbe; channel=0; {ConnectionOpenBody: virtual-host=;
>>> capabilities=void{}; insist=1; }]
>>> 2012-02-11 14:53:39 trace RECV [[127.0.0.1:50491-localhost:5672]]:
>>> Frame[BEbe; channel=0; {ConnectionOpenOkBody: known-hosts=void{}; }]
>>> 2012-02-11 14:53:39 debug Known-brokers for connection:
>>> 2012-02-11 14:53:39 info Connection [127.0.0.1:50491-localhost:5672]
>>> connected to tcp:localhost:5672
>>> 2012-02-11 14:53:39 debug Connection [127.0.0.1:50491-localhost:5672]
>>> no security layer in place
>>> 2012-02-11 14:53:39 info Connected to localhost
>>> 2012-02-11 14:53:39 debug Added known-hosts, reconnect-urls=[localhost]
>>> 2012-02-11 14:53:39 debug SessionState::SessionState .: 0x7f9ba4001178
>>> 2012-02-11 14:53:39 trace SENT [[127.0.0.1:50491-localhost:5672]]:
>>> Frame[BEbe; channel=1; {SessionAttachBody:
>>> name=3892ce4f-42ad-4acb-b015-769382ec726d; }]
>>> 2012-02-11 14:53:39 warning Connection [127.0.0.1:50491-localhost:5672]
>>> closed
>>> 2012-02-11 14:53:39 debug Exception constructed: Connection
>>> [127.0.0.1:50491-localhost:5672] closed
>>> 2012-02-11 14:53:39 debug Exception constructed: Connection
>>> [127.0.0.1:50491-localhost:5672] closed
>>>
>>> Doesn't really appear much more helpful other than that it says there
>>> is an exception of some kind.
>>
>>
>> I think that is just in response to the connection being closed.
>>
>>
>>> I just did a quick trace with wireshark and it also shows the same
>>> sequence but I noticed something that may be a little strange, the
>>> sequence goes like this:
>>> ....some setup...
>>> connection.start-ok (client -> server)
>>> connection.tune (server -> client)
>>> connection.tune-ok connection.open (client -> server)
>>> connection.open-ok [Malformed packet] -- it says an exception
>>> occurred here but I don't see any extra data, and this was from server
>>> -> client
>>> What is also weird is that the client now sends a session.open command
>>> and the server responds and resets the connections with FIN, ACK,
>>> supposedly since there was an error with the previous command
>>
>>
>> The supposedly malformed frame seems to make it ok to the client. Is there
>> anything in the network of your virtual env that could be causing problems?
>> What happens if you try to connect with the c++ client itself (e.g. using
>> one of the test programs or examples)?
>
> OK, I tried using the C++ messaging spout program and got the same
> error. I realized I hadn't installed libsasl2-dev on this machine
> which is probably why you saw that the sasl libs weren't there. So I
> installed them and recompiled but now I am getting a different
> exception:
> 2012-02-13 11:05:21 warning Closing connection due to internal-error:
> Sasl error: SASL(-4): no mechanism available: No worthy mechs found
> (qpid/SaslFactory.cpp:280)
> internal-error: Sasl error: SASL(-4): no mechanism available: No
> worthy mechs found (qpid/SaslFactory.cpp:280)
>
> I don't have a great understanding of SASL and not sure what this
> means or how to fix it...
try username/password@localhost as the broker
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Brandon Pedersen <bp...@gmail.com>.
On Sun, Feb 12, 2012 at 6:19 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 02/11/2012 10:07 PM, Brandon Pedersen wrote:
>>
>> On Sat, Feb 11, 2012 at 11:05 AM, Gordon Sim<gs...@redhat.com> wrote:
>>>
>>> On 02/10/2012 11:38 PM, Brandon Pedersen wrote:
>>> Try export QPID_LOG_ENABLE=trace+ in the client console before you run
>>> your
>>> test... it may be some simple error that isn't getting handled cleanly.
>>
>>
>> Here is the output from running with that:
>> 2012-02-11 14:53:38 info Trying to connect to localhost...
>> 2012-02-11 14:53:38 debug TCPConnector created for 0-10
>> 2012-02-11 14:53:38 info Connecting: 127.0.0.1:5672
>> 2012-02-11 14:53:38 debug RECV [[127.0.0.1:50491-localhost:5672]]:
>> INIT(0-10)
>> 2012-02-11 14:53:38 trace RECV [[127.0.0.1:50491-localhost:5672]]:
>> Frame[BEbe; channel=0; {ConnectionStartBody:
>>
>> server-properties={qpid.federation_tag:V2:36:str16(997761a1-4009-442f-8500-850a18324403)};
>> mechanisms=str16{V2:8:str16(AMQPLAIN), V2:5:str16(PLAIN),
>> V2:8:str16(CRAM-MD5)}; locales=str16{V2:5:str16(en_US)}; }]
>> 2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
>> Frame[BEbe; channel=0; {ConnectionStartOkBody:
>>
>> client-properties={qpid.client_pid:F4:int32(13708),qpid.client_ppid:F4:int32(2345),qpid.client_process:V2:6:str16(python),qpid.session_flow:F4:int32(1)};
>> mechanism=; response=xxxxxx; locale=en_US; }]
>
>
> The line above is odd. The mechanism is not specified. It looks like the
> cyrus sasl integration is not built into your libs. However, it does seem
> that the broker responds to this which would indicate that for whatever
> reason it did authenticate successfully, so this may not be relevant to the
> issue.
>
> I have cyrus enabled and see something different. I also see clear errors
> being sent in a connection-close for any authentication related problems,
> which again suggests the oddness above is not the issue here.
>
>
>> 2012-02-11 14:53:38 trace RECV [[127.0.0.1:50491-localhost:5672]]:
>> Frame[BEbe; channel=0; {ConnectionTuneBody: channel-max=256;
>> max-frame-size=65535; heartbeat-min=0; heartbeat-max=0; }]
>> 2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
>> Frame[BEbe; channel=0; {ConnectionTuneOkBody: channel-max=256;
>> max-frame-size=65535; heartbeat=0; }]
>> 2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
>> Frame[BEbe; channel=0; {ConnectionOpenBody: virtual-host=;
>> capabilities=void{}; insist=1; }]
>> 2012-02-11 14:53:39 trace RECV [[127.0.0.1:50491-localhost:5672]]:
>> Frame[BEbe; channel=0; {ConnectionOpenOkBody: known-hosts=void{}; }]
>> 2012-02-11 14:53:39 debug Known-brokers for connection:
>> 2012-02-11 14:53:39 info Connection [127.0.0.1:50491-localhost:5672]
>> connected to tcp:localhost:5672
>> 2012-02-11 14:53:39 debug Connection [127.0.0.1:50491-localhost:5672]
>> no security layer in place
>> 2012-02-11 14:53:39 info Connected to localhost
>> 2012-02-11 14:53:39 debug Added known-hosts, reconnect-urls=[localhost]
>> 2012-02-11 14:53:39 debug SessionState::SessionState .: 0x7f9ba4001178
>> 2012-02-11 14:53:39 trace SENT [[127.0.0.1:50491-localhost:5672]]:
>> Frame[BEbe; channel=1; {SessionAttachBody:
>> name=3892ce4f-42ad-4acb-b015-769382ec726d; }]
>> 2012-02-11 14:53:39 warning Connection [127.0.0.1:50491-localhost:5672]
>> closed
>> 2012-02-11 14:53:39 debug Exception constructed: Connection
>> [127.0.0.1:50491-localhost:5672] closed
>> 2012-02-11 14:53:39 debug Exception constructed: Connection
>> [127.0.0.1:50491-localhost:5672] closed
>>
>> Doesn't really appear much more helpful other than that it says there
>> is an exception of some kind.
>
>
> I think that is just in response to the connection being closed.
>
>
>> I just did a quick trace with wireshark and it also shows the same
>> sequence but I noticed something that may be a little strange, the
>> sequence goes like this:
>> ....some setup...
>> connection.start-ok (client -> server)
>> connection.tune (server -> client)
>> connection.tune-ok connection.open (client -> server)
>> connection.open-ok [Malformed packet] -- it says an exception
>> occurred here but I don't see any extra data, and this was from server
>> -> client
>> What is also weird is that the client now sends a session.open command
>> and the server responds and resets the connections with FIN, ACK,
>> supposedly since there was an error with the previous command
>
>
> The supposedly malformed frame seems to make it ok to the client. Is there
> anything in the network of your virtual env that could be causing problems?
> What happens if you try to connect with the c++ client itself (e.g. using
> one of the test programs or examples)?
OK, I tried using the C++ messaging spout program and got the same
error. I realized I hadn't installed libsasl2-dev on this machine
which is probably why you saw that the sasl libs weren't there. So I
installed them and recompiled but now I am getting a different
exception:
2012-02-13 11:05:21 warning Closing connection due to internal-error:
Sasl error: SASL(-4): no mechanism available: No worthy mechs found
(qpid/SaslFactory.cpp:280)
internal-error: Sasl error: SASL(-4): no mechanism available: No
worthy mechs found (qpid/SaslFactory.cpp:280)
I don't have a great understanding of SASL and not sure what this
means or how to fix it...
Thanks,
-Brandon
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Gordon Sim <gs...@redhat.com>.
On 02/11/2012 10:07 PM, Brandon Pedersen wrote:
> On Sat, Feb 11, 2012 at 11:05 AM, Gordon Sim<gs...@redhat.com> wrote:
>> On 02/10/2012 11:38 PM, Brandon Pedersen wrote:
>> Try export QPID_LOG_ENABLE=trace+ in the client console before you run your
>> test... it may be some simple error that isn't getting handled cleanly.
>
> Here is the output from running with that:
> 2012-02-11 14:53:38 info Trying to connect to localhost...
> 2012-02-11 14:53:38 debug TCPConnector created for 0-10
> 2012-02-11 14:53:38 info Connecting: 127.0.0.1:5672
> 2012-02-11 14:53:38 debug RECV [[127.0.0.1:50491-localhost:5672]]: INIT(0-10)
> 2012-02-11 14:53:38 trace RECV [[127.0.0.1:50491-localhost:5672]]:
> Frame[BEbe; channel=0; {ConnectionStartBody:
> server-properties={qpid.federation_tag:V2:36:str16(997761a1-4009-442f-8500-850a18324403)};
> mechanisms=str16{V2:8:str16(AMQPLAIN), V2:5:str16(PLAIN),
> V2:8:str16(CRAM-MD5)}; locales=str16{V2:5:str16(en_US)}; }]
> 2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
> Frame[BEbe; channel=0; {ConnectionStartOkBody:
> client-properties={qpid.client_pid:F4:int32(13708),qpid.client_ppid:F4:int32(2345),qpid.client_process:V2:6:str16(python),qpid.session_flow:F4:int32(1)};
> mechanism=; response=xxxxxx; locale=en_US; }]
The line above is odd. The mechanism is not specified. It looks like the
cyrus sasl integration is not built into your libs. However, it does
seem that the broker responds to this which would indicate that for
whatever reason it did authenticate successfully, so this may not be
relevant to the issue.
I have cyrus enabled and see something different. I also see clear
errors being sent in a connection-close for any authentication related
problems, which again suggests the oddness above is not the issue here.
> 2012-02-11 14:53:38 trace RECV [[127.0.0.1:50491-localhost:5672]]:
> Frame[BEbe; channel=0; {ConnectionTuneBody: channel-max=256;
> max-frame-size=65535; heartbeat-min=0; heartbeat-max=0; }]
> 2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
> Frame[BEbe; channel=0; {ConnectionTuneOkBody: channel-max=256;
> max-frame-size=65535; heartbeat=0; }]
> 2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
> Frame[BEbe; channel=0; {ConnectionOpenBody: virtual-host=;
> capabilities=void{}; insist=1; }]
> 2012-02-11 14:53:39 trace RECV [[127.0.0.1:50491-localhost:5672]]:
> Frame[BEbe; channel=0; {ConnectionOpenOkBody: known-hosts=void{}; }]
> 2012-02-11 14:53:39 debug Known-brokers for connection:
> 2012-02-11 14:53:39 info Connection [127.0.0.1:50491-localhost:5672]
> connected to tcp:localhost:5672
> 2012-02-11 14:53:39 debug Connection [127.0.0.1:50491-localhost:5672]
> no security layer in place
> 2012-02-11 14:53:39 info Connected to localhost
> 2012-02-11 14:53:39 debug Added known-hosts, reconnect-urls=[localhost]
> 2012-02-11 14:53:39 debug SessionState::SessionState .: 0x7f9ba4001178
> 2012-02-11 14:53:39 trace SENT [[127.0.0.1:50491-localhost:5672]]:
> Frame[BEbe; channel=1; {SessionAttachBody:
> name=3892ce4f-42ad-4acb-b015-769382ec726d; }]
> 2012-02-11 14:53:39 warning Connection [127.0.0.1:50491-localhost:5672] closed
> 2012-02-11 14:53:39 debug Exception constructed: Connection
> [127.0.0.1:50491-localhost:5672] closed
> 2012-02-11 14:53:39 debug Exception constructed: Connection
> [127.0.0.1:50491-localhost:5672] closed
>
> Doesn't really appear much more helpful other than that it says there
> is an exception of some kind.
I think that is just in response to the connection being closed.
> I just did a quick trace with wireshark and it also shows the same
> sequence but I noticed something that may be a little strange, the
> sequence goes like this:
> ....some setup...
> connection.start-ok (client -> server)
> connection.tune (server -> client)
> connection.tune-ok connection.open (client -> server)
> connection.open-ok [Malformed packet] -- it says an exception
> occurred here but I don't see any extra data, and this was from server
> -> client
> What is also weird is that the client now sends a session.open command
> and the server responds and resets the connections with FIN, ACK,
> supposedly since there was an error with the previous command
The supposedly malformed frame seems to make it ok to the client. Is
there anything in the network of your virtual env that could be causing
problems? What happens if you try to connect with the c++ client itself
(e.g. using one of the test programs or examples)?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Brandon Pedersen <bp...@gmail.com>.
On Sat, Feb 11, 2012 at 11:05 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 02/10/2012 11:38 PM, Brandon Pedersen wrote:
> Try export QPID_LOG_ENABLE=trace+ in the client console before you run your
> test... it may be some simple error that isn't getting handled cleanly.
Here is the output from running with that:
2012-02-11 14:53:38 info Trying to connect to localhost...
2012-02-11 14:53:38 debug TCPConnector created for 0-10
2012-02-11 14:53:38 info Connecting: 127.0.0.1:5672
2012-02-11 14:53:38 debug RECV [[127.0.0.1:50491-localhost:5672]]: INIT(0-10)
2012-02-11 14:53:38 trace RECV [[127.0.0.1:50491-localhost:5672]]:
Frame[BEbe; channel=0; {ConnectionStartBody:
server-properties={qpid.federation_tag:V2:36:str16(997761a1-4009-442f-8500-850a18324403)};
mechanisms=str16{V2:8:str16(AMQPLAIN), V2:5:str16(PLAIN),
V2:8:str16(CRAM-MD5)}; locales=str16{V2:5:str16(en_US)}; }]
2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
Frame[BEbe; channel=0; {ConnectionStartOkBody:
client-properties={qpid.client_pid:F4:int32(13708),qpid.client_ppid:F4:int32(2345),qpid.client_process:V2:6:str16(python),qpid.session_flow:F4:int32(1)};
mechanism=; response=xxxxxx; locale=en_US; }]
2012-02-11 14:53:38 trace RECV [[127.0.0.1:50491-localhost:5672]]:
Frame[BEbe; channel=0; {ConnectionTuneBody: channel-max=256;
max-frame-size=65535; heartbeat-min=0; heartbeat-max=0; }]
2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
Frame[BEbe; channel=0; {ConnectionTuneOkBody: channel-max=256;
max-frame-size=65535; heartbeat=0; }]
2012-02-11 14:53:38 trace SENT [[127.0.0.1:50491-localhost:5672]]:
Frame[BEbe; channel=0; {ConnectionOpenBody: virtual-host=;
capabilities=void{}; insist=1; }]
2012-02-11 14:53:39 trace RECV [[127.0.0.1:50491-localhost:5672]]:
Frame[BEbe; channel=0; {ConnectionOpenOkBody: known-hosts=void{}; }]
2012-02-11 14:53:39 debug Known-brokers for connection:
2012-02-11 14:53:39 info Connection [127.0.0.1:50491-localhost:5672]
connected to tcp:localhost:5672
2012-02-11 14:53:39 debug Connection [127.0.0.1:50491-localhost:5672]
no security layer in place
2012-02-11 14:53:39 info Connected to localhost
2012-02-11 14:53:39 debug Added known-hosts, reconnect-urls=[localhost]
2012-02-11 14:53:39 debug SessionState::SessionState .: 0x7f9ba4001178
2012-02-11 14:53:39 trace SENT [[127.0.0.1:50491-localhost:5672]]:
Frame[BEbe; channel=1; {SessionAttachBody:
name=3892ce4f-42ad-4acb-b015-769382ec726d; }]
2012-02-11 14:53:39 warning Connection [127.0.0.1:50491-localhost:5672] closed
2012-02-11 14:53:39 debug Exception constructed: Connection
[127.0.0.1:50491-localhost:5672] closed
2012-02-11 14:53:39 debug Exception constructed: Connection
[127.0.0.1:50491-localhost:5672] closed
Doesn't really appear much more helpful other than that it says there
is an exception of some kind.
I just did a quick trace with wireshark and it also shows the same
sequence but I noticed something that may be a little strange, the
sequence goes like this:
....some setup...
connection.start-ok (client -> server)
connection.tune (server -> client)
connection.tune-ok connection.open (client -> server)
connection.open-ok [Malformed packet] -- it says an exception
occurred here but I don't see any extra data, and this was from server
-> client
What is also weird is that the client now sends a session.open command
and the server responds and resets the connections with FIN, ACK,
supposedly since there was an error with the previous command
Thanks for your help,
-Brandon
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Gordon Sim <gs...@redhat.com>.
On 02/10/2012 11:38 PM, Brandon Pedersen wrote:
>> I can connect to a 0.14 java broker from both 0.14 and 0.12 c++ swigged
>> python clients. The c++ client also connects fine, which is what this
>> version of the python client sits on top of.
>>
>> What is your application doing?
>
> see my other email, just a simple:
> from cqpid import Connection
> conn = Connection("localhost", username="admin", password="admin",
> reconnect=True)
> conn.open()
> session = conn.session()
>
> I am starting to wonder if it may be the way I am building the cqpid
> stuff that is causing problems. I am using cmake (rather than
> autotools) and using a python virtualenv. When I build the library I
> run cmake in the top directory and then just go into the bindings/qpid
> folder and do make/make install and it installs the _cqpid.so and
> cqpid.py (etc.) to my virtualenv. However I don't actually install the
> c++ client libraries (like libqpidclient.so, etc.), I would think that
> if that were the problem my python would crash by just importing the
> cqpid stuff but it doesn't (and it looks like doing an ldd on
> _cqpid.so, it is picking up the right libraries) but I have no idea
> why else this is not working for me.
Try export QPID_LOG_ENABLE=trace+ in the client console before you run
your test... it may be some simple error that isn't getting handled cleanly.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Brandon Pedersen <bp...@gmail.com>.
> I can connect to a 0.14 java broker from both 0.14 and 0.12 c++ swigged
> python clients. The c++ client also connects fine, which is what this
> version of the python client sits on top of.
>
> What is your application doing?
see my other email, just a simple:
from cqpid import Connection
conn = Connection("localhost", username="admin", password="admin",
reconnect=True)
conn.open()
session = conn.session()
I am starting to wonder if it may be the way I am building the cqpid
stuff that is causing problems. I am using cmake (rather than
autotools) and using a python virtualenv. When I build the library I
run cmake in the top directory and then just go into the bindings/qpid
folder and do make/make install and it installs the _cqpid.so and
cqpid.py (etc.) to my virtualenv. However I don't actually install the
c++ client libraries (like libqpidclient.so, etc.), I would think that
if that were the problem my python would crash by just importing the
cqpid stuff but it doesn't (and it looks like doing an ldd on
_cqpid.so, it is picking up the right libraries) but I have no idea
why else this is not working for me.
-Brandon
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: problems using cqpid with java broker
Posted by Gordon Sim <gs...@redhat.com>.
On 02/10/2012 06:20 AM, Brandon Pedersen wrote:
> When I try to use the
> cqpid client with the Java broker it does not work. My python program
> spits out a ton of messages like "warning Connection
> [127.0.0.1:48782-localhost:5672] closed" and basically hangs...I have
> to force kill it.
I can connect to a 0.14 java broker from both 0.14 and 0.12 c++ swigged
python clients. The c++ client also connects fine, which is what this
version of the python client sits on top of.
What is your application doing?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org