[jira] [Commented] (ARTEMIS-2179) Add management method to get cluster-connection names
[
https://issues.apache.org/jira/browse/ARTEMIS-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693975#comment-16693975
]
ASF GitHub Bot commented on ARTEMIS-2179:
-
GitHub user jbertram opened a pull request:
https://github.com/apache/activemq-artemis/pull/2439
ARTEMIS-2179 mgmnt method to get cluster-cxn names
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-2179
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/2439.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 #2439
commit 355f4fadeb477fece8ddb3d062a7c914b132a669
Author: Justin Bertram
Date: 2018-11-21T00:53:01Z
ARTEMIS-2179 mgmnt method to get cluster-cxn names
> Add management method to get cluster-connection names
> -
>
> Key: ARTEMIS-2179
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2179
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> To invoke management operations on many resources (e.g. queues, addresses,
> bridges, diverts, cluster-connections, etc.) you need to know the _name_ of
> the resource. Many of these resource types have management methods to get
> their names (e.g. {{ActiveMQServerControl}} has {{getQueueNames()}},
> {{getAddressNames()}}, {{getDivertNames()}}, {{getBridgeNames}}, etc.).
> However, cluster-connections do not have such a management method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARTEMIS-2179) Add management method to get cluster-connection names
Justin Bertram created ARTEMIS-2179:
---
Summary: Add management method to get cluster-connection names
Key: ARTEMIS-2179
URL: https://issues.apache.org/jira/browse/ARTEMIS-2179
Project: ActiveMQ Artemis
Issue Type: Improvement
Reporter: Justin Bertram
Assignee: Justin Bertram
To invoke management operations on many resources (e.g. queues, addresses,
bridges, diverts, cluster-connections, etc.) you need to know the _name_ of the
resource. Many of these resource types have management methods to get their
names (e.g. {{ActiveMQServerControl}} has {{getQueueNames()}},
{{getAddressNames()}}, {{getDivertNames()}}, {{getBridgeNames}}, etc.).
However, cluster-connections do not have such a management method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2178) Support routing-type configuration on core bridge
[
https://issues.apache.org/jira/browse/ARTEMIS-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693886#comment-16693886
]
ASF GitHub Bot commented on ARTEMIS-2178:
-
GitHub user jbertram opened a pull request:
https://github.com/apache/activemq-artemis/pull/2438
ARTEMIS-2178 routing-type config for core bridge
MULTICAST messages forwarded by a core bridge will not be routed to any
ANYCAST queues and vice-versa. Diverts have the ability to configure how
routing-type is treated. Core bridges now support this same kind of
functionality. By default the bridge does not alter the routing-type of
forwarded messages to maintain compatibility with existing behavior.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-2178
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/2438.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 #2438
commit 1ae5db1432a56489162b36297f902cbaf5b84e38
Author: Justin Bertram
Date: 2018-11-20T03:24:35Z
ARTEMIS-2178 routing-type config for core bridge
MULTICAST messages forwarded by a core bridge will not be routed to any
ANYCAST queues and vice-versa. Diverts have the ability to configure how
routing-type is treated. Core bridges now support this same kind of
functionality. By default the bridge does not alter the routing-type of
forwarded messages to maintain compatibility with existing behavior.
> Support routing-type configuration on core bridge
> -
>
> Key: ARTEMIS-2178
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2178
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> {{MULTICAST}} messages forwarded by a core bridge will not be routed to any
> {{ANYCAST}} queues and vice-versa. Diverts have the ability to configure how
> routing-type is treated. Core bridges should support this same kind of
> functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2178) Support routing-type configuration on core bridge
[
https://issues.apache.org/jira/browse/ARTEMIS-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-2178:
Description: {{MULTICAST}} messages forwarded by a core bridge will not be
routed to any {{ANYCAST}} queues and vice-versa. Diverts have the ability to
configure how routing-type is treated. Core bridges should support this same
kind of functionality.
> Support routing-type configuration on core bridge
> -
>
> Key: ARTEMIS-2178
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2178
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> {{MULTICAST}} messages forwarded by a core bridge will not be routed to any
> {{ANYCAST}} queues and vice-versa. Diverts have the ability to configure how
> routing-type is treated. Core bridges should support this same kind of
> functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARTEMIS-2178) Support routing-type configuration on core bridge
Justin Bertram created ARTEMIS-2178: --- Summary: Support routing-type configuration on core bridge Key: ARTEMIS-2178 URL: https://issues.apache.org/jira/browse/ARTEMIS-2178 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2170) Optimized CoreMessage's checkProperties and cleanupInternalProperties methods
[
https://issues.apache.org/jira/browse/ARTEMIS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693493#comment-16693493
]
ASF GitHub Bot commented on ARTEMIS-2170:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2427#discussion_r235089654
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -52,6 +52,11 @@
* consumers */
public class CoreMessage extends RefCountMessage implements ICoreMessage {
+ // We use properties to establish routing context on clustering.
+ // However if the client resends the message after receiving, it needs
to be removed
+ private static final Predicate
INTERNAL_PROPERTY_NAMES_CLEANUP_FILTER =
--- End diff --
You'd be better asking people like martyn or clebert to confirm. But the
looks of it there seems some streamlining to be done.
> Optimized CoreMessage's checkProperties and cleanupInternalProperties methods
> -
>
> Key: ARTEMIS-2170
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2170
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Minor
>
> CoreMessage::checkProperties perform too many volatile read/write and has a
> too big body just to handle exceptional cases, while
> cleanupInternalProperties is called on the hot path of session send, but is
> performing too many synchronized operations and loopup on TypedProperties.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7103) Dependency updates flagged by OWASP Dependency Check
[
https://issues.apache.org/jira/browse/AMQ-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693383#comment-16693383
]
Albert Baker commented on AMQ-7103:
---
You can simply run "{{mvn versions:display-dependency-updates}}" to discover
what newer jars exist for your dependencies, and update the poms to those
versions. Each sub-project lead can be tasked with that to spread the load.
Forinstance there are 2605 newer jars available for all sub-projects under
ActiveMQ. Updating the pom and running local tests can be done
frequently(weekly/daily), prior to checking in the changes.
> Dependency updates flagged by OWASP Dependency Check
>
>
> Key: AMQ-7103
> URL: https://issues.apache.org/jira/browse/AMQ-7103
> Project: ActiveMQ
> Issue Type: Improvement
>Affects Versions: 5.15.7
>Reporter: Christopher L. Shannon
>Priority: Major
> Fix For: 5.15.9
>
> Attachments: report.txt
>
>
> Original text from Jira issue from [~ABakerIII] -
>
> Please determine if
> # The 458 vulnerabilities are true vulnerabilities or false positives
> # Are there newer versions of the vulnerable libraries available
> # Will updating the pom to use the new libraries break the build/test or not
> # If updates some do break the build/test, please update the code to work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMQ-7103) Dependency updates flagged by OWASP Dependency Check
[ https://issues.apache.org/jira/browse/AMQ-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Baker updated AMQ-7103: -- Attachment: report.txt > Dependency updates flagged by OWASP Dependency Check > > > Key: AMQ-7103 > URL: https://issues.apache.org/jira/browse/AMQ-7103 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 5.15.7 >Reporter: Christopher L. Shannon >Priority: Major > Fix For: 5.15.9 > > Attachments: report.txt > > > Original text from Jira issue from [~ABakerIII] - > > Please determine if > # The 458 vulnerabilities are true vulnerabilities or false positives > # Are there newer versions of the vulnerable libraries available > # Will updating the pom to use the new libraries break the build/test or not > # If updates some do break the build/test, please update the code to work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7105) Redelivery Now
[ https://issues.apache.org/jira/browse/AMQ-7105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693089#comment-16693089 ] Christopher L. Shannon commented on AMQ-7105: - If you would like to improve the redelivery plugin your best bet would be to create a pull request otherwise it would only be worked on when someone wants to enhance it and has time. You can also always just extend the plugin or create your own to handle your extra functionality you need (that is why the plugin framework is there so users can easily add their own code to handle custom requirements) > Redelivery Now > -- > > Key: AMQ-7105 > URL: https://issues.apache.org/jira/browse/AMQ-7105 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Lázaro Nixon Amaral de Almeida >Priority: Minor > > I would like to use redelivery plugin to retry messages for 20 days but some > times after fix a bug I want to retry all messages and not wait until next > schedule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7105) Redelivery Now
[ https://issues.apache.org/jira/browse/AMQ-7105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-7105: Priority: Minor (was: Critical) > Redelivery Now > -- > > Key: AMQ-7105 > URL: https://issues.apache.org/jira/browse/AMQ-7105 > Project: ActiveMQ > Issue Type: New Feature >Reporter: Lázaro Nixon Amaral de Almeida >Priority: Minor > > I would like to use redelivery plugin to retry messages for 20 days but some > times after fix a bug I want to retry all messages and not wait until next > schedule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7105) Redelivery Now
[ https://issues.apache.org/jira/browse/AMQ-7105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-7105: Issue Type: Improvement (was: New Feature) > Redelivery Now > -- > > Key: AMQ-7105 > URL: https://issues.apache.org/jira/browse/AMQ-7105 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Lázaro Nixon Amaral de Almeida >Priority: Minor > > I would like to use redelivery plugin to retry messages for 20 days but some > times after fix a bug I want to retry all messages and not wait until next > schedule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (AMQ-7104) java.io.IOException: Input/output error on ActiveMQ
[ https://issues.apache.org/jira/browse/AMQ-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon closed AMQ-7104. --- Resolution: Invalid This question is better suited for the user forums as there is nothing here that demonstrates an actual problem. The only thing the logs show are an error syncing to storage and this is most likely something with your environment and has nothing to do with ActiveMQ. Also, I see errors with username/password. In order to do anything you would need to demonstrate an actual issue that we could reproduce in order to fix. > java.io.IOException: Input/output error on ActiveMQ > --- > > Key: AMQ-7104 > URL: https://issues.apache.org/jira/browse/AMQ-7104 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.3 >Reporter: Siddardha >Priority: Major > Fix For: 5.15.3 > > Attachments: activemq.log > > > There is an error related to 'java.io.IOException: Input/output error ' on > Active MQ Cluster Setup (Master/Slave) which is stopping the BrokerService. > Also, It is not failing over the service to other node due to the same. > Active MQ Version: apache-activemq-5.15.3 > Java Version: 1.8.0_181 > OS: RHEL 7.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2069) Backup doesn't activate after shared store is reconnected
[
https://issues.apache.org/jira/browse/ARTEMIS-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693007#comment-16693007
]
ASF GitHub Bot commented on ARTEMIS-2069:
-
Github user TomasHofman commented on the issue:
https://github.com/apache/activemq-artemis/pull/2287
@jbertram @franz1981 we could really use this...
> Backup doesn't activate after shared store is reconnected
> -
>
> Key: ARTEMIS-2069
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2069
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.2
>Reporter: Tomas Hofman
>Priority: Major
>
> *Scenario*
> # Start live backup server pair in dedicated topology with shared store HA,
> with journal located on NFS
> # NFS mounted on backup server fails
> # Reconnect NFS on backup server
> # Try to shut down live EAP server
> # Backup doesn't activate
> *What happens*
> Backup is waiting for live to fail by checking its file lock. In case the
> connection to shared storage fails, backup logs following error.
>
> |{color:#00}05:50:57,896 ERROR [org.apache.activemq.artemis.core.server]
> (AMQ119000: Activation for server
> ActiveMQServerImpl::serverUUID=836c9b1e-f067-11e7-8763-001b21862475)
> AMQ224000: Failure in initialisation: java.io.IOException: Input/output
> error{color}|
> |{color:#00} at sun.nio.ch.FileDispatcherImpl.lock0(Native Method)
> [rt.jar:1.8.0_151]{color}|
> |{color:#00} at
> sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:90)
> [rt.jar:1.8.0_151]{color}|
> |{color:#00} at
> sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:1115)
> [rt.jar:1.8.0_151]{color}|
> |{color:#00} at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.tryLock(FileLockNodeManager.java:299)
> [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]{color}|
> |{color:#00} at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.lock(FileLockNodeManager.java:316)
> [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]{color}|
> |{color:#00} at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.awaitLiveNode(FileLockNodeManager.java:127)
> [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]{color}|
> |{color:#00} at
> org.apache.activemq.artemis.core.server.impl.SharedStoreBackupActivation.run(SharedStoreBackupActivation.java:77)
> [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]{color}|
> |{color:#00} at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2496)
> [artemis-server-1.5.5.008-redhat-1.jar:1.5.5.008-redhat-1]{color}|
> | |
>
> Exception is caught in {{SharedStoreBackupActivation.run}}, and causes
> termination of backup activation process.
> In case the NFS is reconnected later, backup server doesn't continue in
> activation process and it doesn't wait for live to fail. In case the live
> fails, backup doesn't activate, even though it has a connection to shared
> storage.
> Backup should retry checking live lock even in case the storage is
> unavailable. It should log warning/error messages that storage is
> unavailable, but it should not terminate the activation process. This would
> allow backup to continue its duties when the storage is reconnected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2170) Optimized CoreMessage's checkProperties and cleanupInternalProperties methods
[
https://issues.apache.org/jira/browse/ARTEMIS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693001#comment-16693001
]
ASF GitHub Bot commented on ARTEMIS-2170:
-
Github user franz1981 commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2427#discussion_r234941860
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -52,6 +52,11 @@
* consumers */
public class CoreMessage extends RefCountMessage implements ICoreMessage {
+ // We use properties to establish routing context on clustering.
+ // However if the client resends the message after receiving, it needs
to be removed
+ private static final Predicate
INTERNAL_PROPERTY_NAMES_CLEANUP_FILTER =
--- End diff --
Good catch!
I'm looking from the tablet so I hope to have searched all the interesting
points, but it seems to me that HDR_ROUTE_TO_ACK_IDS is not needed anymore? Or
am I missing anything?
`Message.HDR_ROUTE_TO_IDS.concat(bridgeName);` is using HDR_ROUTE_TO_IDS in
a way that it will match the `CoreMessage::cleanupInternalProperties` cases,
but for HDR_ROUTE_TO_ACK_IDS I can't see any points doing anything similar:
just using the entire property name ie it won't match the
`CoreMessage::cleanupInternalProperties` checks.
> Optimized CoreMessage's checkProperties and cleanupInternalProperties methods
> -
>
> Key: ARTEMIS-2170
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2170
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Minor
>
> CoreMessage::checkProperties perform too many volatile read/write and has a
> too big body just to handle exceptional cases, while
> cleanupInternalProperties is called on the hot path of session send, but is
> performing too many synchronized operations and loopup on TypedProperties.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2170) Optimized CoreMessage's checkProperties and cleanupInternalProperties methods
[
https://issues.apache.org/jira/browse/ARTEMIS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16692938#comment-16692938
]
ASF GitHub Bot commented on ARTEMIS-2170:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2427#discussion_r234926580
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -578,34 +567,41 @@ public CoreMessage setUserID(UUID userID) {
/**
* I am keeping this synchronized as the decode of the Properties is
lazy
*/
- protected TypedProperties checkProperties() {
+ protected final TypedProperties getOrCreateProperties() {
--- End diff --
All it does it invoke / delegate this method, as such if anything i see
naming CoreMessage.getProperties cleaner. And there is no need to change it
from final, simply you remove the impl in ClientMessageInternalImpl as it would
just inherit.
```
public TypedProperties getProperties() {
return this.checkProperties();
}
```
> Optimized CoreMessage's checkProperties and cleanupInternalProperties methods
> -
>
> Key: ARTEMIS-2170
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2170
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Minor
>
> CoreMessage::checkProperties perform too many volatile read/write and has a
> too big body just to handle exceptional cases, while
> cleanupInternalProperties is called on the hot path of session send, but is
> performing too many synchronized operations and loopup on TypedProperties.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2170) Optimized CoreMessage's checkProperties and cleanupInternalProperties methods
[
https://issues.apache.org/jira/browse/ARTEMIS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16692858#comment-16692858
]
ASF GitHub Bot commented on ARTEMIS-2170:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2427#discussion_r234909113
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -52,6 +52,11 @@
* consumers */
public class CoreMessage extends RefCountMessage implements ICoreMessage {
+ // We use properties to establish routing context on clustering.
+ // However if the client resends the message after receiving, it needs
to be removed
+ private static final Predicate
INTERNAL_PROPERTY_NAMES_CLEANUP_FILTER =
--- End diff --
@franz1981 in RemoteQueueBindingImpl.addRouteContextToMessage these are
added as extraByteProperties, and used in ClusterConnectionBridge maybe a
simpler solution is to hold extraByteProperties in a separate TypeProperties
like in AMQPMessage, then its easy to strip these extra internal properties (no
need to even iterate) / not let it leak to clients, just as in AMQPMessage.
> Optimized CoreMessage's checkProperties and cleanupInternalProperties methods
> -
>
> Key: ARTEMIS-2170
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2170
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Minor
>
> CoreMessage::checkProperties perform too many volatile read/write and has a
> too big body just to handle exceptional cases, while
> cleanupInternalProperties is called on the hot path of session send, but is
> performing too many synchronized operations and loopup on TypedProperties.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2170) Optimized CoreMessage's checkProperties and cleanupInternalProperties methods
[
https://issues.apache.org/jira/browse/ARTEMIS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16692837#comment-16692837
]
ASF GitHub Bot commented on ARTEMIS-2170:
-
Github user franz1981 commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2427#discussion_r234906424
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -578,34 +567,41 @@ public CoreMessage setUserID(UUID userID) {
/**
* I am keeping this synchronized as the decode of the Properties is
lazy
*/
- protected TypedProperties checkProperties() {
+ protected final TypedProperties getOrCreateProperties() {
--- End diff --
The reason why I haven't done it is due to `ClientMessageImpl extends
CoreMessage implements ClientMessageInternal`: `ClientMessageInternal` has
already a `geProperties` method while `CoreMessage::getProperties` has been
turned into final...
I can drop the final just to have a better name, but I would prefer to keep
it final to avoid any child of `CoreMessage` to broke its thread-safeness
contract by overriding it.
> Optimized CoreMessage's checkProperties and cleanupInternalProperties methods
> -
>
> Key: ARTEMIS-2170
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2170
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Minor
>
> CoreMessage::checkProperties perform too many volatile read/write and has a
> too big body just to handle exceptional cases, while
> cleanupInternalProperties is called on the hot path of session send, but is
> performing too many synchronized operations and loopup on TypedProperties.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2170) Optimized CoreMessage's checkProperties and cleanupInternalProperties methods
[
https://issues.apache.org/jira/browse/ARTEMIS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16692821#comment-16692821
]
ASF GitHub Bot commented on ARTEMIS-2170:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2427#discussion_r234903527
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -803,139 +799,122 @@ public CoreMessage setDurable(boolean durable) {
@Override
public CoreMessage putBooleanProperty(final String key, final boolean
value) {
messageChanged();
- checkProperties();
- properties.putBooleanProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()), value);
+ getOrCreateProperties().putBooleanProperty(key(key), value);
return this;
}
@Override
public CoreMessage putBooleanProperty(final SimpleString key, final
boolean value) {
messageChanged();
- checkProperties();
- properties.putBooleanProperty(key, value);
+ getOrCreateProperties().putBooleanProperty(key, value);
return this;
}
@Override
public Boolean getBooleanProperty(final SimpleString key) throws
ActiveMQPropertyConversionException {
- checkProperties();
- return properties.getBooleanProperty(key);
+ return getOrCreateProperties().getBooleanProperty(key);
}
@Override
public Boolean getBooleanProperty(final String key) throws
ActiveMQPropertyConversionException {
- checkProperties();
- return
properties.getBooleanProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()));
+ return getOrCreateProperties().getBooleanProperty(key(key));
}
@Override
public CoreMessage putByteProperty(final SimpleString key, final byte
value) {
messageChanged();
- checkProperties();
- properties.putByteProperty(key, value);
+ getOrCreateProperties().putByteProperty(key, value);
return this;
}
@Override
public CoreMessage putByteProperty(final String key, final byte value) {
messageChanged();
- checkProperties();
- properties.putByteProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()), value);
+ getOrCreateProperties().putByteProperty(key(key), value);
return this;
}
@Override
public Byte getByteProperty(final SimpleString key) throws
ActiveMQPropertyConversionException {
- checkProperties();
- return properties.getByteProperty(key);
+ return getOrCreateProperties().getByteProperty(key);
}
@Override
public Byte getByteProperty(final String key) throws
ActiveMQPropertyConversionException {
- return getByteProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()));
+ return getByteProperty(key(key));
}
@Override
public CoreMessage putBytesProperty(final SimpleString key, final
byte[] value) {
messageChanged();
- checkProperties();
- properties.putBytesProperty(key, value);
+ getOrCreateProperties().putBytesProperty(key, value);
return this;
}
@Override
public CoreMessage putBytesProperty(final String key, final byte[]
value) {
messageChanged();
- checkProperties();
- properties.putBytesProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()), value);
+ getOrCreateProperties().putBytesProperty(key(key), value);
return this;
}
@Override
public byte[] getBytesProperty(final SimpleString key) throws
ActiveMQPropertyConversionException {
- checkProperties();
- return properties.getBytesProperty(key);
+ return getOrCreateProperties().getBytesProperty(key);
}
@Override
public byte[] getBytesProperty(final String key) throws
ActiveMQPropertyConversionException {
- return getBytesProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()));
+ return getBytesProperty(key(key));
}
@Override
public CoreMessage putCharProperty(SimpleString key, char value) {
messageChanged();
- checkProperties();
- properties.putCharProperty(key, value);
+ getOrCreateProperties().putCharProperty(key, value);
return this;
}
@Override
public CoreMessage putCharProperty(String key, char value) {
messageChanged();
- checkProperties();
-
