Sadly, It is still the case.
Rajith
On Fri, Jul 5, 2013 at 10:04 AM, Gordon Sim wrote:
> On 07/05/2013 02:59 PM, Rajith Attapattu wrote:
>
>> The JMS client will issue a "Flush" when ever it reached the byte or
>> command limit.
>> I incorrectly stated it as
wrote:
> On 07/05/2013 02:08 PM, Rajith Attapattu wrote:
>
>> The timeout happens when the brokers fails to respond to sync operation
>> during the specified time.
>>
>
> Does the JMS client actually sync now? In the past it only used to flush
> instead, which for d
The timeout happens when the brokers fails to respond to sync operation
during the specified time.
This could be due to a number of issues.
1. Broker under load and unable to respond in time.
2. The queue is being filled up and the broker applying flow control (what
Jakub described).
2. If persist
Assuming it's the JMS client,
If you have a single broker then you could set "retries" to a large amount
along with a delay btw retries.
Ex.
amqp://username:password@clientid/test?brokerlist='tcp://localhost:5672?retries='1000'&connectdelay='5000''
If you have a list of brokers, then you could
+1 on this.
Having the flexibility to have individual release cycles for each component
will be huge advantage for us.
However as Justin mentioned, we shouldn't rule out a Qpid wide release
perhaps once a year or so.
>From a users perspective this is a great thing to have, bcos all the
components b
I really like the box as well. It's clear and concise.
I like the fact that the layout is fluid, so it should work well on
different devices.
(William Henry has every device under the Sun, I usually enlist him to
help me with that).
The links on right hand side is nice to have from the main page.
For starters I would copy this email to the user list.
(In the future we should post things like this to a more wider
audience, especially if we are looking for feedback based on real
world use cases.)
I actually like the minimalistic approach you've taken here. It works
well in an embedded contex
On Tue, Mar 19, 2013 at 11:15 AM, Gordon Sim wrote:
> On 03/19/2013 02:55 PM, Rajith Attapattu wrote:
>>
>> Speaking with Gordon, I came to the conclusion that we first need to
>> figure out what we mean by Equals.
>> Does equals mean,
>>
>> If two consumers
be the
> meaning of it in this case?
>
> Kind Regards,
> Alex
>
> On 18 March 2013 14:57, Rajith Attapattu wrote:
>> IMO option two is not correct. The address string contains destination
>> information, directives for creating/deleting or verifying and other
>> d
could have unexpectedly started returning a lot of different
> Topic objects that always say they are equal when they are clearly not
> expected to be.
>
> Robbie
>
> On 11 March 2013 21:04, Rajith Attapattu wrote:
>
>> Hi All,
>>
>> While fixing QPID-3769, I
Hi All,
While fixing QPID-3769, I came across this issue.
There are two options for implementing the equals method (and hashcode).
1. Check the "type" and "name" to ensure they both point to the same
"destination" (which could be a queue or an exchange in pre 1.0
terms).
2. Do a comprehensive c
On Mon, Mar 4, 2013 at 12:54 PM, Richard Peter
wrote:
> Ok, this wasn't an issue with the C++ broker, if a queue was marked durable
> any message was persisted. Thanks for the clarification.
This is not correct. You need to mark the the message as persistent in
order for it to be written to disk
can't say for sure,
> any thoughts on that?
>
>
> Does anybody have any better suggestions than those that'll allow me to use
> lists across different Qpid releases without needing different builds?
>
>
> Did I mention I preferred ObjectMessage :-) so this'll be a
> of List/Map in ObjectMessage plus exposing AMQP Content-Type will a)
> maximise consistency between JMS and qpid::messaging and b) keep within the
> JMS spec. Both of these are IMHO a really good thing.
>
> Regards,
> Frase.
>
>
>
> On 29/01/13 16:27, Rajith Attapattu
I was trying to do something about it but dropped the ball for reasons
I can't seem to remember.
I looked the code and we don't expose it.
I believe there is a JIRA for this.
Rajith
On Sat, Jan 26, 2013 at 11:59 AM, Fraser Adams
wrote:
> Hello all,
> I could have *sworn* I'd seen some postings
hich is suggesting that Lists now seem to be encoded in MapMessages with
> keys that are indices :'( .
>
>
>
> To be fair Rajith Attapattu did post on this subject at the end of August:
>
> http://qpid.2158936.n2.nabble.com/JMS-ListMessage-support-tp7581434.html
>
> and
I was one person who advocated for separate mailing lists in the past.
But given what I have seen so far, I think you raise some very
important concerns.
I'm +1 on consolidating the lists provided we keep the commits/JIRA to
a separate list.
It seems a lot of "users" are not aware of proton or hav
David,
If you have security concerns, I think rather than trying to write a
custom JMS listener, it would probably be worthwhile looking at using
a more secure mechanism like SSL certificates or Kerberos.
Rajith
On Mon, Dec 10, 2012 at 3:25 PM, wrote:
> Hi, Phil,
>
> Got it. It seems that we n
Sajith,
As Phil mentioned, using durable subscriptions is one way of doing it.
You could also use Queues in this case as long as you use 1 queue per node.
When your "client" sends a message it will end up in all the nodes
"interested" in your message.
Lets say you send a message to the following
On Tue, Sep 25, 2012 at 10:42 AM, oggie wrote:
>> When you use topics, a private temp queue is created when a
>> subscription is made.
>> So until then a queue does not exist!
>>
>> If you want a queue to be around at all times, you need use a named Queue.
>
> But I thought my config in my vhost f
On Tue, Sep 25, 2012 at 9:59 AM, oggie wrote:
> I'm using 0.18 java broker. I'm also using a jms producer and and a jms
> consumer. The consumer is using the MessageListener class and the onMessage
> listener. I'm also using spring jms.
>
> It appears that it's in pub/sub mode since the queue doe
You're welcome! glad it worked out for you.
Rajith
On Tue, Sep 11, 2012 at 3:05 PM, ParkiratBagga wrote:
> Thank You Rajith.
>
> As soon as, I replaced the jars with 0.18 version (qpid client). It worked
> like magic.
>
> I was struggling with this morning. :)
>
> Regards,
> Parkirat Singh Bagga
No there is no version mismatch, just that I'm worried that there may
be a bug in the older version.
Are you able to test with the 0.18 jars ? if it works then we know
it's fixed, if not we can investigate this further.
Rajith
On Tue, Sep 11, 2012 at 2:06 PM, ParkiratBagga wrote:
> Thanks Rajith
I suspected the same, but the NPE worries me that it maybe something more.
If the path was wrong we should throw a file not found exception (or
at least we used to iirc).
Rajith
On Tue, Sep 11, 2012 at 1:18 PM, Gordon Sim wrote:
> On 09/11/2012 04:53 PM, ParkiratBagga wrote:
>>
>> Caused by: jav
Hi Parkirat,
What version of broker and client are you using ?
If you are using an older client, are you able to try it with the 0.18
java client (the latest release) ?
I looked at the line numbers in the stack trace and it appears the
version you are using a is a bit different to the one on trunk
I would also lean towards option one.
Agree with Gordon that there is a lot of overhead of reconnecting periodically.
I don't have enough info about your situation, but are you able to
partition your queues across several brokers?
If so you could reduce the number of connections per broker.
If you
Hi All,
There have been a need for a ListMessage support with JMS particularly
among the folks who are using QMFv2.
We have been exploring several ways of providing this and would like
to solicit feedback from the user community.
Following is a summary of the options.
1. Make the list message acc
On Tue, Aug 21, 2012 at 5:21 PM, Roger wrote:
> We are using rabbitmq which is using 0-9. Don't know if it will ever move to
> 0-10 - some differences of opinion on AMQP front.
Understood.
> Played around and got burl to work on default exchange.
> (BURL:direct:myQueue?routingkey='test')
Glad
elow might actually be
> missing a / after amq.topic as well)
I haven't used BURL for a while now :D and relied on the following
link for the example.
https://cwiki.apache.org/qpid/bindingurlformat.html
>
> Robbie
>
> On 21 August 2012 21:42, Rajith Attapattu wrote:
>
>> T
The new syntax is the addressing format.
The old format is BURL which will work with 0-8/0-9 as well.
The hello.properties is using the addressing format.
If you want to use the older format, do the following
BURL:topic://amq.topic?routingkey='test'
The format is described here https://cwiki.apac
Are you running against an AMQP 0.8 broker ?
The examples use the new addressing syntax which is supported only
AMQP 0-10 and upwards.
Regards,
Rajith
On Tue, Aug 21, 2012 at 12:23 PM, Roger wrote:
> Failed to mention that I'm using java client 0.16.
>
> Roger
>
>
>
> --
> View this message in
+1 for (a).
Rajith
On Tue, Aug 7, 2012 at 2:16 PM, Andy Goldstein
wrote:
> My vote is for (a)
>
> Andy
>
> On Aug 7, 2012, at 2:11 PM, Gordon Sim wrote:
>
>> So, to follow up and summarise this thread so far, the only contentious
>> point has been the loss of the 'flow to disk' functionality.
>
Harry,
You could have multiple consumers, but flow control might not be optimal.
Try it out in your environment and see if you are happy with the results.
I wouldn't make a hard decision on having one consumer per session due
to this issue alone.
Rajith
On Fri, Jul 27, 2012 at 2:28 PM, Harry.al
The "target" capacity was meant for producer flow control which was
never implemented.
The "source" capacity is used as message credits for the subscription.
However flow control is controlled at the session level.
That is the unacked messages for the session is taken into account
when issuing com
t allow this so easily.
> We would probably need to change our producers to send the messages
> individually - N producers for N consumers. Only then we will be able
> to use the producer flow control ...
>
> Regards
> Jakub
>
> On Mon, Jul 23, 2012 at 3:27 PM, Rajith Attapattu
Jakub,
I wonder if producer flow control can help here.
If implemented properly this should (at least theoretically) prevent
the broker from going out of memory due to queue growth.
As you correctly point out, flow-2-disk just postpones it at best, in
addition to the fact that it has a serious imp
On Tue, Jul 17, 2012 at 5:52 AM, ghada wrote:
> Hello,
>
> I am a debutante in programming the Apache QPID.
> I want to achieve a Java program "Publisher/subscriber" that sets up a
> publisher and two subscribers sharing the same topic.
> I searched in forums for examples but I found nothing.
> Ca
. In fact, it may be lower, as response queues
> will only exist while clients are waiting for replies.
This is assuming the number of queues in both cases are the same :)
>
> Thanks,
>
> - Toralf
>
>
>
>>
>>
>> On Mon, Jul 16, 2012 at 10:45 AM, Toralf Lun
9:45 AM, Toralf Lund wrote:
> On 16/07/12 15:01, Rajith Attapattu wrote:
>>
>> I'd agree with Gordon.
>> If at all possible I will pre-create my private queues, rather than
>> creating them on demand.
>> Writing a bit of extra code for working with a f
I'd agree with Gordon.
If at all possible I will pre-create my private queues, rather than
creating them on demand.
Writing a bit of extra code for working with a fix number of queues is
worth from a performance standpoint.
Regards,
Rajith
On Mon, Jul 16, 2012 at 8:39 AM, Gordon Sim wrote:
> On
Both onMessage() and receive() will fetch messages.
By default we prefetch 500 messages at a time (if available on the server).
I don't see any advantage of using both receive and ML together, it
will only complicate your code.
There is no periodic polling, when messages become available the
brok
+1 for moving the benchmark script outside.
I managed to use the qpid-cpp-benchmark script with minor changes for
the corresponding JMS send/receive tools.
Regards,
Rajith
On Wed, Jul 11, 2012 at 10:23 AM, Andy Goldstein
wrote:
> We use these apps all the time. I'd prefer to see them all moved
The qpid::client is no longer supported.
Please use the client provided via qpid::messaging
Regards,
Rajith
On Sun, Jul 8, 2012 at 10:40 AM, Zhihua Che wrote:
> Hi,
>
>I learned that namespace qpid::client is conventional amqp-style
> api. As far as I know, the doc offered by official websi
d saw
> geronimo-jms_1.1_spec-1.0.jar which I believe will also be required along
> with the broker and common jar's?
>
> On Thu, Jul 5, 2012 at 6:32 PM, Rajith Attapattu wrote:
>
>> Gaurav,
>>
>> Please use the JMS API, there is no non-jms java client.
am doing is stopping the
> broker at the point in time that my consumer receives a messge (using a
> MessageConsumer), and sleeps for 10s.
>
> I've rolled 0.16 into our applications and they are all reconnecting
> successfully.
>
> Richard
>
> -Original Message
Gaurav,
Please use the JMS API, there is no non-jms java client.
(We might provide one in the future, we are working through that at the moment).
Have a look at
http://qpid.apache.org/books/0.16/Programming-In-Apache-Qpid/html/QpidJMS.html
on how to use the JMS client.
Regards,
Rajith
On Thu,
standalone reproducer you used?
Regards,
Rajith
On Tue, Jul 3, 2012 at 7:10 PM, Rajith Attapattu wrote:
> I tested with trunk and is unable to reproduce this issue.
> Richard could you please confirm if you are still seeing this issue with
> trunk?
> (The code on trunk is what we woul
ght be able to shed some light on what you are seeing Richard, but
> you might want to try the 0.14 Java client runtime instead of the 0.10 one
> to see if that helps things.
>
>
> FWIW I ended up rolling my own reconnection via a JMS Connection
> ExceptionListener but
olution!
> >I'm afraid I don't see a short term solution that could help you
> immediately.
>
> I see. I suppose I will try linked-in drivers or NIFs as a short-term
> solution.
>
>
> Best Regards,
> Sergey
>
> -Original Message-
> From: Raj
> call setConnectionListener, passing your implementation of the
> ConnectionListener interface.
>
>
> AMQConnection#setConnectionListener(org.apache.qpid.jms.ConnectionListener);
>
> Hope this helps
>
> Keith,.
>
>
>
> On 28 May 2012 18:34, Rajith Attapattu wrote:
&g
ould help you
immediately.
Rajith
Moreover c++ broker does not support ampq 1.0 at the moment.
>
> Best Regards,
> Sergey
>
> -Original Message-
> From: Rajith Attapattu [mailto:rajit...@gmail.com]
> Sent: Monday, May 28, 2012 9:42 PM
> To: users@qpid.apache.org
> Subje
Erlang does not have a swig binding.
Your bet best is to do an Erlang driver. But AFIK drivers can only be in C.
Therefore you might have to get a C wrapper around the C++
Even if you get all that going, the difference in the programming paradigms
(functional vs oo) might prevent you from getting
Hamid,
At the moment JMS provides transparent failover. Therefore you will only
get notified (via the exception listener) if you cannot reconnect
successfully.
Since these reconnects are transparent to the application, I wonder why you
want to log them?
If you really want to go that route, you co
Just to add to Alex's note,
On the flip side, If you select sync_publish it will affect performance
quite a bit.
Rajith
On Mon, May 14, 2012 at 10:28 AM, Oleksandr Rudyy wrote:
> Hi Shyamal,
>
> By default, MessageProducer#send operation is asynchronous, i.e. a
> message is put on a wire and pr
he filter, it seemed to me that
> >> it switched off the acknowledgments completely. The Java application
> >> was getting only the selected messages, but I was unable to
> >> acknowledge them and they stayed in the queues. This may be O
Reading your query again, it seems you want selectors to work not really to
do selective message acking.
So I wondering why you can't use a jms selector ? The JMS client supports
message selectors.
I'm wondering why you need to use a workaround here ?
(Note for C++ broker we do client side selecto
On Thu, Apr 12, 2012 at 9:53 AM, Pavel Moravec wrote:
> Hello,
> having Java client and C++ broker, I want to implement selective
> consumption of messages from a queue (something like JMS message selectors
> in Java broker). I.e.:
>
> 1) Having CLIENT_ACKNOWLEDGE mode,
> 2) In a loop through all
Sorry for dropping the ball on this.
It seems Gordon has provided the answer you are looking for.
Sorry again for the delay in responding.
Rajith
On Mon, Apr 9, 2012 at 4:18 PM, ParkiratBagga wrote:
> Even Java Spout Example is giving the following exception while running
> with
> c++ broker.
>
On Wed, Apr 4, 2012 at 8:51 AM, Bruno Matos wrote:
> On Wed, 2012-04-04 at 12:20 +0100, Gordon Sim wrote:
> > On 04/04/2012 10:49 AM, Bruno Matos wrote:
> > > Hi,
> > >
> > > I'm publishing messages with different addresses (ex:
> > > amp.topic/news.1.soccer, amp.topic/news.2.soccer,
> > > amp.top
The jms client code looks fine to me and the your observation that messages
are available after a restart confirms that the jms client is marking the
messages as persistent and the broker doing it's part.
(However IIRC messages does not need to be marked persistent for
flow-2-disk to work - but I s
Sorry I was late to the discussion.
I was sick the whole of last week and this week I had to deal with a
few issues and was late in catching up on email.
Both max-prefetch and capacity are only relevant on the consumer side
and they mean the same thing.
If capacity is specified in the address stri
.
Rajith
> Thanks,
> Jigar
>
>
> On Thu, Feb 2, 2012 at 9:42 PM, Rajith Attapattu [via Qpid] <
> ml-node+s2158936n7247428...@n2.nabble.com> wrote:
>
>> Hi Jigar,
>>
>> I'm sorry to hear that you had trouble with running the examples.
>> I
king on this since past whole week without any success)
>
> Though i am new to qpid, Have worked on JMS for long. Its just lots of
> headache to get this working...looking for alternative.
>
> Thanks,
> Jigar
>
> On Wed, Feb 1, 2012 at 12:29 AM, Rajith Attapattu [via Qpid] &
On Mon, Jan 30, 2012 at 9:29 AM, jigarshaha wrote:
> Hi,
> I am very new to qpid. I am trying to configure producer which creates
> message with specific type. and puts in exchange, which hosts multiple queue
>
> 1. What exchange-queue mapping is for ? How do i configure Message so that
> its dire
I agree with Rob and others about QMF being it's own project with
independent release cycles/website etc.
We could probably start as a sub project of Qpid and depending on how it
goes make a proposal to move it to a top level project.
Rajith
On Wed, Jan 4, 2012 at 1:51 PM, Rob Godfrey wrote:
>
It's a bit difficult to figure out from your description.
Could you please attach the complete stack trace for the exception ?
Also could you please describe the events again?
What did u mean by " However, after I kill the test JMS
> Client. It seems that my JMS application, connects to broker"
M
You could use -Dqpid.heartbeat=x or use heartbeat as a broker url property.
Btw, Please don't use the AMQ** classes. These are internal classes
that will not be there going forward.
It's better to use the JMS interfaces.
Rajith
On Fri, Nov 18, 2011 at 11:44 AM, Henry Molina wrote:
> Hi All,
>
>
he string message properties set by the C++
>> client are not visible by default for the Java client. (They only become
>> visible if the C++ client sets the property encoding to "utf8".)
>>
>> IMHO this should work by default, especially if both client libraries are
>&g
On Wed, Sep 21, 2011 at 10:53 AM, Gordon Sim wrote:
> On 09/21/2011 02:57 PM, Rajith Attapattu wrote:
>>
>> On Wed, Sep 21, 2011 at 2:52 AM, Jiri Krutil wrote:
>>>
>>> Rajith
>>>
>>> I think this makes perfect sense from the JMS point of vi
rties that does need to be treated as "byte[]".
IMO the C++ client should use a default encoding if a property is set
as a String.
Rajith
>
> Regards
> Jiri
>
>
>
> On Tue, Sep 20, 2011 at 5:29 PM, Rajith Attapattu wrote:
>
>> On Thu, Sep 15, 2011 at 2:34 PM, Frase
On Tue, Sep 20, 2011 at 11:04 AM, Rajith Attapattu wrote:
> On Wed, Sep 14, 2011 at 12:46 PM, Jiri Krutil wrote:
>> Hi
>>
>> I'm having problems with timestamps when sending messages from a C++ client
>> and receiving them in a Java client.
>> The C++ messa
On Mon, Sep 19, 2011 at 2:04 PM, Jakub Scholz wrote:
> OK, JIRA QPID-3494 entered. In your opinion, should the lines of code
> overwriting the exclusive and auto-delete options be removed or
> replaced by different behaviour?
>
> I can try to prepare a patch ... although preparing a patch for
> de
On Thu, Sep 15, 2011 at 2:34 PM, Fraser Adams
wrote:
> Hi Jiri
> Out of curiosity have you looked at the type of the property. In other words
> if you get the property and do a myProperty.getClass().getCanonicalName().
>
> I'll bet that it'll come back as a byte array rather than a String. I
> bel
On Thu, Sep 15, 2011 at 2:55 PM, Jiri Krutil wrote:
> Hi Gordon
>
> Thanks for the interesting info. Will try to set encoding as UTF-8 in the
> C++ sender.
> Btw what are the possible valid values for Variant::setEncoding()? I assume
> UTF-8 is "UTF-8".
>
> In our case we don't receive the string
On Wed, Sep 14, 2011 at 12:46 PM, Jiri Krutil wrote:
> Hi
>
> I'm having problems with timestamps when sending messages from a C++ client
> and receiving them in a Java client.
> The C++ messaging client v0.7 does not allow to set the message timestamp.
> It allows to set TTL, but I'm not doing th
parse does treat it as an integer rather than
a long.
So the maximum you can specify is Integer.MAX which ~ 2GB.
Rajith
> Cheers,
> Frase
>
> Rajith Attapattu wrote:
>>
>> Fraser,
>>
>> That class is not used anymore :)
>> We now allow an arbitrary number of a
On Fri, Aug 12, 2011 at 1:36 PM, Gordon Sim wrote:
> On 08/12/2011 05:39 PM, Rajith Attapattu wrote:
>>
>> We now allow an arbitrary number of arguments within the arguments:{}
>> map and no checking is performed.
>
> How are integers treated? They aren't all
Fraser,
That class is not used anymore :)
We now allow an arbitrary number of arguments within the arguments:{}
map and no checking is performed.
I am doing a bit of cleanup and that classes will be removed as part of that.
Regards,
Rajith
On Fri, Aug 12, 2011 at 2:50 AM, fadams wrote:
> Hi al
On Thu, Aug 4, 2011 at 6:03 AM, Amila Suriarachchi
wrote:
> On Sat, Jul 30, 2011 at 7:20 PM, Rajith Attapattu wrote:
>
>> Use -Dqpid.amqp.version="0-8" for 0-8 version and for 0-91 use
>> -Dqpid.amqp.version="0-91".
>>
>
> One more thing. Which v
In addition to what Alan suggested (which is the preferred way) you
can do the following as well.
java -cp $QP org.apache.qpid.example.Spout -P=qpid.subject=hello "demoQueue"
If you type -h or --help, it will tell you how to specify these properties.
regards,
Rajith
On Wed, Aug 3, 2011 at 9:34
Use -Dqpid.amqp.version="0-8" for 0-8 version and for 0-91 use
-Dqpid.amqp.version="0-91".
Rajith
On Sat, Jul 30, 2011 at 9:18 AM, Amila Suriarachchi
wrote:
> I saw by default qpid client send messages with AMQP version 10. how can I
> change that to 9.1 or 8.0 etc ..
>
> thanks,
> Amila.
>
> --
Sorry for the late reply. I did notice this a few days ago when
debugging for an unrelated issue.
However reading the JMS API doc, it seems the 'type' has a different
meaning than merely content-type.
In other words a particular type of message could support several content-types.
For example "text
I was able to set the sals mech using -Dqpid.sasl_mechs= or
sasl_mechs= in the connection URL
Ex.
"amqp://username:password@clientid/test?brokerlist='tcp://localhost:5672?sasl_mechs='ANONYMOUS''"
How did you set it ? using the JVM arg or the connection URL property?
Rajith
On Tue, Jul 19, 2011
I believe the windows broker was defaulting to anonymous when
authentication was disabled and the JMS client didn't support it.
Since then we have added support for anonymous and this should work
fine with the upcomming 0.12 release.
Rajith
On Thu, Jul 14, 2011 at 6:10 PM, Steve Huston wrote:
>
Hello Toralf,
I checked the list and it appears that you are not subscribed to the
list anymore.
It seems that you have been unsubscribed again and please accept our
apologies for this inconvenience.
As for the reason, I am not sure all though we can see if we could
make some further inquiries.
On Thu, Jun 30, 2011 at 12:52 PM, Gordon Sim wrote:
> On 06/30/2011 05:51 PM, Rajith Attapattu wrote:
>>
>> I am also a moderator but don't really recall this particular email.
>
> Do you have access to a list of subscribers?
I don't know whether I could or no
I am also a moderator but don't really recall this particular email.
Rajith
On Thu, Jun 30, 2011 at 6:00 AM, Marnie McCormack
wrote:
> I'm not sure how to check, but I believe Martin and Carl are the list
> moderators ... at least for dev, and I assume users.
>
> Marnie
>
> On Thu, Jun 30, 2011
gt; connections/disconnections to broker?"
>
> I got a lot of help from Gordon Sim and Rajith Attapattu (thanks guys!!) so
> here's my chance to give back a little.
>
> I've written a client called ConnectionAudit that Logs audit information
> about each connection
Unfortunately the JMS client doesn't put the routing key in message
properties when sending messages.
However I believe the C++ client includes a property called
""x-amqp-0-10.routing-key"
I checked with the C++ version of spout but it didn't seem that
property was used.
I came across this property
On Fri, Jun 24, 2011 at 10:36 AM, Gordon Sim wrote:
> On 06/24/2011 09:31 AM, fadams wrote:
>>
>> As it says in the subject.
>>
>> The reason why I'm asking is that there seems to be some differences in
>> QMF
>> between 0.8 and 0.10 and it would be nice to program clients defensively.
>
> Really,
qpid_broker.#" so the topic
> exchange would be using the subject to apply the binding.
>
> have I missed something???
>
>
> Rajith Attapattu wrote:
>>
>> Fraser,
>>
>> The client who is sending the message (in this case the QMF component
>> in
Fraser,
In JMS there is the meta data properties in the Connection object.
So I guess we should be able to leverage that, atleast using a custom property.
For the following methods, we return the AMQP protocol version.
con.getMetaData().getProviderMajorVersion()
con.getMetaData().getProviderMinor
At present the brokers nor any of the clients really support it
Rajith
On Fri, Jun 24, 2011 at 3:10 AM, fadams wrote:
> Out of curiosity...
>
> Is it possible to configure a client such that it only receives message
> headers from the broker (clearly it's possible for a client to ignore the
s.
>
> Like I say though I've not had any luck with
> getStringProperty("qpid.subject") it seems to return null
>
> Any thoughts?
> Fraser
>
>
> Rajith Attapattu wrote:
>>
>> Hi,
>>
>> I just checked with test program and I can retrieve t
Hi,
I just checked with test program and I can retrieve the subject using
msg.getStringProperty("qpid.subject").
Which qpid release are you using ?
What is the address string you are using on the producer side ?
Regards,
Rajith
On Sat, Jun 18, 2011 at 11:44 AM, fadams wrote:
> Hello,
> can any
k
>
> On Thu, May 26, 2011 at 4:41 PM, Rajith Attapattu wrote:
>
>> Your Welcome !
>>
>> Rajith
>>
>> On Thu, May 26, 2011 at 4:21 PM, Siamak Kolahi
>> wrote:
>> > Thanks Rajith. It works and I am fine now
>> >
>> > On Thu, May
Your Welcome !
Rajith
On Thu, May 26, 2011 at 4:21 PM, Siamak Kolahi wrote:
> Thanks Rajith. It works and I am fine now
>
> On Thu, May 26, 2011 at 3:29 PM, Rajith Attapattu wrote:
>
>> The C++ (python, C#) and JMS clients can recognize text,map and of
>> course mess
nks,
> Siamak
>
> On Wed, May 25, 2011 at 2:26 PM, Rajith Attapattu wrote:
>
>> I am very for sending you down a rat hole.
>> The issue here is the double quotes. The address parser treats the
>> entire thing as the queue name hence the exception.
>> Get rid of
lied in the
>> address doesn't resolve to an exchange or a queue"
>>
>>
>> While I am sure my exchange exists, since its the default header exchange.
>> Any idea what I am missing here?
>>
>> and this is how my property look like:
>> destination.h
What you describe can easily be achieved through Topics.
Each subscriber can subscribe to a Topic at the level they are interested.
Ex
A1 subscriber binds to A1.*
A1-1 subscriber binds to A1.1.*
The producer application then sends messages with the subject A1, B1,
A1.1, B1.2, B2.1 ...etc
Please
1 - 100 of 226 matches
Mail list logo
