Re: Artemis rejects the clientid after client disconnection

I'm wondering if it's related to this tkt: https://issues.apache.org/jira/browse/ARTEMIS-1078 I know actually it should had been fixed with version 2.1.0 (that it's the version I'm using), but anyway it seems very similar. Francesco -- View this message in context: http://activemq.2283324.n4.n

Re: Artemis rejects the clientid after client disconnection

Hi Michael, I can confirm that the thread is scheduled, because I see the log "connection id 1643635981 calling fail executor thread". Then I see "RemotingServiceImpl::removing connection ID 1643635981". And then nothing more: no trace. Like if the thread never takes in charge the effective exe

Re: Artemis rejects the clientid after client disconnection

An update. We have re-build "artemis-commons-2.1.0.jar", "artemis-mqtt-protocol-2.1.0.jar" and "artemis-server-2.1.0.jar" in order to improve the logs. It seems that there is a problem with the thread which has in charge the activities to free the clientid, send lwt message, etc.. For a few time al

Re: Artemis rejects the clientid after client disconnection

Just to give you all possible information: when the client goes down (as I wrote above: not gracefully) Artemis does NOT send any lwt message. Actuallly the client, on connection, indicates an lwt topic and message. And in case of gracefully disconnection Artemis sends it... In this case, instead,

Re: Artemis rejects the clientid after client disconnection

Hi Martyn, thanks so much for your answer. I'm using the official version 2.1.0, downloaded from the website (https://www.apache.org/dyn/closer.cgi?filename=activemq/activemq-artemis/2.1.0/apache-artemis-2.1.0-bin.zip&action=download). As soon as I'm able to reproduce it in a systematic way, I'll l

Artemis rejects the clientid after client disconnection

Hi, we're facing another issue with Artemis. Often it happens that after a client disconnects not gracefully (could be for many reasons: energy loss, network loss, etc.), Artemis doesn't accept anymore a connection with the same client id. This results, of course, in a situation where the client ca

Re: ARTEMIS - java.lang.NullPointerException switching subscription with #

Attached you can find a junit to replicate the issue. Cheers. Francesco PahoMQTTWildcardTest.java -- View this message in context: http://activemq.2283324.n4.nabble.com/ARTEMIS-java-lang-NullPointerException-sw

Re: ARTEMIS - java.lang.NullPointerException switching subscription with #

Hi, just an update. We found out that there was a client subscribed to the incriminated topic with a double wildcard char: "/prj/plantid/+/gwid/+/connection_state". So, there is a step 0 to add to the ones in my previous post: "0) connect a client and subscribe the topic /prj/plantid/+/gwid/+/conne

ARTEMIS - java.lang.NullPointerException switching subscription with #

Hi, I'm facing an issue when switching a topic subscription from the full path to the "wildcard char" one (with '#') and viceversa. I'm using the last 2.1.0 version (downloaded from activemq.apache.org). Here my test: 1) connect to Artemis 2) subscribe a topic by using full path, eg. "/prj/plantid

Re: Apache Artemis - Stress-test time

Hi Justin, you're right. We will investigate more closely our login module (redis itself doesn't seem to be a bottleneck ...but of course it could be the constantly querying of it). And we'll also try to perform a stress test session with security disabled. Just for completeness, following is a st

Re: Apache Artemis - Stress-test time

Hi Clebert, my logging is at the DEBUG level. Inside the artemis.log file, I see calls to the LoginModule methods when client connects, subscribes and unsubscribes. Following the thread trace when it happens during subscription: "Thread-1 (activemq-netty-threads-1239132915)" #47 daemon prio=5 os_p

Re: Apache Artemis - Stress-test time

Hi Justin, just an info: by analyzing the log file, it seems that Artemis makes calls to the login methods (initialize, login and commit, defined in the native interface of Artemis LoginModule), not only at the login, but also during subscribtion and unsubscription phases. We saw this with a clean

Re: Apache Artemis - Stress-test time

Hi Justin, we've tried by turning off tls. It doesn't change: cpu usage remain very high. We've tried also by disabling persistence. It changes a bit: at the beginning of the connection phase, cpu goes to 50% ...then it increases time by time til it reaches 100% when there are about 1000 connected

Re: Apache Artemis - Stress-test time

Hi Justin, unfortunately tls is mandatory for our use case :-( I can make a stress test session without it, but it wouldn't be so significative for the real case. Anyway, as you suggest, I'll try it just to see the difference in term of performances. Thanks -- View this message in context: htt

Re: Apache Artemis - Stress-test time

Hi Martyn, after a while of stress-test sessions with the new 2.1.0-SNAPSHOT of Artemis, I'm fairly confident to say that ram consumption now seems ok. Currently, instead, we're facing some problems with cpu usage during clients connections. Our stress test program, at the beginning, initializes 15

Re: Apache Artemis - Stress-test time

Hi Martyn, you are a kind of super hero to us! I'm going to build your fix and try it with our stress tests. I'll give you a feedback. Thanks a lot as usual! Francesco -- View this message in context: http://activemq.2283324.n4.nabble.com/Apache-Artemis-Stress-test-time-tp4723999p4724064.htm

Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage

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

Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage

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

Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage

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

Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage

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

Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage

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

Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage

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

Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage

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