You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Jakub Scholz <sc...@scholzj.com> on 2010/06/15 20:53:25 UTC
Problems with JMS API
Hi,
I'm providing Qpid based service, which allows client's applications
to connect to the broker, send requests, receive responses and receive
broadcasts (via topic exchange). Since there are different clients
connecting with their own applications, the clients are strictly
limited to do only some actions. Currently, I have fully working test
application, which is written in Java and is relying on the old Qpid
API. Since the Qpid API is not really supported, I was trying to
rewrite this application to JMS. Unfortunately, I run into several
problems:
1) To send requests, the client should send the message to a direct
exchange specific for every client. The message needs to have a client
specific routing key defined, which routes the message to a queue
where it is picked up by the server application. The exchanges are
predefined and the client is forbidden to define exchanges. Doing this
with Qpid API is not a problem. I tried to do so in the JMS with
following code (it is based on the JMS examples):
_producer = session.createProducer(null);
TextMessage txtMessage;
txtMessage = session.createTextMessage("<?xml version=\"1.0\"
encoding=\"UTF-8\" standalone=\"no\"?><FIXML>.....</FIXML>");
_producer.send(requestDestination, txtMessage);
The destination called requestDestination is defined using JNDI as
direct://service.CLIENT_X/?routingkey='CLIENT_X.XYZ'. However, when I
run this code against the broker, the message is not send and it fails
with "ACL denied exchange declare request" (however, this error
appears only in the broker log file, not on the client). Running the
program with "-Dqpid.declare_exchanges=FALSE" doesn't help. I
discussed this problem here already a year ago, it should be caused by
BasicMessageProducer_0_10, method declareDestination. However, when I
comment out the exchangeDeclare call in this method, it fixes the
problem with ACL, but it cause's my broker to crash after processing
the message, which I don't know how to fix.
2) To receive responses, the client has to create his own queue and
bind the queue with another direct exchange. The queue name as well as
the routing key have to be in a specific format. The queue needs to be
autodelete, exclusive and have RING policy type with max_size 1000. I
tried following JMS code:
MessageConsumer responseConsumer = session.createConsumer(responseDestination);
responseConsumer.setMessageListener(this);
Where response destination is
direct://service.response/service.tmp.CLIENT_X.123456_resp?routingkey='CLIENT_X.56789'&autodelete='TRUE'&exclusive='TRUE'.
But I don't know, how to define the policytype=RING and max_size=1000.
All parameters I tried are ignored. And without proper policy type and
queue size, I fail again on ACL (this time, the error handling works
fine => I get a proper exception on the client side). How can I
specify the policytype and max_size?
3) To receive broadcasts, the clients have to create their own queue
and subscribe the broadcasts using an binding between topic exchange
and their queue. I tried to use the same consumer as in point 2), but
since this is an topic exchange, I cannot use following destination
direct://service.broadcast/service.tmp.CLIENT_X.123456_bcast?routingkey='#.weather.usa.#'&autodelete='TRUE'&exclusive='TRUE'.
It is forcing me to use the Topic JNDI. But if I specify the topic
JNDI just as #.weather.usa.#, it is trying to bind the default topic
exchange amq.topic (which is different from the exchange I want to
use) and it uses queue with different name and parameters, then what
the client is allowed to. How can I setup binding between a specific
topic exchange and my own very specific queue? (possibly with more
bindings to the same queue)
The configuration on the broker may look quite strict, but I see that
as the only way to provide a stable service to all connected clients.
Since the service is already running, I'm not free to change the
configuration as I want. Therefore, I prefer finding a solution which
would fit the configuration.
FYI: I was trying this with Qpid 0.5, 0.6 as well as the latest trunk.
The broker is C++ ...
Thanks & Regards
Jakub Scholz
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Problems with JMS API
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Rajith,
One more question, hopefully the last one (since now thanks to you,
almost everything is working) ... can I somehow add more bindings to
existing consumer? The address for subscribing multiple bindings into
one queue you suggested before ... "my-own-topic-exchange/usa.#;
{create: receiver, link {name: my queue, x-declare: {auto-delete:
true, 'qpid.max_size': 1000} , x-bindings: [{exchange : 'amq.direct',
key : test},{exchange : 'amq.topic', key : 'xyz.#'}]} }" ... works
nicely. I create a destination from this address and based on the
destination, I create the consumer using
session.createConsumer(Destination dest).
But is there any possibility to add subscription keys to this existing
consumer? I can create another consumer, which would subscribe the new
bindings to the same queue, but this solution doesn't seem elegant
enough for me :-o.
Thanks & Regards
Jakub Scholz
On Mon, Jun 28, 2010 at 16:14, Rajith Attapattu <ra...@gmail.com> wrote:
> On Mon, Jun 28, 2010 at 5:25 AM, Jakub Scholz <ja...@scholz.cz> wrote:
>> Hi Rajith,
>>
>> Thanks for the fix - the first three problems are working as expected
>> with latest trunk. I used following address when I found these
>> problems:
>
> Thanks for checking it out and letting me know.
>
>> amq.direct/CLIENT_X.56789; {create: receiver, link : {name :
>> 'service.tmp.CLIENT_X.123456_resp', x-declare : { auto-delete: true,
>> exclusive: true, 'qpid.max_size': 1000, 'qpid.policy_type': ring } } }
>>
> Thx !
>
>> Regarding the "access" right ... I believe in case it would be
>> necessary, we can add the "access" right to the ACL list. The C++ API
>> (version 0.5) and .NET API (version 0.6) are running successfully
>> against the same ACL setup as I'm running this JMS based application.
>
> Are you doing any explicit exchange queries and exchange binds ?
> If yes then the ACL should fail them. If thats not the case then it
> should be a bug and I'd appreciate any info you have on them.
>
>> But these older versions of course don't use the new addressing
>> scheme. From my point of view, it would be great to have a possibility
>> to bypass this querying functionality (for example by another option
>> in address). But I don't have enough knowledge about the APIs to know
>> whether it is possible or isn't.
>
> The new addressing scheme is common to all clients and we aim to have
> a consistent behaviour.
> When interpreting an address-string the client needs to figure out if
> it's an exchange or a queue if the node type is missing (for 0-10) and
> if it actually exists.
> So there will be an exchange and/or queue query. So those permissions
> are needed in the current ACL model.
> I guess your question is, whether we could turn off the querying for
> existence if the node type is present ?
>
>> Thanks & Regards
>> Jakub Scholz
>>
>> On Fri, Jun 25, 2010 at 22:33, Rajith Attapattu <ra...@gmail.com> wrote:
>>> Hello Jakub,
>>>
>>> I have fixed the fist 3 problems in rev 958102 on qpid trunk.
>>> Many thanks for bringing this to my attention.
>>>
>>> Could you also specify the address string that cause each of these problems?
>>>
>>> As for problem 4, if you are using ACL then you need explicit
>>> permission to access (query) or bind to an exchange.
>>> When using type : queue then the "address" is taken as a queue and
>>> then will be bound to any exchange explicitly specified in string.
>>> (By default every queue created is bound to the nameless exchange with
>>> queue name as the binding key).
>>>
>>> If using type : topic then address is considered as an exchange and
>>> the client will try to see if an exchange by the name exists. Hence
>>> the call to exchange query.
>>>
>>> I was a bit surprised when you mentioned that you don't get this with
>>> the c++ API and .NET API.
>>> Could you provide more details on that ?
>>>
>>> If ACL is used then permissions will determine who can access what.
>>>
>>> Regards,
>>>
>>> Rajith
>>>
>>> On Fri, Jun 25, 2010 at 1:46 PM, Jakub Scholz <ja...@scholz.cz> wrote:
>>>> Hi Rajith,
>>>>
>>>> You don't need to apologize, I'm glad for any help. I builded the
>>>> latest trunk and tried it again. The previous problem with the
>>>> PropertiesFileInitialContextFactoryis indeed fixed. I run into few
>>>> other problems regarding the addresses:
>>>>
>>>> 1) When I used the addresses you suggested, it was complaining about
>>>> NullPointerException in AddressHelper.getLink
>>>>
>>>> WARNUNG: Unable to create destination:java.lang.NullPointerException
>>>> java.lang.NullPointerException
>>>> at org.apache.qpid.client.messaging.address.AddressHelper.getLink(AddressHelper.java:326)
>>>> at org.apache.qpid.client.AMQDestination.getInfoFromAddress(AMQDestination.java:823)
>>>> at org.apache.qpid.client.AMQDestination.<init>(AMQDestination.java:157)
>>>> at org.apache.qpid.client.AMQAnyDestination.<init>(AMQAnyDestination.java:52)
>>>> at org.apache.qpid.client.AMQDestination.createDestination(AMQDestination.java:669)
>>>> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestination(PropertiesFileInitialContextFactory.java:240)
>>>> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestinations(PropertiesFileInitialContextFactory.java:160)
>>>> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.getInitialContext(PropertiesFileInitialContextFactory.java:117)
>>>> at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>>> at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>>> at javax.naming.InitialContext.init(Unknown Source)
>>>> at javax.naming.InitialContext.<init>(Unknown Source)
>>>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:18)
>>>> at jms.Client.main(Client.java:329)
>>>>
>>>> This problem seems to be caused by missing capacity option in my
>>>> Address. After i added capacity: 1000, this problem didn't appeared
>>>> again. Maybe some default CAPACITY value should be added to the
>>>> AddressHelper.
>>>>
>>>> 2) The qpid.policy-type option seems to be expecting integer instead
>>>> of String. Therefore, when I tried to set policy-type to ring, I got
>>>> following exception:
>>>>
>>>> java.lang.NumberFormatException: For input string: "ring"
>>>> at java.lang.NumberFormatException.forInputString(Unknown Source)
>>>> at java.lang.Integer.parseInt(Unknown Source)
>>>> at java.lang.Integer.parseInt(Unknown Source)
>>>> at org.apache.qpid.configuration.Accessor$MapAccessor.getInt(Accessor.java:101)
>>>> at org.apache.qpid.client.messaging.address.AddressHelper.getQpidQueueOptions(AddressHelper.java:132)
>>>> at org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(AddressHelper.java:273)
>>>> at org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(AddressHelper.java:300)
>>>> at org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestination.java:832)
>>>> at org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1217)
>>>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1144)
>>>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>>>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>>>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>>>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>>>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>>>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>>>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>>>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>>>> at jms.Client.main(Client.java:329)
>>>>
>>>> After changing the args.getInt(...) to args.getString(...) on line 132
>>>> of AddressHelper class.
>>>>
>>>> 3) The last exception I run into was this:
>>>>
>>>> java.lang.NullPointerException
>>>> at org.apache.qpid.client.messaging.address.AddressHelper.fillInCommonNodeArgs(AddressHelper.java:281)
>>>> at org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(AddressHelper.java:274)
>>>> at org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(AddressHelper.java:300)
>>>> at org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestination.java:832)
>>>> at org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1217)
>>>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1144)
>>>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>>>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>>>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>>>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>>>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>>>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>>>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>>>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>>>> at jms.Client.main(Client.java:329)
>>>>
>>>> On the line 281 of AddressHelper, the null check is missing again.
>>>> After verifying whether nodeProps != null the problem seemed to be
>>>> fixed.
>>>>
>>>> 4) The last problem I found so far was, that the JMS API needed the
>>>> access right to the exchange I was binding. That is currently
>>>> forbidden on our system. This right was not needed with the old Qpid
>>>> API or in c++ and .NET APIs. I was getting following errors:
>>>>
>>>> INFO: Created session:org.apache.qpid.client.AMQSession_0_10@b1a4e2
>>>> org.apache.qpid.transport.SessionException: ch=0 id=0
>>>> ExecutionException(errorCode=NOT_ALLOWED, commandId=0, classCode=7,
>>>> commandCode=6, fieldIndex=0, description=not-allowed: ACL denied
>>>> exchange bound request from client@QPID5318
>>>> (qpid/broker/SessionAdapter.cpp:238), errorInfo={})
>>>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:847)
>>>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:859)
>>>> at org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1203)
>>>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1144)
>>>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>>>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>>>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>>>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>>>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>>>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>>>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>>>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>>>> at jms.Client.main(Client.java:329)
>>>>
>>>> I tried to force the node type with "node: { type: topic }", which
>>>> gave me different error:
>>>>
>>>> INFO: Created session:org.apache.qpid.client.AMQSession_0_10@2016b0
>>>> org.apache.qpid.transport.SessionException: ch=0 id=0
>>>> ExecutionException(errorCode=NOT_ALLOWED, commandId=0, classCode=7,
>>>> commandCode=3, fieldIndex=0, description=not-allowed: ACL denied
>>>> exchange query request from client@QPID5318
>>>> (qpid/broker/SessionAdapter.cpp:153), errorInfo={})
>>>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:847)
>>>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:859)
>>>> at org.apache.qpid.client.AMQSession_0_10.isExchangeExist(AMQSession_0_10.java:1041)
>>>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1165)
>>>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>>>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>>>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>>>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>>>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>>>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>>>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>>>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>>>> at jms.Client.main(Client.java:329)
>>>>
>>>> But I still need the access rights to the exchange to get it working.
>>>> I tried to use the assert option, but it doesn't help. Can I somehow
>>>> bypass this or is adding the access right for the exchange the only
>>>> possibility?
>>>>
>>>> Thanks & Regards
>>>> Jakub
>>>>
>>>> On Fri, Jun 25, 2010 at 16:06, Rajith Attapattu <ra...@gmail.com> wrote:
>>>>> Hi Jakub,
>>>>>
>>>>> Apologies for the delay in replying to you. I was down with the flu
>>>>> this week and it derailed most of my plans.
>>>>> Anyways there was a bug (QPID-2696) in Qpid which cause the issue you reported.
>>>>> I have fixed this in rev 957942 in trunk.
>>>>> Please give it a try and let us know.
>>>>> Again, very sorry for the delay in responding.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Rajith
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Rajith Attapattu
>>> Red Hat
>>> http://rajith.2rlabs.com/
>>>
>>
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Problems with JMS API
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Jul 1, 2010 at 2:25 PM, Jakub Scholz <ja...@scholz.cz> wrote:
> Hi Rajith,
>
> Sorry for the late answer, I was busy with different project. The
> older API's work as expected - if I call query on exchange or queue, I
> need the access right.- However, since on our system, we the client
> expects, that the exchanges exist and if they don't, then the client
> anyway doesn't have the right to create them and he cannot use our
> service (from my point of view, it doesn't really matter, whether he
> gets an exception or whether he finds it out using exchange query).
> Therefore, until know, we were able to develop client application
> without the need of the access right for the exchanges. Therefore, I
> believe it would be great to have the option to define in the address
> string, that I'm sure that the node exists and that will force the API
> to skip the queries on exchanges/queues.
The code will be changed as follows.
The client will always do a queue/exchange-declare with a passive=true
to assert the node exists.
If assert evaluates to true then an additional queue/exchange query
will be done to assert all properties.
So in your case you could avoid the exchange/queue query by having
assert=never (which is the default).
In your ACL you would need the following permissions. (Assuming you
are using deny mode)
acl allow all queue declare passive=true
acl allow all exchange declare passive=true
If you have any further questions, please feel free to ask.
> I have also few other comments/questions to what I found so far:
>
> 1) The JMSReplyTo method is expecting JMS Destination as a parameter.
> In the AMQMessageDelegate_0_10, the destination is converted to
> AMQDestination, to get the exchange name and routing key. However, it
> seems, that the destination needs to be initiated by creating
> consumer/producer. When I passed a destination which was not used in
> consumer / producer (even when the address was the same, only the
> object was different), I got NullPointerException, because the
> getExchangeName and getRoutingKey methods from AMQDestination return
> null:
>
> Code:
> Destination response = (Destination) context.lookup("response");
> Destination replyto = (Destination) context.lookup("replyto");
>
> MessageConsumer messageConsumer = session.createConsumer(response);
>
> TextMessage message = session.createTextMessage("Hello world!");
> message.setJMSReplyTo(response); // works fine
> message.setJMSReplyTo(replyto); // triggers the exception
>
> Exception:
>
> java.lang.NullPointerException
> at org.apache.qpid.client.message.AMQMessageDelegate_0_10.setJMSReplyTo(AMQMessageDelegate_0_10.java:251)
> at org.apache.qpid.client.message.AbstractJMSMessage.setJMSReplyTo(AbstractJMSMessage.java:138)
> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:46)
> at jms.Client.main(Client.java:329)
>
> Is it expected behavior that I cannot use every destination in
> ReplyTo? I would expect, that I should be able to to every destination
> I wan't, since I nay send a request which should be delivered to other
> client application.
This is a bug - I will fix shortly.
> 2) Our broker setup is using queues and exchanges with same names. I'm
> trying to send an message to the exchange with specific routing key.
> I'm using this Address: "service.CLIENT/CLIENT.ERS; { create: never
> }". The API complains, that the object is ambiguous, because both
> exchange and queue with the name "service.CLIENT" exist. Therefore, I
> specify the node type to "topic" (because it is an exchange, not a
> queue) by using a following address: "service.CLIENT/CLIENT.ERS; {
> node: { type: topic }, create: never }". But, the service.CLIENT
> exchange is direct, not topic. And therefore I'm getting following
> exception:
>
> org.apache.qpid.AMQException: The name 'service.CLIENT' supplied in
> the address doesn't resolve to an exchange or a queue
> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1194)
> at org.apache.qpid.client.BasicMessageProducer_0_10.declareDestination(BasicMessageProducer_0_10.java:81)
> at org.apache.qpid.client.BasicMessageProducer.<init>(BasicMessageProducer.java:141)
> at org.apache.qpid.client.BasicMessageProducer_0_10.<init>(BasicMessageProducer_0_10.java:60)
> at org.apache.qpid.client.AMQSession_0_10.createMessageProducer(AMQSession_0_10.java:633)
> at org.apache.qpid.client.AMQSession_0_10.createMessageProducer(AMQSession_0_10.java:82)
> at org.apache.qpid.client.AMQSession$6.execute(AMQSession.java:2369)
> at org.apache.qpid.client.AMQSession$6.execute(AMQSession.java:2364)
> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
> at org.apache.qpid.client.AMQSession.createProducerImpl(AMQSession.java:2362)
> at org.apache.qpid.client.AMQSession.createProducerImpl(AMQSession.java:2356)
> at org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:1046)
> at org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:95)
> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
> at jms.Client.main(Client.java:329)
>
> I traced this problem into the method isExchangeExist(...) of
> AMQSession_0_10, where the exchange type is compared, and since my
> exchange is direct and not topic, it returns that the exchange doesn't
> exist. How can I send the message to direct exchange, when there is no
> type "direct", but only "queue" and "topic"? When I bypass the
> exchange type check on line 1056 of AMQSession_0_10, it works
> perfectly fine.
>
Again another bug. - I will fix this as well.
> 3) I'm using this Address as the ReplyTo property:
> "amq.direct/CLIENT_X.56789; {create: receiver, link : {name :
> 'service.tmp.CLIENT_X.123456_resp', x-declare : { auto-delete: true,
> exclusive: true, 'qpid.max_size': 1000, 'qpid.policy_type': ring } }
> }". My server application prepares an response and sends it back to
> the replyTo address. When I receive the message and check the
> JMSDestination, I can see following:
>
> JMS Destination:
> direct://amq.direct/CLIENT_X.56789/CLIENT_X.56789?routingkey='CLIENT_X.56789'
>
> I would expect to see something like this (ie. the routing key is used ):
>
> JMS Destination: direct://amq.direct/?routingkey='CLIENT_X.56789'
>
> Nevertheless, the response is correctly delivered to amq.direct
> exchange with routing key CLIENT_X.56789 and routed to the queue
> service.tmp.CLIENT_X.123456_resp. I just noticed, that the destination
> contains the desired routing key several times - may be it is correct
> like this.
I need to find a way to get the toString method to print the
destination correctly.
Thanks again for the detailed explanations.
> Thanks & Regards
> Jakub
>
> On Mon, Jun 28, 2010 at 16:14, Rajith Attapattu <ra...@gmail.com> wrote:
>> On Mon, Jun 28, 2010 at 5:25 AM, Jakub Scholz <ja...@scholz.cz> wrote:
>>> Hi Rajith,
>>>
>>> Thanks for the fix - the first three problems are working as expected
>>> with latest trunk. I used following address when I found these
>>> problems:
>>
>> Thanks for checking it out and letting me know.
>>
>>> amq.direct/CLIENT_X.56789; {create: receiver, link : {name :
>>> 'service.tmp.CLIENT_X.123456_resp', x-declare : { auto-delete: true,
>>> exclusive: true, 'qpid.max_size': 1000, 'qpid.policy_type': ring } } }
>>>
>> Thx !
>>
>>> Regarding the "access" right ... I believe in case it would be
>>> necessary, we can add the "access" right to the ACL list. The C++ API
>>> (version 0.5) and .NET API (version 0.6) are running successfully
>>> against the same ACL setup as I'm running this JMS based application.
>>
>> Are you doing any explicit exchange queries and exchange binds ?
>> If yes then the ACL should fail them. If thats not the case then it
>> should be a bug and I'd appreciate any info you have on them.
>>
>>> But these older versions of course don't use the new addressing
>>> scheme. From my point of view, it would be great to have a possibility
>>> to bypass this querying functionality (for example by another option
>>> in address). But I don't have enough knowledge about the APIs to know
>>> whether it is possible or isn't.
>>
>> The new addressing scheme is common to all clients and we aim to have
>> a consistent behaviour.
>> When interpreting an address-string the client needs to figure out if
>> it's an exchange or a queue if the node type is missing (for 0-10) and
>> if it actually exists.
>> So there will be an exchange and/or queue query. So those permissions
>> are needed in the current ACL model.
>> I guess your question is, whether we could turn off the querying for
>> existence if the node type is present ?
>>
>>> Thanks & Regards
>>> Jakub Scholz
>>>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Problems with JMS API
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Rajith,
Sorry for the late answer, I was busy with different project. The
older API's work as expected - if I call query on exchange or queue, I
need the access right.- However, since on our system, we the client
expects, that the exchanges exist and if they don't, then the client
anyway doesn't have the right to create them and he cannot use our
service (from my point of view, it doesn't really matter, whether he
gets an exception or whether he finds it out using exchange query).
Therefore, until know, we were able to develop client application
without the need of the access right for the exchanges. Therefore, I
believe it would be great to have the option to define in the address
string, that I'm sure that the node exists and that will force the API
to skip the queries on exchanges/queues.
I have also few other comments/questions to what I found so far:
1) The JMSReplyTo method is expecting JMS Destination as a parameter.
In the AMQMessageDelegate_0_10, the destination is converted to
AMQDestination, to get the exchange name and routing key. However, it
seems, that the destination needs to be initiated by creating
consumer/producer. When I passed a destination which was not used in
consumer / producer (even when the address was the same, only the
object was different), I got NullPointerException, because the
getExchangeName and getRoutingKey methods from AMQDestination return
null:
Code:
Destination response = (Destination) context.lookup("response");
Destination replyto = (Destination) context.lookup("replyto");
MessageConsumer messageConsumer = session.createConsumer(response);
TextMessage message = session.createTextMessage("Hello world!");
message.setJMSReplyTo(response); // works fine
message.setJMSReplyTo(replyto); // triggers the exception
Exception:
java.lang.NullPointerException
at org.apache.qpid.client.message.AMQMessageDelegate_0_10.setJMSReplyTo(AMQMessageDelegate_0_10.java:251)
at org.apache.qpid.client.message.AbstractJMSMessage.setJMSReplyTo(AbstractJMSMessage.java:138)
at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:46)
at jms.Client.main(Client.java:329)
Is it expected behavior that I cannot use every destination in
ReplyTo? I would expect, that I should be able to to every destination
I wan't, since I nay send a request which should be delivered to other
client application.
2) Our broker setup is using queues and exchanges with same names. I'm
trying to send an message to the exchange with specific routing key.
I'm using this Address: "service.CLIENT/CLIENT.ERS; { create: never
}". The API complains, that the object is ambiguous, because both
exchange and queue with the name "service.CLIENT" exist. Therefore, I
specify the node type to "topic" (because it is an exchange, not a
queue) by using a following address: "service.CLIENT/CLIENT.ERS; {
node: { type: topic }, create: never }". But, the service.CLIENT
exchange is direct, not topic. And therefore I'm getting following
exception:
org.apache.qpid.AMQException: The name 'service.CLIENT' supplied in
the address doesn't resolve to an exchange or a queue
at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1194)
at org.apache.qpid.client.BasicMessageProducer_0_10.declareDestination(BasicMessageProducer_0_10.java:81)
at org.apache.qpid.client.BasicMessageProducer.<init>(BasicMessageProducer.java:141)
at org.apache.qpid.client.BasicMessageProducer_0_10.<init>(BasicMessageProducer_0_10.java:60)
at org.apache.qpid.client.AMQSession_0_10.createMessageProducer(AMQSession_0_10.java:633)
at org.apache.qpid.client.AMQSession_0_10.createMessageProducer(AMQSession_0_10.java:82)
at org.apache.qpid.client.AMQSession$6.execute(AMQSession.java:2369)
at org.apache.qpid.client.AMQSession$6.execute(AMQSession.java:2364)
at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
at org.apache.qpid.client.AMQSession.createProducerImpl(AMQSession.java:2362)
at org.apache.qpid.client.AMQSession.createProducerImpl(AMQSession.java:2356)
at org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:1046)
at org.apache.qpid.client.AMQSession.createProducer(AMQSession.java:95)
at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
at jms.Client.main(Client.java:329)
I traced this problem into the method isExchangeExist(...) of
AMQSession_0_10, where the exchange type is compared, and since my
exchange is direct and not topic, it returns that the exchange doesn't
exist. How can I send the message to direct exchange, when there is no
type "direct", but only "queue" and "topic"? When I bypass the
exchange type check on line 1056 of AMQSession_0_10, it works
perfectly fine.
3) I'm using this Address as the ReplyTo property:
"amq.direct/CLIENT_X.56789; {create: receiver, link : {name :
'service.tmp.CLIENT_X.123456_resp', x-declare : { auto-delete: true,
exclusive: true, 'qpid.max_size': 1000, 'qpid.policy_type': ring } }
}". My server application prepares an response and sends it back to
the replyTo address. When I receive the message and check the
JMSDestination, I can see following:
JMS Destination:
direct://amq.direct/CLIENT_X.56789/CLIENT_X.56789?routingkey='CLIENT_X.56789'
I would expect to see something like this (ie. the routing key is used ):
JMS Destination: direct://amq.direct/?routingkey='CLIENT_X.56789'
Nevertheless, the response is correctly delivered to amq.direct
exchange with routing key CLIENT_X.56789 and routed to the queue
service.tmp.CLIENT_X.123456_resp. I just noticed, that the destination
contains the desired routing key several times - may be it is correct
like this.
Thanks & Regards
Jakub
On Mon, Jun 28, 2010 at 16:14, Rajith Attapattu <ra...@gmail.com> wrote:
> On Mon, Jun 28, 2010 at 5:25 AM, Jakub Scholz <ja...@scholz.cz> wrote:
>> Hi Rajith,
>>
>> Thanks for the fix - the first three problems are working as expected
>> with latest trunk. I used following address when I found these
>> problems:
>
> Thanks for checking it out and letting me know.
>
>> amq.direct/CLIENT_X.56789; {create: receiver, link : {name :
>> 'service.tmp.CLIENT_X.123456_resp', x-declare : { auto-delete: true,
>> exclusive: true, 'qpid.max_size': 1000, 'qpid.policy_type': ring } } }
>>
> Thx !
>
>> Regarding the "access" right ... I believe in case it would be
>> necessary, we can add the "access" right to the ACL list. The C++ API
>> (version 0.5) and .NET API (version 0.6) are running successfully
>> against the same ACL setup as I'm running this JMS based application.
>
> Are you doing any explicit exchange queries and exchange binds ?
> If yes then the ACL should fail them. If thats not the case then it
> should be a bug and I'd appreciate any info you have on them.
>
>> But these older versions of course don't use the new addressing
>> scheme. From my point of view, it would be great to have a possibility
>> to bypass this querying functionality (for example by another option
>> in address). But I don't have enough knowledge about the APIs to know
>> whether it is possible or isn't.
>
> The new addressing scheme is common to all clients and we aim to have
> a consistent behaviour.
> When interpreting an address-string the client needs to figure out if
> it's an exchange or a queue if the node type is missing (for 0-10) and
> if it actually exists.
> So there will be an exchange and/or queue query. So those permissions
> are needed in the current ACL model.
> I guess your question is, whether we could turn off the querying for
> existence if the node type is present ?
>
>> Thanks & Regards
>> Jakub Scholz
>>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Problems with JMS API
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Jun 28, 2010 at 5:25 AM, Jakub Scholz <ja...@scholz.cz> wrote:
> Hi Rajith,
>
> Thanks for the fix - the first three problems are working as expected
> with latest trunk. I used following address when I found these
> problems:
Thanks for checking it out and letting me know.
> amq.direct/CLIENT_X.56789; {create: receiver, link : {name :
> 'service.tmp.CLIENT_X.123456_resp', x-declare : { auto-delete: true,
> exclusive: true, 'qpid.max_size': 1000, 'qpid.policy_type': ring } } }
>
Thx !
> Regarding the "access" right ... I believe in case it would be
> necessary, we can add the "access" right to the ACL list. The C++ API
> (version 0.5) and .NET API (version 0.6) are running successfully
> against the same ACL setup as I'm running this JMS based application.
Are you doing any explicit exchange queries and exchange binds ?
If yes then the ACL should fail them. If thats not the case then it
should be a bug and I'd appreciate any info you have on them.
> But these older versions of course don't use the new addressing
> scheme. From my point of view, it would be great to have a possibility
> to bypass this querying functionality (for example by another option
> in address). But I don't have enough knowledge about the APIs to know
> whether it is possible or isn't.
The new addressing scheme is common to all clients and we aim to have
a consistent behaviour.
When interpreting an address-string the client needs to figure out if
it's an exchange or a queue if the node type is missing (for 0-10) and
if it actually exists.
So there will be an exchange and/or queue query. So those permissions
are needed in the current ACL model.
I guess your question is, whether we could turn off the querying for
existence if the node type is present ?
> Thanks & Regards
> Jakub Scholz
>
> On Fri, Jun 25, 2010 at 22:33, Rajith Attapattu <ra...@gmail.com> wrote:
>> Hello Jakub,
>>
>> I have fixed the fist 3 problems in rev 958102 on qpid trunk.
>> Many thanks for bringing this to my attention.
>>
>> Could you also specify the address string that cause each of these problems?
>>
>> As for problem 4, if you are using ACL then you need explicit
>> permission to access (query) or bind to an exchange.
>> When using type : queue then the "address" is taken as a queue and
>> then will be bound to any exchange explicitly specified in string.
>> (By default every queue created is bound to the nameless exchange with
>> queue name as the binding key).
>>
>> If using type : topic then address is considered as an exchange and
>> the client will try to see if an exchange by the name exists. Hence
>> the call to exchange query.
>>
>> I was a bit surprised when you mentioned that you don't get this with
>> the c++ API and .NET API.
>> Could you provide more details on that ?
>>
>> If ACL is used then permissions will determine who can access what.
>>
>> Regards,
>>
>> Rajith
>>
>> On Fri, Jun 25, 2010 at 1:46 PM, Jakub Scholz <ja...@scholz.cz> wrote:
>>> Hi Rajith,
>>>
>>> You don't need to apologize, I'm glad for any help. I builded the
>>> latest trunk and tried it again. The previous problem with the
>>> PropertiesFileInitialContextFactoryis indeed fixed. I run into few
>>> other problems regarding the addresses:
>>>
>>> 1) When I used the addresses you suggested, it was complaining about
>>> NullPointerException in AddressHelper.getLink
>>>
>>> WARNUNG: Unable to create destination:java.lang.NullPointerException
>>> java.lang.NullPointerException
>>> at org.apache.qpid.client.messaging.address.AddressHelper.getLink(AddressHelper.java:326)
>>> at org.apache.qpid.client.AMQDestination.getInfoFromAddress(AMQDestination.java:823)
>>> at org.apache.qpid.client.AMQDestination.<init>(AMQDestination.java:157)
>>> at org.apache.qpid.client.AMQAnyDestination.<init>(AMQAnyDestination.java:52)
>>> at org.apache.qpid.client.AMQDestination.createDestination(AMQDestination.java:669)
>>> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestination(PropertiesFileInitialContextFactory.java:240)
>>> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestinations(PropertiesFileInitialContextFactory.java:160)
>>> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.getInitialContext(PropertiesFileInitialContextFactory.java:117)
>>> at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>>> at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>>> at javax.naming.InitialContext.init(Unknown Source)
>>> at javax.naming.InitialContext.<init>(Unknown Source)
>>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:18)
>>> at jms.Client.main(Client.java:329)
>>>
>>> This problem seems to be caused by missing capacity option in my
>>> Address. After i added capacity: 1000, this problem didn't appeared
>>> again. Maybe some default CAPACITY value should be added to the
>>> AddressHelper.
>>>
>>> 2) The qpid.policy-type option seems to be expecting integer instead
>>> of String. Therefore, when I tried to set policy-type to ring, I got
>>> following exception:
>>>
>>> java.lang.NumberFormatException: For input string: "ring"
>>> at java.lang.NumberFormatException.forInputString(Unknown Source)
>>> at java.lang.Integer.parseInt(Unknown Source)
>>> at java.lang.Integer.parseInt(Unknown Source)
>>> at org.apache.qpid.configuration.Accessor$MapAccessor.getInt(Accessor.java:101)
>>> at org.apache.qpid.client.messaging.address.AddressHelper.getQpidQueueOptions(AddressHelper.java:132)
>>> at org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(AddressHelper.java:273)
>>> at org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(AddressHelper.java:300)
>>> at org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestination.java:832)
>>> at org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1217)
>>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1144)
>>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>>> at jms.Client.main(Client.java:329)
>>>
>>> After changing the args.getInt(...) to args.getString(...) on line 132
>>> of AddressHelper class.
>>>
>>> 3) The last exception I run into was this:
>>>
>>> java.lang.NullPointerException
>>> at org.apache.qpid.client.messaging.address.AddressHelper.fillInCommonNodeArgs(AddressHelper.java:281)
>>> at org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(AddressHelper.java:274)
>>> at org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(AddressHelper.java:300)
>>> at org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestination.java:832)
>>> at org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1217)
>>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1144)
>>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>>> at jms.Client.main(Client.java:329)
>>>
>>> On the line 281 of AddressHelper, the null check is missing again.
>>> After verifying whether nodeProps != null the problem seemed to be
>>> fixed.
>>>
>>> 4) The last problem I found so far was, that the JMS API needed the
>>> access right to the exchange I was binding. That is currently
>>> forbidden on our system. This right was not needed with the old Qpid
>>> API or in c++ and .NET APIs. I was getting following errors:
>>>
>>> INFO: Created session:org.apache.qpid.client.AMQSession_0_10@b1a4e2
>>> org.apache.qpid.transport.SessionException: ch=0 id=0
>>> ExecutionException(errorCode=NOT_ALLOWED, commandId=0, classCode=7,
>>> commandCode=6, fieldIndex=0, description=not-allowed: ACL denied
>>> exchange bound request from client@QPID5318
>>> (qpid/broker/SessionAdapter.cpp:238), errorInfo={})
>>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:847)
>>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:859)
>>> at org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1203)
>>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1144)
>>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>>> at jms.Client.main(Client.java:329)
>>>
>>> I tried to force the node type with "node: { type: topic }", which
>>> gave me different error:
>>>
>>> INFO: Created session:org.apache.qpid.client.AMQSession_0_10@2016b0
>>> org.apache.qpid.transport.SessionException: ch=0 id=0
>>> ExecutionException(errorCode=NOT_ALLOWED, commandId=0, classCode=7,
>>> commandCode=3, fieldIndex=0, description=not-allowed: ACL denied
>>> exchange query request from client@QPID5318
>>> (qpid/broker/SessionAdapter.cpp:153), errorInfo={})
>>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:847)
>>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:859)
>>> at org.apache.qpid.client.AMQSession_0_10.isExchangeExist(AMQSession_0_10.java:1041)
>>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1165)
>>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>>> at jms.Client.main(Client.java:329)
>>>
>>> But I still need the access rights to the exchange to get it working.
>>> I tried to use the assert option, but it doesn't help. Can I somehow
>>> bypass this or is adding the access right for the exchange the only
>>> possibility?
>>>
>>> Thanks & Regards
>>> Jakub
>>>
>>> On Fri, Jun 25, 2010 at 16:06, Rajith Attapattu <ra...@gmail.com> wrote:
>>>> Hi Jakub,
>>>>
>>>> Apologies for the delay in replying to you. I was down with the flu
>>>> this week and it derailed most of my plans.
>>>> Anyways there was a bug (QPID-2696) in Qpid which cause the issue you reported.
>>>> I have fixed this in rev 957942 in trunk.
>>>> Please give it a try and let us know.
>>>> Again, very sorry for the delay in responding.
>>>>
>>>> Regards,
>>>>
>>>> Rajith
>>>>
>>>
>>
>>
>>
>> --
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Problems with JMS API
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Rajith,
Thanks for the fix - the first three problems are working as expected
with latest trunk. I used following address when I found these
problems:
amq.direct/CLIENT_X.56789; {create: receiver, link : {name :
'service.tmp.CLIENT_X.123456_resp', x-declare : { auto-delete: true,
exclusive: true, 'qpid.max_size': 1000, 'qpid.policy_type': ring } } }
Regarding the "access" right ... I believe in case it would be
necessary, we can add the "access" right to the ACL list. The C++ API
(version 0.5) and .NET API (version 0.6) are running successfully
against the same ACL setup as I'm running this JMS based application.
But these older versions of course don't use the new addressing
scheme. From my point of view, it would be great to have a possibility
to bypass this querying functionality (for example by another option
in address). But I don't have enough knowledge about the APIs to know
whether it is possible or isn't.
Thanks & Regards
Jakub Scholz
On Fri, Jun 25, 2010 at 22:33, Rajith Attapattu <ra...@gmail.com> wrote:
> Hello Jakub,
>
> I have fixed the fist 3 problems in rev 958102 on qpid trunk.
> Many thanks for bringing this to my attention.
>
> Could you also specify the address string that cause each of these problems?
>
> As for problem 4, if you are using ACL then you need explicit
> permission to access (query) or bind to an exchange.
> When using type : queue then the "address" is taken as a queue and
> then will be bound to any exchange explicitly specified in string.
> (By default every queue created is bound to the nameless exchange with
> queue name as the binding key).
>
> If using type : topic then address is considered as an exchange and
> the client will try to see if an exchange by the name exists. Hence
> the call to exchange query.
>
> I was a bit surprised when you mentioned that you don't get this with
> the c++ API and .NET API.
> Could you provide more details on that ?
>
> If ACL is used then permissions will determine who can access what.
>
> Regards,
>
> Rajith
>
> On Fri, Jun 25, 2010 at 1:46 PM, Jakub Scholz <ja...@scholz.cz> wrote:
>> Hi Rajith,
>>
>> You don't need to apologize, I'm glad for any help. I builded the
>> latest trunk and tried it again. The previous problem with the
>> PropertiesFileInitialContextFactoryis indeed fixed. I run into few
>> other problems regarding the addresses:
>>
>> 1) When I used the addresses you suggested, it was complaining about
>> NullPointerException in AddressHelper.getLink
>>
>> WARNUNG: Unable to create destination:java.lang.NullPointerException
>> java.lang.NullPointerException
>> at org.apache.qpid.client.messaging.address.AddressHelper.getLink(AddressHelper.java:326)
>> at org.apache.qpid.client.AMQDestination.getInfoFromAddress(AMQDestination.java:823)
>> at org.apache.qpid.client.AMQDestination.<init>(AMQDestination.java:157)
>> at org.apache.qpid.client.AMQAnyDestination.<init>(AMQAnyDestination.java:52)
>> at org.apache.qpid.client.AMQDestination.createDestination(AMQDestination.java:669)
>> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestination(PropertiesFileInitialContextFactory.java:240)
>> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestinations(PropertiesFileInitialContextFactory.java:160)
>> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.getInitialContext(PropertiesFileInitialContextFactory.java:117)
>> at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
>> at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
>> at javax.naming.InitialContext.init(Unknown Source)
>> at javax.naming.InitialContext.<init>(Unknown Source)
>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:18)
>> at jms.Client.main(Client.java:329)
>>
>> This problem seems to be caused by missing capacity option in my
>> Address. After i added capacity: 1000, this problem didn't appeared
>> again. Maybe some default CAPACITY value should be added to the
>> AddressHelper.
>>
>> 2) The qpid.policy-type option seems to be expecting integer instead
>> of String. Therefore, when I tried to set policy-type to ring, I got
>> following exception:
>>
>> java.lang.NumberFormatException: For input string: "ring"
>> at java.lang.NumberFormatException.forInputString(Unknown Source)
>> at java.lang.Integer.parseInt(Unknown Source)
>> at java.lang.Integer.parseInt(Unknown Source)
>> at org.apache.qpid.configuration.Accessor$MapAccessor.getInt(Accessor.java:101)
>> at org.apache.qpid.client.messaging.address.AddressHelper.getQpidQueueOptions(AddressHelper.java:132)
>> at org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(AddressHelper.java:273)
>> at org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(AddressHelper.java:300)
>> at org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestination.java:832)
>> at org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1217)
>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1144)
>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>> at jms.Client.main(Client.java:329)
>>
>> After changing the args.getInt(...) to args.getString(...) on line 132
>> of AddressHelper class.
>>
>> 3) The last exception I run into was this:
>>
>> java.lang.NullPointerException
>> at org.apache.qpid.client.messaging.address.AddressHelper.fillInCommonNodeArgs(AddressHelper.java:281)
>> at org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(AddressHelper.java:274)
>> at org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(AddressHelper.java:300)
>> at org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestination.java:832)
>> at org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1217)
>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1144)
>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>> at jms.Client.main(Client.java:329)
>>
>> On the line 281 of AddressHelper, the null check is missing again.
>> After verifying whether nodeProps != null the problem seemed to be
>> fixed.
>>
>> 4) The last problem I found so far was, that the JMS API needed the
>> access right to the exchange I was binding. That is currently
>> forbidden on our system. This right was not needed with the old Qpid
>> API or in c++ and .NET APIs. I was getting following errors:
>>
>> INFO: Created session:org.apache.qpid.client.AMQSession_0_10@b1a4e2
>> org.apache.qpid.transport.SessionException: ch=0 id=0
>> ExecutionException(errorCode=NOT_ALLOWED, commandId=0, classCode=7,
>> commandCode=6, fieldIndex=0, description=not-allowed: ACL denied
>> exchange bound request from client@QPID5318
>> (qpid/broker/SessionAdapter.cpp:238), errorInfo={})
>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:847)
>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:859)
>> at org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1203)
>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1144)
>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>> at jms.Client.main(Client.java:329)
>>
>> I tried to force the node type with "node: { type: topic }", which
>> gave me different error:
>>
>> INFO: Created session:org.apache.qpid.client.AMQSession_0_10@2016b0
>> org.apache.qpid.transport.SessionException: ch=0 id=0
>> ExecutionException(errorCode=NOT_ALLOWED, commandId=0, classCode=7,
>> commandCode=3, fieldIndex=0, description=not-allowed: ACL denied
>> exchange query request from client@QPID5318
>> (qpid/broker/SessionAdapter.cpp:153), errorInfo={})
>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:847)
>> at org.apache.qpid.transport.Session$ResultFuture.get(Session.java:859)
>> at org.apache.qpid.client.AMQSession_0_10.isExchangeExist(AMQSession_0_10.java:1041)
>> at org.apache.qpid.client.AMQSession_0_10.handleAddressBasedDestination(AMQSession_0_10.java:1165)
>> at org.apache.qpid.client.AMQSession.registerConsumer(AMQSession.java:2606)
>> at org.apache.qpid.client.AMQSession.access$500(AMQSession.java:95)
>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1809)
>> at org.apache.qpid.client.AMQSession$4.execute(AMQSession.java:1775)
>> at org.apache.qpid.client.AMQConnectionDelegate_0_10.executeRetrySupport(AMQConnectionDelegate_0_10.java:278)
>> at org.apache.qpid.client.AMQConnection.executeRetrySupport(AMQConnection.java:765)
>> at org.apache.qpid.client.failover.FailoverRetrySupport.execute(FailoverRetrySupport.java:102)
>> at org.apache.qpid.client.AMQSession.createConsumerImpl(AMQSession.java:1773)
>> at org.apache.qpid.client.AMQSession.createConsumer(AMQSession.java:921)
>> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:30)
>> at jms.Client.main(Client.java:329)
>>
>> But I still need the access rights to the exchange to get it working.
>> I tried to use the assert option, but it doesn't help. Can I somehow
>> bypass this or is adding the access right for the exchange the only
>> possibility?
>>
>> Thanks & Regards
>> Jakub
>>
>> On Fri, Jun 25, 2010 at 16:06, Rajith Attapattu <ra...@gmail.com> wrote:
>>> Hi Jakub,
>>>
>>> Apologies for the delay in replying to you. I was down with the flu
>>> this week and it derailed most of my plans.
>>> Anyways there was a bug (QPID-2696) in Qpid which cause the issue you reported.
>>> I have fixed this in rev 957942 in trunk.
>>> Please give it a try and let us know.
>>> Again, very sorry for the delay in responding.
>>>
>>> Regards,
>>>
>>> Rajith
>>>
>>
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Problems with JMS API
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi Jakub,
Apologies for the delay in replying to you. I was down with the flu
this week and it derailed most of my plans.
Anyways there was a bug (QPID-2696) in Qpid which cause the issue you reported.
I have fixed this in rev 957942 in trunk.
Please give it a try and let us know.
Again, very sorry for the delay in responding.
Regards,
Rajith
On Thu, Jun 17, 2010 at 1:49 PM, Jakub Scholz <sc...@scholzj.com> wrote:
> Hi ,
>
> Thanks for your answer. I checkout the latest trunk source codes from
> svn and built them. I tried the addresses you suggested as well as the
> JMS example from the documentation you pointed me to. Although the
> example seems to be working, it seems to me that it is just exchanging
> the messages over queue named amq.topic, not over a topic exchange. I
> believe it is happening because it understands the destination as
> Binding URL and not as an Address.
>
> 17.06.2010 19:35:28
> org.apache.qpid.jndi.PropertiesFileInitialContextFactory
> getInitialContext
> INFO: No Provider URL specified.
> 17.06.2010 19:35:28 org.apache.qpid.client.AMQDestination <init>
> INFO: Based on direct:////amq.topic the selected destination syntax is BURL
> 17.06.2010 19:35:28 org.apache.qpid.client.AMQConnection <init>
> INFO: Connection:amqp://admin:********@clientid/test?brokerlist='tcp://rgd001:25318'
> 17.06.2010 19:35:28 org.apache.qpid.client.protocol.AMQProtocolSession <init>
> INFO: Using ProtocolVersion for Session:0-10
> 17.06.2010 19:35:28
> org.apache.qpid.client.handler.ClientMethodDispatcherImpl
> newMethodDispatcher
> INFO: New Method Dispatcher:AMQProtocolSession[null]
> 17.06.2010 19:35:28 org.apache.qpid.client.AMQConnection <init>
> INFO: Connecting with ProtocolHandler Version:0-10
> 17.06.2010 19:35:29 org.apache.qpid.client.AMQConnection <init>
> INFO: Connected with ProtocolHandler Version:0-10
> 17.06.2010 19:35:29 org.apache.qpid.client.AMQSession <init>
> INFO: Created session:org.apache.qpid.client.AMQSession_0_10@1a61172
> 17.06.2010 19:35:29 org.apache.qpid.client.BasicMessageProducer setPublishMode
> INFO: MessageProducer
> org.apache.qpid.client.BasicMessageProducer_0_10@1843a75 using publish
> mode : ASYNC_PUBLISH_ALL
> 17.06.2010 19:35:29 org.apache.qpid.client.AMQSession registerConsumer
> INFO: Prefetching delayed existing messages will not flow until
> requested via receive*() or setML().
> 17.06.2010 19:35:29 org.apache.qpid.client.AMQDestination <init>
> INFO: Based on :////?routingkey='' the selected destination syntax is BURL
> 17.06.2010 19:35:29 org.apache.qpid.client.AMQSession startDispatcherIfNecessary
> INFO: Dispatcher-Channel-1 created
> 17.06.2010 19:35:29 org.apache.qpid.client.AMQSession$Dispatcher run
> INFO: Dispatcher-Channel-1 started
> 17.06.2010 19:35:29 org.apache.qpid.client.AMQDestination <init>
> INFO: Based on :///amq.topic/amq.topic?routingkey='amq.topic' the
> selected destination syntax is BURL
> 17.06.2010 19:35:29 org.apache.qpid.client.AMQDestination <init>
> INFO: Based on :///amq.topic/amq.topic?routingkey='amq.topic' the
> selected destination syntax is BURL
> 17.06.2010 19:35:29 org.apache.qpid.client.AMQDestination <init>
> INFO: Based on :///amq.topic/amq.topic?routingkey='amq.topic' the
> selected destination syntax is BURL
> MESSAGE:Hello world!
> 17.06.2010 19:37:09 org.apache.qpid.client.AMQSession close
> INFO: Closing session: org.apache.qpid.client.AMQSession_0_10@1a61172
> 17.06.2010 19:37:09 org.apache.qpid.client.BasicMessageConsumer close
> INFO: Closing consumer:1[9996039]
> 17.06.2010 19:37:09 org.apache.qpid.client.AMQSession$Dispatcher run
> INFO: Dispatcher-Channel-1 thread terminating for channel
> 1:org.apache.qpid.client.AMQSession_0_10@1a61172
>
> If I use a more complicated destination address, I get exception with
> error in parsing of the address:
>
> 17.06.2010 19:39:58
> org.apache.qpid.jndi.PropertiesFileInitialContextFactory
> getInitialContext
> INFO: No Provider URL specified.
> 17.06.2010 19:39:58
> org.apache.qpid.jndi.PropertiesFileInitialContextFactory
> createDestination
> WARNUNG: Unable to create destination:java.net.URISyntaxException:
> Error occured while parsing URL at index 77: amq.direct/CLIENT_X.XYZ;
> {create:always, link : {name : service.CLIENT_X} }%^
> java.net.URISyntaxException: Error occured while parsing URL at index
> 77: amq.direct/CLIENT_X.XYZ; {create:always, link : {name :
> service.CLIENT_X} }%^
> at org.apache.qpid.url.BindingURLParser.<init>(BindingURLParser.java:88)
> at org.apache.qpid.url.AMQBindingURL.parseBindingURL(AMQBindingURL.java:58)
> at org.apache.qpid.url.AMQBindingURL.<init>(AMQBindingURL.java:53)
> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestination(PropertiesFileInitialContextFactory.java:241)
> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestinations(PropertiesFileInitialContextFactory.java:160)
> at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.getInitialContext(PropertiesFileInitialContextFactory.java:117)
> at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
> at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
> at javax.naming.InitialContext.init(Unknown Source)
> at javax.naming.InitialContext.<init>(Unknown Source)
> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:18)
> at jms.Client.main(Client.java:328)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 77
> at org.apache.qpid.url.BindingURLParser.extractExchangeName(BindingURLParser.java:218)
> at org.apache.qpid.url.BindingURLParser.next(BindingURLParser.java:137)
> at org.apache.qpid.url.BindingURLParser.<init>(BindingURLParser.java:70)
> ... 11 more
> 17.06.2010 19:39:59 org.apache.qpid.client.AMQConnection <init>
> INFO: Connection:amqp://admin:********@clientid/test?brokerlist='tcp://rgd001:25318'
> 17.06.2010 19:39:59 org.apache.qpid.client.protocol.AMQProtocolSession <init>
> INFO: Using ProtocolVersion for Session:0-10
> 17.06.2010 19:39:59
> org.apache.qpid.client.handler.ClientMethodDispatcherImpl
> newMethodDispatcher
> INFO: New Method Dispatcher:AMQProtocolSession[null]
> 17.06.2010 19:39:59 org.apache.qpid.client.AMQConnection <init>
> INFO: Connecting with ProtocolHandler Version:0-10
> 17.06.2010 19:39:59 org.apache.qpid.client.AMQConnection <init>
> INFO: Connected with ProtocolHandler Version:0-10
> 17.06.2010 19:39:59 org.apache.qpid.client.AMQSession <init>
> INFO: Created session:org.apache.qpid.client.AMQSession_0_10@1c391c3
> javax.naming.NameNotFoundException: topicExchange
> at org.apache.qpid.jndi.ReadOnlyContext.lookup(ReadOnlyContext.java:271)
> at javax.naming.InitialContext.lookup(Unknown Source)
> at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:26)
> at jms.Client.main(Client.java:328)
>
> Do I need to switch the support for addresses somewhere? Do I need
> 0.7/trunk broker as well or is the 0.7/trunk client sufficient
> (currently, I'm running against the latest RedHat MRG broker)?
>
> Thanks & Regards
> Jakub Scholz
>
> On Wed, Jun 16, 2010 at 18:08, Rajith Attapattu <ra...@gmail.com> wrote:
>> On Tue, Jun 15, 2010 at 2:53 PM, Jakub Scholz <sc...@scholzj.com> wrote:
>>> Hi,
>>>
>>> I'm providing Qpid based service, which allows client's applications
>>> to connect to the broker, send requests, receive responses and receive
>>> broadcasts (via topic exchange). Since there are different clients
>>> connecting with their own applications, the clients are strictly
>>> limited to do only some actions. Currently, I have fully working test
>>> application, which is written in Java and is relying on the old Qpid
>>> API. Since the Qpid API is not really supported, I was trying to
>>> rewrite this application to JMS. Unfortunately, I run into several
>>> problems:
>>>
>>> 1) To send requests, the client should send the message to a direct
>>> exchange specific for every client. The message needs to have a client
>>> specific routing key defined, which routes the message to a queue
>>> where it is picked up by the server application. The exchanges are
>>> predefined and the client is forbidden to define exchanges. Doing this
>>> with Qpid API is not a problem. I tried to do so in the JMS with
>>> following code (it is based on the JMS examples):
>>>
>>> _producer = session.createProducer(null);
>>> TextMessage txtMessage;
>>> txtMessage = session.createTextMessage("<?xml version=\"1.0\"
>>> encoding=\"UTF-8\" standalone=\"no\"?><FIXML>.....</FIXML>");
>>> _producer.send(requestDestination, txtMessage);
>>>
>>> The destination called requestDestination is defined using JNDI as
>>> direct://service.CLIENT_X/?routingkey='CLIENT_X.XYZ'. However, when I
>>> run this code against the broker, the message is not send and it fails
>>> with "ACL denied exchange declare request" (however, this error
>>> appears only in the broker log file, not on the client).
>>
>> When ACL denies an operation the session will be invalidated.
>> Therefore you should get a JMS exception.
>>
>>> Running the
>>> program with "-Dqpid.declare_exchanges=FALSE" doesn't help. I
>>
>> After looking at the code, I noticed that the -Dqpid.declare_exchanges
>> is not checked before calling the exchange declare method.
>> I will fix this for folks still using the old binding URL format.
>>
>> However in your case, I would recommend you to use the new addressing
>> syntax instead of the binding URL scheme.
>> The documentation is available here
>> http://people.apache.org/~jonathan/Programming-In-Apache-Qpid.html
>> (The above docs will appear in our new website fairly soon, until then
>> you could use the above link.)
>>
>> For your specific case the addressing string would be as follows.
>> destination.<your-jndi-name>="amq.direct/CLIENT_X.XYZ; {create:
>> always, link : {name : service.CLIENT_X} }"
>>
>> If you want the only the consumer to create the queue (and not the
>> producer) then use "create: receiver" instead of "create : always".
>> The documentation should give you a good overview of all the options available.
>> If you run into issues, please don't hesitate to contact us.
>>
>> Please note the addressing support is only available in trunk.
>> Even if I fix the bug with -Dqpid.declare_exchanges you would still
>> need to use trunk, therefore it's best to use the new addressing
>> syntax.
>>
>>> discussed this problem here already a year ago, it should be caused by
>>> BasicMessageProducer_0_10, method declareDestination. However, when I
>>> comment out the exchangeDeclare call in this method, it fixes the
>>> problem with ACL, but it cause's my broker to crash after processing
>>> the message, which I don't know how to fix.
>>>
>> What do you mean by broker crash?
>> Does it core dump ?
>> If you could provide details of the broker crash via a JIRA, that
>> would be great as it could be a bug in the broker code.
>>
>>> 2) To receive responses, the client has to create his own queue and
>>> bind the queue with another direct exchange. The queue name as well as
>>> the routing key have to be in a specific format. The queue needs to be
>>> autodelete, exclusive and have RING policy type with max_size 1000. I
>>> tried following JMS code:
>>>
>>> MessageConsumer responseConsumer = session.createConsumer(responseDestination);
>>> responseConsumer.setMessageListener(this);
>>>
>>> Where response destination is
>>> direct://service.response/service.tmp.CLIENT_X.123456_resp?routingkey='CLIENT_X.56789'&autodelete='TRUE'&exclusive='TRUE'.
>>> But I don't know, how to define the policytype=RING and max_size=1000.
>>> All parameters I tried are ignored. And without proper policy type and
>>> queue size, I fail again on ACL (this time, the error handling works
>>> fine => I get a proper exception on the client side). How can I
>>> specify the policytype and max_size?
>>
>> The addressing syntax can cover the above case.
>> Here is an example,
>>
>> "amq.direct/CLIENT_X.56789; {create: receiver, link : {name :
>> service.tmp.CLIENT_X.123456_resp, x-declare : { auto-delete: true,
>> exclusive: true, 'qpid.max_size': 1000, 'qpid.policy_type': ring } } }
>> "
>>
>>
>>> 3) To receive broadcasts, the clients have to create their own queue
>>> and subscribe the broadcasts using an binding between topic exchange
>>> and their queue. I tried to use the same consumer as in point 2), but
>>> since this is an topic exchange, I cannot use following destination
>>> direct://service.broadcast/service.tmp.CLIENT_X.123456_bcast?routingkey='#.weather.usa.#'&autodelete='TRUE'&exclusive='TRUE'.
>>> It is forcing me to use the Topic JNDI. But if I specify the topic
>>> JNDI just as #.weather.usa.#, it is trying to bind the default topic
>>> exchange amq.topic (which is different from the exchange I want to
>>> use) and it uses queue with different name and parameters, then what
>>> the client is allowed to. How can I setup binding between a specific
>>> topic exchange and my own very specific queue? (possibly with more
>>> bindings to the same queue)
>>
>> Here is an example,
>> "my-own-topic-exchange/usa.#; {create: receiver, link {name: my queue,
>> x-declare: {auto-delete: true, 'qpid.max_size': 1000} , x-bindings:
>> [{exchange : 'amq.direct', key : test},{exchange : 'amq.topic', key :
>> 'xyz.#'}]} }"
>>
>> Here you are making 3 bindings to the queue "my-queue".
>> 1 my-own-topic-exchange with key "usa.#"
>> 2. amq.direct with key "test"
>> 3. amq.topic with key "xyz.#"
>>
>> The link properties are there to define your subscription queue.
>> The x-declare (inside link props) will allow you to customize the queue props.
>> The x-bindings (inside link props) will allow you to specify
>> additional bindings.
>>
>> I suggest you to read the documentation I mentioned above to get a
>> proper understanding of the concepts.
>> Please let us know if you run into issues, if the docs are not clear
>> or find a use case that is not covered by the addressing syntax.
>>
>>> The configuration on the broker may look quite strict, but I see that
>>> as the only way to provide a stable service to all connected clients.
>>> Since the service is already running, I'm not free to change the
>>> configuration as I want. Therefore, I prefer finding a solution which
>>> would fit the configuration.
>>>
>>> FYI: I was trying this with Qpid 0.5, 0.6 as well as the latest trunk.
>>> The broker is C++ ...
>>
>> Again the new addressing support is only available in trunk.
>> I hope I managed to answer all your questions. If not feel free to
>> clarify any doubts.
>>
>>> Thanks & Regards
>>> Jakub Scholz
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Regards,
>>
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Problems with JMS API
Posted by Jakub Scholz <sc...@scholzj.com>.
Hi ,
Thanks for your answer. I checkout the latest trunk source codes from
svn and built them. I tried the addresses you suggested as well as the
JMS example from the documentation you pointed me to. Although the
example seems to be working, it seems to me that it is just exchanging
the messages over queue named amq.topic, not over a topic exchange. I
believe it is happening because it understands the destination as
Binding URL and not as an Address.
17.06.2010 19:35:28
org.apache.qpid.jndi.PropertiesFileInitialContextFactory
getInitialContext
INFO: No Provider URL specified.
17.06.2010 19:35:28 org.apache.qpid.client.AMQDestination <init>
INFO: Based on direct:////amq.topic the selected destination syntax is BURL
17.06.2010 19:35:28 org.apache.qpid.client.AMQConnection <init>
INFO: Connection:amqp://admin:********@clientid/test?brokerlist='tcp://rgd001:25318'
17.06.2010 19:35:28 org.apache.qpid.client.protocol.AMQProtocolSession <init>
INFO: Using ProtocolVersion for Session:0-10
17.06.2010 19:35:28
org.apache.qpid.client.handler.ClientMethodDispatcherImpl
newMethodDispatcher
INFO: New Method Dispatcher:AMQProtocolSession[null]
17.06.2010 19:35:28 org.apache.qpid.client.AMQConnection <init>
INFO: Connecting with ProtocolHandler Version:0-10
17.06.2010 19:35:29 org.apache.qpid.client.AMQConnection <init>
INFO: Connected with ProtocolHandler Version:0-10
17.06.2010 19:35:29 org.apache.qpid.client.AMQSession <init>
INFO: Created session:org.apache.qpid.client.AMQSession_0_10@1a61172
17.06.2010 19:35:29 org.apache.qpid.client.BasicMessageProducer setPublishMode
INFO: MessageProducer
org.apache.qpid.client.BasicMessageProducer_0_10@1843a75 using publish
mode : ASYNC_PUBLISH_ALL
17.06.2010 19:35:29 org.apache.qpid.client.AMQSession registerConsumer
INFO: Prefetching delayed existing messages will not flow until
requested via receive*() or setML().
17.06.2010 19:35:29 org.apache.qpid.client.AMQDestination <init>
INFO: Based on :////?routingkey='' the selected destination syntax is BURL
17.06.2010 19:35:29 org.apache.qpid.client.AMQSession startDispatcherIfNecessary
INFO: Dispatcher-Channel-1 created
17.06.2010 19:35:29 org.apache.qpid.client.AMQSession$Dispatcher run
INFO: Dispatcher-Channel-1 started
17.06.2010 19:35:29 org.apache.qpid.client.AMQDestination <init>
INFO: Based on :///amq.topic/amq.topic?routingkey='amq.topic' the
selected destination syntax is BURL
17.06.2010 19:35:29 org.apache.qpid.client.AMQDestination <init>
INFO: Based on :///amq.topic/amq.topic?routingkey='amq.topic' the
selected destination syntax is BURL
17.06.2010 19:35:29 org.apache.qpid.client.AMQDestination <init>
INFO: Based on :///amq.topic/amq.topic?routingkey='amq.topic' the
selected destination syntax is BURL
MESSAGE:Hello world!
17.06.2010 19:37:09 org.apache.qpid.client.AMQSession close
INFO: Closing session: org.apache.qpid.client.AMQSession_0_10@1a61172
17.06.2010 19:37:09 org.apache.qpid.client.BasicMessageConsumer close
INFO: Closing consumer:1[9996039]
17.06.2010 19:37:09 org.apache.qpid.client.AMQSession$Dispatcher run
INFO: Dispatcher-Channel-1 thread terminating for channel
1:org.apache.qpid.client.AMQSession_0_10@1a61172
If I use a more complicated destination address, I get exception with
error in parsing of the address:
17.06.2010 19:39:58
org.apache.qpid.jndi.PropertiesFileInitialContextFactory
getInitialContext
INFO: No Provider URL specified.
17.06.2010 19:39:58
org.apache.qpid.jndi.PropertiesFileInitialContextFactory
createDestination
WARNUNG: Unable to create destination:java.net.URISyntaxException:
Error occured while parsing URL at index 77: amq.direct/CLIENT_X.XYZ;
{create:always, link : {name : service.CLIENT_X} }%^
java.net.URISyntaxException: Error occured while parsing URL at index
77: amq.direct/CLIENT_X.XYZ; {create:always, link : {name :
service.CLIENT_X} }%^
at org.apache.qpid.url.BindingURLParser.<init>(BindingURLParser.java:88)
at org.apache.qpid.url.AMQBindingURL.parseBindingURL(AMQBindingURL.java:58)
at org.apache.qpid.url.AMQBindingURL.<init>(AMQBindingURL.java:53)
at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestination(PropertiesFileInitialContextFactory.java:241)
at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestinations(PropertiesFileInitialContextFactory.java:160)
at org.apache.qpid.jndi.PropertiesFileInitialContextFactory.getInitialContext(PropertiesFileInitialContextFactory.java:117)
at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
at javax.naming.InitialContext.init(Unknown Source)
at javax.naming.InitialContext.<init>(Unknown Source)
at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:18)
at jms.Client.main(Client.java:328)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 77
at org.apache.qpid.url.BindingURLParser.extractExchangeName(BindingURLParser.java:218)
at org.apache.qpid.url.BindingURLParser.next(BindingURLParser.java:137)
at org.apache.qpid.url.BindingURLParser.<init>(BindingURLParser.java:70)
... 11 more
17.06.2010 19:39:59 org.apache.qpid.client.AMQConnection <init>
INFO: Connection:amqp://admin:********@clientid/test?brokerlist='tcp://rgd001:25318'
17.06.2010 19:39:59 org.apache.qpid.client.protocol.AMQProtocolSession <init>
INFO: Using ProtocolVersion for Session:0-10
17.06.2010 19:39:59
org.apache.qpid.client.handler.ClientMethodDispatcherImpl
newMethodDispatcher
INFO: New Method Dispatcher:AMQProtocolSession[null]
17.06.2010 19:39:59 org.apache.qpid.client.AMQConnection <init>
INFO: Connecting with ProtocolHandler Version:0-10
17.06.2010 19:39:59 org.apache.qpid.client.AMQConnection <init>
INFO: Connected with ProtocolHandler Version:0-10
17.06.2010 19:39:59 org.apache.qpid.client.AMQSession <init>
INFO: Created session:org.apache.qpid.client.AMQSession_0_10@1c391c3
javax.naming.NameNotFoundException: topicExchange
at org.apache.qpid.jndi.ReadOnlyContext.lookup(ReadOnlyContext.java:271)
at javax.naming.InitialContext.lookup(Unknown Source)
at org.apache.qpid.example.jmsexample.hello.Hello.runTest(Hello.java:26)
at jms.Client.main(Client.java:328)
Do I need to switch the support for addresses somewhere? Do I need
0.7/trunk broker as well or is the 0.7/trunk client sufficient
(currently, I'm running against the latest RedHat MRG broker)?
Thanks & Regards
Jakub Scholz
On Wed, Jun 16, 2010 at 18:08, Rajith Attapattu <ra...@gmail.com> wrote:
> On Tue, Jun 15, 2010 at 2:53 PM, Jakub Scholz <sc...@scholzj.com> wrote:
>> Hi,
>>
>> I'm providing Qpid based service, which allows client's applications
>> to connect to the broker, send requests, receive responses and receive
>> broadcasts (via topic exchange). Since there are different clients
>> connecting with their own applications, the clients are strictly
>> limited to do only some actions. Currently, I have fully working test
>> application, which is written in Java and is relying on the old Qpid
>> API. Since the Qpid API is not really supported, I was trying to
>> rewrite this application to JMS. Unfortunately, I run into several
>> problems:
>>
>> 1) To send requests, the client should send the message to a direct
>> exchange specific for every client. The message needs to have a client
>> specific routing key defined, which routes the message to a queue
>> where it is picked up by the server application. The exchanges are
>> predefined and the client is forbidden to define exchanges. Doing this
>> with Qpid API is not a problem. I tried to do so in the JMS with
>> following code (it is based on the JMS examples):
>>
>> _producer = session.createProducer(null);
>> TextMessage txtMessage;
>> txtMessage = session.createTextMessage("<?xml version=\"1.0\"
>> encoding=\"UTF-8\" standalone=\"no\"?><FIXML>.....</FIXML>");
>> _producer.send(requestDestination, txtMessage);
>>
>> The destination called requestDestination is defined using JNDI as
>> direct://service.CLIENT_X/?routingkey='CLIENT_X.XYZ'. However, when I
>> run this code against the broker, the message is not send and it fails
>> with "ACL denied exchange declare request" (however, this error
>> appears only in the broker log file, not on the client).
>
> When ACL denies an operation the session will be invalidated.
> Therefore you should get a JMS exception.
>
>> Running the
>> program with "-Dqpid.declare_exchanges=FALSE" doesn't help. I
>
> After looking at the code, I noticed that the -Dqpid.declare_exchanges
> is not checked before calling the exchange declare method.
> I will fix this for folks still using the old binding URL format.
>
> However in your case, I would recommend you to use the new addressing
> syntax instead of the binding URL scheme.
> The documentation is available here
> http://people.apache.org/~jonathan/Programming-In-Apache-Qpid.html
> (The above docs will appear in our new website fairly soon, until then
> you could use the above link.)
>
> For your specific case the addressing string would be as follows.
> destination.<your-jndi-name>="amq.direct/CLIENT_X.XYZ; {create:
> always, link : {name : service.CLIENT_X} }"
>
> If you want the only the consumer to create the queue (and not the
> producer) then use "create: receiver" instead of "create : always".
> The documentation should give you a good overview of all the options available.
> If you run into issues, please don't hesitate to contact us.
>
> Please note the addressing support is only available in trunk.
> Even if I fix the bug with -Dqpid.declare_exchanges you would still
> need to use trunk, therefore it's best to use the new addressing
> syntax.
>
>> discussed this problem here already a year ago, it should be caused by
>> BasicMessageProducer_0_10, method declareDestination. However, when I
>> comment out the exchangeDeclare call in this method, it fixes the
>> problem with ACL, but it cause's my broker to crash after processing
>> the message, which I don't know how to fix.
>>
> What do you mean by broker crash?
> Does it core dump ?
> If you could provide details of the broker crash via a JIRA, that
> would be great as it could be a bug in the broker code.
>
>> 2) To receive responses, the client has to create his own queue and
>> bind the queue with another direct exchange. The queue name as well as
>> the routing key have to be in a specific format. The queue needs to be
>> autodelete, exclusive and have RING policy type with max_size 1000. I
>> tried following JMS code:
>>
>> MessageConsumer responseConsumer = session.createConsumer(responseDestination);
>> responseConsumer.setMessageListener(this);
>>
>> Where response destination is
>> direct://service.response/service.tmp.CLIENT_X.123456_resp?routingkey='CLIENT_X.56789'&autodelete='TRUE'&exclusive='TRUE'.
>> But I don't know, how to define the policytype=RING and max_size=1000.
>> All parameters I tried are ignored. And without proper policy type and
>> queue size, I fail again on ACL (this time, the error handling works
>> fine => I get a proper exception on the client side). How can I
>> specify the policytype and max_size?
>
> The addressing syntax can cover the above case.
> Here is an example,
>
> "amq.direct/CLIENT_X.56789; {create: receiver, link : {name :
> service.tmp.CLIENT_X.123456_resp, x-declare : { auto-delete: true,
> exclusive: true, 'qpid.max_size': 1000, 'qpid.policy_type': ring } } }
> "
>
>
>> 3) To receive broadcasts, the clients have to create their own queue
>> and subscribe the broadcasts using an binding between topic exchange
>> and their queue. I tried to use the same consumer as in point 2), but
>> since this is an topic exchange, I cannot use following destination
>> direct://service.broadcast/service.tmp.CLIENT_X.123456_bcast?routingkey='#.weather.usa.#'&autodelete='TRUE'&exclusive='TRUE'.
>> It is forcing me to use the Topic JNDI. But if I specify the topic
>> JNDI just as #.weather.usa.#, it is trying to bind the default topic
>> exchange amq.topic (which is different from the exchange I want to
>> use) and it uses queue with different name and parameters, then what
>> the client is allowed to. How can I setup binding between a specific
>> topic exchange and my own very specific queue? (possibly with more
>> bindings to the same queue)
>
> Here is an example,
> "my-own-topic-exchange/usa.#; {create: receiver, link {name: my queue,
> x-declare: {auto-delete: true, 'qpid.max_size': 1000} , x-bindings:
> [{exchange : 'amq.direct', key : test},{exchange : 'amq.topic', key :
> 'xyz.#'}]} }"
>
> Here you are making 3 bindings to the queue "my-queue".
> 1 my-own-topic-exchange with key "usa.#"
> 2. amq.direct with key "test"
> 3. amq.topic with key "xyz.#"
>
> The link properties are there to define your subscription queue.
> The x-declare (inside link props) will allow you to customize the queue props.
> The x-bindings (inside link props) will allow you to specify
> additional bindings.
>
> I suggest you to read the documentation I mentioned above to get a
> proper understanding of the concepts.
> Please let us know if you run into issues, if the docs are not clear
> or find a use case that is not covered by the addressing syntax.
>
>> The configuration on the broker may look quite strict, but I see that
>> as the only way to provide a stable service to all connected clients.
>> Since the service is already running, I'm not free to change the
>> configuration as I want. Therefore, I prefer finding a solution which
>> would fit the configuration.
>>
>> FYI: I was trying this with Qpid 0.5, 0.6 as well as the latest trunk.
>> The broker is C++ ...
>
> Again the new addressing support is only available in trunk.
> I hope I managed to answer all your questions. If not feel free to
> clarify any doubts.
>
>> Thanks & Regards
>> Jakub Scholz
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>>
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> 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 with JMS API
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Jun 15, 2010 at 2:53 PM, Jakub Scholz <sc...@scholzj.com> wrote:
> Hi,
>
> I'm providing Qpid based service, which allows client's applications
> to connect to the broker, send requests, receive responses and receive
> broadcasts (via topic exchange). Since there are different clients
> connecting with their own applications, the clients are strictly
> limited to do only some actions. Currently, I have fully working test
> application, which is written in Java and is relying on the old Qpid
> API. Since the Qpid API is not really supported, I was trying to
> rewrite this application to JMS. Unfortunately, I run into several
> problems:
>
> 1) To send requests, the client should send the message to a direct
> exchange specific for every client. The message needs to have a client
> specific routing key defined, which routes the message to a queue
> where it is picked up by the server application. The exchanges are
> predefined and the client is forbidden to define exchanges. Doing this
> with Qpid API is not a problem. I tried to do so in the JMS with
> following code (it is based on the JMS examples):
>
> _producer = session.createProducer(null);
> TextMessage txtMessage;
> txtMessage = session.createTextMessage("<?xml version=\"1.0\"
> encoding=\"UTF-8\" standalone=\"no\"?><FIXML>.....</FIXML>");
> _producer.send(requestDestination, txtMessage);
>
> The destination called requestDestination is defined using JNDI as
> direct://service.CLIENT_X/?routingkey='CLIENT_X.XYZ'. However, when I
> run this code against the broker, the message is not send and it fails
> with "ACL denied exchange declare request" (however, this error
> appears only in the broker log file, not on the client).
When ACL denies an operation the session will be invalidated.
Therefore you should get a JMS exception.
> Running the
> program with "-Dqpid.declare_exchanges=FALSE" doesn't help. I
After looking at the code, I noticed that the -Dqpid.declare_exchanges
is not checked before calling the exchange declare method.
I will fix this for folks still using the old binding URL format.
However in your case, I would recommend you to use the new addressing
syntax instead of the binding URL scheme.
The documentation is available here
http://people.apache.org/~jonathan/Programming-In-Apache-Qpid.html
(The above docs will appear in our new website fairly soon, until then
you could use the above link.)
For your specific case the addressing string would be as follows.
destination.<your-jndi-name>="amq.direct/CLIENT_X.XYZ; {create:
always, link : {name : service.CLIENT_X} }"
If you want the only the consumer to create the queue (and not the
producer) then use "create: receiver" instead of "create : always".
The documentation should give you a good overview of all the options available.
If you run into issues, please don't hesitate to contact us.
Please note the addressing support is only available in trunk.
Even if I fix the bug with -Dqpid.declare_exchanges you would still
need to use trunk, therefore it's best to use the new addressing
syntax.
> discussed this problem here already a year ago, it should be caused by
> BasicMessageProducer_0_10, method declareDestination. However, when I
> comment out the exchangeDeclare call in this method, it fixes the
> problem with ACL, but it cause's my broker to crash after processing
> the message, which I don't know how to fix.
>
What do you mean by broker crash?
Does it core dump ?
If you could provide details of the broker crash via a JIRA, that
would be great as it could be a bug in the broker code.
> 2) To receive responses, the client has to create his own queue and
> bind the queue with another direct exchange. The queue name as well as
> the routing key have to be in a specific format. The queue needs to be
> autodelete, exclusive and have RING policy type with max_size 1000. I
> tried following JMS code:
>
> MessageConsumer responseConsumer = session.createConsumer(responseDestination);
> responseConsumer.setMessageListener(this);
>
> Where response destination is
> direct://service.response/service.tmp.CLIENT_X.123456_resp?routingkey='CLIENT_X.56789'&autodelete='TRUE'&exclusive='TRUE'.
> But I don't know, how to define the policytype=RING and max_size=1000.
> All parameters I tried are ignored. And without proper policy type and
> queue size, I fail again on ACL (this time, the error handling works
> fine => I get a proper exception on the client side). How can I
> specify the policytype and max_size?
The addressing syntax can cover the above case.
Here is an example,
"amq.direct/CLIENT_X.56789; {create: receiver, link : {name :
service.tmp.CLIENT_X.123456_resp, x-declare : { auto-delete: true,
exclusive: true, 'qpid.max_size': 1000, 'qpid.policy_type': ring } } }
"
> 3) To receive broadcasts, the clients have to create their own queue
> and subscribe the broadcasts using an binding between topic exchange
> and their queue. I tried to use the same consumer as in point 2), but
> since this is an topic exchange, I cannot use following destination
> direct://service.broadcast/service.tmp.CLIENT_X.123456_bcast?routingkey='#.weather.usa.#'&autodelete='TRUE'&exclusive='TRUE'.
> It is forcing me to use the Topic JNDI. But if I specify the topic
> JNDI just as #.weather.usa.#, it is trying to bind the default topic
> exchange amq.topic (which is different from the exchange I want to
> use) and it uses queue with different name and parameters, then what
> the client is allowed to. How can I setup binding between a specific
> topic exchange and my own very specific queue? (possibly with more
> bindings to the same queue)
Here is an example,
"my-own-topic-exchange/usa.#; {create: receiver, link {name: my queue,
x-declare: {auto-delete: true, 'qpid.max_size': 1000} , x-bindings:
[{exchange : 'amq.direct', key : test},{exchange : 'amq.topic', key :
'xyz.#'}]} }"
Here you are making 3 bindings to the queue "my-queue".
1 my-own-topic-exchange with key "usa.#"
2. amq.direct with key "test"
3. amq.topic with key "xyz.#"
The link properties are there to define your subscription queue.
The x-declare (inside link props) will allow you to customize the queue props.
The x-bindings (inside link props) will allow you to specify
additional bindings.
I suggest you to read the documentation I mentioned above to get a
proper understanding of the concepts.
Please let us know if you run into issues, if the docs are not clear
or find a use case that is not covered by the addressing syntax.
> The configuration on the broker may look quite strict, but I see that
> as the only way to provide a stable service to all connected clients.
> Since the service is already running, I'm not free to change the
> configuration as I want. Therefore, I prefer finding a solution which
> would fit the configuration.
>
> FYI: I was trying this with Qpid 0.5, 0.6 as well as the latest trunk.
> The broker is C++ ...
Again the new addressing support is only available in trunk.
I hope I managed to answer all your questions. If not feel free to
clarify any doubts.
> Thanks & Regards
> Jakub Scholz
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org