qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: Problems with JMS API
Date Wed, 16 Jun 2010 16:08:41 GMT
On Tue, Jun 15, 2010 at 2:53 PM, Jakub Scholz <scholzj@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
(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

> 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


Rajith Attapattu
Red Hat

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

View raw message