[jira] [Commented] (ARTEMIS-2145) connectionTtl not work in MQTT Protocol
[ https://issues.apache.org/jira/browse/ARTEMIS-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16692801#comment-16692801 ] alin.p commented on ARTEMIS-2145: - I find another config connection-ttl-check-interval, by default, this will check dead connection from server every 2 seconds. I think this is the reason. > connectionTtl not work in MQTT Protocol > --- > > Key: ARTEMIS-2145 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2145 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: MQTT >Affects Versions: 2.6.3 > Environment: OS: windows 6.1.7601 64bit > artemis version: 2.6.3 > java version: 1.8.0_25 hotspot 64bit > client version: paho >Reporter: alin.p >Priority: Minor > > 1. use mqtt acceptor and config in broker.xml like below > tcp://0.0.0.0:1883?protocols=MQTT > 2. start artemis > 3. use [org.eclipse.paho.client > |https://www.eclipse.org/paho/clients/java/]client to connect and connection > option like below > MqttConnectOptions connOpts = new MqttConnectOptions(); > connOpts.setCleanSession(false); > connOpts.setConnectionTimeout(30); > connOpts.setKeepAliveInterval(*0*); > 4. if set connOpts.setKeepAliveInterval(0); the client connection will close > immediately > > 5. if set connOpts.setKeepAliveInterval(*30*); the client connection will > close normally > > expect: > mqtt acceptor should close connection depend on connectionTtl , the default > value is 30 seconds. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (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:comment-tabpanel=16692790#comment-16692790 ] Siddardha commented on AMQ-7104: Hi, Is there any update on this issue. > 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-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=16692208#comment-16692208
]
ASF GitHub Bot commented on ARTEMIS-2170:
-
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2427#discussion_r234767548
--- 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 not in top of my mind. I would first check if properties = null,
or empty... ? or add a parsed boolean? but i would need to debug to remember
the best way.
> 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=16691967#comment-16691967
]
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_r234697388
--- 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 --
Just name this getProperties. The name otherwise is too confusing with your
extracted method
> 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=16691763#comment-16691763
]
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_r234637863
--- 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();
-
[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=16691713#comment-16691713
]
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_r234622813
--- 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();
-
[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=16691706#comment-16691706
]
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_r234622321
--- 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));
--- End diff --
can be delegated as: getBooleanProperty(key(key))
> 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=16691710#comment-16691710
]
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_r234622539
--- 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);
--- End diff --
can be delegated as: putBytesProperty(key(key), value)
> 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=16691708#comment-16691708
]
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_r234622417
--- 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);
--- End diff --
can be delegated as: putByteProperty(key(key), value)
> 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=16691463#comment-16691463
]
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_r234546810
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -52,6 +52,62 @@
* consumers */
public class CoreMessage extends RefCountMessage implements ICoreMessage {
+ private static final class CoreTypedProperties extends TypedProperties {
+
+ // 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 =
+ name -> (name.startsWith(Message.HDR_ROUTE_TO_IDS) &&
!name.equals(Message.HDR_ROUTE_TO_IDS)) ||
+(name.startsWith(Message.HDR_ROUTE_TO_ACK_IDS) &&
!name.equals(Message.HDR_ROUTE_TO_ACK_IDS));
+ private static final SimpleString AMQ_PROPNAME = new
SimpleString("_AMQ_");
+ private boolean internalProperties;
+
+ CoreTypedProperties() {
+ super();
+ internalProperties = false;
+ }
+
+ private CoreTypedProperties(TypedProperties other) {
+ super(other);
+ if (other instanceof CoreTypedProperties) {
+internalProperties = ((CoreTypedProperties)
other).internalProperties;
+ } else {
+internalProperties = other.containsProperty(name ->
name.startsWith(AMQ_PROPNAME));
+ }
+ }
+
+ @Override
+ protected synchronized void doPutValue(SimpleString key,
TypedProperties.PropertyValue value) {
+ if (!internalProperties && key.startsWith(AMQ_PROPNAME)) {
+internalProperties = true;
+ }
+ super.doPutValue(key, value);
+ }
+
+ public synchronized boolean cleanupInternalProperties() {
+ if (!internalProperties) {
+return false;
+ }
+ return removeProperty(INTERNAL_PROPERTY_NAMES_CLEANUP_FILTER);
+ }
+
+ public static boolean cleanupInternalProperties(TypedProperties
typedProperties) {
+ if (typedProperties == null) {
+return false;
+ }
+ if (typedProperties instanceof CoreTypedProperties) {
+return ((CoreTypedProperties)
typedProperties).cleanupInternalProperties();
+ }
+ return
typedProperties.removeProperty(INTERNAL_PROPERTY_NAMES_CLEANUP_FILTER);
+ }
+
+ public static CoreTypedProperties copyOf(TypedProperties
typedProperties) {
+ synchronized (typedProperties) {
--- End diff --
So it being internal, means where this gets put MUST be somewhere in
Artemis code base, maybe a small nullable boolean flag on the CoreMessage could
be introduced that is set after by that code when these properties are added.
> 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] [Updated] (AMQ-7085) Queue.start() does not call systemUsage.start() so TempStore usage is not handled correctly
[
https://issues.apache.org/jira/browse/AMQ-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Sitsky updated AMQ-7085:
--
Attachment: AQM-7085.patch
> Queue.start() does not call systemUsage.start() so TempStore usage is not
> handled correctly
> ---
>
> Key: AMQ-7085
> URL: https://issues.apache.org/jira/browse/AMQ-7085
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.6
>Reporter: David Sitsky
>Priority: Major
> Attachments: AQM-7085.patch
>
>
> I have an application using ActiveMQ and have a situation where a producer is
> blocked with this log message due to the temp usage limit being hit:
> {noformat}
> [ActiveMQ Transport: tcp:///aaa.bbb.ccc.ddd:65119@64759] 82567721 INFO
> org.apache.activemq.broker.region.Queue -
> Usage(Main:temp:queue://aaabbb:temp) percentUsage=99%, usage=61771109932,
> limit=61771104256, percentUsageMinDelta=1%;Parent:Usage(Main:temp)
> percentUsage=100%, usage=61771109932, limit=61771104256,
> percentUsageMinDelta=1%: Temp Store is Full (99% of 61771104256). Stopping
> producer (ID:a-3:1:1:1) to prevent flooding queue://aaabbb. See
> http://activemq.apache.org/producer-flow-control.html for more info (blocking
> for: 8512s){noformat}
> In the past I have been able to use JConsole and update the broker's
> TempLimit value to a higher value to allow things to continue.
>
> However on this occasion, the messages above when output again show that the
> parent's temp limit has updated however the child's limit (the queue) is
> unchanged. So it seems the broker's TempUsage does not know about the
> queue's TempUsage.
>
> In looking at the code.. it seems a child Usage class has to call start() in
> order for this parent -> children link to be established and for parent limit
> changes to be propagated down to children. However the Queue start() method
> doesn't call systemUsage.getTempUsage().start() for some reason (or even just
> systemUsage.start()).
>
> Is this a bug?
>
> DestinationView sadly does not expose setTempLimit() either so this wasn't an
> option either.
>
> From Queue:
> {code:java}
> @Override
> public void start() throws Exception {
> if (started.compareAndSet(false, true)) {
> if (memoryUsage != null) {
> memoryUsage.start();
> }
> if (systemUsage.getStoreUsage() != null) {
> systemUsage.getStoreUsage().start();
> }
> systemUsage.getMemoryUsage().addUsageListener(this);
> messages.start();
> if (getExpireMessagesPeriod() > 0) {
> scheduler.executePeriodically(expireMessagesTask,
> getExpireMessagesPeriod());
> }
> doPageIn(false);
> }
> }{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMQ-7085) Queue.start() does not call systemUsage.start() so TempStore usage is not handled correctly
[
https://issues.apache.org/jira/browse/AMQ-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Sitsky updated AMQ-7085:
--
Attachment: (was: AMQ-7085.patch)
> Queue.start() does not call systemUsage.start() so TempStore usage is not
> handled correctly
> ---
>
> Key: AMQ-7085
> URL: https://issues.apache.org/jira/browse/AMQ-7085
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.6
>Reporter: David Sitsky
>Priority: Major
> Attachments: amq-7085.patch
>
>
> I have an application using ActiveMQ and have a situation where a producer is
> blocked with this log message due to the temp usage limit being hit:
> {noformat}
> [ActiveMQ Transport: tcp:///aaa.bbb.ccc.ddd:65119@64759] 82567721 INFO
> org.apache.activemq.broker.region.Queue -
> Usage(Main:temp:queue://aaabbb:temp) percentUsage=99%, usage=61771109932,
> limit=61771104256, percentUsageMinDelta=1%;Parent:Usage(Main:temp)
> percentUsage=100%, usage=61771109932, limit=61771104256,
> percentUsageMinDelta=1%: Temp Store is Full (99% of 61771104256). Stopping
> producer (ID:a-3:1:1:1) to prevent flooding queue://aaabbb. See
> http://activemq.apache.org/producer-flow-control.html for more info (blocking
> for: 8512s){noformat}
> In the past I have been able to use JConsole and update the broker's
> TempLimit value to a higher value to allow things to continue.
>
> However on this occasion, the messages above when output again show that the
> parent's temp limit has updated however the child's limit (the queue) is
> unchanged. So it seems the broker's TempUsage does not know about the
> queue's TempUsage.
>
> In looking at the code.. it seems a child Usage class has to call start() in
> order for this parent -> children link to be established and for parent limit
> changes to be propagated down to children. However the Queue start() method
> doesn't call systemUsage.getTempUsage().start() for some reason (or even just
> systemUsage.start()).
>
> Is this a bug?
>
> DestinationView sadly does not expose setTempLimit() either so this wasn't an
> option either.
>
> From Queue:
> {code:java}
> @Override
> public void start() throws Exception {
> if (started.compareAndSet(false, true)) {
> if (memoryUsage != null) {
> memoryUsage.start();
> }
> if (systemUsage.getStoreUsage() != null) {
> systemUsage.getStoreUsage().start();
> }
> systemUsage.getMemoryUsage().addUsageListener(this);
> messages.start();
> if (getExpireMessagesPeriod() > 0) {
> scheduler.executePeriodically(expireMessagesTask,
> getExpireMessagesPeriod());
> }
> doPageIn(false);
> }
> }{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1867) Support FQQN for producers
[
https://issues.apache.org/jira/browse/ARTEMIS-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691434#comment-16691434
]
ASF GitHub Bot commented on ARTEMIS-1867:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2434#discussion_r234540655
--- Diff:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
---
@@ -3178,138 +3187,7 @@ public Queue createQueue(final SimpleString address,
final int consumersBeforeDispatch,
final long delayBeforeDispatch,
final boolean autoCreateAddress) throws
Exception {
- return createQueue(address, routingType, queueName, filterString,
user, durable, temporary, ignoreIfExists, transientQueue, autoCreated,
maxConsumers, purgeOnNoConsumers, exclusive, lastValue, lastValueKey,
nonDestructive, consumersBeforeDispatch, delayBeforeDispatch,
autoCreateAddress, false);
- }
-
- private Queue createQueue(final SimpleString address,
--- End diff --
Thanks, i was going to flag about configurationManaged not being present on
the other, but have noticed since you've added it, so it shouldn't be an issue.
> Support FQQN for producers
> --
>
> Key: ARTEMIS-1867
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1867
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: STOMP
>Reporter: Justin Bertram
>Priority: Major
>
> Allow STOMP clients to send messages directly to a fully-qualified queue
> rather than just an address.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMQ-7085) Queue.start() does not call systemUsage.start() so TempStore usage is not handled correctly
[
https://issues.apache.org/jira/browse/AMQ-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Sitsky updated AMQ-7085:
--
Attachment: (was: amq-7085.patch)
> Queue.start() does not call systemUsage.start() so TempStore usage is not
> handled correctly
> ---
>
> Key: AMQ-7085
> URL: https://issues.apache.org/jira/browse/AMQ-7085
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.6
>Reporter: David Sitsky
>Priority: Major
> Attachments: AQM-7085.patch
>
>
> I have an application using ActiveMQ and have a situation where a producer is
> blocked with this log message due to the temp usage limit being hit:
> {noformat}
> [ActiveMQ Transport: tcp:///aaa.bbb.ccc.ddd:65119@64759] 82567721 INFO
> org.apache.activemq.broker.region.Queue -
> Usage(Main:temp:queue://aaabbb:temp) percentUsage=99%, usage=61771109932,
> limit=61771104256, percentUsageMinDelta=1%;Parent:Usage(Main:temp)
> percentUsage=100%, usage=61771109932, limit=61771104256,
> percentUsageMinDelta=1%: Temp Store is Full (99% of 61771104256). Stopping
> producer (ID:a-3:1:1:1) to prevent flooding queue://aaabbb. See
> http://activemq.apache.org/producer-flow-control.html for more info (blocking
> for: 8512s){noformat}
> In the past I have been able to use JConsole and update the broker's
> TempLimit value to a higher value to allow things to continue.
>
> However on this occasion, the messages above when output again show that the
> parent's temp limit has updated however the child's limit (the queue) is
> unchanged. So it seems the broker's TempUsage does not know about the
> queue's TempUsage.
>
> In looking at the code.. it seems a child Usage class has to call start() in
> order for this parent -> children link to be established and for parent limit
> changes to be propagated down to children. However the Queue start() method
> doesn't call systemUsage.getTempUsage().start() for some reason (or even just
> systemUsage.start()).
>
> Is this a bug?
>
> DestinationView sadly does not expose setTempLimit() either so this wasn't an
> option either.
>
> From Queue:
> {code:java}
> @Override
> public void start() throws Exception {
> if (started.compareAndSet(false, true)) {
> if (memoryUsage != null) {
> memoryUsage.start();
> }
> if (systemUsage.getStoreUsage() != null) {
> systemUsage.getStoreUsage().start();
> }
> systemUsage.getMemoryUsage().addUsageListener(this);
> messages.start();
> if (getExpireMessagesPeriod() > 0) {
> scheduler.executePeriodically(expireMessagesTask,
> getExpireMessagesPeriod());
> }
> doPageIn(false);
> }
> }{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7085) Queue.start() does not call systemUsage.start() so TempStore usage is not handled correctly
[
https://issues.apache.org/jira/browse/AMQ-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691433#comment-16691433
]
David Sitsky commented on AMQ-7085:
---
Fair enough.. I've added two tests which demonstrate the fix. Many thanks.
> Queue.start() does not call systemUsage.start() so TempStore usage is not
> handled correctly
> ---
>
> Key: AMQ-7085
> URL: https://issues.apache.org/jira/browse/AMQ-7085
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.6
>Reporter: David Sitsky
>Priority: Major
> Attachments: amq-7085.patch
>
>
> I have an application using ActiveMQ and have a situation where a producer is
> blocked with this log message due to the temp usage limit being hit:
> {noformat}
> [ActiveMQ Transport: tcp:///aaa.bbb.ccc.ddd:65119@64759] 82567721 INFO
> org.apache.activemq.broker.region.Queue -
> Usage(Main:temp:queue://aaabbb:temp) percentUsage=99%, usage=61771109932,
> limit=61771104256, percentUsageMinDelta=1%;Parent:Usage(Main:temp)
> percentUsage=100%, usage=61771109932, limit=61771104256,
> percentUsageMinDelta=1%: Temp Store is Full (99% of 61771104256). Stopping
> producer (ID:a-3:1:1:1) to prevent flooding queue://aaabbb. See
> http://activemq.apache.org/producer-flow-control.html for more info (blocking
> for: 8512s){noformat}
> In the past I have been able to use JConsole and update the broker's
> TempLimit value to a higher value to allow things to continue.
>
> However on this occasion, the messages above when output again show that the
> parent's temp limit has updated however the child's limit (the queue) is
> unchanged. So it seems the broker's TempUsage does not know about the
> queue's TempUsage.
>
> In looking at the code.. it seems a child Usage class has to call start() in
> order for this parent -> children link to be established and for parent limit
> changes to be propagated down to children. However the Queue start() method
> doesn't call systemUsage.getTempUsage().start() for some reason (or even just
> systemUsage.start()).
>
> Is this a bug?
>
> DestinationView sadly does not expose setTempLimit() either so this wasn't an
> option either.
>
> From Queue:
> {code:java}
> @Override
> public void start() throws Exception {
> if (started.compareAndSet(false, true)) {
> if (memoryUsage != null) {
> memoryUsage.start();
> }
> if (systemUsage.getStoreUsage() != null) {
> systemUsage.getStoreUsage().start();
> }
> systemUsage.getMemoryUsage().addUsageListener(this);
> messages.start();
> if (getExpireMessagesPeriod() > 0) {
> scheduler.executePeriodically(expireMessagesTask,
> getExpireMessagesPeriod());
> }
> doPageIn(false);
> }
> }{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMQ-7085) Queue.start() does not call systemUsage.start() so TempStore usage is not handled correctly
[
https://issues.apache.org/jira/browse/AMQ-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Sitsky updated AMQ-7085:
--
Attachment: amq-7085.patch
> Queue.start() does not call systemUsage.start() so TempStore usage is not
> handled correctly
> ---
>
> Key: AMQ-7085
> URL: https://issues.apache.org/jira/browse/AMQ-7085
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.6
>Reporter: David Sitsky
>Priority: Major
> Attachments: amq-7085.patch
>
>
> I have an application using ActiveMQ and have a situation where a producer is
> blocked with this log message due to the temp usage limit being hit:
> {noformat}
> [ActiveMQ Transport: tcp:///aaa.bbb.ccc.ddd:65119@64759] 82567721 INFO
> org.apache.activemq.broker.region.Queue -
> Usage(Main:temp:queue://aaabbb:temp) percentUsage=99%, usage=61771109932,
> limit=61771104256, percentUsageMinDelta=1%;Parent:Usage(Main:temp)
> percentUsage=100%, usage=61771109932, limit=61771104256,
> percentUsageMinDelta=1%: Temp Store is Full (99% of 61771104256). Stopping
> producer (ID:a-3:1:1:1) to prevent flooding queue://aaabbb. See
> http://activemq.apache.org/producer-flow-control.html for more info (blocking
> for: 8512s){noformat}
> In the past I have been able to use JConsole and update the broker's
> TempLimit value to a higher value to allow things to continue.
>
> However on this occasion, the messages above when output again show that the
> parent's temp limit has updated however the child's limit (the queue) is
> unchanged. So it seems the broker's TempUsage does not know about the
> queue's TempUsage.
>
> In looking at the code.. it seems a child Usage class has to call start() in
> order for this parent -> children link to be established and for parent limit
> changes to be propagated down to children. However the Queue start() method
> doesn't call systemUsage.getTempUsage().start() for some reason (or even just
> systemUsage.start()).
>
> Is this a bug?
>
> DestinationView sadly does not expose setTempLimit() either so this wasn't an
> option either.
>
> From Queue:
> {code:java}
> @Override
> public void start() throws Exception {
> if (started.compareAndSet(false, true)) {
> if (memoryUsage != null) {
> memoryUsage.start();
> }
> if (systemUsage.getStoreUsage() != null) {
> systemUsage.getStoreUsage().start();
> }
> systemUsage.getMemoryUsage().addUsageListener(this);
> messages.start();
> if (getExpireMessagesPeriod() > 0) {
> scheduler.executePeriodically(expireMessagesTask,
> getExpireMessagesPeriod());
> }
> doPageIn(false);
> }
> }{code}
>
--
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=16691411#comment-16691411
]
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_r234533807
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -52,6 +52,62 @@
* consumers */
public class CoreMessage extends RefCountMessage implements ICoreMessage {
+ private static final class CoreTypedProperties extends TypedProperties {
+
+ // 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 =
+ name -> (name.startsWith(Message.HDR_ROUTE_TO_IDS) &&
!name.equals(Message.HDR_ROUTE_TO_IDS)) ||
+(name.startsWith(Message.HDR_ROUTE_TO_ACK_IDS) &&
!name.equals(Message.HDR_ROUTE_TO_ACK_IDS));
+ private static final SimpleString AMQ_PROPNAME = new
SimpleString("_AMQ_");
+ private boolean internalProperties;
+
+ CoreTypedProperties() {
+ super();
+ internalProperties = false;
+ }
+
+ private CoreTypedProperties(TypedProperties other) {
+ super(other);
+ if (other instanceof CoreTypedProperties) {
+internalProperties = ((CoreTypedProperties)
other).internalProperties;
+ } else {
+internalProperties = other.containsProperty(name ->
name.startsWith(AMQ_PROPNAME));
+ }
+ }
+
+ @Override
+ protected synchronized void doPutValue(SimpleString key,
TypedProperties.PropertyValue value) {
+ if (!internalProperties && key.startsWith(AMQ_PROPNAME)) {
+internalProperties = true;
+ }
+ super.doPutValue(key, value);
+ }
+
+ public synchronized boolean cleanupInternalProperties() {
+ if (!internalProperties) {
+return false;
+ }
+ return removeProperty(INTERNAL_PROPERTY_NAMES_CLEANUP_FILTER);
+ }
+
+ public static boolean cleanupInternalProperties(TypedProperties
typedProperties) {
+ if (typedProperties == null) {
+return false;
+ }
+ if (typedProperties instanceof CoreTypedProperties) {
+return ((CoreTypedProperties)
typedProperties).cleanupInternalProperties();
+ }
+ return
typedProperties.removeProperty(INTERNAL_PROPERTY_NAMES_CLEANUP_FILTER);
+ }
+
+ public static CoreTypedProperties copyOf(TypedProperties
typedProperties) {
+ synchronized (typedProperties) {
--- End diff --
Yep, I was expecting it to be, but reality was that even with that flag it
would fail and will iterate through the properties: the flag was only checking
if *any* internal properties is being put, while the `cleanupInternlProperties`
aim to cleanup just specific internal ones.
> 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-1867) Support FQQN for producers
[
https://issues.apache.org/jira/browse/ARTEMIS-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691406#comment-16691406
]
ASF GitHub Bot commented on ARTEMIS-1867:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2434#discussion_r234532241
--- Diff:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
---
@@ -3178,138 +3187,7 @@ public Queue createQueue(final SimpleString address,
final int consumersBeforeDispatch,
final long delayBeforeDispatch,
final boolean autoCreateAddress) throws
Exception {
- return createQueue(address, routingType, queueName, filterString,
user, durable, temporary, ignoreIfExists, transientQueue, autoCreated,
maxConsumers, purgeOnNoConsumers, exclusive, lastValue, lastValueKey,
nonDestructive, consumersBeforeDispatch, delayBeforeDispatch,
autoCreateAddress, false);
- }
-
- private Queue createQueue(final SimpleString address,
--- End diff --
So afaik, the one being removed is the main one called by bits like config
loader etc and invoked more directly by many other code paths, so it would be
better to remove the other if any IMO.
> Support FQQN for producers
> --
>
> Key: ARTEMIS-1867
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1867
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: STOMP
>Reporter: Justin Bertram
>Priority: Major
>
> Allow STOMP clients to send messages directly to a fully-qualified queue
> rather than just an address.
--
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=16691389#comment-16691389
]
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_r234527890
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -52,6 +52,62 @@
* consumers */
public class CoreMessage extends RefCountMessage implements ICoreMessage {
+ private static final class CoreTypedProperties extends TypedProperties {
+
+ // 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 =
+ name -> (name.startsWith(Message.HDR_ROUTE_TO_IDS) &&
!name.equals(Message.HDR_ROUTE_TO_IDS)) ||
+(name.startsWith(Message.HDR_ROUTE_TO_ACK_IDS) &&
!name.equals(Message.HDR_ROUTE_TO_ACK_IDS));
+ private static final SimpleString AMQ_PROPNAME = new
SimpleString("_AMQ_");
+ private boolean internalProperties;
+
+ CoreTypedProperties() {
+ super();
+ internalProperties = false;
+ }
+
+ private CoreTypedProperties(TypedProperties other) {
+ super(other);
+ if (other instanceof CoreTypedProperties) {
+internalProperties = ((CoreTypedProperties)
other).internalProperties;
+ } else {
+internalProperties = other.containsProperty(name ->
name.startsWith(AMQ_PROPNAME));
+ }
+ }
+
+ @Override
+ protected synchronized void doPutValue(SimpleString key,
TypedProperties.PropertyValue value) {
+ if (!internalProperties && key.startsWith(AMQ_PROPNAME)) {
+internalProperties = true;
+ }
+ super.doPutValue(key, value);
+ }
+
+ public synchronized boolean cleanupInternalProperties() {
+ if (!internalProperties) {
+return false;
+ }
+ return removeProperty(INTERNAL_PROPERTY_NAMES_CLEANUP_FILTER);
+ }
+
+ public static boolean cleanupInternalProperties(TypedProperties
typedProperties) {
+ if (typedProperties == null) {
+return false;
+ }
+ if (typedProperties instanceof CoreTypedProperties) {
+return ((CoreTypedProperties)
typedProperties).cleanupInternalProperties();
+ }
+ return
typedProperties.removeProperty(INTERNAL_PROPERTY_NAMES_CLEANUP_FILTER);
+ }
+
+ public static CoreTypedProperties copyOf(TypedProperties
typedProperties) {
+ synchronized (typedProperties) {
--- End diff --
+1 agreed this would need to be resolved as currently thats why the flag
exist to avoid the iterating over the properties.
> 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)
