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 Fri, 25 Jun 2010 14:06:09 GMT
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 <scholzj@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 <rajith77@gmail.com> wrote:
>> 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
>> 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


Mime
View raw message