Some components of my system need to interact with the broker through C# (and
soon C++). That is the main motivation behind using qpid, rather than other
jms providers.
Marnie McCormack wrote:
>
> The Java broker works with the M4 Java Client and the M4 0-8 .Net client.
> It
> does not yet sup
(sorry for the late response, thought I already replied)
As a user of qpid, I am most interested in getting at the content of a
message immediately (not having to deal with attributes in terms of byte
arrays, not having to unwrap layers of wrappings). A wrapper around
IMessage could do this nice
On Wed, 28 Jan 2009, Alan Conway wrote:
you can also declare the queue with auto_delete=true if you want it
automatically deleted
when you close your session
What about the local queues generated by session.incoming(), such as:
locLocalQueue = session.incoming(locLocalQueueName, auto_delete
I am not totally seeing how I can use this to solve my problem.
I am currently sending all my messages to a direct exchange with the
same routing key. (Maybe a mistake). Suppose I had each "group" of
messages have a different routing key. I can't get all the messages
going to that exchange on a
2009/1/22 Andrew Wright :
> Background: we're examining ways to get reliable app-level node failover
> without losing messages. Best thing we've got so far is durable JMS topic
> subscriptions, and a backup app node taking over a client id if the primary
> node fails. But this atomic-swap of direc
The Apache Qpid community is pleased to announce the release of Apache
Qpid M4!
Apache Qpid (http://qpid.apache.org) is a cross platform enterprise
messaging solution which implements the Advanced Message Queueing
Protocol (http://www.amqp.org). It provides brokers written in Java
and C++ and cli
Ted Ross wrote:
Can you remove references to the management and managementdata
modules? These are obsolete.
Eventually, but
There are actually a zillion obsolete things in the generated API docs,
which makes them a bit of a trap. It needs major cleaning, either by
cleaning up the API i
Jonathan Robie wrote:
I just posted Python API docs here:
http://people.apache.org/~jonathan/qpid/api/python/html/
I'll be linking to that form the wiki. I've decided I'm a fan of
epydoc ;->
Jonathan
-
Apache Qpid - AMQP Me
Carl Trieloff wrote:
don't post it in your home, dir let put it under docs section. I can
help you
OK - thanks, see you in IRC!
Jonathan
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/In
Jonathan Robie wrote:
I just posted Python API docs here:
http://people.apache.org/~jonathan/qpid/api/python/html/
I'll be linking to that form the wiki. I've decided I'm a fan of
epydoc ;->
Jonathan
-
Apache Qpid - AMQP Me
I just posted Python API docs here:
http://people.apache.org/~jonathan/qpid/api/python/html/
I'll be linking to that form the wiki. I've decided I'm a fan of epydoc ;->
Jonathan
-
Apache Qpid - AMQP Messaging Implementation
Pr
2009/1/21 Carl Trieloff :
>
> Rob,
>
> Are you going to be able to provide a brief discription? I can expand it
> with 0-10 based
> code example if you write up the pattern.
Sorry for the delay - I will get round to that this week.
RG
-
I commented out a bunch of stuff, and the second part works now:
SubscriptionManager subscriptions(session);
// Create a listener and subscribe it to the queue named
"message_queue"
Listener listener(subscriptions);
// Receive messages until the subscription is cancelled
//
yes, there are no dequeues, so the broker has all the messages which is
correct. So
it looks like the second subscriptions is not running - will look into that
Carl.
Adam Chase wrote:
I used the qpid-tool and see this for my queue ( I guess I was only
writing 10 messages in my producer):
Alan Conway wrote:
you can also declare the queue with auto_delete=true if you want it
automatically deleted
when you close your session
And that's more robust - it does not depend on your program to get it
right, and it works even if your program crashes.
Jonathan
I used the qpid-tool and see this for my queue ( I guess I was only
writing 10 messages in my producer):
Type Element110
=
property vhostRef 103
property name message_queue
prop
Joshua Kramer wrote:
Remember to delete the queue when you're done with it, or queues will
accumulate on the server.
In python - is it enough to call the close() method of the queue
object, or is there also some sort of destroy() method?
qpid.session.Session.queueDelete() is your friend. I w
Rafael Schloming wrote:
Joshua Kramer wrote:
Remember to delete the queue when you're done with it, or queues will
accumulate on the server.
In python - is it enough to call the close() method of the queue
object, or is there also some sort of destroy() method?
Calling the close() method
Joshua Kramer wrote:
Remember to delete the queue when you're done with it, or queues will
accumulate on the server.
In python - is it enough to call the close() method of the queue object,
or is there also some sort of destroy() method?
Calling the close() method of the queue object does
Remember to delete the queue when you're done with it, or queues will
accumulate on the server.
In python - is it enough to call the close() method of the queue object,
or is there also some sort of destroy() method?
Thanks,
-Josh
--
-
http://www.globalherald.net/jb01
GlobalHerald.NET
Alan Conway wrote:
Justin Ross wrote:
Hi, Josh.
Do you have some kind of user session id you could use to create
session-scoped queues? With a queue per active user, the world would
remain coherent without the need to create and destroy things too much.
Josh - if you create sessions without
Justin Ross wrote:
Hi, Josh.
Do you have some kind of user session id you could use to create session-scoped queues? With a queue per active user, the world would remain coherent without the need to create and destroy things too much.
Josh - if you create sessions without explcitly giving th
Hi, Josh.
Do you have some kind of user session id you could use to create session-scoped
queues? With a queue per active user, the world would remain coherent without
the need to create and destroy things too much.
Justin
Original Message
Subject:Best Practice fo
Hello,
Is there a best practice for handling transient sessions - where server
and local queues are created, publish and consume one message, then
destroyed?
I'm thinking of a case where I service web pages. If I keep the same
queues alive between transactions, then it is concievable that
Adam,
To determine where the issue is, you could also use qpid-tool
then do a
list
show queue
look for the queue ID
show 'queue ID'
and see what is on the queue after the cancel to the local queue. That
will tell us if the client
lib is holding onto them, or the new subscription is not ge
I find this surprising. When Adam does the cancel, I would expect all
messages that haven't been acknowledged to be available on the
server-side queue. When he subscribes the listener, I would expect him
to receive the rest.
In my programs I always set up the subscriptions first, then call
st
Sorry, one more question, are you M4 or trunk, as Gordon had corrected
something in
this area a little while after M4.
Still thinking but the cancel after the start. might need another
start(?). I work more on the broker
so will need to go look at that code.
Carl.
Adam Chase wrote:
That
That is correct.
I published 100 messages to the queue, got one off the localQueue and
then cancelled. Since I didn't accept the one I would expect to get
100 from the listener. But I'm getting none. I think the LocalQueue
must have prefetched them and be holding on to them. I thought maybe
th
Adam Chase wrote:
SubscriptionManager subscriptions(session);
// Create a listener and subscribe it to the queue named "message_queue"
Listener listener(subscriptions);
// Receive messages until the subscription is cancelled
// by Listener::received()
LocalQueu
falconair wrote:
If the callback method returns IMessage itself, then the user has to get
application headers out of it, then get at the actual attributes. That
looks unintuitive to me since the attributes of message are the most
important piece of the message.
According to me a message has a
If the callback method returns IMessage itself, then the user has to get
application headers out of it, then get at the actual attributes. That
looks unintuitive to me since the attributes of message are the most
important piece of the message. Bypassing IMessage completely also doesn't
make sen
31 matches
Mail list logo
