Hi all,
We've run into a small issue with temporary queues. In a nutshell -
calling temporaryQueue.delete() from a JMS app doesn't actually delete
the AMQP queue on the broker. Closing the session that originally
created the temp queue does remove it.
Is this expected or does it sound lik
On 8 Apr 2010, at 13:16, Carl Trieloff wrote:
On 04/07/2010 03:36 PM, Andrew Wright wrote:
On 31 Mar 2010, at 14:30, Andrew Wright wrote:
On 31 Mar 2010, at 14:02, Alan Conway wrote:
On 03/30/2010 05:38 PM, Andrew Wright wrote:
Hi all,
I've recently run some tests to try and se
On 31 Mar 2010, at 14:30, Andrew Wright wrote:
On 31 Mar 2010, at 14:02, Alan Conway wrote:
On 03/30/2010 05:38 PM, Andrew Wright wrote:
Hi all,
I've recently run some tests to try and see how much overhead
clustering
brings. In short - I saw roughly a 50% reduction in me
On 31 Mar 2010, at 14:02, Alan Conway wrote:
On 03/30/2010 05:38 PM, Andrew Wright wrote:
Hi all,
I've recently run some tests to try and see how much overhead
clustering
brings. In short - I saw roughly a 50% reduction in message
throughput
when clients ran against a 2 node cluster
Hi all,
I've recently run some tests to try and see how much overhead
clustering brings. In short - I saw roughly a 50% reduction in message
throughput when clients ran against a 2 node cluster vs a standalone
broker. I'd definitely expect some reduction, but perhaps not as much
as that.
Dare I wonder out loud what might be involved in hooking this up?
(java
client/c++ broker combination of particular interest for us)
Its not a trivial change I'm afraid, and would require some initial
refactoring around the c++ brokers queue implementation. However in
my
opinion it would
On 15 Sep 2009, at 13:33, Gordon Sim wrote:
On 09/15/2009 01:13 PM, Robert Godfrey wrote:
Hi Gordon,
2009/9/15 Gordon Sim
I think clunky is a fair description of the current capabilities
and I
think we can improve on that.
My view of what ideal 'LVQ' behaviour whould be like is that the
Hi all,
We've been using LVQs from our JMS clients and while they work well
enough, the way we're going about feels a little clunky. The process
we use breaks down as:
- Declare a LVQ with the NO_BROWSE option set for the cache
- Declare a second (non-lvq) to receive real-time updates (like
Hi all,
I notice the AMQTopic(String, String) constructor has been commented
out. There's an equivalent on AMQQueue that is still present. Any
particular reason? This would be a handy shortcut, and would need one
less 'AMQ-specific' import (AMQShortString). Obviously using jndi
alleviates
Would a durable subscriber (a la JMS) work? Not sure of the c++ api to
recreate this. That would retain messages received on the exchange
since first registration of the client.
Another potential option may be a 'ring LVQ topic' - one that holds
the last n values which would be sent to a ne
Hi Stephen,
This is a problem in the java client that shipped with M4. It's fixed
in svn-trunk, if you need a workaround in the meantime, you can add
maxprefetch='1' to the broker connection string.
Cheers,
Andrew
On 16 Feb 2009, at 10:19, Stephen wrote:
Hi all
I suspect C++ broker does
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
ou to doc
and code for that integration, either to use, hack, or to copy :-)
Carl.
Andrew Wright wrote:
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. Th
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
leave, so can take over the processing of a given topic if
the primary processor goes away.
As you say, Coherence has this sort of thing built in. Unfortunately
it also comes with a fairly hefty Oracle price tag...
Andrew
On 30 Jan 2009, at 23:14, Robert Greig wrote:
2009/1/30 Andrew W
Cheers,
Andrew
On 30 Jan 2009, at 21:14, Robert Greig wrote:
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 durabl
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
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 g
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 inter
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
20 matches
Mail list logo
