[Qpid Java Broker] Remove Derby jar causes broker to crash when creating a VritualHost with Derby message store or config

[Adel Boutros]

Hello,


For legal issues, we are unable to ship Derby in our product. So to be able to 
use Qpid, I have removed the Derby jar and relaunched the broker which had a 
"Memory" virtual host.


I tried to add a new VirtualHostNode/VirtualHost with config and message store 
"DERBY" and it crashed. I was expecting it to behave just the way it does for 
BerkleyDB when the jar is not present.


Is it possible to fix this?


Regards,

Adel


Full Stack in broker log

-


[Broker] BRK-1004 : Qpid Broker Ready

#
# Unhandled Exception org.apache.qpid.server.store.StoreException: Failed to 
load driver org.apache.derby.jdbc.EmbeddedDriver in Thread 
HttpManagement-HTTP-122
#
# Exiting
#

org.apache.qpid.server.store.StoreException: Failed to load driver 
org.apache.derby.jdbc.EmbeddedDriver
at 
org.apache.qpid.server.store.derby.DerbyUtils.loadDerbyDriver(DerbyUtils.java:65)
at 
org.apache.qpid.server.store.derby.DerbyConfigurationStore.openConfigurationStore(DerbyConfigurationStore.java:75)
at 
org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.activate(AbstractStandardVirtualHostNode.java:84)
at 
org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNode.doActivate(AbstractVirtualHostNode.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1266)
at 
org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1245)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:864)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:858)
at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
at 
com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
at 
com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
at com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
at 
com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
at com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322)
at com.google.common.util.concurrent.Futures.addCallback(Futures.java:1258)
at 
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:857)
at 
org.apache.qpid.server.model.AbstractConfiguredObject.access$300(AbstractConfiguredObject.java:78)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:756)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:719)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:521)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:514)
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:154)
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:142)
at 
org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:513)
at 
org.apache.qpid.server.model.AbstractConfiguredObject.createAsync(AbstractConfiguredObject.java:718)
at 
org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.createAsync(AbstractConfiguredObjectTypeFactory.java:76)
at 
org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.createAsync(ConfiguredObjectFactoryImpl.java:125)
at 
org.apache.qpid.server.model.adapter.BrokerAdapter.createVirtualHostNodeAsync(BrokerAdapter.java:598)
at 
org.apache.qpid.server.model.adapter.BrokerAdapter.addChildAsync(BrokerAdapter.java:652)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$18.execute(AbstractConfiguredObject.java:1876)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$18.execute(AbstractConfiguredObject.java:1871)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:521)
at 
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:514)
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:342)
at java.security.AccessController.doPrivileg

DSCP tags

[drasil]

Hello,

do Proton client libraries support DSCP tagging of IP packets? I found the
"transport.trafficClass" configuration option in qpid-jms, but I did not
find anything similar in Proton C, C++, Python or Java API.

Regards, Pavel



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/DSCP-tags-tp7655237.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

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

Re: [Qpid Java Broker] Remove Derby jar causes broker to crash when creating a VritualHost with Derby message store or config

[Rob Godfrey]

Just to be clear - the current behaviour of the broker when started with a
BDB VirtualHost*Node* and the BDB jar missing is for the broker to fail to
start.  A JSON vitualhostnode with a BDB virtualhost will allow the boker
to start up, but the virtualhostnode will be in the ERROR state.

It would be relatively easy to have the same sort of behaviour for the
Derby Virtual Host... It would be a bigger change if you were wanting the
broker to start up with VirtualHostNodes which depend on missing libraries.

Is this what you are looking for, or are you needing to have the broker
start up even with virtual host nodes defined which cannot be created (if
you are, I'm not sure there's actually an easy way to solve that)

Cheers,
Rob

On 1 December 2016 at 15:21, Adel Boutros  wrote:

> Hello,
>
>
> For legal issues, we are unable to ship Derby in our product. So to be
> able to use Qpid, I have removed the Derby jar and relaunched the broker
> which had a "Memory" virtual host.
>
>
> I tried to add a new VirtualHostNode/VirtualHost with config and message
> store "DERBY" and it crashed. I was expecting it to behave just the way it
> does for BerkleyDB when the jar is not present.
>
>
> Is it possible to fix this?
>
>
> Regards,
>
> Adel
>
>
> Full Stack in broker log
>
> -
>
>
> [Broker] BRK-1004 : Qpid Broker Ready
> 
> #
> # Unhandled Exception org.apache.qpid.server.store.StoreException: Failed
> to load driver org.apache.derby.jdbc.EmbeddedDriver in Thread
> HttpManagement-HTTP-122
> #
> # Exiting
> #
> 
> org.apache.qpid.server.store.StoreException: Failed to load driver
> org.apache.derby.jdbc.EmbeddedDriver
> at org.apache.qpid.server.store.derby.DerbyUtils.loadDerbyDrive
> r(DerbyUtils.java:65)
> at org.apache.qpid.server.store.derby.DerbyConfigurationStore.o
> penConfigurationStore(DerbyConfigurationStore.java:75)
> at org.apache.qpid.server.virtualhostnode.AbstractStandardVirtu
> alHostNode.activate(AbstractStandardVirtualHostNode.java:84)
> at org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNo
> de.doActivate(AbstractVirtualHostNode.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> ssorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.qpid.server.model.AbstractConfiguredObject.attain
> State(AbstractConfiguredObject.java:1266)
> at org.apache.qpid.server.model.AbstractConfiguredObject.attain
> State(AbstractConfiguredObject.java:1245)
> at org.apache.qpid.server.model.AbstractConfiguredObject$8.onSu
> ccess(AbstractConfiguredObject.java:864)
> at org.apache.qpid.server.model.AbstractConfiguredObject$8.onSu
> ccess(AbstractConfiguredObject.java:858)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at com.google.common.util.concurrent.MoreExecutors$DirectExecut
> or.execute(MoreExecutors.java:457)
> at com.google.common.util.concurrent.ExecutionList.executeListe
> ner(ExecutionList.java:156)
> at com.google.common.util.concurrent.ExecutionList.add(Executio
> nList.java:101)
> at com.google.common.util.concurrent.AbstractFuture.addListener
> (AbstractFuture.java:170)
> at com.google.common.util.concurrent.Futures.addCallback(
> Futures.java:1322)
> at com.google.common.util.concurrent.Futures.addCallback(
> Futures.java:1258)
> at org.apache.qpid.server.model.AbstractConfiguredObject.doAtta
> inState(AbstractConfiguredObject.java:857)
> at org.apache.qpid.server.model.AbstractConfiguredObject.access
> $300(AbstractConfiguredObject.java:78)
> at org.apache.qpid.server.model.AbstractConfiguredObject$6.exec
> ute(AbstractConfiguredObject.java:756)
> at org.apache.qpid.server.model.AbstractConfiguredObject$6.exec
> ute(AbstractConfiguredObject.java:719)
> at org.apache.qpid.server.model.AbstractConfiguredObject$2.exec
> ute(AbstractConfiguredObject.java:521)
> at org.apache.qpid.server.model.AbstractConfiguredObject$2.exec
> ute(AbstractConfiguredObject.java:514)
> at org.apache.qpid.server.configuration.updater.TaskExecutorImp
> l$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
> at org.apache.qpid.server.configuration.updater.TaskExecutorImp
> l.submitWrappedTask(TaskExecutorImpl.java:154)
> at org.apache.qpid.server.configuration.updater.TaskExecutorImp
> l.submit(TaskExecutorImpl.java:142)
> at org.apache.qpid.server.model.AbstractConfiguredObject.doOnCo
> nfigThread(AbstractConfiguredObject.java:513)
> at org.apache.qpid.server.model.AbstractConfiguredObject.create
> Async(AbstractConfiguredObject.java:718)
> at org.apache.qpid.server.model.AbstractConfiguredObjectTypeFac
> tory.createAsync(AbstractConfiguredObjectTypeFactory.java:76)
> at org.apache.qpid.server.model.Confi

Re: Qpid JMS client JmsConnection.close() hangs

[Timothy Bish]

Close timeout handling has been fixed up a fair bit with issue:
https://issues.apache.org/jira/browse/QPIDJMS-228

On 11/25/2016 11:04 AM, Robbie Gemmell wrote:

"I also think I see an issue with the closeTimeout handling in that in
one place it seems likely to be using the requestTimeout value
instead. Need to investigate that further."

Though in my attemps that didnt actually matter and the close
completed fine if the network dropped and no response could be
received (or was ever sent). As I say, needs more investigation.

On 25 November 2016 at 15:49, DraCzech  wrote:

I'll try to find a way of preventing this problem from happening. (Though I'm
not sure how to do that properly at the moment.)

But how do you explain unlimited waiting for Close frame response as shown
in my previous post?


DraCzech wrote

2016-11-24 16:41:45.202589  [19105288:0] -> Close{error=null}

on network lost vs.

2016-11-24 16:51:31.027968  [18734493:0] -> Close{error=null}
2016-11-24 16:51:31.977722  [18734493:0] <- Close{error=null}

Shouldn't some timeout throw an exception or so?



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Qpid-JMS-client-JmsConnection-close-hangs-tp7654565p7654872.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

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


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





--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/


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

Re: [Qpid Java Broker] Remove Derby jar causes broker to crash when creating a VritualHost with Derby message store or config

[Adel Boutros]

Hello Rob,


Having the same behavior as BerkleyDB is enough for me right now.


I don't mind the broker not starting if a VirtualHostNode is missing jars. 
However, I don't like the fact that a management operation can make a running 
broker fail especially when you have a lot of messages being exchanged at the 
same moment.


Regards,

Adel


From: Rob Godfrey 
Sent: Thursday, December 1, 2016 5:08:15 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker] Remove Derby jar causes broker to crash when 
creating a VritualHost with Derby message store or config

Just to be clear - the current behaviour of the broker when started with a
BDB VirtualHost*Node* and the BDB jar missing is for the broker to fail to
start.  A JSON vitualhostnode with a BDB virtualhost will allow the boker
to start up, but the virtualhostnode will be in the ERROR state.

It would be relatively easy to have the same sort of behaviour for the
Derby Virtual Host... It would be a bigger change if you were wanting the
broker to start up with VirtualHostNodes which depend on missing libraries.

Is this what you are looking for, or are you needing to have the broker
start up even with virtual host nodes defined which cannot be created (if
you are, I'm not sure there's actually an easy way to solve that)

Cheers,
Rob

On 1 December 2016 at 15:21, Adel Boutros  wrote:

> Hello,
>
>
> For legal issues, we are unable to ship Derby in our product. So to be
> able to use Qpid, I have removed the Derby jar and relaunched the broker
> which had a "Memory" virtual host.
>
>
> I tried to add a new VirtualHostNode/VirtualHost with config and message
> store "DERBY" and it crashed. I was expecting it to behave just the way it
> does for BerkleyDB when the jar is not present.
>
>
> Is it possible to fix this?
>
>
> Regards,
>
> Adel
>
>
> Full Stack in broker log
>
> -
>
>
> [Broker] BRK-1004 : Qpid Broker Ready
> 
> #
> # Unhandled Exception org.apache.qpid.server.store.StoreException: Failed
> to load driver org.apache.derby.jdbc.EmbeddedDriver in Thread
> HttpManagement-HTTP-122
> #
> # Exiting
> #
> 
> org.apache.qpid.server.store.StoreException: Failed to load driver
> org.apache.derby.jdbc.EmbeddedDriver
> at org.apache.qpid.server.store.derby.DerbyUtils.loadDerbyDrive
> r(DerbyUtils.java:65)
> at org.apache.qpid.server.store.derby.DerbyConfigurationStore.o
> penConfigurationStore(DerbyConfigurationStore.java:75)
> at org.apache.qpid.server.virtualhostnode.AbstractStandardVirtu
> alHostNode.activate(AbstractStandardVirtualHostNode.java:84)
> at org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNo
> de.doActivate(AbstractVirtualHostNode.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> ssorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.qpid.server.model.AbstractConfiguredObject.attain
> State(AbstractConfiguredObject.java:1266)
> at org.apache.qpid.server.model.AbstractConfiguredObject.attain
> State(AbstractConfiguredObject.java:1245)
> at org.apache.qpid.server.model.AbstractConfiguredObject$8.onSu
> ccess(AbstractConfiguredObject.java:864)
> at org.apache.qpid.server.model.AbstractConfiguredObject$8.onSu
> ccess(AbstractConfiguredObject.java:858)
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> at com.google.common.util.concurrent.MoreExecutors$DirectExecut
> or.execute(MoreExecutors.java:457)
> at com.google.common.util.concurrent.ExecutionList.executeListe
> ner(ExecutionList.java:156)
> at com.google.common.util.concurrent.ExecutionList.add(Executio
> nList.java:101)
> at com.google.common.util.concurrent.AbstractFuture.addListener
> (AbstractFuture.java:170)
> at com.google.common.util.concurrent.Futures.addCallback(
> Futures.java:1322)
> at com.google.common.util.concurrent.Futures.addCallback(
> Futures.java:1258)
> at org.apache.qpid.server.model.AbstractConfiguredObject.doAtta
> inState(AbstractConfiguredObject.java:857)
> at org.apache.qpid.server.model.AbstractConfiguredObject.access
> $300(AbstractConfiguredObject.java:78)
> at org.apache.qpid.server.model.AbstractConfiguredObject$6.exec
> ute(AbstractConfiguredObject.java:756)
> at org.apache.qpid.server.model.AbstractConfiguredObject$6.exec
> ute(AbstractConfiguredObject.java:719)
> at org.apache.qpid.server.model.AbstractConfiguredObject$2.exec
> ute(AbstractConfiguredObject.java:521)
> at org.apache.qpid.server.model.AbstractConfiguredObject$2.exec
> ute(AbstractConfiguredObject.java:514)
> at org.apache.qpid.server.configuration.updater.TaskExecutorImp
> l$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
> at o

Re: [Qpid Java Broker] Remove Derby jar causes broker to crash when creating a VritualHost with Derby message store or config

[Rob Godfrey]

Yeah - using the same mechanism as BDB would mean that you wouldn't be able
to create a Derby vhost / vhostnode if the library wasn't present...  We
basically add a check on startup in the class to see if the necessary
preconditions for creating an object of the type are met.  At that point
you'll no longer see the types in the drop downs in the web console.  I'll
raise a JIRA and make a change on trunk.

-- Rob

On 1 December 2016 at 16:46, Adel Boutros  wrote:

> Hello Rob,
>
>
> Having the same behavior as BerkleyDB is enough for me right now.
>
>
> I don't mind the broker not starting if a VirtualHostNode is missing jars.
> However, I don't like the fact that a management operation can make a
> running broker fail especially when you have a lot of messages being
> exchanged at the same moment.
>
>
> Regards,
>
> Adel
>
> 
> From: Rob Godfrey 
> Sent: Thursday, December 1, 2016 5:08:15 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Java Broker] Remove Derby jar causes broker to crash
> when creating a VritualHost with Derby message store or config
>
> Just to be clear - the current behaviour of the broker when started with a
> BDB VirtualHost*Node* and the BDB jar missing is for the broker to fail to
> start.  A JSON vitualhostnode with a BDB virtualhost will allow the boker
> to start up, but the virtualhostnode will be in the ERROR state.
>
> It would be relatively easy to have the same sort of behaviour for the
> Derby Virtual Host... It would be a bigger change if you were wanting the
> broker to start up with VirtualHostNodes which depend on missing libraries.
>
> Is this what you are looking for, or are you needing to have the broker
> start up even with virtual host nodes defined which cannot be created (if
> you are, I'm not sure there's actually an easy way to solve that)
>
> Cheers,
> Rob
>
> On 1 December 2016 at 15:21, Adel Boutros  wrote:
>
> > Hello,
> >
> >
> > For legal issues, we are unable to ship Derby in our product. So to be
> > able to use Qpid, I have removed the Derby jar and relaunched the broker
> > which had a "Memory" virtual host.
> >
> >
> > I tried to add a new VirtualHostNode/VirtualHost with config and message
> > store "DERBY" and it crashed. I was expecting it to behave just the way
> it
> > does for BerkleyDB when the jar is not present.
> >
> >
> > Is it possible to fix this?
> >
> >
> > Regards,
> >
> > Adel
> >
> >
> > Full Stack in broker log
> >
> > -
> >
> >
> > [Broker] BRK-1004 : Qpid Broker Ready
> > 
> > #
> > # Unhandled Exception org.apache.qpid.server.store.StoreException:
> Failed
> > to load driver org.apache.derby.jdbc.EmbeddedDriver in Thread
> > HttpManagement-HTTP-122
> > #
> > # Exiting
> > #
> > 
> > org.apache.qpid.server.store.StoreException: Failed to load driver
> > org.apache.derby.jdbc.EmbeddedDriver
> > at org.apache.qpid.server.store.derby.DerbyUtils.loadDerbyDrive
> > r(DerbyUtils.java:65)
> > at org.apache.qpid.server.store.derby.DerbyConfigurationStore.o
> > penConfigurationStore(DerbyConfigurationStore.java:75)
> > at org.apache.qpid.server.virtualhostnode.AbstractStandardVirtu
> > alHostNode.activate(AbstractStandardVirtualHostNode.java:84)
> > at org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNo
> > de.doActivate(AbstractVirtualHostNode.java:160)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> > ssorImpl.java:57)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> > thodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:606)
> > at org.apache.qpid.server.model.AbstractConfiguredObject.attain
> > State(AbstractConfiguredObject.java:1266)
> > at org.apache.qpid.server.model.AbstractConfiguredObject.attain
> > State(AbstractConfiguredObject.java:1245)
> > at org.apache.qpid.server.model.AbstractConfiguredObject$8.onSu
> > ccess(AbstractConfiguredObject.java:864)
> > at org.apache.qpid.server.model.AbstractConfiguredObject$8.onSu
> > ccess(AbstractConfiguredObject.java:858)
> > at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> > at com.google.common.util.concurrent.MoreExecutors$DirectExecut
> > or.execute(MoreExecutors.java:457)
> > at com.google.common.util.concurrent.ExecutionList.executeListe
> > ner(ExecutionList.java:156)
> > at com.google.common.util.concurrent.ExecutionList.add(Executio
> > nList.java:101)
> > at com.google.common.util.concurrent.AbstractFuture.addListener
> > (AbstractFuture.java:170)
> > at com.google.common.util.concurrent.Futures.addCallback(
> > Futures.java:1322)
> > at com.google.common.util.concurrent.Futures.addCallback(
> > Futures.java:1258)
> > at org.apache.qpid.server.model.AbstractConfiguredObject.doAtta
> > inState(AbstractConfig

I'm using the Qpid Broker and JMS MessageConsumer times out waiting for a sync

[Michael Nachmias]

Hello,

I'm running a enterprise Java web application using Java jdk 1.7.0.101,
Qpid 0.30, and JMS 1.1. I'm running into intermittent issues where closing
or retrieving from the JMS MessageConsumer times out waiting for a sync.
The following is the stack trace of the exception:

2016-11-29 19:38:23,791 DEBUG [org.apache.qpid.client.AMQConnection]
(ajp-/10.1.15.14:8009-21) exceptionReceived done by:ajp-/10.1.15.14:8009-21:
org.apache.qpid.AMQException: timed out waiting for sync: complete = 23136,
point = 23141 [error code 541: internal error]
at 
org.apache.qpid.client.AMQSession_0_10.setCurrentException(AMQSession_0_10.java:1081)
[qpid-client-0.30.jar:0.30]
at org.apache.qpid.client.BasicMessageConsumer_0_10.sendCancel(
BasicMessageConsumer_0_10.java:175) [qpid-client-0.30.jar:0.30]
at 
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:613)
[qpid-client-0.30.jar:0.30]
at 
org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:573)
[qpid-client-0.30.jar:0.30]

Is there any way to determine what is the root cause of this or if this has
been addressed in an updated version of Qpid/JMS? Thank you for your help.

Re: I'm using the Qpid Broker and JMS MessageConsumer times out waiting for a sync

[Rob Godfrey]

Hi Michael,

Which Broker (Java/C++) are you using?  Is there anything in the broker
logs indicating an issue at the time where these errors are occurring?

-- Rob

On 1 December 2016 at 17:22, Michael Nachmias 
wrote:

> Hello,
>
> I'm running a enterprise Java web application using Java jdk 1.7.0.101,
> Qpid 0.30, and JMS 1.1. I'm running into intermittent issues where closing
> or retrieving from the JMS MessageConsumer times out waiting for a sync.
> The following is the stack trace of the exception:
>
> 2016-11-29 19:38:23,791 DEBUG [org.apache.qpid.client.AMQConnection]
> (ajp-/10.1.15.14:8009-21) exceptionReceived done by:ajp-/10.1.15.14:8009
> -21:
> org.apache.qpid.AMQException: timed out waiting for sync: complete = 23136,
> point = 23141 [error code 541: internal error]
> at org.apache.qpid.client.AMQSession_0_10.setCurrentException(
> AMQSession_0_10.java:1081)
> [qpid-client-0.30.jar:0.30]
> at org.apache.qpid.client.BasicMessageConsumer_0_10.sendCancel(
> BasicMessageConsumer_0_10.java:175) [qpid-client-0.30.jar:0.30]
> at org.apache.qpid.client.BasicMessageConsumer.close(
> BasicMessageConsumer.java:613)
> [qpid-client-0.30.jar:0.30]
> at org.apache.qpid.client.BasicMessageConsumer.close(
> BasicMessageConsumer.java:573)
> [qpid-client-0.30.jar:0.30]
>
> Is there any way to determine what is the root cause of this or if this has
> been addressed in an updated version of Qpid/JMS? Thank you for your help.
>

Re: [Qpid Java Broker] Remove Derby jar causes broker to crash when creating a VritualHost with Derby message store or config

[Rob Godfrey]

OK - changed under QPID-7561


-- Rob

On 1 December 2016 at 17:04, Rob Godfrey  wrote:

> Yeah - using the same mechanism as BDB would mean that you wouldn't be
> able to create a Derby vhost / vhostnode if the library wasn't present...
> We basically add a check on startup in the class to see if the necessary
> preconditions for creating an object of the type are met.  At that point
> you'll no longer see the types in the drop downs in the web console.  I'll
> raise a JIRA and make a change on trunk.
>
> -- Rob
>
> On 1 December 2016 at 16:46, Adel Boutros  wrote:
>
>> Hello Rob,
>>
>>
>> Having the same behavior as BerkleyDB is enough for me right now.
>>
>>
>> I don't mind the broker not starting if a VirtualHostNode is missing
>> jars. However, I don't like the fact that a management operation can make a
>> running broker fail especially when you have a lot of messages being
>> exchanged at the same moment.
>>
>>
>> Regards,
>>
>> Adel
>>
>> 
>> From: Rob Godfrey 
>> Sent: Thursday, December 1, 2016 5:08:15 PM
>> To: users@qpid.apache.org
>> Subject: Re: [Qpid Java Broker] Remove Derby jar causes broker to crash
>> when creating a VritualHost with Derby message store or config
>>
>> Just to be clear - the current behaviour of the broker when started with a
>> BDB VirtualHost*Node* and the BDB jar missing is for the broker to fail to
>> start.  A JSON vitualhostnode with a BDB virtualhost will allow the boker
>> to start up, but the virtualhostnode will be in the ERROR state.
>>
>> It would be relatively easy to have the same sort of behaviour for the
>> Derby Virtual Host... It would be a bigger change if you were wanting the
>> broker to start up with VirtualHostNodes which depend on missing
>> libraries.
>>
>> Is this what you are looking for, or are you needing to have the broker
>> start up even with virtual host nodes defined which cannot be created (if
>> you are, I'm not sure there's actually an easy way to solve that)
>>
>> Cheers,
>> Rob
>>
>> On 1 December 2016 at 15:21, Adel Boutros  wrote:
>>
>> > Hello,
>> >
>> >
>> > For legal issues, we are unable to ship Derby in our product. So to be
>> > able to use Qpid, I have removed the Derby jar and relaunched the broker
>> > which had a "Memory" virtual host.
>> >
>> >
>> > I tried to add a new VirtualHostNode/VirtualHost with config and message
>> > store "DERBY" and it crashed. I was expecting it to behave just the way
>> it
>> > does for BerkleyDB when the jar is not present.
>> >
>> >
>> > Is it possible to fix this?
>> >
>> >
>> > Regards,
>> >
>> > Adel
>> >
>> >
>> > Full Stack in broker log
>> >
>> > -
>> >
>> >
>> > [Broker] BRK-1004 : Qpid Broker Ready
>> > 
>> 
>> > #
>> > # Unhandled Exception org.apache.qpid.server.store.StoreException:
>> Failed
>> > to load driver org.apache.derby.jdbc.EmbeddedDriver in Thread
>> > HttpManagement-HTTP-122
>> > #
>> > # Exiting
>> > #
>> > 
>> 
>> > org.apache.qpid.server.store.StoreException: Failed to load driver
>> > org.apache.derby.jdbc.EmbeddedDriver
>> > at org.apache.qpid.server.store.derby.DerbyUtils.loadDerbyDrive
>> > r(DerbyUtils.java:65)
>> > at org.apache.qpid.server.store.derby.DerbyConfigurationStore.o
>> > penConfigurationStore(DerbyConfigurationStore.java:75)
>> > at org.apache.qpid.server.virtualhostnode.AbstractStandardVirtu
>> > alHostNode.activate(AbstractStandardVirtualHostNode.java:84)
>> > at org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNo
>> > de.doActivate(AbstractVirtualHostNode.java:160)
>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> > ssorImpl.java:57)
>> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> > thodAccessorImpl.java:43)
>> > at java.lang.reflect.Method.invoke(Method.java:606)
>> > at org.apache.qpid.server.model.AbstractConfiguredObject.attain
>> > State(AbstractConfiguredObject.java:1266)
>> > at org.apache.qpid.server.model.AbstractConfiguredObject.attain
>> > State(AbstractConfiguredObject.java:1245)
>> > at org.apache.qpid.server.model.AbstractConfiguredObject$8.onSu
>> > ccess(AbstractConfiguredObject.java:864)
>> > at org.apache.qpid.server.model.AbstractConfiguredObject$8.onSu
>> > ccess(AbstractConfiguredObject.java:858)
>> > at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
>> > at com.google.common.util.concurrent.MoreExecutors$DirectExecut
>> > or.execute(MoreExecutors.java:457)
>> > at com.google.common.util.concurrent.ExecutionList.executeListe
>> > ner(ExecutionList.java:156)
>> > at com.google.common.util.concurrent.ExecutionList.add(Executio
>> > nList.java:101)
>> > at com.google.common.util.concurrent.AbstractFuture.addListener
>> > (AbstractFu

[HEADS UP] qpid-cpp 1.36.0, proton 0.16.0

[Robbie Gemmell]

Hi folks,

It has been a few months since qpid-cpp 1.35.0 went out and there have
been a number of improvements and fixes made since, so I think it
would be good to do a qpid-cpp 1.36.0 release soon to go with proton
0.16.0.

As an update on 0.16.0 itself, I'll be looking to make cut of that
either late tomorrow afternoon (UK) or early next week.

Robbie

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

Understanding Topics and Queues association with Exchanges

[James Franco]

I am trying to wrap my head around the association of topics and queues
with an exchange. Here is my understanding so far (please correct me if I
am wrong). In the end I have a question .

Point 1:
Whenever we create a queue by default it is under the default exchange
amq.direct.We can move this queue to a different direct exchange using the
bind command shown below:

./qpid-config bind NameOfDirectExchange NameOfQueue bindingKey

Now I would like to know more about topics. Whenever we create a topic we
use the command resembling the one below

./qpid-config add exchange topic news

Now the above command is basically creating an exchange of topic type.

My question is how can I create a topic without creating a new exchange  ?
Say if I wanted to create a topic under the default exchange amq.topic?

Is it possible for one exchange to have both topics and queues ? I would
think not because an exchnage can be either Direct , topic , fanout or
headers am I correct ?

Re: Understanding Topics and Queues association with Exchanges

[Gordon Sim]

On 01/12/16 18:46, James Franco wrote:

I am trying to wrap my head around the association of topics and queues
with an exchange. Here is my understanding so far (please correct me if I
am wrong). In the end I have a question .

Point 1:
Whenever we create a queue by default it is under the default exchange
amq.direct.We can move this queue to a different direct exchange using the
bind command shown below:

./qpid-config bind NameOfDirectExchange NameOfQueue bindingKey

Now I would like to know more about topics. Whenever we create a topic we
use the command resembling the one below

./qpid-config add exchange topic news

Now the above command is basically creating an exchange of topic type.

My question is how can I create a topic without creating a new exchange  ?
Say if I wanted to create a topic under the default exchange amq.topic?

Is it possible for one exchange to have both topics and queues ? I would
think not because an exchnage can be either Direct , topic , fanout or
headers am I correct ?


In AMQP 0-10 and earlier, messages are always published to an exchange 
and always consumed from queues.


Exchanges have bindings associated with them. These are just rules on 
which queues the exchange should forward (or route) a given message to.


There are different types of exchange. The exchange type dictates what 
form the binding 'rules' can take. For a fanout exchange, a binding to a 
queue means that all messages to that exchange should go to that queue. 
For a direct exchange, each binding specifies a 'key' that is matched 
against a special property (called a routing key) of the message being 
routed using an exact match; messages whose routing key is exactly the 
same as the key of a binding are routed to the queue that binding is 
associated with. A topic exchange also uses a key in its bindings, but 
the matching allows for wildcards.


The 'topic' exchange type is (in my view) an unfortunate choice of name. 
You can achieve JMS style 'topic' semantics using any of the exchange 
types. The difference is whether you need wildcard matching or not.


A queue can be bound to more than one exchange, and there can be more 
than one binding between a given queue and exchange (providing these 
bindings differ in some way, e.g. have a different key). Binding doesn't 
move a queue in any way.


The 'default exchange' is really just a way to give the illusion of 
being able to send direct to a queue. The bindings of the default 
exchange are guaranteed to route a message whose routing key is the 
queue name to that queue (and only that queue).


Hope this helps a little. There are some better explanations of the 
concepts available [1][2][3]. Note though that these concepts are 
specific to pre 1.0 versions of the AMQP protocol.


[1] 
http://qpid.apache.org/releases/qpid-java-6.1.0/java-broker/book/Java-Broker-Concepts-Exchanges.html

[2] https://www.rabbitmq.com/tutorials/amqp-concepts.html
[3] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.1/html/Messaging_User_Guide/chap-Messaging_User_Guide-Exchanges.html



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

Re: I'm using the Qpid Broker and JMS MessageConsumer times out waiting for a sync

[Michael Nachmias]

Hi Rob,

We are using the C++ Broker version 1.35.0. There is an error at the same
time the sync timed out on the Broker:

Nov 29 19:37:23 dc-mb-01 qpidd[902]: 2016-11-29 19:37:23 [Broker] error
Execution exception: not-found: Unknown destination 192
session=**@QPID.c9e6c4f7-8464-463c-9919-e77fdc0d2258
(/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/broker/SemanticState.cpp:572)

Thank you for your help.

Regards,
Michael

On Thu, Dec 1, 2016 at 12:41 PM, Rob Godfrey 
wrote:

> Hi Michael,
>
> Which Broker (Java/C++) are you using?  Is there anything in the broker
> logs indicating an issue at the time where these errors are occurring?
>
> -- Rob
>
> On 1 December 2016 at 17:22, Michael Nachmias 
> wrote:
>
> > Hello,
> >
> > I'm running a enterprise Java web application using Java jdk 1.7.0.101,
> > Qpid 0.30, and JMS 1.1. I'm running into intermittent issues where
> closing
> > or retrieving from the JMS MessageConsumer times out waiting for a sync.
> > The following is the stack trace of the exception:
> >
> > 2016-11-29 19:38:23,791 DEBUG [org.apache.qpid.client.AMQConnection]
> > (ajp-/10.1.15.14:8009-21) exceptionReceived done by:ajp-/10.1.15.14:8009
> > -21:
> > org.apache.qpid.AMQException: timed out waiting for sync: complete =
> 23136,
> > point = 23141 [error code 541: internal error]
> > at org.apache.qpid.client.AMQSession_0_10.setCurrentException(
> > AMQSession_0_10.java:1081)
> > [qpid-client-0.30.jar:0.30]
> > at org.apache.qpid.client.BasicMessageConsumer_0_10.sendCancel(
> > BasicMessageConsumer_0_10.java:175) [qpid-client-0.30.jar:0.30]
> > at org.apache.qpid.client.BasicMessageConsumer.close(
> > BasicMessageConsumer.java:613)
> > [qpid-client-0.30.jar:0.30]
> > at org.apache.qpid.client.BasicMessageConsumer.close(
> > BasicMessageConsumer.java:573)
> > [qpid-client-0.30.jar:0.30]
> >
> > Is there any way to determine what is the root cause of this or if this
> has
> > been addressed in an updated version of Qpid/JMS? Thank you for your
> help.
> >
>

Re: Understanding Topics and Queues association with Exchanges

[James Franco]

Thanks for the reply Gordon , so another question that I had regarding the
same topic was about the hello world example and how it is functioning ? In
that example , we have a message producer and a consumer the producer sends
a message to the default topic exchange amq.topic . Now I am confused with
the example primarily because of two reasons:
1-A message is being sent to a default Topic Exchange however no queue has
been associated with it ? Dont topic exchanges have topic queues
2-What is the routing key of the message being sent ? since there is no
subject in the message isnt the routing key empty ?

I would appreciate it if you could help me understand that.


On Thu, Dec 1, 2016 at 7:52 PM, Gordon Sim  wrote:

> On 01/12/16 18:46, James Franco wrote:
>
>> I am trying to wrap my head around the association of topics and queues
>> with an exchange. Here is my understanding so far (please correct me if I
>> am wrong). In the end I have a question .
>>
>> Point 1:
>> Whenever we create a queue by default it is under the default exchange
>> amq.direct.We can move this queue to a different direct exchange using the
>> bind command shown below:
>>
>> ./qpid-config bind NameOfDirectExchange NameOfQueue bindingKey
>>
>> Now I would like to know more about topics. Whenever we create a topic we
>> use the command resembling the one below
>>
>> ./qpid-config add exchange topic news
>>
>> Now the above command is basically creating an exchange of topic type.
>>
>> My question is how can I create a topic without creating a new exchange  ?
>> Say if I wanted to create a topic under the default exchange amq.topic?
>>
>> Is it possible for one exchange to have both topics and queues ? I would
>> think not because an exchnage can be either Direct , topic , fanout or
>> headers am I correct ?
>>
>
> In AMQP 0-10 and earlier, messages are always published to an exchange and
> always consumed from queues.
>
> Exchanges have bindings associated with them. These are just rules on
> which queues the exchange should forward (or route) a given message to.
>
> There are different types of exchange. The exchange type dictates what
> form the binding 'rules' can take. For a fanout exchange, a binding to a
> queue means that all messages to that exchange should go to that queue. For
> a direct exchange, each binding specifies a 'key' that is matched against a
> special property (called a routing key) of the message being routed using
> an exact match; messages whose routing key is exactly the same as the key
> of a binding are routed to the queue that binding is associated with. A
> topic exchange also uses a key in its bindings, but the matching allows for
> wildcards.
>
> The 'topic' exchange type is (in my view) an unfortunate choice of name.
> You can achieve JMS style 'topic' semantics using any of the exchange
> types. The difference is whether you need wildcard matching or not.
>
> A queue can be bound to more than one exchange, and there can be more than
> one binding between a given queue and exchange (providing these bindings
> differ in some way, e.g. have a different key). Binding doesn't move a
> queue in any way.
>
> The 'default exchange' is really just a way to give the illusion of being
> able to send direct to a queue. The bindings of the default exchange are
> guaranteed to route a message whose routing key is the queue name to that
> queue (and only that queue).
>
> Hope this helps a little. There are some better explanations of the
> concepts available [1][2][3]. Note though that these concepts are specific
> to pre 1.0 versions of the AMQP protocol.
>
> [1] http://qpid.apache.org/releases/qpid-java-6.1.0/java-broker/
> book/Java-Broker-Concepts-Exchanges.html
> [2] https://www.rabbitmq.com/tutorials/amqp-concepts.html
> [3] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp
> rise_MRG/1.1/html/Messaging_User_Guide/chap-Messaging_
> User_Guide-Exchanges.html
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Understanding Topics and Queues association with Exchanges

[Gordon Sim]

On 01/12/16 20:18, James Franco wrote:

Thanks for the reply Gordon , so another question that I had regarding the
same topic was about the hello world example and how it is functioning ? In
that example , we have a message producer and a consumer the producer sends
a message to the default topic exchange amq.topic . Now I am confused with
the example primarily because of two reasons:
1-A message is being sent to a default Topic Exchange however no queue has
been associated with it ? Dont topic exchanges have topic queues
2-What is the routing key of the message being sent ? since there is no
subject in the message isnt the routing key empty ?


This is the qpid::messaging hello world example?

Assuming so, the qpid messaging api aims to mask some of the protocol 
specifics. So when you create a receiver with 'amq.topic' as the source, 
the library - if using AMQP 0-10 - will first determine whether that 
source is a queue or an exchange. If it is an exchange (as it will be 
for amq.topic) it then creates a temporary queue on the broker and binds 
that to the exchange in question.


This lets you use an exchange name in the way you would use a topic in 
JMS, i.e. for a non-competing consumer pattern.


The binding used depends on the topic type (which the client determines 
by asking the broker) and the subject (or other details of the address). 
Since no 'subject' is specified by default in hello world, and the 
exchange type is a 'topic' exchange that supports wildcarding, the key 
used for the binding is '#' which matches anything.



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

Re: I'm using the Qpid Broker and JMS MessageConsumer times out waiting for a sync

[Gordon Sim]

On 01/12/16 20:16, Michael Nachmias wrote:

We are using the C++ Broker version 1.35.0. There is an error at the same
time the sync timed out on the Broker:

Nov 29 19:37:23 dc-mb-01 qpidd[902]: 2016-11-29 19:37:23 [Broker] error
Execution exception: not-found: Unknown destination 192
session=**@QPID.c9e6c4f7-8464-463c-9919-e77fdc0d2258
(/builddir/build/BUILD/qpid-cpp-1.35.0/src/qpid/broker/SemanticState.cpp:572)


How easy is it to reproduce the error? Is it feasible to reproduce with 
protocol level tracing enabled on the broker? E.g. pass --log-enable 
notice+ --log-enable trace+:Protocol to qpidd when starting?


That would provide a bit more context. The error suggests that some 
operation was attempted on a consumer that the broker did not think existed.


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

Re: Understanding Topics and Queues association with Exchanges

[James Franco]

yes it is the qpid hello world example . In your statement

"The binding used depends on the topic type (which the client determines by
asking the broker) and the subject (or other details of the address). Since
no 'subject' is specified by default in hello world, and the exchange type
is a 'topic' exchange that supports wildcarding, the key used for the
binding is '#' which matches anything."address). Since no 'subject' is
specified by default in hello world, and the exchange type is a 'topic'
exchange that supports wildcarding, the key used for the binding is '#'
which matches anything."

Does that mean if a listener is listening to a TopicExchange instead of a
queue then it is bound to all the queues of the exchange (i.e the listener
will get whatever goes through the exchange to other queues) ?

Re: Understanding Topics and Queues association with Exchanges

[Rob Godfrey]

On Fri, 2 Dec 2016 at 00:01, James Franco  wrote:

> yes it is the qpid hello world example . In your statement
>
> "The binding used depends on the topic type (which the client determines by
> asking the broker) and the subject (or other details of the address). Since
> no 'subject' is specified by default in hello world, and the exchange type
> is a 'topic' exchange that supports wildcarding, the key used for the
> binding is '#' which matches anything."address). Since no 'subject' is
> specified by default in hello world, and the exchange type is a 'topic'
> exchange that supports wildcarding, the key used for the binding is '#'
> which matches anything."
>
> Does that mean if a listener is listening to a TopicExchange instead of a
> queue then it is bound to all the queues of the exchange (i.e the listener
> will get whatever goes through the exchange to other queues) ?
>

By definition a listener (consumer) in AMQP 0.x can only listen (consume)
from a queue (there is no way to listen to an exchange).

The addressing syntax used by the clients is an attempt to abstract away
from the implementation details (queues and exchanges) into more common
notions such as topics. If you subscribe to an address like foo/bar which
you expect to provide topic like semantics... then what the client will be
doing under the covers is creating a temporary queue, binding that to the
exchange foo with the binding key bar and then listening for message
arrivals into that temporary queue. Similarly subscribing to just amq.topic
will bind (with a wildcard) a temporary queue which will receive all
messages sent to the exchange. One thing that is very misleading in all
this is that there is nothing specifically "topic" like about the topic
exchange... it would have much better been called the wildcard exchange.
You can equally well get topic like behavior from any of the other exchange
types

-- Rob

Re: Understanding Topics and Queues association with Exchanges

[James Franco]

Ok that makes sense thanks for clearing that up

On Thu, Dec 1, 2016 at 11:24 PM, Rob Godfrey 
wrote:

> On Fri, 2 Dec 2016 at 00:01, James Franco  wrote:
>
> > yes it is the qpid hello world example . In your statement
> >
> > "The binding used depends on the topic type (which the client determines
> by
> > asking the broker) and the subject (or other details of the address).
> Since
> > no 'subject' is specified by default in hello world, and the exchange
> type
> > is a 'topic' exchange that supports wildcarding, the key used for the
> > binding is '#' which matches anything."address). Since no 'subject' is
> > specified by default in hello world, and the exchange type is a 'topic'
> > exchange that supports wildcarding, the key used for the binding is '#'
> > which matches anything."
> >
> > Does that mean if a listener is listening to a TopicExchange instead of a
> > queue then it is bound to all the queues of the exchange (i.e the
> listener
> > will get whatever goes through the exchange to other queues) ?
> >
>
> By definition a listener (consumer) in AMQP 0.x can only listen (consume)
> from a queue (there is no way to listen to an exchange).
>
> The addressing syntax used by the clients is an attempt to abstract away
> from the implementation details (queues and exchanges) into more common
> notions such as topics. If you subscribe to an address like foo/bar which
> you expect to provide topic like semantics... then what the client will be
> doing under the covers is creating a temporary queue, binding that to the
> exchange foo with the binding key bar and then listening for message
> arrivals into that temporary queue. Similarly subscribing to just amq.topic
> will bind (with a wildcard) a temporary queue which will receive all
> messages sent to the exchange. One thing that is very misleading in all
> this is that there is nothing specifically "topic" like about the topic
> exchange... it would have much better been called the wildcard exchange.
> You can equally well get topic like behavior from any of the other exchange
> types
>
> -- Rob
>

How to reference a default exchange - spout fails

[James Franco]

I created a queue using the command:

>> ./qpid-config add queue test_queue

Then I get something like this

./qpid-config exchanges -r



*Exchange '' (direct)bind [bd2dfd48-6f3f-4807-b591-df543a306403:0.0] =>
bd2dfd48-6f3f-4807-b591-df543a306403:0.0bind [qservice_queue] =>
qservice_queuebind [test_queue] => test_queue*
Exchange 'amq.direct' (direct)
Exchange 'amq.fanout' (fanout)
Exchange 'amq.match' (headers)
Exchange 'amq.topic' (topic)
Exchange 'qmf.default.direct' (direct)
Exchange 'qmf.default.topic' (topic)
bind [direct.09701f02-2092-4752-b7e8-7a4ba976fbc9] =>
bd2dfd48-6f3f-4807-b591-df543a306403:0.0
Exchange 'qpid.management' (topic)
Exchange 'qservice' (topic)
bind [*.test] => qservice_queue
bind [testbind] => qservice_queue

My question is how can I access a default exchnage , say if I wanted to do
something like this

>>./spout ' '/test_queue SOME_TEST_CONTENT
  File "./spout", line 101, in 
snd = ssn.sender(addr)
  File "", line 6, in sender
  File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line
600, in sender
raise e
qpid.messaging.exceptions.MalformedAddress: unexpected token SLASH(/)
line:1,1: /test_queue

How can I reference the default exchange as it has a queue called
test_queue bound to it by the id test_queue ?  I tried doing this (I also
want to attach a subject to it with the id test_queue)

 >>./spout ' '/test_queue SOME_TEST_CONTENT

but that does not work. Any suggestions ?