I ended up trying what you propose. I had an issue that I didn't know
when I could delete the queue. I ended up sending messages back to
the producer to do the deletion which worked and then it all got very
slow when I added clustering. My requirements have eased a little in
this area and I'm no
Adam Chase wrote:
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 t
On 4 Feb 2009, at 22:50, Robert Greig wrote:
The big difficulty we have is a hard requirement for in-order message
processing. This unfortunately rules out load balancing from a
queue across
active-active client pairs. We'd rather just route incoming msgs to a
store-and-forward topic, and
2009/2/2 Andrew Wright :
> Essentially, yes. Each app node is responsible for a subset of the data
> processing (we're looking to implement an order matching engine/exchange).
OK - a domain quite familiar to me.
> The big difficulty we have is a hard requirement for in-order message
> processing
Andrew Wright wrote:
Hi Carl,
It's a little different to scheduling/job submission - but perhaps not
that different. Any examples from other systems would be most helpful,
if you wouldn't mind pointing me in their direction it'd be much
appreciated.
ack, I think this one aspect will might
Hi Carl,
It's a little different to scheduling/job submission - but perhaps not
that different. Any examples from other systems would be most helpful,
if you wouldn't mind pointing me in their direction it'd be much
appreciated.
Cheers,
Andrew
On 31 Jan 2009, at 02:07, Carl Trieloff wrot
Thanks for the comments - a few responses below.
On 31 Jan 2009, at 23:20, Robert Greig wrote:
2009/1/30 Andrew Wright :
Actually this was to integrate with Terracotta. TC needs some sort
of load
balancer to get locality of reference (for performance) - qpid
would fit the
bill here, via hi
2009/1/30 Andrew Wright :
> Actually this was to integrate with Terracotta. TC needs some sort of load
> balancer to get locality of reference (for performance) - qpid would fit the
> bill here, via hierarchical topics. There'd only be a single subscriber on a
> topic at a time. TC clients are not
Andrew,
In some other work some of I guys I work with have done have created a
low-latency scheduling mechanism via AMQP (Qpid) for the Condor Grid. It
sounds like you are trying to achieve something equivalent using a
different grid engine. If you like I can point you to doc and code for
th
Actually this was to integrate with Terracotta. TC needs some sort of
load balancer to get locality of reference (for performance) - qpid
would fit the bill here, via hierarchical topics. There'd only be a
single subscriber on a topic at a time. TC clients are notified as
nodes join/leave,
2009/1/30 Andrew Wright :
> Apologies, I've confused the options rather. We'd thought about using the
> dynamic federation features in M4 to get effective point-to-point links
> between 'entry' nodes, and 'processing' nodes, in a distributed app. The
> idea was that each app node would subscribe to
Apologies, I've confused the options rather. We'd thought about using
the dynamic federation features in M4 to get effective point-to-point
links between 'entry' nodes, and 'processing' nodes, in a distributed
app. The idea was that each app node would subscribe to a subset of
incoming mess
2009/1/29 Andrew Wright :
> There is currently debate going on as to the relative merits of a
> centralised, active-active qpid cluster vs. local brokers on active-active
> application nodes. Given we're looking at using durable topic subscribers,
> does anyone have recommendations/suggestions/war
Andrew Wright wrote:
Yes indeed - we are aware of the active-active apid clustering - it's
a good thing!
There is currently debate going on as to the relative merits of a
centralised, active-active qpid cluster vs. local brokers on
active-active application nodes. Given we're looking at using
Yes indeed - we are aware of the active-active apid clustering - it's
a good thing!
There is currently debate going on as to the relative merits of a
centralised, active-active qpid cluster vs. local brokers on active-
active application nodes. Given we're looking at using durable topic
su
2009/1/29 Carl Trieloff :
>
> Have you given the Qpid Active-Active cluster a spin yet? did you know we
> had one..
I had assumed from the description I had read that the HA here was
around the client apps not the broker? Is that right Adam?
RG
---
Have you given the Qpid Active-Active cluster a spin yet? did you know
we had one..
i.e. we can do full Active Active clustering out the box with the C++
broker. it add about .35ms round trip
latency on latencytest to keep a 4 node A-A cluster fully in sync
Carl.
Andrew Wright wrote:
Yes,
Yes, that's right. We're looking at in-memory replicated clustering
technologies (eg. Terracotta/Coherence etc) in an active-active style
setup.
Cheers,
Andrew
On 28 Jan 2009, at 23:44, Robert Greig wrote:
2009/1/22 Andrew Wright :
Background: we're examining ways to get reliable app-leve
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
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
-
Thanks for the tip - we'll check it out.
On 23 Jan 2009, at 01:14, Carl Trieloff wrote:
Andrew Wright wrote:
Hi all,
I've been watching this thread with interest (partially in the hope
of an example as well!) An example of atomic update of direct
bindings does sound very interesting. Is i
sure that sounds interesting.
Adam
On Thu, Jan 22, 2009 at 10:51 AM, Carl Trieloff wrote:
>
> Adam,
>
> there is now also an option to atomically update a direct binding. This
> means that you can
> move where the messages are being routed without fear.
>
> This would also be a very simple way t
Andrew Wright wrote:
Hi all,
I've been watching this thread with interest (partially in the hope of
an example as well!) An example of atomic update of direct bindings
does sound very interesting. Is it possible to get at this from Java?
(Pure JMS not a requirement).
Andrew,
yes, when you
Hi all,
I've been watching this thread with interest (partially in the hope of
an example as well!) An example of atomic update of direct bindings
does sound very interesting. Is it possible to get at this from Java?
(Pure JMS not a requirement).
Cheers,
Andrew
Background: we're examinin
Adam,
there is now also an option to atomically update a direct binding. This
means that you can
move where the messages are being routed without fear.
This would also be a very simple way to do this use case.
if you want to try that I can give it a try I send an example on how to
Carl.
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.
Carl.
Adam Chase wrote:
Any luck on this headers exchange wiki page? I'd be content with just
a basic outline.
Thanks,
Adam
On Thu, Jan 8, 2009 at 3:2
Any luck on this headers exchange wiki page? I'd be content with just
a basic outline.
Thanks,
Adam
On Thu, Jan 8, 2009 at 3:24 PM, Robert Greig wrote:
> 2009/1/7 Carl Trieloff :
>
>> We do support the headers exchange, so that can be used. Maybe the best
>> thing is to
>> doc the pattern on a
Adam Chase wrote:
I delayed giving message credit for a queue until the previous message
had completed and this prevented the queue from getting deleted
prematurely.
When explicitly giving message credit, do you need to give more credit
when you release a message? Or just for accepted messages?
I delayed giving message credit for a queue until the previous message
had completed and this prevented the queue from getting deleted
prematurely.
When explicitly giving message credit, do you need to give more credit
when you release a message? Or just for accepted messages?
Adam
On Fri, Jan
Adam Chase wrote:
So I'm trying this approach...
I'm manually accepting the messages. And I have COMPLETE_ON_ACCEPT.
It seems like the queue is able to be deleted even with the if_empty
flag sent when my listener has the last message but I haven't accepted
it yet. Not sure if that's a bug or n
So I'm trying this approach...
I'm manually accepting the messages. And I have COMPLETE_ON_ACCEPT.
It seems like the queue is able to be deleted even with the if_empty
flag sent when my listener has the last message but I haven't accepted
it yet. Not sure if that's a bug or not. If I check the
Thanks.
Adam
On Thu, Jan 8, 2009 at 3:24 PM, Robert Greig wrote:
> 2009/1/7 Carl Trieloff :
>
>> We do support the headers exchange, so that can be used. Maybe the best
>> thing is to
>> doc the pattern on a wiki page using headers exchange for Adam. Are you able
>> to do that?
>
> Yes, I'll tak
2009/1/7 Carl Trieloff :
> We do support the headers exchange, so that can be used. Maybe the best
> thing is to
> doc the pattern on a wiki page using headers exchange for Adam. Are you able
> to do that?
Yes, I'll take a look at writing that up over the next few days. I
think it will work, alth
When you get an exception, how do you clear it from the session? Do
you need to create a new session?
Thanks,
Adam
On Mon, Jan 5, 2009 at 3:16 PM, Alan Conway wrote:
> Carl Trieloff wrote:
>>
>> Adam Chase wrote:
>>>
>>> Premature sending (sorry) (the tab key killed me)
>>>
>>> So I have a sy
Robert Greig wrote:
2009/1/6 Carl Trieloff :
Adam Chase wrote:
But Qpid doesn't currently support selectors, right?
Qpidd does not have server side selectors, the Java client has client side
selectors. Java broker to Java client can also do selectors. So if you want
to use an
Adam Chase wrote:
Does AMQP support selectors? Would Qpid supporting something like
that in the future be possible?
Yes, its certainly something I want to get added. I currently have a
Jira for it: https://issues.apache.org/jira/browse/QPID-530. I'm
unlikely to get time to start on this unti
roadmap.
RG
-Original Message-
From: Adam Chase
Sent: 07 January 2009 01:34
To: users@qpid.apache.org; cctriel...@redhat.com
Subject: Re: Queue creation/deletion
Does AMQP support selectors? Would Qpid supporting something like
that in the future be possible?
Just curious.
Adam
On Tue
On Wed, Jan 7, 2009 at 1:34 AM, Adam Chase wrote:
> Does AMQP support selectors? Would Qpid supporting something like
> that in the future be possible?
AMQP 1-0 drafts do, earlier versions don't.
The Qpid Java broker already supports server side selectors, and the
0-10 Java client supports cli
Does AMQP support selectors? Would Qpid supporting something like
that in the future be possible?
Just curious.
Adam
On Tue, Jan 6, 2009 at 5:56 PM, Carl Trieloff wrote:
> Adam Chase wrote:
>>
>> But Qpid doesn't currently support selectors, right?
>>
>>
>
> Qpidd does not have server side sel
2009/1/6 Carl Trieloff :
> Adam Chase wrote:
>>
>> But Qpid doesn't currently support selectors, right?
>>
>>
>
> Qpidd does not have server side selectors, the Java client has client side
> selectors. Java broker to Java client can also do selectors. So if you want
> to use anything other than Ja
Adam Chase wrote:
But Qpid doesn't currently support selectors, right?
Qpidd does not have server side selectors, the Java client has client side
selectors. Java broker to Java client can also do selectors. So if you
want
to use anything other than Java client or JMS then you will need t
But Qpid doesn't currently support selectors, right?
Adam
On Tue, Jan 6, 2009 at 5:23 PM, Robert Greig wrote:
> 2009/1/6 Adam Chase :
>
>> 4) something else?? If I have the queue auto-delete, won't I lose
>> messages if the consumer that is subscribed to that work queue
>> crashes? Put all the
2009/1/6 Adam Chase :
> 4) something else?? If I have the queue auto-delete, won't I lose
> messages if the consumer that is subscribed to that work queue
> crashes? Put all the work in one queue and have consumers release
> messages that they aren't responsible for, group responsibility could
>
Thank you for the responses.
Essentially there are groups and each group has a set of messages
associated with it that need to get processed in order. I want only
one consumer processing a particular group at a time. I'd like to
distribute the work among a number of consumers. I occasionally wo
Carl Trieloff wrote:
Adam Chase wrote:
Premature sending (sorry) (the tab key killed me)
So I have a system where I have groups of messages that need to be
accumulated and then processed exclusively. I might get a message for
any group at any time. The space of possible groups is quite large,
2008/12/31 Adam Chase :
> But between the pop and the delete, a message is added to the queue.
> This is possible, right?
Yes. In general, I don't like comparisons between RDBMSs and
messaging, but I think here there are some parallels. Most RDBMSs
don't have transactional DDL and it is the same
Adam Chase wrote:
Yes.
consumer:
if (queue.pop() == false && lastReceived > timeout)
{
delete(queue);
}
But between the pop and the delete, a message is added to the queue.
This is possible, right?
Adam
You can solve the above issue using an alternate queue or, you can
unbind the queu
Yes.
consumer:
if (queue.pop() == false && lastReceived > timeout)
{
delete(queue);
}
But between the pop and the delete, a message is added to the queue.
This is possible, right?
Adam
On Tue, Dec 30, 2008 at 9:58 PM, Carl Trieloff wrote:
> Adam Chase wrote:
>>
>> Premature sending (sor
Adam Chase wrote:
Premature sending (sorry) (the tab key killed me)
So I have a system where I have groups of messages that need to be
accumulated and then processed exclusively. I might get a message for
any group at any time. The space of possible groups is quite large,
but at any time I exp
50 matches
Mail list logo
