[jira] [Commented] (ARTEMIS-2097) Could it be possible to add a feature to block message producers?
[ https://issues.apache.org/jira/browse/ARTEMIS-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629708#comment-16629708 ] Howard Gao commented on ARTEMIS-2097: - [~clebertsuconic] I think this is useful. Wdyt? > Could it be possible to add a feature to block message producers? > - > > Key: ARTEMIS-2097 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2097 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 1.5.5 > Environment: AMQ-1.5.5 >Reporter: Tyronne Wickramarathne >Assignee: Howard Gao >Priority: Major > Fix For: unscheduled > > > Could it be possible to block all incoming messages without changing the > address-full-policy to 'BLOCK'? > The address full policy can be configured to block incoming messages should > the address full policy reaches the configured max-size-bytes attributes. > However, on certain circumstances it is important to make a JMS destination > drain without accepting incoming messages while keeping the > address-full-policy at 'PAGE'. For an instance, if a user needs to bring down > the broker for maintenance, it is important to allow the user to drain > existing messages in the corresponding destination without accepting any new > messages. > > Currently the pause() method on a destination pauses message consumers. In a > similar fashion could it be possible to add a new method to block message > producers on a given destination irrespective of the address-full-policy > being used? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ARTEMIS-2097) Could it be possible to add a feature to block message producers?
[ https://issues.apache.org/jira/browse/ARTEMIS-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard Gao reassigned ARTEMIS-2097: --- Assignee: Howard Gao > Could it be possible to add a feature to block message producers? > - > > Key: ARTEMIS-2097 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2097 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 1.5.5 > Environment: AMQ-1.5.5 >Reporter: Tyronne Wickramarathne >Assignee: Howard Gao >Priority: Major > Fix For: unscheduled > > > Could it be possible to block all incoming messages without changing the > address-full-policy to 'BLOCK'? > The address full policy can be configured to block incoming messages should > the address full policy reaches the configured max-size-bytes attributes. > However, on certain circumstances it is important to make a JMS destination > drain without accepting incoming messages while keeping the > address-full-policy at 'PAGE'. For an instance, if a user needs to bring down > the broker for maintenance, it is important to allow the user to drain > existing messages in the corresponding destination without accepting any new > messages. > > Currently the pause() method on a destination pauses message consumers. In a > similar fashion could it be possible to add a new method to block message > producers on a given destination irrespective of the address-full-policy > being used? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2099) Avoid possible double instantiation of properties
[ https://issues.apache.org/jira/browse/ARTEMIS-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629411#comment-16629411 ] ASF subversion and git services commented on ARTEMIS-2099: -- Commit fd303af827f9adbcec27a0f8a191525750e76335 in activemq-artemis's branch refs/heads/2.6.x from [~teaandcoffee] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=fd303af ] ARTEMIS-2099 Avoid possible double instantiation of properties (cherry picked from commit 8ab3be71a3ebc5667c402c2b6e6458cb73bce616) > Avoid possible double instantiation of properties > - > > Key: ARTEMIS-2099 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2099 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Priority: Major > Fix For: 2.7.0, 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-2099) Avoid possible double instantiation of properties
[ https://issues.apache.org/jira/browse/ARTEMIS-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-2099. - Resolution: Fixed Fix Version/s: 2.6.4 2.7.0 > Avoid possible double instantiation of properties > - > > Key: ARTEMIS-2099 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2099 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Priority: Major > Fix For: 2.7.0, 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2099) Avoid possible double instantiation of properties
[ https://issues.apache.org/jira/browse/ARTEMIS-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629409#comment-16629409 ] ASF subversion and git services commented on ARTEMIS-2099: -- Commit 8ab3be71a3ebc5667c402c2b6e6458cb73bce616 in activemq-artemis's branch refs/heads/master from [~teaandcoffee] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=8ab3be7 ] ARTEMIS-2099 Avoid possible double instantiation of properties > Avoid possible double instantiation of properties > - > > Key: ARTEMIS-2099 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2099 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1996) MappedSequentialFileFactory may cause DirectByteBuffer memory leaks
[
https://issues.apache.org/jira/browse/ARTEMIS-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629398#comment-16629398
]
ASF GitHub Bot commented on ARTEMIS-1996:
-
Github user franz1981 commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2250#discussion_r220720824
--- Diff:
artemis-journal/src/main/java/org/apache/activemq/artemis/core/journal/impl/JournalImpl.java
---
@@ -1796,15 +1826,15 @@ private synchronized JournalLoadInformation
load(final LoaderCallback loadManage
private void checkID(final long id) {
if (id > maxID.longValue()) {
- maxID.set(id);
+ maxID.lazySet(id);
--- End diff --
It's a fair concern, but If we are not single threaded here I'm quite sure
that both set/lazySet are wrong, given that none of them is addressing the
chance that others will do the same concurrently :)
But looking at the code maxID is being created and used with single
threaded semantic here, quoting the comments on the code:
`// AtomicLong is used only as a reference, not as an Atomic value
final AtomicLong maxID = new AtomicLong(-1);final AtomicLong
maxID = new AtomicLong(-1);`
> MappedSequentialFileFactory may cause DirectByteBuffer memory leaks
> ---
>
> Key: ARTEMIS-1996
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1996
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: tang pu
>Priority: Minor
>
> Because of some customization requirements, the readJournalFile method of
> JournalImpl needs to be calledmultiple times.
> During the stress test, it was found that almost every 5 hours, the Broker
> appeared a Full GC.
> This is the information about the Full GC in the GC log.
> {color:#FF}2018-07-25T12:14:07.323+0800: 10089.523: [Full GC
> (System.gc()) 6767M->253M(16G), 8.7138691 secs]{color}
> {color:#FF} [Eden: 632.0M(712.0M)->0.0B(816.0M) Survivors: 104.0M->0.0B
> Heap: 6767.6M(16.0G)->253.9M(16.0G)], [Metaspace:
> 36323K->35961K(1083392K)]{color}
> {color:#FF} [Times: user=2.56 sys=0.42, real=8.71 secs] {color}
> When the Full GC appears, the thread stack is as follows:
> {color:#FF}java.lang.System.gc(System.java:993){color}
> {color:#FF}java.nio.Bits.reserveMemory(Bits.java:666){color}
> {color:#FF}java.nio.DirectByteBuffer.(DirectByteBuffer.java:123){color}
> {color:#FF}java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311){color}
> {color:#FF}org.apache.activemq.artemis.core.io.mapped.MappedSequentialFileFactory.newBuffer(MappedSequentialFileFactory.java:109){color}
> {color:#FF}org.apache.activemq.artemis.core.journal.impl.JournalImpl.readJournalFile(JournalImpl.java:463){color}
> By analyzing the stack, it should be that the JVM's heap memory cannot be
> allocated, causing the JVM to call the System.gc() method.
> In the Broker, MappedSequentialFileFactory caches off-heap memory through
> ThreadLocal. Once the thread is evicted by the CompactExecutor(keepalive is
> 60s) in the Journal, the heap memory is "leaked".
> {color:#FF}NIOSequentialFileFactory{color} also has the same problem
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2099) Avoid possible double instantiation of properties
[ https://issues.apache.org/jira/browse/ARTEMIS-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629373#comment-16629373 ] ASF GitHub Bot commented on ARTEMIS-2099: - Github user jbertram commented on the issue: https://github.com/apache/activemq-artemis/pull/2335 I just created ARTEMIS-2099. I'll update the commit message to use this when I merge it. I'm just waiting for the PR build to finish. > Avoid possible double instantiation of properties > - > > Key: ARTEMIS-2099 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2099 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2099) Avoid possible double instantiation of properties
Justin Bertram created ARTEMIS-2099: --- Summary: Avoid possible double instantiation of properties Key: ARTEMIS-2099 URL: https://issues.apache.org/jira/browse/ARTEMIS-2099 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Justin Bertram -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2098) Potential NPE when decoding protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629327#comment-16629327
]
ASF GitHub Bot commented on ARTEMIS-2098:
-
Github user jbertram commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2334#discussion_r220700987
--- Diff:
artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/ProtocolHandler.java
---
@@ -196,6 +196,10 @@ protected void decode(ChannelHandlerContext ctx,
ByteBuf in, List out) t
}
ProtocolManager protocolManagerToUse =
protocolMap.get(protocolToUse);
+ if (protocolManagerToUse == null) {
+
ActiveMQServerLogger.LOGGER.failedToFindProtocolManager(ctx.channel().remoteAddress().toString(),
ctx.channel().localAddress().toString(), protocolToUse,
protocolMap.keySet().toString());
--- End diff --
I performed manual testing to confirm the logging works as expected, but
I'm not 100% sure these won't *ever* be null so checks are worth doing.
> Potential NPE when decoding protocol
>
>
> Key: ARTEMIS-2098
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2098
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.3
>Reporter: Justin Bertram
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1996) MappedSequentialFileFactory may cause DirectByteBuffer memory leaks
[
https://issues.apache.org/jira/browse/ARTEMIS-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629322#comment-16629322
]
ASF GitHub Bot commented on ARTEMIS-1996:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2250#discussion_r220699668
--- Diff:
artemis-journal/src/main/java/org/apache/activemq/artemis/core/journal/impl/JournalImpl.java
---
@@ -1796,15 +1826,15 @@ private synchronized JournalLoadInformation
load(final LoaderCallback loadManage
private void checkID(final long id) {
if (id > maxID.longValue()) {
- maxID.set(id);
+ maxID.lazySet(id);
--- End diff --
After just dealing with a bunch of concurrency issues (bit worried) how
sure is it we def have only single thread at this point with the callbacks,
e.g. how safe is it to switch these to lazySet from set?
> MappedSequentialFileFactory may cause DirectByteBuffer memory leaks
> ---
>
> Key: ARTEMIS-1996
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1996
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: tang pu
>Priority: Minor
>
> Because of some customization requirements, the readJournalFile method of
> JournalImpl needs to be calledmultiple times.
> During the stress test, it was found that almost every 5 hours, the Broker
> appeared a Full GC.
> This is the information about the Full GC in the GC log.
> {color:#FF}2018-07-25T12:14:07.323+0800: 10089.523: [Full GC
> (System.gc()) 6767M->253M(16G), 8.7138691 secs]{color}
> {color:#FF} [Eden: 632.0M(712.0M)->0.0B(816.0M) Survivors: 104.0M->0.0B
> Heap: 6767.6M(16.0G)->253.9M(16.0G)], [Metaspace:
> 36323K->35961K(1083392K)]{color}
> {color:#FF} [Times: user=2.56 sys=0.42, real=8.71 secs] {color}
> When the Full GC appears, the thread stack is as follows:
> {color:#FF}java.lang.System.gc(System.java:993){color}
> {color:#FF}java.nio.Bits.reserveMemory(Bits.java:666){color}
> {color:#FF}java.nio.DirectByteBuffer.(DirectByteBuffer.java:123){color}
> {color:#FF}java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311){color}
> {color:#FF}org.apache.activemq.artemis.core.io.mapped.MappedSequentialFileFactory.newBuffer(MappedSequentialFileFactory.java:109){color}
> {color:#FF}org.apache.activemq.artemis.core.journal.impl.JournalImpl.readJournalFile(JournalImpl.java:463){color}
> By analyzing the stack, it should be that the JVM's heap memory cannot be
> allocated, causing the JVM to call the System.gc() method.
> In the Broker, MappedSequentialFileFactory caches off-heap memory through
> ThreadLocal. Once the thread is evicted by the CompactExecutor(keepalive is
> 60s) in the Journal, the heap memory is "leaked".
> {color:#FF}NIOSequentialFileFactory{color} also has the same problem
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2098) Potential NPE when decoding protocol
[
https://issues.apache.org/jira/browse/ARTEMIS-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629305#comment-16629305
]
ASF GitHub Bot commented on ARTEMIS-2098:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2334#discussion_r220697913
--- Diff:
artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/ProtocolHandler.java
---
@@ -196,6 +196,10 @@ protected void decode(ChannelHandlerContext ctx,
ByteBuf in, List out) t
}
ProtocolManager protocolManagerToUse =
protocolMap.get(protocolToUse);
+ if (protocolManagerToUse == null) {
+
ActiveMQServerLogger.LOGGER.failedToFindProtocolManager(ctx.channel().remoteAddress().toString(),
ctx.channel().localAddress().toString(), protocolToUse,
protocolMap.keySet().toString());
--- End diff --
Question, how sure/guarenteed is it that these objects will def be wont be
null them selves, aka doing this logger wont cause an NPE.
ctx.channel().remoteAddress().toString()
ctx.channel().localAddress().toString()
is it worth null checking the dot train?
e.g. is it worth doing?
ctx.channel() == null ? null : ctx.channel().localAddress() == null ? null
: ctx.channel().localAddress().toString
> Potential NPE when decoding protocol
>
>
> Key: ARTEMIS-2098
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2098
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.3
>Reporter: Justin Bertram
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629298#comment-16629298 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2331 @jbertram have you pr'd your fix for the packet issue? I couldnt find it in the commits > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629297#comment-16629297 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user michaelandrepearce closed the pull request at: https://github.com/apache/activemq-artemis/pull/2333 > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2098) Potential NPE when decoding protocol
[ https://issues.apache.org/jira/browse/ARTEMIS-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629295#comment-16629295 ] ASF GitHub Bot commented on ARTEMIS-2098: - GitHub user jbertram opened a pull request: https://github.com/apache/activemq-artemis/pull/2334 ARTEMIS-2098 potential NPE when decoding protocol You can merge this pull request into a Git repository by running: $ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-2098 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2334.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2334 commit 9283e6227581078c18d5b73261e8685d437e1cb0 Author: Justin Bertram Date: 2018-09-26T19:27:14Z ARTEMIS-2098 potential NPE when decoding protocol > Potential NPE when decoding protocol > > > Key: ARTEMIS-2098 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2098 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Justin Bertram >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629271#comment-16629271 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2333 Close it please! It's important to keep the cherry-pick consistent.. so I ammended your commit before pushing. I also have been keeping the entire hash of the commit, not just the short one.. .I'm not sure what client version you use, but I get the full hash when I do "git cherry-pick -x " > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629270#comment-16629270 ] ASF subversion and git services commented on ARTEMIS-2095: -- Commit 2aa7844d58b21f3772c08b41344888ff8380431c in activemq-artemis's branch refs/heads/2.6.x from [~teaandcoffee] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=2aa7844 ] ARTEMIS-2095 - Typed Properties ThreadSafety (cherry picked from commit b8b89d81badf755b97846ca12beb5f9373dec31f) > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629268#comment-16629268 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2331 > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629266#comment-16629266 ] ASF subversion and git services commented on ARTEMIS-2095: -- Commit 8e40b2d4f4f242271d3dfcda4f9b96d3f94cee1b in activemq-artemis's branch refs/heads/master from [~teaandcoffee] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=8e40b2d ] ARTEMIS-2095 - Typed Properties ThreadSafety Add Concurrency Test to expose concurrency errors seen in logs. Add Fix to ensure TypedProperties to ensure threadsafety Add forEach and forEachKey to allow for provide a thread safe way of iterating through keys and values, without needing to duplicate the collection. Add getMapNames method to remove code duplication and to ensure thread safe > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629263#comment-16629263 ] ASF subversion and git services commented on ARTEMIS-2094: -- Commit a59a5891f80c0a310091d24cae0fb8efef3a66ca in activemq-artemis's branch refs/heads/2.6.x from [~teaandcoffee] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=a59a589 ] ARTEMIS-2094 - Fix Configuration change loss when network Issue (cherry picked from commit cce0e1927c258ce6f3c3c3cb0d90bad5337b7d12) > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629262#comment-16629262 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2332 > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629260#comment-16629260 ] ASF subversion and git services commented on ARTEMIS-2094: -- Commit 89a6ba92a7ee6c42927453355e870a49387d670e in activemq-artemis's branch refs/heads/2.6.x from [~teaandcoffee] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=89a6ba9 ] ARTEMIS-2094 - Fix Configuration change loss when network Issue (cherry picked from commit cce0e19) > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2098) Potential NPE when decoding protocol
Justin Bertram created ARTEMIS-2098: --- Summary: Potential NPE when decoding protocol Key: ARTEMIS-2098 URL: https://issues.apache.org/jira/browse/ARTEMIS-2098 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.6.3 Reporter: Justin Bertram -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629195#comment-16629195 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2332 I saw that. Looks good. I will be able to merge it in 30 min. > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1937) Diverts do not work with auto created queues
[
https://issues.apache.org/jira/browse/ARTEMIS-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629029#comment-16629029
]
Justin Bertram commented on ARTEMIS-1937:
-
The nuance here is that each protocol implementation on the broker (e.g. STOMP,
AMQP, MQTT) is responsible for creating addresses & queues which don't exist,
but the core protocol itself never auto-creates addresses or queues. When the
message is routed to the divert the divert has no idea about the originating
protocol, and it doesn't perform any auto-creation on its own. It's possible
the semantics here could be changed but it will take some careful thought and
potentially some significant refactoring.
> Diverts do not work with auto created queues
>
>
> Key: ARTEMIS-1937
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1937
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> Consider the following configuration snippet:
> {code}
>
>
> ANYCAST
> ANYCAST
>
>
> MULTICAST
> MULTICAST
>
> ...
>
>
>
>
> /topic/test.foo
> /queue/test.vq.aaa.foo
> false
>
>
> /topic/test.foo
> /queue/test.vq.bbb.foo
> false
>
> ...
>
> {code}
> The goal of the {{}} part is to make sure that STOMP
> destinations like {{/queue/test.\*}} act like a queue and the ones like
> {{/topic/test.\*}} act like a topic. It works fine and sending a message to a
> non existing destination works as expected.
> The goal of the {{}} part is to emulate ActiveMQ 5 virtual
> destinations. A message sent to {{/topic/test.foo}} will get duplicated and
> will end up both in {{/queue/test.vq.aaa.foo}} and in
> {{/queue/test.vq.bbb.foo}}.
> The problem is that the configuration above does not work as a message being
> sent to {{/topic/test.foo}} is lost if the final queue does not exist. OTOH,
> a message directly sent to {{/queue/test.vq.aaa.foo}} will auto create the
> queue and will be kept.
> Adding the following:
> {code}
>
>
>
>
>
>
>
>
>
>
>
> ...
>
> {code}
> makes Artemis work as expected but this voids the use of the
> {{}} part.
> IMHO, a message sent to a divert pointing to an address (whether it already
> exists or not) should have the exact same behavior as a message sent directly
> to the forwarding address.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1795) The documentation regarding STOMP and message IDs is not correct
[
https://issues.apache.org/jira/browse/ARTEMIS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-1795:
Fix Version/s: (was: 2.6.3)
2.6.1
2.7.0
> The documentation regarding STOMP and message IDs is not correct
>
>
> Key: ARTEMIS-1795
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1795
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Priority: Major
> Fix For: 2.6.1, 2.7.0
>
>
> In "Protocols and Interoperability", there is a "Message IDs for Stomp
> messages" section.
> It refers to {{stompEnableMessageId}} which does not seem to be used anymore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1795) The documentation regarding STOMP and message IDs is not correct
[
https://issues.apache.org/jira/browse/ARTEMIS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-1795.
-
Resolution: Fixed
Fix Version/s: 2.6.3
This should have been fixed via ARTEMIS-1912.
> The documentation regarding STOMP and message IDs is not correct
>
>
> Key: ARTEMIS-1795
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1795
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Priority: Major
> Fix For: 2.6.3
>
>
> In "Protocols and Interoperability", there is a "Message IDs for Stomp
> messages" section.
> It refers to {{stompEnableMessageId}} which does not seem to be used anymore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628988#comment-16628988 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2332 @clebertsuconic heres the cherry > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2085) Improve validation of MDB activation config properties values
[
https://issues.apache.org/jira/browse/ARTEMIS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628913#comment-16628913
]
ASF GitHub Bot commented on ARTEMIS-2085:
-
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2312
@rpelisse theres a suite of tests i believe under
(org.apache.activemq.artemis.tests.integration.ra ) package in the integration
test module, this would probably where i would look to add such test.
> Improve validation of MDB activation config properties values
> -
>
> Key: ARTEMIS-2085
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2085
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Romain PELISSE
>Priority: Major
>
> Most of activation config properties values are not validated during MDB
> deploy. This might lead to successful deployment of misconfigured MDB without
> any warning.
> *Customer scenario*: Customer deploys MDB with misconfigured activation
> config property(wrong type, unsupported value). MDB deploys without any
> warning message. However, it doesn't work as expected. In worst case, MDB can
> not read any message.
> *Current validation status*
> Values of activation config properties are validated in
> \{{ActiveMQActivationSpec.validate()}} method. Validation covers only 3
> scenarios
> * not specified destination
> * wrong destination type (other than Queue / Topic)
> * no subscription name when MDB is durable topic subscriber
> Some \{{ActiveMQActivationSpec}} properties try to validate supported values
> in setters. For example \{{setAcknowledgeMode()}} throws
> \{{IllegalArgumentException}}. However these exceptions only log message on
> \{{finest}} level, which usually doesn't attract user's attention (see
> \{{BeenUtils.mapJavaBeanProperties}} in \{{jboss-common-beans}})
> Other parameters are not validated.
> *Possible issues*
> Not validated activation config properties can be set to any value without
> warning. There is a possibility of misconfiguration which can be detected
> during deploy time.
> _Examples_
> Value of \{{acknowledgeMode}} can be set to any string or number without
> warning. If that is the case, server uses default auto acknowledge. However,
> it doesn't warn user.
> If property \{{maxSessions}} is configured with negative value, no warning is
> logged and MDB is unable to consume messages.
> If \{{destination}} property specifies unknown destination, new destination
> with provided name is created. User should be informed about that at least on
> INFO log level (Currently it is debug in
> \{{ActiveMQActivation.setupDestination()}}).
> MDB unable to consume messages should not successfully deploy, and user
> should be informed about the misconfigured values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628908#comment-16628908 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2333 This is a cherry pick to 2.6.x of https://github.com/apache/activemq-artemis/pull/2331 > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628906#comment-16628906 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2331 Whilst its fresh, i made the cherry pick ready here: https://github.com/apache/activemq-artemis/pull/2333 > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628905#comment-16628905 ] ASF GitHub Bot commented on ARTEMIS-2095: - GitHub user michaelandrepearce opened a pull request: https://github.com/apache/activemq-artemis/pull/2333 ARTEMIS-2095 - Typed Properties ThreadSafety (cherry picked from commit 8e40b2d) You can merge this pull request into a Git repository by running: $ git pull https://github.com/michaelandrepearce/activemq-artemis ARTEMIS-2095-Cherry Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2333.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2333 commit a03716aef2ad1cf85c4123f1aecefca1fe3d37a8 Author: Michael André Pearce Date: 2018-09-26T15:00:01Z ARTEMIS-2095 - Typed Properties ThreadSafety (cherry picked from commit 8e40b2d) > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628886#comment-16628886 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2326 cherry pick here: https://github.com/apache/activemq-artemis/pull/2332 > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628885#comment-16628885 ] ASF GitHub Bot commented on ARTEMIS-2094: - GitHub user michaelandrepearce opened a pull request: https://github.com/apache/activemq-artemis/pull/2332 ARTEMIS-2094 - Fix Configuration change loss when network Issue (cherry picked from commit cce0e19) You can merge this pull request into a Git repository by running: $ git pull https://github.com/michaelandrepearce/activemq-artemis ARTEMIS-2094-Cherry Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2332.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2332 commit 89a6ba92a7ee6c42927453355e870a49387d670e Author: Michael André Pearce Date: 2018-09-26T14:47:05Z ARTEMIS-2094 - Fix Configuration change loss when network Issue (cherry picked from commit cce0e19) > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628864#comment-16628864 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2331 grr. (makes that change makes cherry picking fun) > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628833#comment-16628833 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user jbertram commented on the issue: https://github.com/apache/activemq-artemis/pull/2331 Looks like this needs to be rebased now since another PR was merged which also changes `artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/converter/AmqpCoreConverter.java`. > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628792#comment-16628792 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2326 @michaelandrepearce can you do the cherry-pick on 2.6.x? there are conflicts.. on such cases I usually ask the committer to do the cherry-pick. on 2.6.x the code was changed around LegacyJMSConfiguration. Can you please still refer commit cce0e1927c258ce6f3c3c3cb0d90bad5337b7d12 once you send your PR or the commit directly? I have written a report generator to correlate these XREFs and make sure we won't miss them. > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-2096) AMQP: Refactoring AMQPMessage abstraction for better consistency and performance
[ https://issues.apache.org/jira/browse/ARTEMIS-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved ARTEMIS-2096. --- Resolution: Fixed > AMQP: Refactoring AMQPMessage abstraction for better consistency and > performance > > > Key: ARTEMIS-2096 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2096 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.6.3 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 2.7.0 > > > The AMQPMessage abstraction used to wrap the AMQP message section has some > inconsistencies in how it manages the underlying data and the decoded AMQP > section obtained from the Proton-J codec as well as issues with state being > maintained in the presence of changes to the message made through the public > facing Message APIs > A refactoring of the AMQPMessage class to better utilize the proton-j codec > to manage the message data and how it is parsed and re-encoded on change > needs to be done to ensure no corrupt messages are sent and that we are not > decoding and encoding sections of the message we are not intending to read or > change on the sever (We currently can decode message bodies or footer is a > few cases where we intend not to). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2096) AMQP: Refactoring AMQPMessage abstraction for better consistency and performance
[ https://issues.apache.org/jira/browse/ARTEMIS-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628763#comment-16628763 ] ASF subversion and git services commented on ARTEMIS-2096: -- Commit a851a8f93f30972d252f2bff0bb3d5847cfd7b5f in activemq-artemis's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=a851a8f ] ARTEMIS-2096 Refactor AMQMessage abstraction Major refactoring of the AMQPMessage abstraction to resolve some issue of message corruption still present in the code and improve the API handling of message changes and re-encoding. Improves handling of decoding of message sections limiting the work to only the portions needed and ensuring the state data is always updated with what has been done. Fixes issues of corrupt state on copy of message or other changes in filters. > AMQP: Refactoring AMQPMessage abstraction for better consistency and > performance > > > Key: ARTEMIS-2096 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2096 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.6.3 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 2.7.0 > > > The AMQPMessage abstraction used to wrap the AMQP message section has some > inconsistencies in how it manages the underlying data and the decoded AMQP > section obtained from the Proton-J codec as well as issues with state being > maintained in the presence of changes to the message made through the public > facing Message APIs > A refactoring of the AMQPMessage class to better utilize the proton-j codec > to manage the message data and how it is parsed and re-encoded on change > needs to be done to ensure no corrupt messages are sent and that we are not > decoding and encoding sections of the message we are not intending to read or > change on the sever (We currently can decode message bodies or footer is a > few cases where we intend not to). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628778#comment-16628778 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2326 > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628776#comment-16628776 ] ASF subversion and git services commented on ARTEMIS-2094: -- Commit cce0e1927c258ce6f3c3c3cb0d90bad5337b7d12 in activemq-artemis's branch refs/heads/master from [~teaandcoffee] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=cce0e19 ] ARTEMIS-2094 - Fix Configuration change loss when network Issue Further fix around network loss. If network loss (split) and slave activates, for a period its config used when it initializes in initialisePart2 was stale. Add/Extend test to ensure address-setting change made on live preserved on slave (after activation) Add/Extend test to ensure security-setting change made on live preserved on backup (after activation) > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2087) Support masked passwords in management.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628771#comment-16628771 ] ASF subversion and git services commented on ARTEMIS-2087: -- Commit 4f6a13e0fb3636ad45ad853182d89faa7489e6fa in activemq-artemis's branch refs/heads/2.6.x from [~jbertram] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=4f6a13e ] ARTEMIS-2087 fix NPE; mask password in example (cherry picked from commit 5d329a70d197cea551b0e26a55c73d099f5e8093) > Support masked passwords in management.xml > -- > > Key: ARTEMIS-2087 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2087 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2096) AMQP: Refactoring AMQPMessage abstraction for better consistency and performance
[ https://issues.apache.org/jira/browse/ARTEMIS-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628766#comment-16628766 ] ASF GitHub Bot commented on ARTEMIS-2096: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2329 > AMQP: Refactoring AMQPMessage abstraction for better consistency and > performance > > > Key: ARTEMIS-2096 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2096 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.6.3 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 2.7.0 > > > The AMQPMessage abstraction used to wrap the AMQP message section has some > inconsistencies in how it manages the underlying data and the decoded AMQP > section obtained from the Proton-J codec as well as issues with state being > maintained in the presence of changes to the message made through the public > facing Message APIs > A refactoring of the AMQPMessage class to better utilize the proton-j codec > to manage the message data and how it is parsed and re-encoded on change > needs to be done to ensure no corrupt messages are sent and that we are not > decoding and encoding sections of the message we are not intending to read or > change on the sever (We currently can decode message bodies or footer is a > few cases where we intend not to). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2087) Support masked passwords in management.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628769#comment-16628769 ] ASF subversion and git services commented on ARTEMIS-2087: -- Commit 5d329a70d197cea551b0e26a55c73d099f5e8093 in activemq-artemis's branch refs/heads/master from [~jbertram] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=5d329a7 ] ARTEMIS-2087 fix NPE; mask password in example > Support masked passwords in management.xml > -- > > Key: ARTEMIS-2087 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2087 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2087) Support masked passwords in management.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628770#comment-16628770 ] ASF GitHub Bot commented on ARTEMIS-2087: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2330 > Support masked passwords in management.xml > -- > > Key: ARTEMIS-2087 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2087 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628693#comment-16628693 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2326 Will merge it. > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628674#comment-16628674 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2326 @jbertram , @clebertsuconic can this be merged? And also cherry picked to 2.6.x this is causing issues. > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628607#comment-16628607 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2331 @jbertram just to be clear this sorts another issue, not the packet issue you're aware we are having. As i believe the fix you have for that is due to a you think a concurrency issue possibly in CoreMessage? Just want to avoid getting two issues mixed up. > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMQ-7062) RedeliverPlugin can loop on duplicate detection sending to dlq
[
https://issues.apache.org/jira/browse/AMQ-7062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-7062.
-
Resolution: Fixed
> RedeliverPlugin can loop on duplicate detection sending to dlq
> --
>
> Key: AMQ-7062
> URL: https://issues.apache.org/jira/browse/AMQ-7062
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 5.16.0
>
>
> When brokers "RedeliveryPlugin" is configured with maximumRedeliveries="-1"
> (deliver forever) and a "duplicate message from store" is detected, the
> duplicate message never makes it to the DLQ and keeps getting redelivered to
> the original queue.
> {code:java}
> WARN | JobScheduler:JMS | AbstractStoreCursor |
> gion.cursors.AbstractStoreCursor 116 |
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch@13044dcb:MYQUEUEXXX,batchResetNeeded=false,size=0,cacheEnabled=true,maxBatchSize:3,hasSpace:true,pendingCachedIds.size:1,lastSyncCachedId:null,lastSyncCachedId-seq:null,lastAsyncCachedId:ID:MYID2XXX-41992-1537343117867-33:1:1:1:31,lastAsyncCachedId-seq:34164,store=permits:,sd=nextSeq:34228,lastRet:MessageOrderCursor:[def:0,
> low:0, high:0],pending:0 - cursor got duplicate send
> ID:MYIDXXX1536652818855-25:1:2:1:4 seq:
> org.apache.activemq.store.kahadb.KahaDBStore$StoreQueueTask$InnerFutureTask@26c9ffc9
> WARN | JobScheduler:JMS | Queue|
> mq.broker.region.BaseDestination 853 | duplicate message from store
> ID:MYIDXXX1536652818855-25:1:2:1:4, redirecting for dlq processing
> TRACE | JobScheduler:JMS | RedeliveryPlugin |
> emq.broker.util.RedeliveryPlugin 173 | redelivery #31514 of:
> ID:MYIDXXX1536652818855-25:1:2:1:4 with delay: 1, dest: queue://MYQUEUEXXX
> WARN | JobScheduler:JMS | AbstractStoreCursor |
> gion.cursors.AbstractStoreCursor 116 |
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch@13044dcb:MYQUEUEXXX,batchResetNeeded=false,size=0,cacheEnabled=true,maxBatchSize:3,hasSpace:true,pendingCachedIds.size:1,lastSyncCachedId:null,lastSyncCachedId-seq:null,lastAsyncCachedId:ID:MYID2XXX-41992-1537343117867-33:1:1:1:31,lastAsyncCachedId-seq:34164,store=permits:,sd=nextSeq:34229,lastRet:MessageOrderCursor:[def:0,
> low:0, high:0],pending:0 - cursor got duplicate send
> ID:MYIDXXX1536652818855-25:1:2:1:4 seq:
> org.apache.activemq.store.kahadb.KahaDBStore$StoreQueueTask$InnerFutureTask@7be7d7d7
> WARN | JobScheduler:JMS | Queue|
> mq.broker.region.BaseDestination 853 | duplicate message from store
> ID:MYIDXXX1536652818855-25:1:2:1:4, redirecting for dlq processing
> TRACE | JobScheduler:JMS | RedeliveryPlugin |
> emq.broker.util.RedeliveryPlugin 173 | redelivery #31515 of:
> ID:MYIDXXX1536652818855-25:1:2:1:4 with delay: 1, dest: queue://MYQUEUEXXX
> WARN | JobScheduler:JMS | AbstractStoreCursor |
> gion.cursors.AbstractStoreCursor 116 |
> org.apache.activemq.broker.region.cursors.QueueStorePrefetch@13044dcb:MYQUEUEXXX,batchResetNeeded=false,size=0,cacheEnabled=true,maxBatchSize:3,hasSpace:true,pendingCachedIds.size:1,lastSyncCachedId:null,lastSyncCachedId-seq:null,lastAsyncCachedId:ID:MYID2XXX-41992-1537343117867-33:1:1:1:31,lastAsyncCachedId-seq:34164,store=permits:,sd=nextSeq:34230,lastRet:MessageOrderCursor:[def:0,
> low:0, high:0],pending:0 - cursor got duplicate send
> ID:MYIDXXX1536652818855-25:1:2:1:4 seq:
> org.apache.activemq.store.kahadb.KahaDBStore$StoreQueueTask$InnerFutureTask@17f4d783
> WARN | JobScheduler:JMS | Queue|
> mq.broker.region.BaseDestination 853 | duplicate message from store
> ID:MYIDXXX1536652818855-25:1:2:1:4, redirecting for dlq processing
> TRACE | JobScheduler:JMS | RedeliveryPlugin |
> emq.broker.util.RedeliveryPlugin 173 | redelivery #31516 of:
> ID:MYIDXXX1536652818855-25:1:2:1:4 with delay: 1, dest: queue://MYQUEUEXXX
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628510#comment-16628510 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2328 @franz1981 theres a new PR, i pinged you on it. > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628508#comment-16628508 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2328 @franz1981 i redid the solution to fix the issues, essentially ensuring all access is via synchronized methods, and nothing leaks out (e.g. internal properties isnt able to be got from outside , i spotted a few cases) Perf wise seems good enough to me. The main thing was to fix the concurrency issues. > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628501#comment-16628501 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2331 @franz1981 so it looks like stampedlock unless using optimistic read, (which we cant in this case), doesn't play nice with dual socket's, i guess something with all of last year cpu security issues. Anyhow heres alternative fix to address concurrency issues. > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628497#comment-16628497 ] ASF GitHub Bot commented on ARTEMIS-2095: - GitHub user michaelandrepearce opened a pull request: https://github.com/apache/activemq-artemis/pull/2331 ARTEMIS-2095 - Typed Properties ThreadSafety Add Concurrency Test to expose concurrency errors seen in logs. Add Fix to ensure TypedProperties to ensure threadsafety Add forEach and forEachKey to allow for provide a thread safe way of iterating through keys and values, without needing to duplicate the collection. Add getMapNames method to remove code duplication and to ensure thread safe You can merge this pull request into a Git repository by running: $ git pull https://github.com/michaelandrepearce/activemq-artemis ARTEMIS-2095 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2331.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2331 commit 18a889e4515459e80ebbc8920958fd26259f13aa Author: Michael André Pearce Date: 2018-09-25T21:57:12Z ARTEMIS-2095 - Typed Properties ThreadSafety Add Concurrency Test to expose concurrency errors seen in logs. Add Fix to ensure TypedProperties to ensure threadsafety Add forEach and forEachKey to allow for provide a thread safe way of iterating through keys and values, without needing to duplicate the collection. Add getMapNames method to remove code duplication and to ensure thread safe > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628448#comment-16628448 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2328 @michaelandrepearce I have done some experiments on it and I have noticed that the issue is the contention of the `state` field on `StampedLock` with the rest of the surrounding fields on the heap. Just using a `AtomicLongArray` of 32 elements (256 bytes) and using the 16th element to hold the state is enough to avoid any weird contention issues with multi-sockets setup. The effects of such change is so evident that just using a single-socket CPU would already benefit by this change. The point is that it is an extreme way to improve perf on this and I don't know if we've such high contention of TypedProperties to justify it... > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628406#comment-16628406 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2328 @michaelandrepearce I have @home an AMD Thread Ripper dual socket so I can try something with it :P Just to understand the issue here: with single threading a stamped lock is fine but under contention it is getting worst due to the present of multiple sockets? In which parts of our processing pipeline we have high contention on Typed Properties? > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628382#comment-16628382 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2328 @franz1981 i don't think that would help, issue here is whilst locally, performance was better, i put it on a real server to quickly re-check, and it was slower. I think the issue is that servers have two cpu sockets, instead of one, so going to shared main memory is slightly different to having single cpu, multi core. > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2095) TypedProperties thread safety
[ https://issues.apache.org/jira/browse/ARTEMIS-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628292#comment-16628292 ] ASF GitHub Bot commented on ARTEMIS-2095: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2328 @michaelandrepearce Michael, you know that I love doing perf stuff as well, so I can share some bench with JMH as soon as I would find some minutes during the day (or this evening) :+1: On Proton-j we have a module with all the JMH benchs, probably having something similar on Artemis will avoid writing new ones every time... > TypedProperties thread safety > - > > Key: ARTEMIS-2095 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2095 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Whilst TypedProperties is meant to have a single thread acting on it (and > this is the most typical interaction), there are occurrences where, it can be > acted on by other threads, when this occurs some concurrent modification > errors can occur. > As such TypedProperties must be thread safe, but concurrency tuning should > factor in to be most performant for single thread. > > e.g. > 2018-09-24 15:01:27,751 WARN > [org.apache.activemq.artemis.core.message.impl.CoreMessage] Error creating > String for message: : java.util.ConcurrentModificationException at > java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1471) [rt.jar:1.8.0_102] > at java.util.HashMap$EntryIterator.next(HashMap.java:1469) [rt.jar:1.8.0_102] > at > org.apache.activemq.artemis.utils.collections.TypedProperties.toString(TypedProperties.java:464) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
