[jira] [Commented] (ARTEMIS-2709) Fix LiveToLiveFailoverTest::scaleDownDelay
[ https://issues.apache.org/jira/browse/ARTEMIS-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104692#comment-17104692 ] Atri Sharma commented on ARTEMIS-2709: -- [~clebertsuconic] I raised a PR, please see and share: [https://github.com/apache/activemq-artemis/pull/3127] > Fix LiveToLiveFailoverTest::scaleDownDelay > --- > > Key: ARTEMIS-2709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2709 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.12.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-2709) Fix LiveToLiveFailoverTest::scaleDownDelay
[ https://issues.apache.org/jira/browse/ARTEMIS-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104692#comment-17104692 ] Atri Sharma edited comment on ARTEMIS-2709 at 5/11/20, 5:20 PM: [~clebertsuconic] I raised a PR, please see and comment: [https://github.com/apache/activemq-artemis/pull/3127] was (Author: atris): [~clebertsuconic] I raised a PR, please see and share: [https://github.com/apache/activemq-artemis/pull/3127] > Fix LiveToLiveFailoverTest::scaleDownDelay > --- > > Key: ARTEMIS-2709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2709 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.12.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2709) Fix LiveToLiveFailoverTest::scaleDownDelay
[ https://issues.apache.org/jira/browse/ARTEMIS-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099119#comment-17099119 ] Atri Sharma commented on ARTEMIS-2709: -- I debugged it further and saw that the two servers set up (liveServer0 and liveServer1) are killed by different methods (the primary server is killed by crash() during scaleDownDelay and backup by tearDown method of FailoverTestBase class). I am surprised by the invocation of tearDown method before the completion of the test. Is this because of the asynchronous ordering of these tasks on an ExecutorService? > Fix LiveToLiveFailoverTest::scaleDownDelay > --- > > Key: ARTEMIS-2709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2709 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.12.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-2709) Fix LiveToLiveFailoverTest::scaleDownDelay
[ https://issues.apache.org/jira/browse/ARTEMIS-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099119#comment-17099119 ] Atri Sharma edited comment on ARTEMIS-2709 at 5/4/20, 4:52 PM: --- I debugged it further and saw that the two servers set up (liveServer0 and liveServer1) are killed by different methods (the primary server is killed by crash() during scaleDownDelay and backup by tearDown method of FailoverTestBase class). I am surprised by the invocation of tearDown method before the completion of the test. Is this because of the asynchronous ordering of these tasks on an ExecutorService? [~clebertsuconic] was (Author: atris): I debugged it further and saw that the two servers set up (liveServer0 and liveServer1) are killed by different methods (the primary server is killed by crash() during scaleDownDelay and backup by tearDown method of FailoverTestBase class). I am surprised by the invocation of tearDown method before the completion of the test. Is this because of the asynchronous ordering of these tasks on an ExecutorService? > Fix LiveToLiveFailoverTest::scaleDownDelay > --- > > Key: ARTEMIS-2709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2709 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.12.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2709) Fix LiveToLiveFailoverTest::scaleDownDelay
[
https://issues.apache.org/jira/browse/ARTEMIS-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098293#comment-17098293
]
Atri Sharma commented on ARTEMIS-2709:
--
Ok the issue is that the messages are not getting recovered due to
ScaleDownHandler not being able to create a new session (it gets rejected). The
reason is that the server is not started till that point.
{code:java}
[AMQ229000: Activation for server
ActiveMQServerImpl::serverUUID=1f03d0d7-8d13-11ea-8dae-f018980ae810]
13:26:02,298 ERROR [org.apache.activemq.artemis.core.server] AMQ224000: Failure
in initialisation:
ActiveMQSessionCreationException[errorType=SESSION_CREATION_REJECTED
message=AMQ229034: Server not started]
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:467)
[:]
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:361)
[:]
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:300)
[:]
at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:249)
[:]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionChannel(ClientSessionFactoryImpl.java:1349)
[:]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:674)
[:]
at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:299)
[:]
at
org.apache.activemq.artemis.core.server.impl.ScaleDownHandler.scaleDownMessages(ScaleDownHandler.java:112)
[:]
at
org.apache.activemq.artemis.core.server.impl.ScaleDownHandler.scaleDown(ScaleDownHandler.java:97)
[:]
at
org.apache.activemq.artemis.core.server.impl.BackupRecoveryJournalLoader.postLoad(BackupRecoveryJournalLoader.java:96)
[:]
at
org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadMessageJournal(AbstractJournalStorageManager.java:1214)
[:]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:3221)
[:]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2891)
[:]
at
org.apache.activemq.artemis.core.server.impl.SharedStoreBackupActivation.run(SharedStoreBackupActivation.java:90)
[:]
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:3873)
[:]
{code}
> Fix LiveToLiveFailoverTest::scaleDownDelay
> ---
>
> Key: ARTEMIS-2709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2709
> Project: ActiveMQ Artemis
> Issue Type: Task
>Reporter: Clebert Suconic
>Priority: Major
> Fix For: 2.12.0
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2709) Fix LiveToLiveFailoverTest::scaleDownDelay
[ https://issues.apache.org/jira/browse/ARTEMIS-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17092306#comment-17092306 ] Atri Sharma commented on ARTEMIS-2709: -- I am working on this — will take a bit of a time since I am learning the internals -- Regards, Atri *l'apprenant* > Fix LiveToLiveFailoverTest::scaleDownDelay > --- > > Key: ARTEMIS-2709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2709 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.12.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2709) Fix LiveToLiveFailoverTest::scaleDownDelay
[
https://issues.apache.org/jira/browse/ARTEMIS-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087351#comment-17087351
]
Atri Sharma commented on ARTEMIS-2709:
--
Some naive comments here:
What I see happening is that post the ingestion of a message (
{code:java}
ClientConsumerImpl::handleRegularMessage
{code}
), we queue a runnable which will invoke
{code:java}
ClientConsumerImpl::callOnMessage
{code}
which in turn will poll the message from the underlying priority queue buffer,
thus removing it from the buffer. Since every ingestion has a runnable queued,
that effectively means that all messages that are brought into the system are
polled from the buffer even before scaleDownDelay gets to call
recieveDurableMessages, which will seek for messages on the buffer. Hence,
receiveDurableMessages sees an empty buffer and the assertion for non null
messages fails.
What am I missing?
> Fix LiveToLiveFailoverTest::scaleDownDelay
> ---
>
> Key: ARTEMIS-2709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2709
> Project: ActiveMQ Artemis
> Issue Type: Task
>Reporter: Clebert Suconic
>Priority: Major
> Fix For: 2.12.0
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2709) Fix LiveToLiveFailoverTest::scaleDownDelay
[ https://issues.apache.org/jira/browse/ARTEMIS-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087353#comment-17087353 ] Atri Sharma commented on ARTEMIS-2709: -- [~clebertsuconic] ^^ > Fix LiveToLiveFailoverTest::scaleDownDelay > --- > > Key: ARTEMIS-2709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2709 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.12.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2688) FileStoreMonitor.calculateUsage Should Check for NaN
[ https://issues.apache.org/jira/browse/ARTEMIS-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17073782#comment-17073782 ] Atri Sharma commented on ARTEMIS-2688: -- This is not related to ARTEMIS-2636. FileStoreMonitor.calculateUsage does not check for its arguments, so it is possible to raise an ArithmeticException while using it simply by passing in a 0 for totalUsage parameter. > FileStoreMonitor.calculateUsage Should Check for NaN > > > Key: ARTEMIS-2688 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2688 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Atri Sharma >Priority: Major > > calculateUsage does a division today without checking for potential 0 values > -- this can lead to NaN issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2688) FileStoreMonitor.calculateUsage Should Check for NaN
Atri Sharma created ARTEMIS-2688: Summary: FileStoreMonitor.calculateUsage Should Check for NaN Key: ARTEMIS-2688 URL: https://issues.apache.org/jira/browse/ARTEMIS-2688 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Atri Sharma calculateUsage does a division today without checking for potential 0 values -- this can lead to NaN issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2636) Expose disk store used percentage metric
[ https://issues.apache.org/jira/browse/ARTEMIS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072937#comment-17072937 ] Atri Sharma commented on ARTEMIS-2636: -- Should we resolve this? > Expose disk store used percentage metric > > > Key: ARTEMIS-2636 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2636 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.11.0 >Reporter: Christoph Ewerlin >Priority: Major > Time Spent: 7h 10m > Remaining Estimate: 0h > > It would be very nice if the disk store used could be exposed via the metrics > registry (preferably) and/or JMX like address.memory.usage already already is. > In addition it would be nice to have percentage values for both > address_memory_usage and disk_store_usage which would make setting up alarms > much easier. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
