It rules out using EFS for your locker implementation, but as Justin said,
pluggable lockers would allow you to put your data into an EFS but use
another mechanism for locking to determine ownership. But obviously there
would need to be a fix to the code that figures out whether there's enough
Crishel,
Are you using durable subscriptions on your topics? If not, that's why
it's not behaving the way you expect. Topic semantics say that messages
for a given non-durable subscriber can be discarded whenever that
subscriber disconnects, and a failover event involves a disconnection of
all
The issue is perhaps that EFS supports NFS4 but with the following
limitations:
http://docs.aws.amazon.com/efs/latest/ug/nfs4-unsupported-features.html
In particular: "All locks in Amazon EFS are advisory, which means that READ
and WRITE operations do not check for conflicting locks before the
Be careful of this, in my own load testing the lock state can be lost over EFS
leading to a “master-master” scenario under heavy load, which can lead to
journal corruption. Check out the lease locking pluggable storage locker,
which is a viable workaround for this problem.
Thanks,
Justin
I think all EFS volumes are that size. It's a play-by-usage model - it did
strike me as risky, a runaway process could cost you a lot of money!
On 2 Sep 2016 4:19 p.m., "Tim Bain" wrote:
Was your EFS as large as the one the OP described? The perceived problem
was that
Thanks both.
I may have time over the weekend to convert the various bits I've got into a
self-contained test case in a public github repo.
-Original Message-
From: John D. Ament [mailto:johndam...@apache.org]
Sent: 02 September 2016 17:52
To: users@activemq.apache.org
Subject: Re:
Cool, thanks. I won't be able to recreate a test today. But I have a
suspicion that the message length is being lost. Will follow up.
And like Justin, I would expect this to work as well.
John
On Fri, Sep 2, 2016 at 12:48 PM Andy Redhead
wrote:
> Hmm,
Hmm, something is eating my attachments, both classes inline below:
NativeProcessMsgReader>
package com...c2java;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
> I’m still curious to know if it’s reasonable to expect using an AMQP producer
> and an Artemis Core consumer to work?
I would expect this use-case to work.
> I could have sworn I attached the code in my original email - trying again...
I don't think email attachments get distributed to all
Hi,
Sorry, I could have sworn I attached the code in my original email - trying
again...
Cheers, Andy
-Original Message-
From: John D. Ament [mailto:johndam...@apache.org]
Sent: 02 September 2016 17:42
To: users@activemq.apache.org
Subject: Re: Artemis Core consumer hangs when reading
OK, persistent messages to a queue I expect to always be redelivered after
a missing acknowledgement on a dropped connection.
If a repeatable missing message redelivery in this case can be
demonstrated, I would be interested to look at the code.
As mentioned above, timing comes into play, and it
Andy,
Are you able to provide your client code? NativeProcessMsgReader isn't
Artemis's so its not clear what else you're doing to connect, subscribe,
etc.
John
On Fri, Sep 2, 2016 at 12:38 PM Andy Redhead
wrote:
> Hi,
>
>
>
> Adding to the information below, if
Hi,
Adding to the information below, if I change the junit test case that tries
sending a message through artemis into "NativeProcessMsgReader" to use AMQP
(rather than the core api), I get the stack trace:
Exception in thread "Thread-1" java.lang.IndexOutOfBoundsException:
readerIndex(25) +
Yes they are to a queue.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/kill-9-in-message-listener-tp4714620p4716116.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Actually the subscription recovery policy does not work for my case,
because it only allows to send to the new client a message previously sent
to the topic, not a different one.
2016-09-02 15:20 GMT+02:00 Matt Pavlovich :
> +1 the subscription recovery policy should do it.
Hi,We are using Active MQ for queue purpose. We have just 1 consumer. There
are some case, it does not get all messages from ActiveMQ. If producer
produces messages in Queue in the same rate , consumer consumers --> in that
caes, Consumer gets all messages. But if producer produces messages too
Tim,
I contacted AWS tech support and their response was this:
"I've checked with our EFS team to see if there is any EFS-related
workaround they can offer. Unfortunately, they have confirmed that this is
EFS intended behavior and there is no way of mounting a filesystem with
"predetermined
Was your EFS as large as the one the OP described? The perceived problem
was that the code couldn't handle a volume that size, not that it couldn't
handle an EFS volume.
On Sep 2, 2016 5:17 AM, "Korny Sietsma" wrote:
> Interesting - we set up ActiveMQ 5.9 successfully on
Hi,
We are using Active MQ for queue purpose. We have just 1 consumer. There are
some case, it does not get all messages from ActiveMQ.
If producer produces messages in Queue in the same rate , consumer consumers
--> in that caes, Consumer gets all messages.
But if producer produces messages
I'm not sure I understand your question. We have the simplest (and I thought
the only) case here, one broker and two clients. One of the clients is a
message producer the other a message consumer.
To reiterate from my original post, the message broker is ActiveMQ v5.5.1. The
clients were a
The broker and client negotiate the version of the OpenWire protocol when
the client connects. If the client sends a version of an ack that the
broker doesn't support, something is really wrong.
Are all the brokers running the same version of ActiveMQ?
On Thu, Sep 1, 2016 at 12:52 PM,
+1 the subscription recovery policy should do it. Might makes sense to
separate the destinations as well.. one for boot strap and another for
updates.
On 9/1/16 2:19 PM, Julien Nicoulaud wrote:
I realize using retroactive consumers with a
custom SubscriptionRecoveryPolicy might be just what
Interesting - we set up ActiveMQ 5.9 successfully on EFS, I'm guessing
these error messages relate to checks made in later versions of the product.
Note that we gave up on this approach - we found that shared filesystem
master/slave had several problems for us when we tested it with network lag
I read through all release notes 5.13.x and 5.14.0 and cannot find a KahaDb
incompatibility issue.
This is quite an unexpected blocker for anyone trying to upgrade to 5.14.0.
Will try temporarily setting ignoreMissingJournalfiles=true and see it if
comes up, then later try changing it back.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/KahaDb-issue-Detected-missing-journal-files-when-upgrading-from-5-12-2-to-5-14-0-tp4716052p4716099.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
you can do that by different ways
if your messages are non persistent this can be done by subscribing to the
topic "ActiveMQ.Advisory.NoConsumer.Queue"
or if persistent by subscribing to topic
"ActiveMQ.Advisory.MessageDelivered.Queue"
or "ActiveMQ.Advisory.MessageConsumed.Queue" to be notified if
26 matches
Mail list logo