Francesco,
Do you have any logs I could look at? Do you hang out on IRC we could have
a quick chat in #apache-activemq what is your IRC nick?
Cheers
On Mon, Feb 13, 2017 at 11:59 AM, Martyn Taylor wrote:
> Thank you for your patience. This is really great feedback. I'll have
> something for
Thank you for your patience. This is really great feedback. I'll have
something for you by the end of today.
Regards
Martyn
On Mon, Feb 13, 2017 at 11:53 AM, francesco81 wrote:
> Super,
> you'd be so kind (as usual)!
> I'll wait for a feedback on this new snapshot to test.
>
> Again: thanks f
Super,
you'd be so kind (as usual)!
I'll wait for a feedback on this new snapshot to test.
Again: thanks for your "huge" patience.
Francesco!
--
View this message in context:
http://activemq.2283324.n4.nabble.com/ARTEMIS-bad-performance-behaviour-after-7-10-days-of-usage-tp4721272p4721911.ht
Hi Francesco,
Thanks for the Thread dump. I think I know what the issue is, I'll get it
fixed today. This fix won't make the 1.5.3 release but I can provide you
with another snapshot with all the required fixes.
We can try to do another revision release soon after including this fix.
Cheers
Ma
Hi Martyn,
good Monday.
Unfortunately, I've an update about our tests on artemis snapshot 1.6 you g=
ave me last week.
It seems that after few time of use (sometimes an hour ...other times less)=
it stops to accept connections. Resources on server are totally ok: we hav=
e about 40/50 clients, ea
___
> From: Francesco PADOVANI
> Sent: Friday, February 10, 2017 2:58:19 PM
> To: users@activemq.apache.org
> Subject: Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage
>
>
> Hi Martyn,
>
> we're testing your 1.6.0 snapshot.
>
> The issues rela
: Francesco PADOVANI
Sent: Friday, February 10, 2017 2:58:19 PM
To: users@activemq.apache.org
Subject: Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage
Hi Martyn,
we're testing your 1.6.0 snapshot.
The issues related to retained messages ACK and durable queues seem ok now.
Grea
advance.
Francesco
From: Martyn Taylor
Sent: Thursday, February 9, 2017 5:36:19 PM
To: users@activemq.apache.org
Subject: Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage
On Thu, Feb 9, 2017 at 3:54 PM, Francesco PADOVANI <
francesco.padov...@bticino.
__
> From: Martyn Taylor
> Sent: Thursday, February 9, 2017 1:22:52 PM
> To: users@activemq.apache.org
> Subject: Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage
>
> Francesco,
>
> I think I've identified the cause of this probl
1:22:52 PM
To: users@activemq.apache.org
Subject: Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage
Francesco,
I think I've identified the cause of this problem. There were two issues
which are now fixed as part of:
https://github.com/apache/activemq-artemis/pull/1002
I
Francesco,
I think I've identified the cause of this problem. There were two issues
which are now fixed as part of:
https://github.com/apache/activemq-artemis/pull/1002
I'll get these fixes cherry-picked onto Artemis 1.x stream.
I plan on doing a 1.5.3 (with these changes included) within the n
Hi Martyn,
I'll be happy to enjoy the IRC chat as soon as I can.
Effectively, your words about the "treating as new subscription" would
explain the issue with retained messages.
However there's still something that I don't understand: for example why
also the non-retained messages are resent on res
Francesco,
Thanks for providing this information. I think there's a couple of things
going on and I'd like to work with you to create some reproducers, we could
have a chat IRC #apache-activ...@freenode.net and I'll see if I can
recreate your env / case in our test suite.
With the case above, th
Hi Clebert,
ok, we will build some junit tests to replicate the problem, follwing the
exemple section.
Meanwhile, I can confirm to you the bug(s): it seems that the reference to
the message is never removed from the queue. If the message is not retained
it persists 1 reference on the queue and ever
I actually thought about a self contained test, that we can use to
debug at our dev environment.
Putting something complex to be executed over the AWS wouldn't help
much. We would still need to figure out your whole app framework.
Why don't you use some of the examples infra-structure to create s
Ok, perfect.
I'd be very happy if Martyn could take a look on this.
Meanwile, I'll try to put in place a test environment on AWS, accessible to
everyone of the community ...this way I hope you'll be able to help me to
debug and solve the problem.
Thanks
Francesco
--
View this message in contex
The bug wouldn't be on the persistence layer itself. The MQTT protocol
manager is managing retainers by removing (acking) older messages. And
something is broken. I'm not sure if it's a general case or something
specifically to your use case. I was wondering if you could replicate
the issue on a si
Hi Clebert,
good to know it.
But, just to be clear, I have the same problem also with persistence enabled
(indeed, it's even worse).
Regardless of the persistence, the behavior is the same: after a certain
window of usage, ram fills and the broker starts to work constantly in
paging mode (cpu --> 1
apparently there's a bug MQTT retained queues. when you disabled
persistence on the broker we removed the capacity of validating or
debugging it.
On Mon, Jan 30, 2017 at 9:58 AM, francesco81
wrote:
> Hello,
> just an update about this topic.
>
> By disabling persistence, the broker starts again
Hello,
just an update about this topic.
By disabling persistence, the broker starts again to work fast and reliable.
But just for about 2 more weeks: then the memory come bake to be full and
the broker starts to page constantly, and cpu usage goes to 100%.
I tried to run the command "artemis data
A question. Are u consuming from the subscriptions or u intend to leave
them hinging?
While paging. Do u need transactions? If u start to page not using
transactions would make paging to act like partitions on Kafka.
I will be waiting for more data from you before we can help some more.
On
An easy way to check what is going on is with
Artemis data print
(Preferably with the broker stopped)
You can then check what is not being asked and why it became paging.
You could maybe replicate a similar load pattern on a test? Like sending
many messages a second instead of 2 per minute
22 matches
Mail list logo
