We're sending non-persistent messages to a topic where some consumers may
sometimes be slow. We've configured a slowConsumerStrategy of
AbortSlowConsumerStrategy to disconnect any consumers that happen to be
slow. The detection of a slow consumer relies on there being at least 2x
the consumer's
Were those the actual commands you used? All of them have the typo
transactonID instead of transactionID.
I can't say that this approach would work with the typo corrected, but it's
certainly not going to work with the typo. I've never used the
command-line browser, so if it's not the right
I'm doing performance characterization of ActiveMQ when a network of
brokers runs across a high-latency (100ms range) WAN. When my producer on
one side of the WAN sends faster than our meager allocation of the WAN's
bandwidth, I quickly see all messages fail to be delivered to the end
consumer.
solely on whether messages were timing out before they were processed
by the consumer, and instead people would probably want a hybrid approach).
Tim
On Wed, Sep 10, 2014 at 3:25 PM, Tim Bain tb...@alumni.duke.edu wrote:
We're sending non-persistent messages to a topic where some consumers may
The standard answer to this is that you're failing to close connections to
the broker, so you eventually run out. We're not going to be able to track
down why that's happening since it's your code, but you should be able to
figure it out with the help of a debugger.
On Wed, Sep 17, 2014 at 1:06
Hopefully you saw that the mailing list thread you referenced was from nine
years ago. You might want to consult more current information, such as
http://activemq.apache.org/persistence.html and
http://activemq.apache.org/jdbc-master-slave.html.
I've not used JDBC persistence in years, but my
I'm using an AbortSlowConsumerStrategy with AMQ 5.8.0, with a single
producer (P) and a single intentionally-slow consumer (C), and two brokers
(B1 and B2) between them. C connects to B2 using the failover transport
(but only one broker, B2, in Cluster 2 at the moment), so it will attempt
to
You could start by doing code inspection and looking to see if there is any
code path where you could fail to close a connection once you open it,
which wouldn't require access to the customer environment.
Was there anything unusual in the logs around the time the errors were seen?
Finally, your
Is there any consistency in which sensor brokers succeed and which fail, or
is it random every time?
If you're able to download the source code for your version of ActiveMQ and
attach a debugger to one of your sensor brokers, you could set breakpoints
and watch the subscription request from
Use JConsole to look at which consumers are connected (make sure at least
one is!), how many messages they're currently working on
(MessageCountAwaitingAcknowlegement), and whether the numbers appear to be
increasing. For each queue, confirm whether the EnqueueCount is
increasing; if it's not,
https://issues.apache.org/jira/browse/AMQ-5253
Resolved in 5.11.0, not back-ported to any earlier version, so you'll just
need to wait.
On Fri, Sep 19, 2014 at 6:29 PM, Kevin Burton bur...@spinn3r.com wrote:
Ouch.. this is middy annoying. This should be considered a typo right?
not an
The fact that you create a new ActiveMQ connection for each message seems
like the probable cause for the error you saw. If you had a surge of N
messages to process all at once, you'd have N connections open (I'm
assuming you're processing your messages asynchronously), so if N was large
enough,
I can't answer your question about TransportListeners, I'm using Camel and
the AbortSlowConsumerStrategy, and when it aborts a slow consumer, I get
the following two lines in that consumer's log file:
WARN 2014-Sep-24 00:02:09.082 [Camel (camel-1) thread #0 -
JmsConsumer[Foo]]
Gary, Torsten, and others have said in various places that broker-to-broker
networkConnectors should set maxReconnectAttempts=0 to allow reconnection
to be handled by the network bridge. (Sources: 1
http://tmielke.blogspot.com/2011/09/activemq-network-bridge-to-masterslave.html,
2
You're right that the units for that parameter are milliseconds.
But I think you've misunderstood what it does; that setting specifies how
often the broker should look for messages whose expiration date has
arrived, and process them (e.g. by moving them to the DLQ), but the
messages have to have
The default value, the meaning of 0, and the units for that field are
documented at http://activemq.apache.org/per-destination-policies.html
along with all the other options for policies.
In my experience, clients that are delivered an expired message will not
process it. For the scenario you
/SimpleDiscoveryAgent.java#L42
The network bridge is a discovery listener, it gets told to add/remove
services (urls) that are discovered/retried.
On 24 September 2014 20:20, Tim Bain tb...@alumni.duke.edu wrote:
Gary, Torsten, and others have said in various places that
broker-to-broker
: transport is to hide those.
On 25 September 2014 19:37, Tim Bain tb...@alumni.duke.edu wrote:
Based on the comments that you and Torsten made in the links from my
first
message, I had understood that for networkConnectors between brokers, you
should not allow the discovery transport
I've submitted https://issues.apache.org/jira/browse/AMQ-5370 for this
feature request.
On Mon, Sep 15, 2014 at 11:16 AM, Tim Bain tb...@alumni.duke.edu wrote:
I'm doing performance characterization of ActiveMQ when a network of
brokers runs across a high-latency (100ms range) WAN. When my
Was your connection via Jmxterm using the hostname, or localhost?
Is that machine able to do a DNS resolve of its own hostname? And can you
try specifying the IP instead of the hostname in the config and in the
connection info from JConsole?
On Fri, Sep 26, 2014 at 9:46 AM, James Green
Sounds good; thanks for the explanation.
On Mon, Sep 29, 2014 at 4:17 AM, Gary Tully gary.tu...@gmail.com wrote:
everything is possible! but they evolved independently, hence the overlap
in functionality
On 26 September 2014 16:02, Tim Bain tb...@alumni.duke.edu wrote:
Would
It looks like you're failing to get an HTTP connection in one of your
routes. Four of the six endpoints you listed use HTTP; have you been able
to figure out which of them is the one you're failing on, and whether
there's anything unusual about hitting that endpoint? When this fails, are
you
It seems like you're having similar problems to the ones ahsanali is
having, so the questions I just asked him apply to you as well. Since you
haven't shared much info about your configuration, it's harder to suggest
where to look, but hopefully you can look through your endpoints and figure
out
Have you tried attaching a debugger to the broker and setting a conditional
breakpoint (with the condition that the header in question is null) to see
better what's going on? I've had pretty good luck figuring out what
ActiveMQ is doing using that approach, so it might help you figure out why
Are you saying that the manual solution (a configurable threshold on a
broker's network connection to another broker) doesn't sound reasonable, or
just that the automatic solution (where the broker would measure end-to-end
latency all the way to the consumer) doesn't? I agree that the automatic
I'm confused by what you're asking, so let me try to explain what I would
expect, and see if that answers your questions.
You will have producers, which all connect to a broker (call it BP). That
broker will have networkConnectors to the broker for Version1 consumers
(BV1) and the broker for
Are the numbers in the Enqueued column increasing, or just non-zero? If
it's not increasing, could you have stranded messages on secondary when you
took primary down (and everyone failed over to backup) and then consumers
eventually migrated back to primary? (See the Stuck Messages section of
JConsole has an MBeans tab for viewing the JMX beans for the app it
attaches to, and you can drill down to the topic and then see what
consumers are attached to it. You might take a look there to see if there
are any consumers attached that you're not aware of, or any durable
subscriptions for
Yes, the web console will show you those things. But it won't show you the
things I mentioned, such as which consumers are subscribed to a topic, or
the list of not just which clients are currently connected but also some
(all?) of the clients that have previously connected, which is why I
The TimeStampPlugin (http://activemq.apache.org/timestampplugin.html) will
allow broker clocks to override the JMS timestamp on the message, ignoring
faulty client clock; is that what you're looking for?
Note that timeToLive in ActiveMQ generally refers to the number of
brokers a message is
I just read your other message where you indicate you're already aware of
the TimeStampPlugin, so disregard that suggestion.
On Fri, Oct 3, 2014 at 12:44 PM, Tim Bain tb...@alumni.duke.edu wrote:
The TimeStampPlugin (http://activemq.apache.org/timestampplugin.html)
will allow broker clocks
Why are consumers in other timezones a concern? The expiration timestamp
is measured in milliseconds UTC, so the same instant in time will have the
same value in all timezones. As long as all clocks are relatively close to
being in sync, it shouldn't matter what timezone anyone's located in...
Destinations will only be propagated to other brokers when there is a
consumer for the destination. If no consumers are connected, messages will
accumulate on the producer's broker but go no further, because there is no
indication of where they need to go since there are no consumers.
On Fri,
Do you already have another process listening on port 1099?
On Thu, Oct 2, 2014 at 12:17 AM, Avinash avinash.n.yadag...@gmail.com
wrote:
Hi,
Please don't consider this as duplicate question. I searched regarding this
issue on Internet and could not find a proper answer. Hence posting it
You need to set the connectorPort property on the ManagementContext to the
port number you want to use, as described in
http://activemq.apache.org/jmx.html. It doesn't go in the URI that the
clients use to connect to the broker; that's a different port entirely.
On Mon, Oct 6, 2014 at 1:12 AM,
In addition to using timeouts, you can also configure the broker to discard
messages when more than a certain number are pending, to avoid blocking
producers; see http://activemq.apache.org/slow-consumer-handling.html for
more details.
On Thu, Oct 9, 2014 at 2:59 AM, Andreas Gies
The failover transport's behavior is connect to any one of the URIs in
this set; if that connection dies, try connecting again to any URI in the
set. By default, the failover transport will log if it is unable to get a
connection to any of the URIs, and then wait for a while and try again.
When
An application will exit when no more non-daemon threads exist. I don't
know whether the failover thread is a daemon or non-daemon thread, but you
could attach a debugger to your producer and connect to the iterate()
method of the Task created in
One option that's definitely open to you is to do what anyone can do when
an open-source project doesn't support a feature they need: implement it
yourself and contribute the code to the project so everyone benefits from
it like you've benefited from the work others have already done.
On Tue, Oct
What are you using to figure out that consumers are duplicated? I've seen
misleading information in the clientConnectors section of the JMX displays
(accessed from JConsole) under ActiveMQ 5.8.0 that sometimes looks like
there are more consumers connected than there really are, because it
appears
In your broker-to-broker networkConnectors, are you using maxReconnects=0
as an argument to the failover URI? It wouldn't explain why amq4 got
demoted, but it could explain why messages aren't transferring to amq5
instead.
You say you've got duplex connections between the clusters; which cluster
2. I believe (but haven't done it) that Individual will let you
acknowledge some messages (e.g. 1 and 3 but not yet 2), whereas Client
doesn't allow any gaps. Both of those allow you to ack the message at any
point during your handling of it (when you first receive it, when you're
completely
Has your broker been set up to be persistent, with a persistence store
configured? And are your messages flagged as persistent?
Also, how are you determining that the queues aren't persistent? What's
your test for that?
On Thu, Oct 16, 2014 at 9:36 AM, Kitewheel dtarsit...@kitewheel.com wrote:
masterslave: is an alias for failover: with maxReconnects=0. (There might
be another URI option included in the alias, I don't remember; I think the
details are in the JIRA where Gary added the failover transport, if you're
curious.) So there's no need to try using failover explicitly, since the
2. That plugin will cause messages to be discarded immediately instead of
going to the DLQ. There's 5-day timeout like you're looking for, they just
go straight into the bit bucket.
On Fri, Oct 17, 2014 at 11:17 AM, gchakra gopal.chakravar...@fox.com
wrote:
1.For the dead letter queue
Those plugin modifications will get the message into the DLQ with an
expiration date, but is there anything that will cause messages in the DLQ
to be deleted when they expire? Or will Gopal also need to implement
something to do that?
On Fri, Oct 17, 2014 at 2:28 PM, Gary Tully
If you have a network of brokers, messages on topics will be forwarded to
whichever broker the consumer connects to, without duplicate delivery of
any messages so long as no messages were processed by the consumer without
being ack'ed. If you were using queues, there's the potential for messages
. controlled by destination
policy expireMessagesPeriod 0
On 17 October 2014 22:12, Tim Bain tb...@alumni.duke.edu wrote:
Those plugin modifications will get the message into the DLQ with an
expiration date, but is there anything that will cause messages in the
DLQ
to be deleted when
Take a look at whether the JVM is doing a full garbage collect at the time
when the failover occurs. Our team has observed clients to failover to an
alternate broker at a time that corresponded to a full GC, and it might be
that the same thing is happening here (but the failover isn't happening
This sounds like application logic to me. It's the broker's job to try to
prevent re-delivery of the same message, but it's not the broker's job to
identify that two messages have similar content. That's the job of the
consumer of your messages, using whatever heuristics are most appropriate
to
G1GC is great for reducing the duration of any single stop-the-world GC
(and hence minimizing latency of any individual operation as well as
avoiding timeouts), but the total time spent performing GCs (and hence the
total amount of time the brokers are paused) is several times that of the
parallel
This sounds like it could be https://issues.apache.org/jira/browse/AMQ-4595,
which was fixed in 5.9.0 (which uses the new HawtIO web console)...
On Wed, Oct 22, 2014 at 6:36 AM, sharma_arun_se arun.kaun...@gmail.com
wrote:
We are using 1.6.0_24 , 64 bit jdk
--
View this message in context:
I just came across https://issues.apache.org/jira/browse/AMQ-3080, which
describes a situation that might or might not be the same one you're
seeing. Is your topic created statically at broker startup or dynamically
on first use? If the latter, then maybe you're seeing the same thing
that's
in AMQ-5411 isn't an
option in the near term.
Tim
On Mon, Sep 29, 2014 at 9:51 AM, Tim Bain tb...@alumni.duke.edu wrote:
Sounds good; thanks for the explanation.
On Mon, Sep 29, 2014 at 4:17 AM, Gary Tully gary.tu...@gmail.com wrote:
everything is possible! but they evolved independently, hence
1. In my limited experience with slow consumer abort strategies (using the
SlowConsumerAbortStrategy, not the SlowAckConsumerAbortStrategy), I've
observed that a client will continue processing the current message even
when aborted; the abort seems to allow the broker to get on with its life
but
I'm not clear on what behavior you're seeing, because the descriptions you
give (as I understand them) seem contradictory. You say that the consumer
won't abort, but that you've got a 30-minute client-side abort timeout.
You say that after the intended abort, you know it didn't work because the
One thing that might be a concern for you is the possibility of a message
on broker A going to B because B has a connection to C, but that connection
is dropped before B can forward the message to C. If I has another route
to C (e.g. through D) but B doesn't have any other route there, then the
want with two network connectors. one
to the primary and one to the backup. When both are alive and you use
decreaseNetworkConsumerPriority and priority dispatch, messages should take
the shortest path (priority decreases with number of hops).
On 24 October 2014 21:14, Tim Bain tb
Well, you could get rid of those messages by choosing not to delete
inactive destinations (documentation:
http://activemq.apache.org/delete-inactive-destinations.html).
Or you could tune Log4J to only show WARN level messages for that Logger
On Thu, Oct 30, 2014 at 10:01 AM, Lodgen, Brad
for that, but I'm trying to get rid of the messages by fixing the
issue of the messages going outstanding, not changing the logging levels or
turning off the feature. :)
Anyone have a troubleshooting path or tuning recommendation, by chance?
Tim Bain tb...@alumni.duke.edu wrote:
Well, you could
of G1 is several times that of
the parallel GC, if you're more interested in avoiding occasional lengthy
pauses due to full GCs than in getting the highest possible throughput from
your broker.
On Tue, Oct 21, 2014 at 10:13 AM, Tim Bain tb...@alumni.duke.edu wrote:
G1GC is great for reducing
Marek,
Thanks for the explanation; that helped me to separate the different things
you're seeing.
On Fri, Oct 31, 2014 at 5:21 AM, Marek Dominiak isdomi...@gmail.com wrote:
tbain98 wrote
I'm not clear on what behavior you're seeing, because the descriptions
you
give (as I understand them)
Most developers I know would define crash to be the process
terminated. Since that doesn't seem to be the case here (and since you
applied the term to an instance of Producer Flow Control in a previous
situation, which is most definitely not an ActiveMQ crash nor an ActiveMQ
error of any sort), I
I second Kevin's suggestion; redelivered messages with CLIENT_ACKNOWLEDGE
could certainly be a bug somewhere in ActiveMQ, but it could very easily be
a case where your application logic is failing to acknowledge those
messages properly, such that the broker believes it needs to re-deliver
them
Seems reasonable. If you want the earliest duplicate message to win
instead of the latest one, you can store a processed flag in the database
instead of storing a nonce, but otherwise it sounds fine.
On Mon, Nov 3, 2014 at 10:46 AM, Kevin Burton bur...@spinn3r.com wrote:
I have a database with
.
*
* According to Tim Bain on Oct., 20th 2014 this indicates a bug rather
than a missing feature in ActiveMQ
* and this Spec shall pinpoint the behavior.
* *
* The test is based on ActiveMQ 5.10
*
* Observations:
* -
* Depending on when the durable subscriber is known
Can you use Camel to pull the messages, and insert a processor in your A
route that will just count how many A messages you've gotten, and when
(count % 100) == 0 you can create a message for your B route to tell it to
do the clean-up processing? That would all be pretty simple to do in Camel.
Have you tried shortening the WireFormat's maxInactivityDuration URI option
described at http://activemq.apache.org/configuring-wire-formats.html?
On Thu, Oct 30, 2014 at 9:08 PM, jonb jburf...@solekai.com wrote:
I have a network of several brokers where a couple nodes are producers to
one
working fine.
On Tue, Nov 4, 2014 at 12:00 AM, Tim Bain tb...@alumni.duke.edu wrote:
Most developers I know would define crash to be the process
terminated. Since that doesn't seem to be the case here (and since you
applied the term to an instance of Producer Flow Control in a previous
kind of synchronize the
consumption of messages of a DS within a NWOB.
However, before going that path I wanted to make sure that I am not
missing something obvious.
Thanks for the answers so far and best regards
Andreas
On 03/11/14 20:23, Tim Bain wrote:
Andreas,
Your spec added two
I don't know if there's a way to do this without changing the broker config
(I doubt it, but I don't have any direct knowledge either way), but it
seems like a simple enough change to the broker config. Other than the
need for a broker restart, is there a reason not to just do that?
Anuj,
You should probably post questions that are purely about LevelDB to the
LevelDB mailing list. If you're confused about how ActiveMQ uses LevelDB,
then this list could be a good source of information, but most of the
questions you've asked about LevelDB recently are about its inner workings
I said that those options are related to LevelDB and not ActiveMQ because,
very simply, they're features of LevelDB; for example, you can see both
variables in the LevelDB API at
https://github.com/dain/leveldb/blob/master/leveldb-api/src/main/java/org/iq80/leveldb/Options.java,
which was the
Yes, you can have a pair of brokers that are both active at the same time
and that both have their own independent message store (not master/slave
with a shared message store). You'll need to configure the brokers so they
can talk to either other (either a duplex networkConnector from one to the
What you're describing sounds like what I warned about in my last
paragraph: messages are getting routed to broker1 while the consumer is
offline, which means they exist in broker1's message store and not anywhere
else in the network of brokers. When broker1 goes offline, those messages
don't
As far as I know, this behavior would happen with simple topics and simple
queues just as much as with virtual topics; this is a result of ActiveMQ's
fundamental architecture, not something specific to virtual topics. The
architecture of ActiveMQ ensures that any broker only knows about its own
As I understand it, the text you quoted only applies if
replayWhenNoConsumers=false. With replayWhenNoConsumers=true (as you have
it), you should get all messages delivered from all brokers that are up,
but you still won't get messages from brokers that are down until they come
back up. So I
I apologize, it sounds like I steered you astray on that particular
question. Hopefully either someone on the mailing list like Hiram will be
able to answer your question, or you'll learn the answer as you look
through the source and post the answer back here for the next person who
has the
There's a Java JMX API if you'd rather use that instead of a RESTful
interface. I'm not sure if there's anything similar for Perl; like
Andreas, that's outside my area of expertise.
On Tue, Nov 11, 2014 at 4:21 AM, Andreas Gies andr...@wayofquality.de
wrote:
Hmmm,
I am not a Perl expert, but
One can not mix activemq versions is too broad of a statement. There
will be some pairs of versions you can mix, and others you can't. But one
can not mix *these particular* activemq versions is a perfectly accurate
statement.
When I've seen Tim and Gary and others talk about backwards
That's expected behavior. By default, brokers only forward messages when
there's a currently-connected consumer somewhere in the network. If
there's no consumer, the message will hang out on the producing broker,
waiting for the consumer to connect. When it does connect, the broker that
holds
You can specify that messages should be forwarded even if no consumer is
connected by using the staticallyIncludedDestinations element on the
networkConnector. See
Looking at the documentation for activemq-admin (
http://activemq.apache.org/activemq-command-line-tools-reference.html), I
don't see a way to get this information without using JMX, but maybe
someone knows of a way to do it.
If you can't find a way to do this via activemq-admin, you should be
Right, that's why I said that I'm not sure you'll be able to do this using
the activemq-admin console (though maybe someone else will know of a way),
and that I believe that it can be done using the Java JMX MBeans API plus
some custom Java code to group/count the results. But as I said, I've
Configure the broker to expose JMX status (
http://activemq.apache.org/jmx.html), if you haven't already done so. Then
make sure you understand what's in the JMX beans; an easy way to do that is
to attach JConsole to the broker and navigate through the MBeans tab. Once
you've done this, you
The priorityBackup=true URI option for the failover transport does exactly
what you want.
On Nov 16, 2014 4:39 PM, atomicx6637 tricha...@gmail.com wrote:
I have the following environment and would like some feedback on the
configuration I currently have.
I have 2 MuleESB (mulep01, mulep02)
So what do you want to happen when the Version2 consumer isn't connected?
Right now the Version2 messages stay available for the Version2 when it
reconnects; what do you want to happen instead?
On Mon, Nov 17, 2014 at 12:00 PM, juanmanuel.romeraferrio
juanmanuel.romerafer...@gmail.com wrote:
Sorry, which consumer is off and which is on? Your email said VERSION 2
for both, but I assume that's not what you meant.
On Nov 18, 2014 5:41 AM, juanmanuel.romeraferrio
juanmanuel.romerafer...@gmail.com wrote:
No, this is OK. The problems is that when the consumer VERSION 2 is off and
the
Also, which version of ActiveMQ are you using?
On Nov 18, 2014 5:41 AM, juanmanuel.romeraferrio
juanmanuel.romerafer...@gmail.com wrote:
No, this is OK. The problems is that when the consumer VERSION 2 is off and
the consumer VERSION 2 is on, and I send messages of the 2 VERSION the
messages
There's a workaround for 5.10 in the comments too, in case you didn't see
that.
On Tue, Nov 18, 2014 at 9:29 AM, guerra jg.gue...@gmail.com wrote:
Never mind. There is a issue already open against it. Fixed on 5.11
https://issues.apache.org/jira/browse/AMQ-5105
--
View this message in
It might be a problem with selectors, or with cursors, or maybe something
else.
What version of ActiveMQ are you using? I remember seeing JIRAs against
pre-5.8.0 versions about cursors that allowed messages to get stuck, so if
you're using an older version, you might just need to upgrade.
On
One problem we've run across while debugging ActiveMQ problems after the
fact (after the broker and clients have all been cycled) is that it's often
difficult to figure out which client was the one that corresponded to a
particular error in the broker's logs. The broker's log file will
generally
It sounds like it could be a bug, though it might not be. Assuming you can
reproduce this in a test environment, you should try attaching a debugger
to the broker, setting breakpoints, and stepping through the relevant
code. AbstractSubscription.matches() and Queue.doAcutalDispatch() seem
like
It looks like you're setting those URI options on the static transport
instead of the nested failover transport. Try moving your second closing
parenthesis to the end of the URI options.
On Mon, Nov 24, 2014 at 10:07 AM, Larry Davis lad...@yahoo.com.invalid
wrote:
Hi all,
I¹m trying to use
Gary Tully, does the first change Sergiy referenced (
http://mail-archives.apache.org/mod_mbox/activemq-commits/201403.mbox/%3c58f67097f342495e921e1a25e951a...@git.apache.org%3E)
really disable CLIENT_ACKNOWLEDGE from 5.10 onward, or is he
misunderstanding the change you made? If he's got it
As Art says, the advantages are minor, and the disadvantages (such as the
inability to detect disconnections due to network problems) are not. So
your default should be to use a non-zero value unless you come up with a
clear reason why you think a value of zero would be better for you, and
:47, Tim Bain tb...@alumni.duke.edu wrote:
Gary Tully, does the first change Sergiy referenced (
http://mail-archives.apache.org/mod_mbox/activemq-commits/201403.mbox/%3c58f67097f342495e921e1a25e951a...@git.apache.org%3E
)
really disable CLIENT_ACKNOWLEDGE from 5.10 onward, or is he
The log line tells you how you're doing against two different limits: the
per-destination limit and the entire-broker limit. The per-destination
limit is first, and the log line says you're using 0% of what you've
allocated per destination, so you're right that you're fine there. The
full-broker
Your dynamicallyIncludedDestinations doesn't appear to include any rule
that would result in messages and subscriptions on the temporary reply
queue being bridged between the brokers; it looks to me like you're only
bridging the request queue.
On Mon, Dec 8, 2014 at 3:56 PM, azdvorak
I'm not aware of one, though I've never actually used temp destinations so
someone else might know of something I don't know about.
If there's not, you might want to submit a JIRA requesting that
ActiveMQDestination.TEMP_DESTINATION_NAME_PREFIX be made modifiable so you
can prefix all temp
1 - 100 of 2242 matches
Mail list logo
