[jira] [Updated] (AMQ-7099) After upgrading activemq 5.5.1 to activemq 5.13.1, issues with java.security.Security.insertProviderAt/org.apache.activemq.broker.BrokerService
[ https://issues.apache.org/jira/browse/AMQ-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sunil kumar updated AMQ-7099: - Description: We upgraded activemq 5.5.1 to activemq 5.13.1 to over come the security vulnerable to CVE-2015-5254 and CVE-2014-3612. for ref: here are the links for each CVE: [http://activemq.apache.org/security-advisories.data/CVE-2015-5254-announcement.txt?version=1=1449589734000=v2] [http://activemq.apache.org/security-advisories.data/CVE-2014-3612-announcement.txt?version=2=1423051365000=v2] After upgrading we hit with following issues while getting LDAP user informations . Following are the stack trace : *16:06:07.353 0x33fb300 j9trc_aux.0 - jstacktrace:* *16:06:07.353 0x33fb300 j9trc_aux.1 - [1] java.security.Security.insertProviderAt (Security.java:369)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [2] org.apache.activemq.broker.BrokerService. (BrokerService.java:275)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [3] com.ibm.tivoli.rest.event.amq.AMQPropertiesBrokerFactory.createBroker (AMQPropertiesBrokerFactory.java:30)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [4] org.apache.activemq.broker.BrokerFactory.createBroker (BrokerFactory.java:71)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [5] org.apache.activemq.broker.BrokerFactory.createBroker (BrokerFactory.java:54)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [6] com.ibm.tivoli.rest.event.amq.AMQEventRouterFactory.startBroker (AMQEventRouterFactory.java:430)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [7] com.ibm.tivoli.rest.event.amq.AMQEventRouterFactory.start (AMQEventRouterFactory.java:151)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [8] com.ibm.tivoli.rest.event.EventRouterFactory.getInstance (EventRouterFactory.java:43)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [9] com.ibm.tivoli.rest.amq.AjaxServlet. (AjaxServlet.java:59)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [10] java.lang.J9VMInternals.newInstanceImpl (Native Method)* 16:06:07.353 0x33fb300 j9trc_aux.1 - [11] java.lang.Class.newInstance (Class.java:1843) (Compiled Code) 16:06:07.353 0x33fb300 j9trc_aux.1 - [12] java.beans.Beans.instantiate (Beans.java:240) 16:06:07.353 0x33fb300 j9trc_aux.1 - [13] java.beans.Beans.instantiate (Beans.java:88) 16:06:07.353 0x33fb300 j9trc_aux.1 - [14] com.ibm.ws.webcontainer.servlet.ServletWrapper$1.run (ServletWrapper.java:1489) 16:06:07.353 0x33fb300 j9trc_aux.1 - [15] com.ibm.ws.security.util.AccessController.doPrivileged (AccessController.java:118) (Compiled Code) 16:06:07.353 0x33fb300 j9trc_aux.1 - [16] com.ibm.ws.webcontainer.servlet.ServletWrapper.loadServlet (ServletWrapper.java:1478) 16:06:07.353 0x33fb300 j9trc_aux.1 - [17] com.ibm.ws.webcontainer.servlet.ServletWrapper.loadOnStartupCheck (ServletWrapper.java:1357) 16:06:07.353 0x33fb300 j9trc_aux.1 - [18] com.ibm.ws.webcontainer.webapp.WebApp.doLoadOnStartupActions (WebApp.java:642) 16:06:07.353 0x33fb300 j9trc_aux.1 - [19] com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinally (WebApp.java:608) 16:06:07.353 0x33fb300 j9trc_aux.1 - [20] com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize (WebAppImpl.java:426) 16:06:07.353 0x33fb300 j9trc_aux.1 - [21] com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication (WebGroupImpl.java:88) 16:06:07.353 0x33fb300 j9trc_aux.1 - [22] com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication (VirtualHostImpl.java:171) 16:06:07.353 0x33fb300 j9trc_aux.1 - [23] com.ibm.ws.webcontainer.WSWebContainer.addWebApp (WSWebContainer.java:904) 16:06:07.353 0x33fb300 j9trc_aux.1 - [24] com.ibm.ws.webcontainer.WSWebContainer.addWebApplication (WSWebContainer.java:789) 16:06:07.353 0x33fb300 j9trc_aux.1 - [25] com.ibm.ws.webcontainer.component.WebContainerImpl.install (WebContainerImpl.java:427) 16:06:07.353 0x33fb300 j9trc_aux.1 - [26] com.ibm.ws.webcontainer.component.WebContainerImpl.start (WebContainerImpl.java:719) 16:06:07.353 0x33fb300 j9trc_aux.1 - [27] com.ibm.ws.runtime.component.ApplicationMgrImpl.start (ApplicationMgrImpl.java:1211) 16:06:07.353 0x33fb300 j9trc_aux.1 - [28] com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart (DeployedApplicationImpl.java:1450) 16:06:07.353 0x33fb300 j9trc_aux.1 - [29] com.ibm.ws.runtime.component.DeployedModuleImpl.start (DeployedModuleImpl.java:639) 16:06:07.353 0x33fb300 j9trc_aux.1 - [30] com.ibm.ws.runtime.component.DeployedApplicationImpl.start (DeployedApplicationImpl.java:1032) 16:06:07.353 0x33fb300 j9trc_aux.1 - [31] com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication (ApplicationMgrImpl.java:795) 16:06:07.353 0x33fb300 j9trc_aux.1 - [32] com.ibm.ws.runtime.component.ApplicationMgrImpl$5.run (ApplicationMgrImpl.java:2279) 16:06:07.353 0x33fb300 j9trc_aux.1 - [33] com.ibm.ws.security.auth.ContextManagerImpl.runAs (ContextManagerImpl.java:5572) 16:06:07.353 0x33fb300 j9trc_aux.1 - [34]
[jira] [Created] (AMQ-7099) After upgrading activemq 5.5.1 to activemq 5.13.1, issues with java.security.Security.insertProviderAt/org.apache.activemq.broker.BrokerService
sunil kumar created AMQ-7099: Summary: After upgrading activemq 5.5.1 to activemq 5.13.1, issues with java.security.Security.insertProviderAt/org.apache.activemq.broker.BrokerService Key: AMQ-7099 URL: https://issues.apache.org/jira/browse/AMQ-7099 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.13.1 Environment: OS: All platforms Products involved are : WAS 8.5.5.9 - 8.5.5.14 LDAP/Active directory JazzSM(DASH) 3.1.3 CP5 -CP7 Reporter: sunil kumar We upgraded activemq 5.5.1 to activemq 5.13.1 to over come the security vulnerable to CVE-2015-5254 and CVE-2014-3612. for ref: here are the links for each CVE: http://activemq.apache.org/security-advisories.data/CVE-2015-5254-announcement.txt?version=1=1449589734000=v2 http://activemq.apache.org/security-advisories.data/CVE-2014-3612-announcement.txt?version=2=1423051365000=v2 After upgrading we hit with following issues while getting LDAP user informations . Following are the stack trace : *16:06:07.353 0x33fb300 j9trc_aux.0 - jstacktrace:* *16:06:07.353 0x33fb300 j9trc_aux.1 - [1] java.security.Security.insertProviderAt (Security.java:369)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [2] org.apache.activemq.broker.BrokerService. (BrokerService.java:275)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [3] com.ibm.tivoli.rest.event.amq.AMQPropertiesBrokerFactory.createBroker (AMQPropertiesBrokerFactory.java:30)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [4] org.apache.activemq.broker.BrokerFactory.createBroker (BrokerFactory.java:71)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [5] org.apache.activemq.broker.BrokerFactory.createBroker (BrokerFactory.java:54)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [6] com.ibm.tivoli.rest.event.amq.AMQEventRouterFactory.startBroker (AMQEventRouterFactory.java:430)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [7] com.ibm.tivoli.rest.event.amq.AMQEventRouterFactory.start (AMQEventRouterFactory.java:151)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [8] com.ibm.tivoli.rest.event.EventRouterFactory.getInstance (EventRouterFactory.java:43)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [9] com.ibm.tivoli.rest.amq.AjaxServlet. (AjaxServlet.java:59)* *16:06:07.353 0x33fb300 j9trc_aux.1 - [10] java.lang.J9VMInternals.newInstanceImpl (Native Method)* 16:06:07.353 0x33fb300 j9trc_aux.1 - [11] java.lang.Class.newInstance (Class.java:1843) (Compiled Code) 16:06:07.353 0x33fb300 j9trc_aux.1 - [12] java.beans.Beans.instantiate (Beans.java:240) 16:06:07.353 0x33fb300 j9trc_aux.1 - [13] java.beans.Beans.instantiate (Beans.java:88) 16:06:07.353 0x33fb300 j9trc_aux.1 - [14] com.ibm.ws.webcontainer.servlet.ServletWrapper$1.run (ServletWrapper.java:1489) 16:06:07.353 0x33fb300 j9trc_aux.1 - [15] com.ibm.ws.security.util.AccessController.doPrivileged (AccessController.java:118) (Compiled Code) 16:06:07.353 0x33fb300 j9trc_aux.1 - [16] com.ibm.ws.webcontainer.servlet.ServletWrapper.loadServlet (ServletWrapper.java:1478) 16:06:07.353 0x33fb300 j9trc_aux.1 - [17] com.ibm.ws.webcontainer.servlet.ServletWrapper.loadOnStartupCheck (ServletWrapper.java:1357) 16:06:07.353 0x33fb300 j9trc_aux.1 - [18] com.ibm.ws.webcontainer.webapp.WebApp.doLoadOnStartupActions (WebApp.java:642) 16:06:07.353 0x33fb300 j9trc_aux.1 - [19] com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinally (WebApp.java:608) 16:06:07.353 0x33fb300 j9trc_aux.1 - [20] com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize (WebAppImpl.java:426) 16:06:07.353 0x33fb300 j9trc_aux.1 - [21] com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication (WebGroupImpl.java:88) 16:06:07.353 0x33fb300 j9trc_aux.1 - [22] com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication (VirtualHostImpl.java:171) 16:06:07.353 0x33fb300 j9trc_aux.1 - [23] com.ibm.ws.webcontainer.WSWebContainer.addWebApp (WSWebContainer.java:904) 16:06:07.353 0x33fb300 j9trc_aux.1 - [24] com.ibm.ws.webcontainer.WSWebContainer.addWebApplication (WSWebContainer.java:789) 16:06:07.353 0x33fb300 j9trc_aux.1 - [25] com.ibm.ws.webcontainer.component.WebContainerImpl.install (WebContainerImpl.java:427) 16:06:07.353 0x33fb300 j9trc_aux.1 - [26] com.ibm.ws.webcontainer.component.WebContainerImpl.start (WebContainerImpl.java:719) 16:06:07.353 0x33fb300 j9trc_aux.1 - [27] com.ibm.ws.runtime.component.ApplicationMgrImpl.start (ApplicationMgrImpl.java:1211) 16:06:07.353 0x33fb300 j9trc_aux.1 - [28] com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart (DeployedApplicationImpl.java:1450) 16:06:07.353 0x33fb300 j9trc_aux.1 - [29] com.ibm.ws.runtime.component.DeployedModuleImpl.start (DeployedModuleImpl.java:639) 16:06:07.353 0x33fb300 j9trc_aux.1 - [30] com.ibm.ws.runtime.component.DeployedApplicationImpl.start (DeployedApplicationImpl.java:1032) 16:06:07.353 0x33fb300 j9trc_aux.1 - [31]
[jira] [Commented] (ARTEMIS-1867) Support FQQN in STOMP
[ https://issues.apache.org/jira/browse/ARTEMIS-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687434#comment-16687434 ] ASF GitHub Bot commented on ARTEMIS-1867: - GitHub user jbertram opened a pull request: https://github.com/apache/activemq-artemis/pull/2434 ARTEMIS-1867 FQQN for producers You can merge this pull request into a Git repository by running: $ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-1867-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2434.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 #2434 commit 3248c7c22b470dc213edaa52320460503ca9d3b3 Author: Justin Bertram Date: 2018-11-10T02:17:39Z NO-JIRA de-duplicate createQueue() There were two different but nearly identical implementations of createQueue(). I consolidated these into a single method. There should be no semantic differences. commit 27d7ea59eee90384792c1bd8868715ec44552ede Author: Justin Bertram Date: 2018-11-12T22:05:53Z ARTEMIS-1867 FQQN for producers There's a *slight* semantic change with the behavior of the queue query and binding query to make them consistent with the address query, namely that they will return the name of the queue and the name of the address in every case and the returned names will be not use the FQQN syntax but will be parsed to reflect their actual names in the broker. > Support FQQN in STOMP > - > > 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] (ARTEMIS-1867) Support FQQN for producers
[ https://issues.apache.org/jira/browse/ARTEMIS-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-1867: Summary: Support FQQN for producers (was: Support FQQN in STOMP) > 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-1938) AMQP: Update Qpid JMS (and Netty) and Proton-J to latest
[ https://issues.apache.org/jira/browse/ARTEMIS-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16687142#comment-16687142 ] ASF GitHub Bot commented on ARTEMIS-1938: - GitHub user tabish121 opened a pull request: https://github.com/apache/activemq-artemis/pull/2433 ARTEMIS-1938 Update proton-j to 0.30.0 and Qpid JMS 0.37.0 Update to latest proton-j release and refactor the dispostion code to use the new type enums to better deal with the dispistions. Updates to Qpid JMS 0.37.0 which still uses the current netty 4.1.28.Final dependency. You can merge this pull request into a Git repository by running: $ git pull https://github.com/tabish121/activemq-artemis ARTEMIS-1938-0.30.0 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2433.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 #2433 commit ec35e9c512ca247866f3716f2b86826aafdab576 Author: Timothy Bish Date: 2018-11-14T21:17:00Z ARTEMIS-1938 Update proton-j to 0.30.0 and Qpid JMS 0.37.0 Update to latest proton-j release and refactor the dispostion code to use the new type enums to better deal with the dispistions. Updates to Qpid JMS 0.37.0 which still uses the current netty 4.1.28.Final dependency. > AMQP: Update Qpid JMS (and Netty) and Proton-J to latest > > > Key: ARTEMIS-1938 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1938 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Affects Versions: 2.6.1 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 2.7.0 > > > Update to latest Qpid JMS client release -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2163) Classloading issue if artemis-commons is not in ther same classloader as artemis-client-* or artemis-server
[
https://issues.apache.org/jira/browse/ARTEMIS-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686989#comment-16686989
]
ASF GitHub Bot commented on ARTEMIS-2163:
-
Github user ehsavoie commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2416#discussion_r233576260
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionFactoryImpl.java
---
@@ -982,7 +982,13 @@ protected ConnectorFactory
instantiateConnectorFactory(final String connectorFac
return AccessController.doPrivileged(new
PrivilegedAction() {
@Override
public ConnectorFactory run() {
-return (ConnectorFactory)
ClassloadingUtil.newInstanceFromClassLoader(connectorFactoryClassName);
+ClassLoader cl =
Thread.currentThread().getContextClassLoader();
--- End diff --
done
> Classloading issue if artemis-commons is not in ther same classloader as
> artemis-client-* or artemis-server
> ---
>
> Key: ARTEMIS-2163
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2163
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Broker
>Affects Versions: 2.6.3
>Reporter: Emmanuel Hugonnet
>Priority: Major
>
> The class org.apache.activemq.artemis.utils.ClassLoadingUtil is defined in
> artemis-commons. In a jboss-modules environment this creates a loop to be
> able to load classes from another module.
> Setting the ThreadContext classloader to the calling class before invoking
> ClassLoadingUtil
>
--
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=16686934#comment-16686934
]
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_r233559690
--- 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 --
Of course
> 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-2176) RA connection properties are not propagated to XARecoveryConfig
[ https://issues.apache.org/jira/browse/ARTEMIS-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686880#comment-16686880 ] ASF GitHub Bot commented on ARTEMIS-2176: - Github user clebertsuconic commented on a diff in the pull request: https://github.com/apache/activemq-artemis/pull/2432#discussion_r233540277 --- Diff: artemis-service-extensions/src/main/java/org/apache/activemq/artemis/service/extensions/xa/recovery/XARecoveryConfig.java --- @@ -45,16 +45,41 @@ private final Map properties; private final ClientProtocolManagerFactory clientProtocolManager; + // ServerLocator properties --- End diff -- why you had to bring those here? > RA connection properties are not propagated to XARecoveryConfig > --- > > Key: ARTEMIS-2176 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2176 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Bartosz Spyrko-Smietanko >Priority: Major > > XARecoveryConfig#createServerLocator uses only > TransportConfiguration/DiscoveryGroupConfiguration to create a new instance > of ServerLocator. That means that connection properties like connectionTTL or > callFailoverTime are ignored. This can lead to network issues - eg. > [https://issues.jboss.org/browse/WFLY-10725] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2163) Classloading issue if artemis-commons is not in ther same classloader as artemis-client-* or artemis-server
[
https://issues.apache.org/jira/browse/ARTEMIS-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686879#comment-16686879
]
ASF GitHub Bot commented on ARTEMIS-2163:
-
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2416#discussion_r233539372
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionFactoryImpl.java
---
@@ -982,7 +982,13 @@ protected ConnectorFactory
instantiateConnectorFactory(final String connectorFac
return AccessController.doPrivileged(new
PrivilegedAction() {
@Override
public ConnectorFactory run() {
-return (ConnectorFactory)
ClassloadingUtil.newInstanceFromClassLoader(connectorFactoryClassName);
+ClassLoader cl =
Thread.currentThread().getContextClassLoader();
--- End diff --
@ehsavoie can you amend it then?
> Classloading issue if artemis-commons is not in ther same classloader as
> artemis-client-* or artemis-server
> ---
>
> Key: ARTEMIS-2163
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2163
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Broker
>Affects Versions: 2.6.3
>Reporter: Emmanuel Hugonnet
>Priority: Major
>
> The class org.apache.activemq.artemis.utils.ClassLoadingUtil is defined in
> artemis-commons. In a jboss-modules environment this creates a loop to be
> able to load classes from another module.
> Setting the ThreadContext classloader to the calling class before invoking
> ClassLoadingUtil
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2175) Duplicate messages when JMS bridge is stopped and restarted
[ https://issues.apache.org/jira/browse/ARTEMIS-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686846#comment-16686846 ] ASF subversion and git services commented on ARTEMIS-2175: -- Commit 566ecbb4d29ec7f201bb7f6645252dbc0eb72228 in activemq-artemis's branch refs/heads/2.6.x from [~iweiss] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=566ecbb ] [ARTEMIS-2175] Duplicate messages when JMS bridge is stopped and restarted Issue: https://issues.apache.org/jira/browse/ARTEMIS-2175 (cherry picked from commit ff5f1213bbf3fd2cfd9419ce44a4baf77ed9597f) > Duplicate messages when JMS bridge is stopped and restarted > --- > > Key: ARTEMIS-2175 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2175 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.7.0 >Reporter: Ingo Weiss >Priority: Major > Labels: bridge, jms > > When a JMS bridge is stopped and then restarted, during a short period the > source might quickly try to retransmit a rolled back message outside the > transaction, leading to a duplicate message on the target. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2163) Classloading issue if artemis-commons is not in ther same classloader as artemis-client-* or artemis-server
[
https://issues.apache.org/jira/browse/ARTEMIS-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686858#comment-16686858
]
ASF GitHub Bot commented on ARTEMIS-2163:
-
Github user ehsavoie commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2416#discussion_r233531108
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionFactoryImpl.java
---
@@ -982,7 +982,13 @@ protected ConnectorFactory
instantiateConnectorFactory(final String connectorFac
return AccessController.doPrivileged(new
PrivilegedAction() {
@Override
public ConnectorFactory run() {
-return (ConnectorFactory)
ClassloadingUtil.newInstanceFromClassLoader(connectorFactoryClassName);
+ClassLoader cl =
Thread.currentThread().getContextClassLoader();
--- End diff --
No problem there
> Classloading issue if artemis-commons is not in ther same classloader as
> artemis-client-* or artemis-server
> ---
>
> Key: ARTEMIS-2163
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2163
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Broker
>Affects Versions: 2.6.3
>Reporter: Emmanuel Hugonnet
>Priority: Major
>
> The class org.apache.activemq.artemis.utils.ClassLoadingUtil is defined in
> artemis-commons. In a jboss-modules environment this creates a loop to be
> able to load classes from another module.
> Setting the ThreadContext classloader to the calling class before invoking
> ClassLoadingUtil
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2174) Broker reconnect to another with scale down policy cause OOM
[ https://issues.apache.org/jira/browse/ARTEMIS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686852#comment-16686852 ] ASF subversion and git services commented on ARTEMIS-2174: -- Commit 173b21e6e23828f595ff9101e043071e69d9aa8a in activemq-artemis's branch refs/heads/2.6.x from [~gaohoward] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=173b21e ] ARTEMIS-2174 Broker reconnect cause OOM with scale down When a node tries to reconnects to another node in a scale down cluster, the reconnect request gets denied by the other node and keeps retrying, which causes tasks in the ordered executor accumulate and eventually OOM. The fix is to change the ActiveMQPacketHandler#handleCheckForFailover to allow reconnect if the scale down node is the node itself. (cherry picked from commit 6e89b22eaae8cd82852ae3d0a643bb3502cf994c) > Broker reconnect to another with scale down policy cause OOM > > > Key: ARTEMIS-2174 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2174 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.6.4 > > > When a node tries to reconnects to another node in a scale down cluster, the > reconnect request gets denied by the other node and keeps retrying, which > causes tasks in the ordered executor accumulate and eventually OOM. > To reproduce: > # Start 2 nodes (node1 and 2) cluster configured in scale down mode. > # stop node2 and restart it. > # node1 will try to reconnect to node2 repeatedly and ever succeed. > # Inspect the connecting ClientSessionFactory (like adding log) and its > threadpool (closeExecutor an object of OrderedExecutor) keeps adding tasks to > its queue. > Over the time the queue keeps ever growing, and will exhaust the heap memory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2175) Duplicate messages when JMS bridge is stopped and restarted
[ https://issues.apache.org/jira/browse/ARTEMIS-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686847#comment-16686847 ] ASF subversion and git services commented on ARTEMIS-2175: -- Commit 566ecbb4d29ec7f201bb7f6645252dbc0eb72228 in activemq-artemis's branch refs/heads/2.6.x from [~iweiss] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=566ecbb ] [ARTEMIS-2175] Duplicate messages when JMS bridge is stopped and restarted Issue: https://issues.apache.org/jira/browse/ARTEMIS-2175 (cherry picked from commit ff5f1213bbf3fd2cfd9419ce44a4baf77ed9597f) > Duplicate messages when JMS bridge is stopped and restarted > --- > > Key: ARTEMIS-2175 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2175 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.7.0 >Reporter: Ingo Weiss >Priority: Major > Labels: bridge, jms > > When a JMS bridge is stopped and then restarted, during a short period the > source might quickly try to retransmit a rolled back message outside the > transaction, leading to a duplicate message on the target. -- 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=16686843#comment-16686843
]
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_r233526079
--- 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 --
You can't put a synchronized before the call to `super(other)`, that's why
I have used a factory: if I will drop `CoreTypedProperties` all of this will
disappear right?
> 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=16686825#comment-16686825
]
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_r233520960
--- 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;
--- End diff --
I have used a static factory on this same class to do 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=16686813#comment-16686813
]
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_r233518660
--- 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 --
this shouldnt be needed, as the constructor of CoreTypedProperties that
takes TypedProperties should really be the thing that ensure syncronicitity
> 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=16686822#comment-16686822
]
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_r233520221
--- 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;
--- End diff --
CoreTypedProperties is not sync safe due to direct access to
((CoreTypedProperties) other).internalProperties;
Best solution is to create a private syncronized get method to access
internalProperties from the other variable. This then means sync bloc in copyOf
method is not needed and this constructor becomes sync safe.
> 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-2176) RA connection properties are not propagated to XARecoveryConfig
[ https://issues.apache.org/jira/browse/ARTEMIS-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686815#comment-16686815 ] ASF GitHub Bot commented on ARTEMIS-2176: - GitHub user spyrkob opened a pull request: https://github.com/apache/activemq-artemis/pull/2432 [ARTEMIS-2176] RA connection properties are not propagated to XARecov… …eryConfig Possible fix and test for https://issues.apache.org/jira/browse/ARTEMIS-2176 You can merge this pull request into a Git repository by running: $ git pull https://github.com/spyrkob/jboss-activemq-artemis ARTEMIS-2176 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2432.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 #2432 commit 96b3d87be7448626ad777ea3b32a185c0fb3b5f3 Author: Bartosz Spyrko-Smietanko Date: 2018-11-13T15:50:33Z [ARTEMIS-2176] RA connection properties are not propagated to XARecoveryConfig > RA connection properties are not propagated to XARecoveryConfig > --- > > Key: ARTEMIS-2176 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2176 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Bartosz Spyrko-Smietanko >Priority: Major > > XARecoveryConfig#createServerLocator uses only > TransportConfiguration/DiscoveryGroupConfiguration to create a new instance > of ServerLocator. That means that connection properties like connectionTTL or > callFailoverTime are ignored. This can lead to network issues - eg. > [https://issues.jboss.org/browse/WFLY-10725] -- 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=16686793#comment-16686793
]
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_r233513734
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -564,34 +604,59 @@ public CoreMessage setUserID(UUID userID) {
/**
* I am keeping this synchronized as the decode of the Properties is
lazy
*/
- protected TypedProperties checkProperties() {
+ protected final TypedProperties checkProperties() {
try {
+ TypedProperties properties = this.properties;
if (properties == null) {
-synchronized (this) {
- if (properties == null) {
- TypedProperties properties = new TypedProperties();
- if (buffer != null && propertiesLocation >= 0) {
- final ByteBuf byteBuf =
buffer.duplicate().readerIndex(propertiesLocation);
- properties.decode(byteBuf, coreMessageObjectPools ==
null ? null : coreMessageObjectPools.getPropertiesDecoderPools());
- }
- this.properties = properties;
- }
+properties = getOrInitializeTypedProperties();
+ }
+ return properties;
+ } catch (Throwable e) {
+ throw onCheckPropertiesError(e);
--- End diff --
this MUST throw the original exception if such exception, to keep exception
behaviour of any code upstream that maybe catching specific exceptions..
> 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=16686809#comment-16686809
]
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_r233517904
--- 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) {
--- End diff --
synchronize on other.
> 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-2104) Implement tests for Import/Export (replay) of messages
[ https://issues.apache.org/jira/browse/ARTEMIS-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686802#comment-16686802 ] ASF subversion and git services commented on ARTEMIS-2104: -- Commit 26df390fbc46b45689169951caae7ea0735883a9 in activemq-artemis's branch refs/heads/2.6.x from feuillemorte [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=26df390 ] ARTEMIS-2104 Added tests in artemis-cli//MessageSerializerTest Added new cases: - export from anycast queue, then import to multicast topic where number of queues > 1 - export from anycast queue, then import to multicast fqqn where number of queues > 1 - export from multicast topic, then import to anycast queue (both address) - export from anycast queue, then import to multicast topic (both address) (cherry picked from commit be9676c0d397384bd2ab647311fcd19729cb080a) > Implement tests for Import/Export (replay) of messages > -- > > Key: ARTEMIS-2104 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2104 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Broker >Reporter: Oleg Sushchenko >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2108) Potential StackOverflowError when load balancing disabled
[ https://issues.apache.org/jira/browse/ARTEMIS-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686800#comment-16686800 ] ASF subversion and git services commented on ARTEMIS-2108: -- Commit 773721f7b028754c39e441aa9372dc614f31ce47 in activemq-artemis's branch refs/heads/2.6.x from Justin Bertram [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=773721f ] ARTEMIS-2108 fix another potential StackOverflow (cherry picked from commit f4396da9fd9f7ecc7d9c0b02118d1eb1b76af523) > Potential StackOverflowError when load balancing disabled > - > > Key: ARTEMIS-2108 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2108 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > It's possible that when a cluster has disabled message load balancing then a > message sent to a node that only has a corresponding remote queue binding > will trigger a stack overflow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1825) Live-backup topology not correctly displayed on console
[ https://issues.apache.org/jira/browse/ARTEMIS-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686797#comment-16686797 ] ASF subversion and git services commented on ARTEMIS-1825: -- Commit 59300713a7e994c05d72cc4e5c03fdacc8b5a50c in activemq-artemis's branch refs/heads/2.6.x from [~gaohoward] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=5930071 ] ARTEMIS-1825 Live-backup topology not correctly displayed on console (cherry picked from commit ae320c14a5db988f410242e44b9d6e5438c7914c) > Live-backup topology not correctly displayed on console > --- > > Key: ARTEMIS-1825 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1825 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.5.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.7.0 > > > The backup's web console doesn't correctly shows the topology diagram of > live-backup pair. It points to itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2127) Add auth details to consumer created notification
[ https://issues.apache.org/jira/browse/ARTEMIS-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686790#comment-16686790 ] ASF subversion and git services commented on ARTEMIS-2127: -- Commit 3105d01bb358779bf8a43e5120099a9a90ee145b 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=3105d01 ] ARTEMIS-2127 Add auth details to consumer created notification (cherry picked from commit c2188aa058a2f6aae65ca2247c14c7b968faaf56) > Add auth details to consumer created notification > - > > Key: ARTEMIS-2127 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2127 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Minor > -- 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=16686787#comment-16686787
]
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_r233513078
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -564,34 +604,59 @@ public CoreMessage setUserID(UUID userID) {
/**
* I am keeping this synchronized as the decode of the Properties is
lazy
*/
- protected TypedProperties checkProperties() {
+ protected final TypedProperties checkProperties() {
try {
+ TypedProperties properties = this.properties;
if (properties == null) {
-synchronized (this) {
- if (properties == null) {
- TypedProperties properties = new TypedProperties();
- if (buffer != null && propertiesLocation >= 0) {
- final ByteBuf byteBuf =
buffer.duplicate().readerIndex(propertiesLocation);
- properties.decode(byteBuf, coreMessageObjectPools ==
null ? null : coreMessageObjectPools.getPropertiesDecoderPools());
- }
- this.properties = properties;
- }
+properties = getOrInitializeTypedProperties();
+ }
+ return properties;
+ } catch (Throwable e) {
+ throw onCheckPropertiesError(e);
+ }
+ }
+
+ private TypedProperties getOrInitializeTypedProperties() {
+ synchronized (this) {
+ TypedProperties properties = this.properties;
+ if (properties == null) {
+properties = createTypedProperties();
+if (buffer != null && propertiesLocation >= 0) {
+ final ByteBuf byteBuf =
buffer.duplicate().readerIndex(propertiesLocation);
+ properties.decode(byteBuf, coreMessageObjectPools == null ?
null : coreMessageObjectPools.getPropertiesDecoderPools());
}
+this.properties = properties;
}
+ return properties;
+ }
+ }
- return this.properties;
- } catch (Throwable e) {
- ByteBuf duplicatebuffer = buffer.duplicate();
- duplicatebuffer.readerIndex(0);
+ private RuntimeException onCheckPropertiesError(Throwable e) {
+ ByteBuf duplicatebuffer = buffer.duplicate();
+ duplicatebuffer.readerIndex(0);
- // This is not an expected error, hence no specific logger created
- logger.warn("Could not decode properties for
CoreMessage[messageID=" + messageID + ",durable=" + durable + ",userID=" +
userID + ",priority=" + priority +
-", timestamp=" + timestamp + ",expiration=" + expiration +
",address=" + address + ", propertiesLocation=" + propertiesLocation, e);
- logger.warn("Failed message has messageID=" + messageID + " and
the following buffer:\n" + ByteBufUtil.prettyHexDump(duplicatebuffer));
+ // This is not an expected error, hence no specific logger created
+ logger.warn("Could not decode properties for CoreMessage[messageID="
+ messageID + ",durable=" + durable + ",userID=" + userID + ",priority=" +
priority +
+ ", timestamp=" + timestamp + ",expiration=" +
expiration + ",address=" + address + ", propertiesLocation=" +
propertiesLocation, e);
+ logger.warn("Failed message has messageID=" + messageID + " and the
following buffer:\n" + ByteBufUtil.prettyHexDump(duplicatebuffer));
- throw new RuntimeException(e.getMessage(), e);
+ return new RuntimeException(e.getMessage(), e);
--- End diff --
This really should throw the original exception, dont wrap it into
something else, incase other code was catching something explicit.
> 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
[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=16686782#comment-16686782
]
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_r233512044
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -564,34 +604,59 @@ public CoreMessage setUserID(UUID userID) {
/**
* I am keeping this synchronized as the decode of the Properties is
lazy
*/
- protected TypedProperties checkProperties() {
+ protected final TypedProperties checkProperties() {
try {
+ TypedProperties properties = this.properties;
if (properties == null) {
-synchronized (this) {
- if (properties == null) {
- TypedProperties properties = new TypedProperties();
- if (buffer != null && propertiesLocation >= 0) {
- final ByteBuf byteBuf =
buffer.duplicate().readerIndex(propertiesLocation);
- properties.decode(byteBuf, coreMessageObjectPools ==
null ? null : coreMessageObjectPools.getPropertiesDecoderPools());
- }
- this.properties = properties;
- }
+properties = getOrInitializeTypedProperties();
+ }
+ return properties;
+ } catch (Throwable e) {
+ throw onCheckPropertiesError(e);
+ }
+ }
+
+ private TypedProperties getOrInitializeTypedProperties() {
--- End diff --
i would rename "checkProperties" to "getProperties", and i would call this
initalizeTypedProperties without the return.
> 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-1850) QueueControl.listDeliveringMessages returns empty result
[ https://issues.apache.org/jira/browse/ARTEMIS-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686756#comment-16686756 ] ASF subversion and git services commented on ARTEMIS-1850: -- Commit dea166ab83287ed15dba799aa9ed5effac75d416 in activemq-artemis's branch refs/heads/2.6.x from [~gaohoward] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=dea166a ] ARTEMIS-1850 QueueControl.listDeliveringMessages returns empty result With AMQP protocol when some messages are received in a transaction, calling JMX QueueControl.listDeliveringMessages() returns empty list before the transaction is committed. (cherry picked from commit 72eadb201d870b097c8659497823f27bf2401d6f) > QueueControl.listDeliveringMessages returns empty result > > > Key: ARTEMIS-1850 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1850 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.5.0 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.6.4 > > > With AMQP protocol when some messages are received in a transaction, calling > JMX QueueControl.listDeliveringMessages() returns empty list before the > transaction is committed. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2176) RA connection properties are not propagated to XARecoveryConfig
Bartosz Spyrko-Smietanko created ARTEMIS-2176: - Summary: RA connection properties are not propagated to XARecoveryConfig Key: ARTEMIS-2176 URL: https://issues.apache.org/jira/browse/ARTEMIS-2176 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.6.3 Reporter: Bartosz Spyrko-Smietanko XARecoveryConfig#createServerLocator uses only TransportConfiguration/DiscoveryGroupConfiguration to create a new instance of ServerLocator. That means that connection properties like connectionTTL or callFailoverTime are ignored. This can lead to network issues - eg. [https://issues.jboss.org/browse/WFLY-10725] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2125) Queue preference changes to display columns not persistent through page refresh
[ https://issues.apache.org/jira/browse/ARTEMIS-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686770#comment-16686770 ] ASF subversion and git services commented on ARTEMIS-2125: -- Commit 48b090afd7032c6a3bb3096a35849b2160a7be36 in activemq-artemis's branch refs/heads/2.6.x from feuillemorte [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=48b090a ] ARTEMIS-2125 Tabs preference changes to display columns not persistent through page refresh (cherry picked from commit a65e711fbcca19d7da043ac1f7151722ca99190f) > Queue preference changes to display columns not persistent through page > refresh > --- > > Key: ARTEMIS-2125 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2125 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.6.3 >Reporter: Tadayoshi Sato >Assignee: Francesco Nigro >Priority: Major > > When using the Hawtio web console, we change the default column list in > Queues using the arrow in the top right-hand corner. The change in which > columns to display does not persist when the page is refreshed, nor does it > persist if the page is added to a Dashboard. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2175) Duplicate messages when JMS bridge is stopped and restarted
[ https://issues.apache.org/jira/browse/ARTEMIS-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686747#comment-16686747 ] ASF subversion and git services commented on ARTEMIS-2175: -- Commit ff5f1213bbf3fd2cfd9419ce44a4baf77ed9597f in activemq-artemis's branch refs/heads/master from [~iweiss] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=ff5f121 ] [ARTEMIS-2175] Duplicate messages when JMS bridge is stopped and restarted Issue: https://issues.apache.org/jira/browse/ARTEMIS-2175 > Duplicate messages when JMS bridge is stopped and restarted > --- > > Key: ARTEMIS-2175 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2175 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.7.0 >Reporter: Ingo Weiss >Priority: Major > Labels: bridge, jms > > When a JMS bridge is stopped and then restarted, during a short period the > source might quickly try to retransmit a rolled back message outside the > transaction, leading to a duplicate message on the target. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1710) Allow for management messages to exceed global-max-size limit
[ https://issues.apache.org/jira/browse/ARTEMIS-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686767#comment-16686767 ] ASF subversion and git services commented on ARTEMIS-1710: -- Commit f79ab66d0ddd178167b2b0adf00d53ba1602756b in activemq-artemis's branch refs/heads/2.6.x from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=f79ab66 ] ARTEMIS-1710 Allow for management msgs to exceed global-max-size limit Added docs to explain the behaviour of management addresses on paging (cherry picked from commit 075a4024dfab01469bfec6eacc3b55501b0e0080) > Allow for management messages to exceed global-max-size limit > - > > Key: ARTEMIS-1710 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1710 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Ulf Lilleengen >Assignee: Francesco Nigro >Priority: Major > > Use case: global-max-size is set to some limit to prevent the broker from > falling over. The broker is configured with N queues which are all blocked by > this limit. > If this limit is reached, however, it is not possible to perform management > operations on the broker, so you're stuck. > > It should be possible to have an address like 'activemq.management' bypass > this limit so that a broker can be recovered when the global-max-size is > reached. > > To work around the problem, an external component needs to ensure that all > addresses created have a max-size-bytes set so that worst case, there is some > room left for 'activemq.management' address. In this case the broker > configuration needs to be known by the component creating addresses which is > impractical and it feels like this problem would be easier to solve inside > the broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2140) AMQP Shared Subscriptions fail because of RaceCondition
[
https://issues.apache.org/jira/browse/ARTEMIS-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686751#comment-16686751
]
ASF subversion and git services commented on ARTEMIS-2140:
--
Commit e81453e6608ce70436576f1ed54b1f62d30ddc2e in activemq-artemis's branch
refs/heads/master from [~jbertram]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=e81453e ]
ARTEMIS-2140 queue creation race w/AMQP shared subs
> AMQP Shared Subscriptions fail because of RaceCondition
> ---
>
> Key: ARTEMIS-2140
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2140
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.6.3
>Reporter: Johan Stenberg
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.7.0, 2.6.4
>
> Attachments: Artemis2140_AmqpSharedConsumerRaceConditionTest.java
>
>
> When multiple clients concurrently try to subscribe to the same shared
> subscription the following exception occurs:
> {noformat}
> Okt 19, 2018 4:25:21 PM
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler
> dispatch
> WARN: AMQ119018: Binding already exists LocalQueueBinding
> [address=topics.cat, queue=QueueImpl[name=nonDurable.MY_SUB,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=cf020fcf-d3aa-11e8-ac61-54524514640f],
> temp=false]@6425eba3, filter=null, name=nonDurable.MY_SUB,
> clusterName=nonDurable.MY_SUBcf020fcf-d3aa-11e8-ac61-54524514640f]
> ActiveMQQueueExistsException[errorType=QUEUE_EXISTS message=AMQ119018:
> Binding already exists LocalQueueBinding [address=topics.cat,
> queue=QueueImpl[name=nonDurable.MY_SUB, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=cf020fcf-d3aa-11e8-ac61-54524514640f],
> temp=false]@6425eba3, filter=null, name=nonDurable.MY_SUB,
> clusterName=nonDurable.MY_SUBcf020fcf-d3aa-11e8-ac61-54524514640f]]
> at
> org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:85)
> at
> org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:90)
> at
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:615)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2818)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1690)
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:594)
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:634)
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.createSharedVolatileQueue(AMQPSessionCallback.java:283)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.initialise(ProtonServerSenderContext.java:374)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPSessionContext.addSender(AMQPSessionContext.java:168)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.remoteLinkOpened(AMQPConnectionContext.java:243)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.onRemoteOpen(AMQPConnectionContext.java:462)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.Events.dispatch(Events.java:68)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:494)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:307)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:272)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:158)
> at
> org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:147)
> at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:643)
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at
>
[jira] [Commented] (ARTEMIS-2140) AMQP Shared Subscriptions fail because of RaceCondition
[
https://issues.apache.org/jira/browse/ARTEMIS-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686752#comment-16686752
]
ASF GitHub Bot commented on ARTEMIS-2140:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2426
> AMQP Shared Subscriptions fail because of RaceCondition
> ---
>
> Key: ARTEMIS-2140
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2140
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.6.3
>Reporter: Johan Stenberg
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.7.0, 2.6.4
>
> Attachments: Artemis2140_AmqpSharedConsumerRaceConditionTest.java
>
>
> When multiple clients concurrently try to subscribe to the same shared
> subscription the following exception occurs:
> {noformat}
> Okt 19, 2018 4:25:21 PM
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler
> dispatch
> WARN: AMQ119018: Binding already exists LocalQueueBinding
> [address=topics.cat, queue=QueueImpl[name=nonDurable.MY_SUB,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=cf020fcf-d3aa-11e8-ac61-54524514640f],
> temp=false]@6425eba3, filter=null, name=nonDurable.MY_SUB,
> clusterName=nonDurable.MY_SUBcf020fcf-d3aa-11e8-ac61-54524514640f]
> ActiveMQQueueExistsException[errorType=QUEUE_EXISTS message=AMQ119018:
> Binding already exists LocalQueueBinding [address=topics.cat,
> queue=QueueImpl[name=nonDurable.MY_SUB, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=cf020fcf-d3aa-11e8-ac61-54524514640f],
> temp=false]@6425eba3, filter=null, name=nonDurable.MY_SUB,
> clusterName=nonDurable.MY_SUBcf020fcf-d3aa-11e8-ac61-54524514640f]]
> at
> org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:85)
> at
> org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:90)
> at
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:615)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2818)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1690)
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:594)
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:634)
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.createSharedVolatileQueue(AMQPSessionCallback.java:283)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.initialise(ProtonServerSenderContext.java:374)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPSessionContext.addSender(AMQPSessionContext.java:168)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.remoteLinkOpened(AMQPConnectionContext.java:243)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.onRemoteOpen(AMQPConnectionContext.java:462)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.Events.dispatch(Events.java:68)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.dispatch(ProtonHandler.java:494)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.flush(ProtonHandler.java:307)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.handler.ProtonHandler.inputBuffer(ProtonHandler.java:272)
> at
> org.apache.activemq.artemis.protocol.amqp.proton.AMQPConnectionContext.inputBuffer(AMQPConnectionContext.java:158)
> at
> org.apache.activemq.artemis.protocol.amqp.broker.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:147)
> at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:643)
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434)
> at
>
[jira] [Commented] (ARTEMIS-2175) Duplicate messages when JMS bridge is stopped and restarted
[ https://issues.apache.org/jira/browse/ARTEMIS-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686748#comment-16686748 ] ASF subversion and git services commented on ARTEMIS-2175: -- Commit ff5f1213bbf3fd2cfd9419ce44a4baf77ed9597f in activemq-artemis's branch refs/heads/master from [~iweiss] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=ff5f121 ] [ARTEMIS-2175] Duplicate messages when JMS bridge is stopped and restarted Issue: https://issues.apache.org/jira/browse/ARTEMIS-2175 > Duplicate messages when JMS bridge is stopped and restarted > --- > > Key: ARTEMIS-2175 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2175 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.7.0 >Reporter: Ingo Weiss >Priority: Major > Labels: bridge, jms > > When a JMS bridge is stopped and then restarted, during a short period the > source might quickly try to retransmit a rolled back message outside the > transaction, leading to a duplicate message on the target. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2142) Support JMSXGroupSeq -1 to close/reset Groups
[ https://issues.apache.org/jira/browse/ARTEMIS-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686750#comment-16686750 ] ASF GitHub Bot commented on ARTEMIS-2142: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2424 @clebertsuconic this is the patch fix that can easily goto 2.6.x branch or any HF branches people may keep them selves. > Support JMSXGroupSeq -1 to close/reset Groups > - > > Key: ARTEMIS-2142 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2142 > Project: ActiveMQ Artemis > Issue Type: Sub-task >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Support Closing groups as per ActiveMQ 5 , > [http://activemq.apache.org/message-groups.html] using -1 on groupsequence to > as the signal -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7080) Keep track of free pages - Update db.free file during checkpoints
[
https://issues.apache.org/jira/browse/AMQ-7080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-7080:
Fix Version/s: (was: 5.15.8)
> Keep track of free pages - Update db.free file during checkpoints
> -
>
> Key: AMQ-7080
> URL: https://issues.apache.org/jira/browse/AMQ-7080
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0
>
> Attachments: AMQ-7080-freeList-update.diff
>
>
> In a event of an unclean shutdown, Activemq loses the information about the
> free pages in the index. In order to recover this information, ActiveMQ read
> the whole index during shutdown searching for free pages and then save the
> db.free file. This operation can take a long time, making the failover
> slower. (during the shutdown, activemq will still hold the lock).
> From http://activemq.apache.org/shared-file-system-master-slave.html
> {quote}"If you have a SAN or shared file system it can be used to provide
> high availability such that if a broker is killed, another broker can take
> over immediately."
> {quote}
> Is important to note if the shutdown takes more than ACTIVEMQ_KILL_MAXSECONDS
> seconds, any following shutdown will be unclean. This broker will stay in
> this state unless the index is deleted (this state means that every failover
> will take more then ACTIVEMQ_KILL_MAXSECONDS, so, if you increase this time
> to 5 minutes, you fail over can take more than 5 minutes).
>
> In order to prevent ActiveMQ reading the whole index file to search for free
> pages, we can keep track of those on every Checkpoint. In order to do that we
> need to be sure that db.data and db.free are in sync. To achieve that we can
> have a attribute in the db.free page that is referenced by the db.data.
> So during the checkpoint we have:
> 1 - Save db.free and give a freePageUniqueId
> 2 - Save this freePageUniqueId in the db.data (metadata)
> In a crash, we can see if the db.data has the same freePageUniqueId as the
> db.free. If this is the case we can safely use the free page information
> contained in the db.free
> Now, the only way to read the whole index file again is IF the crash happens
> btw step 1 and 2 (what is very unlikely).
> The drawback of this implementation is that we will have to save db.free
> during the checkpoint, what can possibly increase the checkpoint time.
> Is also important to note that we CAN (and should) have stale data in db.free
> as it is referencing stale db.data:
> Imagine the timeline:
> T0 -> P1, P2 and P3 are free.
> T1 -> Checkpoint
> T2 -> P1 got occupied.
> T3 -> Crash
> In the current scenario after the Pagefile#load the P1 will be free and then
> the replay will mark P1 as occupied or will occupied another page (now that
> the recovery of free pages is done on shutdown)
> This change only make sure that db.data and db.free are in sync and showing
> the reality in T1 (checkpoint), If they are in sync we can trust the db.free.
> This is a really fast draft of what i'm suggesting... If you guys agree, i
> can create the proper patch after:
> [https://github.com/alanprot/activemq/commit/18036ef7214ef0eaa25c8650f40644dd8b4632a5]
>
> This is related to https://issues.apache.org/jira/browse/AMQ-6590
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2142) Support JMSXGroupSeq -1 to close/reset Groups
[ https://issues.apache.org/jira/browse/ARTEMIS-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686742#comment-16686742 ] ASF GitHub Bot commented on ARTEMIS-2142: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2425 The idea is https://github.com/apache/activemq-artemis/pull/2424 was the bare minimum fix path, so it would goto HF, or if you're maintaining some private fork ;) you'd use that, and this PR was a fuller refactor but stays in master. > Support JMSXGroupSeq -1 to close/reset Groups > - > > Key: ARTEMIS-2142 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2142 > Project: ActiveMQ Artemis > Issue Type: Sub-task >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Support Closing groups as per ActiveMQ 5 , > [http://activemq.apache.org/message-groups.html] using -1 on groupsequence to > as the signal -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7093) KahaDB index, recover free pages in parallel with start (Continued)
[ https://issues.apache.org/jira/browse/AMQ-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686711#comment-16686711 ] Christopher L. Shannon commented on AMQ-7093: - [~alanprot] - Yep, we figured it out at the same time :) I merged it in so I can continue with the release now > KahaDB index, recover free pages in parallel with start (Continued) > --- > > Key: AMQ-7093 > URL: https://issues.apache.org/jira/browse/AMQ-7093 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.7 >Reporter: Jeff Genender >Priority: Major > Fix For: 5.16.0, 5.15.8 > > > AMQ-7082 was implemented to create a concurrent thread to handle the free > page recovery. It was included as a part of 5.15.7. There was some > additional add-on coding that was not a part of that release which had > introduced some potential bugs. This was made to track the additional > commits for this. -- 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=16686714#comment-16686714
]
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_r233496401
--- Diff:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/collections/TypedProperties.java
---
@@ -318,6 +320,33 @@ public synchronized boolean containsProperty(final
SimpleString key) {
}
}
+ public synchronized boolean
cleanupInternalProperties(Predicate propertyNamePredicate) {
+ if (!internalProperties) {
--- End diff --
tbh id rather we do one refactor. so +1 for me.
> 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-7084) Kahadb pagefile, allocated and unused pages from read only transactions are leaked
[ https://issues.apache.org/jira/browse/AMQ-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686706#comment-16686706 ] ASF subversion and git services commented on AMQ-7084: -- Commit deb87353c41a4bef41346d27b8c7ad4c1ab21bef in activemq's branch refs/heads/activemq-5.15.x from gtully [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=deb8735 ] AMQ-7084 - ensure allocated and unused free pages are visible to subsequent transactions, fix and test with test updates to reflect proper usage (cherry picked from commit 8a1abd9bb2744de70af11053f1755116c40ec55f) > Kahadb pagefile, allocated and unused pages from read only transactions are > leaked > -- > > Key: AMQ-7084 > URL: https://issues.apache.org/jira/browse/AMQ-7084 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > The work in AMQ-7080 to checkpoint the free list has identified a case where > the free list is not updated to reflect the disk state of an allocated free > page. This can lead to a free page leak in error. In practice this pattern of > usage is not widely used, but it is relevant when the free page list is being > tracked and failure can be arbitrary. It is important that an accurate > reflection of the current state is being checkpointed. -- 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=16686720#comment-16686720
]
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_r233497082
--- 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 {
--- End diff --
I think go for broke, if youre doing a refactor, just to it all :).
> 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=16686679#comment-16686679
]
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_r233491522
--- 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 {
--- End diff --
I have maintained the original logic and consistency with this PR, but we
can just cleaning them without checking their presence too making a lot more
simpler everything
> 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=16686712#comment-16686712
]
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_r233496010
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -564,34 +604,59 @@ public CoreMessage setUserID(UUID userID) {
/**
* I am keeping this synchronized as the decode of the Properties is
lazy
*/
- protected TypedProperties checkProperties() {
+ protected final TypedProperties checkProperties() {
try {
+ TypedProperties properties = this.properties;
if (properties == null) {
-synchronized (this) {
- if (properties == null) {
- TypedProperties properties = new TypedProperties();
- if (buffer != null && propertiesLocation >= 0) {
- final ByteBuf byteBuf =
buffer.duplicate().readerIndex(propertiesLocation);
- properties.decode(byteBuf, coreMessageObjectPools ==
null ? null : coreMessageObjectPools.getPropertiesDecoderPools());
- }
- this.properties = properties;
- }
+properties = getOrInitializeTypedProperties();
+ }
+ return properties;
+ } catch (Throwable e) {
+ throw onCheckPropertiesError(e);
+ }
+ }
+
+ private TypedProperties getOrInitializeTypedProperties() {
+ synchronized (this) {
--- End diff --
if youre separating this to its own method, which is nice +1, theres an
extra trick which is to change from sync block to sync method, which will be
marginally faster.
> 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-7093) KahaDB index, recover free pages in parallel with start (Continued)
[ https://issues.apache.org/jira/browse/AMQ-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686709#comment-16686709 ] Christopher L. Shannon commented on AMQ-7093: - Nevermind, I figured it out. We were missing the commit for https://issues.apache.org/jira/browse/AMQ-7084 > KahaDB index, recover free pages in parallel with start (Continued) > --- > > Key: AMQ-7093 > URL: https://issues.apache.org/jira/browse/AMQ-7093 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.7 >Reporter: Jeff Genender >Priority: Major > Fix For: 5.16.0, 5.15.8 > > > AMQ-7082 was implemented to create a concurrent thread to handle the free > page recovery. It was included as a part of 5.15.7. There was some > additional add-on coding that was not a part of that release which had > introduced some potential bugs. This was made to track the additional > commits for this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7084) Kahadb pagefile, allocated and unused pages from read only transactions are leaked
[ https://issues.apache.org/jira/browse/AMQ-7084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-7084: Fix Version/s: 5.15.8 > Kahadb pagefile, allocated and unused pages from read only transactions are > leaked > -- > > Key: AMQ-7084 > URL: https://issues.apache.org/jira/browse/AMQ-7084 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0, 5.15.8 > > > The work in AMQ-7080 to checkpoint the free list has identified a case where > the free list is not updated to reflect the disk state of an allocated free > page. This can lead to a free page leak in error. In practice this pattern of > usage is not widely used, but it is relevant when the free page list is being > tracked and failure can be arbitrary. It is important that an accurate > reflection of the current state is being checkpointed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7093) KahaDB index, recover free pages in parallel with start (Continued)
[ https://issues.apache.org/jira/browse/AMQ-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686707#comment-16686707 ] Alan Protasio commented on AMQ-7093: [~cshannon] Probably is this change: https://github.com/apache/activemq/commit/8a1abd9bb2744de70af11053f1755116c40ec55f > KahaDB index, recover free pages in parallel with start (Continued) > --- > > Key: AMQ-7093 > URL: https://issues.apache.org/jira/browse/AMQ-7093 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.7 >Reporter: Jeff Genender >Priority: Major > Fix For: 5.16.0, 5.15.8 > > > AMQ-7082 was implemented to create a concurrent thread to handle the free > page recovery. It was included as a part of 5.15.7. There was some > additional add-on coding that was not a part of that release which had > introduced some potential bugs. This was made to track the additional > commits for this. -- 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=16686698#comment-16686698
]
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_r233493524
--- 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() {
--- End diff --
again is this really public, should this only be invokable by CoreMessage
> 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=16686695#comment-16686695
]
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_r233493239
--- 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) {
--- End diff --
is this really public?
> 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-2174) Broker reconnect to another with scale down policy cause OOM
[ https://issues.apache.org/jira/browse/ARTEMIS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686682#comment-16686682 ] ASF subversion and git services commented on ARTEMIS-2174: -- Commit 6e89b22eaae8cd82852ae3d0a643bb3502cf994c in activemq-artemis's branch refs/heads/master from [~gaohoward] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=6e89b22 ] ARTEMIS-2174 Broker reconnect cause OOM with scale down When a node tries to reconnects to another node in a scale down cluster, the reconnect request gets denied by the other node and keeps retrying, which causes tasks in the ordered executor accumulate and eventually OOM. The fix is to change the ActiveMQPacketHandler#handleCheckForFailover to allow reconnect if the scale down node is the node itself. > Broker reconnect to another with scale down policy cause OOM > > > Key: ARTEMIS-2174 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2174 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.6.4 > > > When a node tries to reconnects to another node in a scale down cluster, the > reconnect request gets denied by the other node and keeps retrying, which > causes tasks in the ordered executor accumulate and eventually OOM. > To reproduce: > # Start 2 nodes (node1 and 2) cluster configured in scale down mode. > # stop node2 and restart it. > # node1 will try to reconnect to node2 repeatedly and ever succeed. > # Inspect the connecting ClientSessionFactory (like adding log) and its > threadpool (closeExecutor an object of OrderedExecutor) keeps adding tasks to > its queue. > Over the time the queue keeps ever growing, and will exhaust the heap memory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2174) Broker reconnect to another with scale down policy cause OOM
[ https://issues.apache.org/jira/browse/ARTEMIS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686686#comment-16686686 ] ASF GitHub Bot commented on ARTEMIS-2174: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2430 > Broker reconnect to another with scale down policy cause OOM > > > Key: ARTEMIS-2174 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2174 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.6.4 > > > When a node tries to reconnects to another node in a scale down cluster, the > reconnect request gets denied by the other node and keeps retrying, which > causes tasks in the ordered executor accumulate and eventually OOM. > To reproduce: > # Start 2 nodes (node1 and 2) cluster configured in scale down mode. > # stop node2 and restart it. > # node1 will try to reconnect to node2 repeatedly and ever succeed. > # Inspect the connecting ClientSessionFactory (like adding log) and its > threadpool (closeExecutor an object of OrderedExecutor) keeps adding tasks to > its queue. > Over the time the queue keeps ever growing, and will exhaust the heap memory. -- 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=16686681#comment-16686681
]
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_r233491698
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -1133,8 +1158,7 @@ public Object removeProperty(final SimpleString key) {
@Override
public Object removeProperty(final String key) {
messageChanged();
- checkProperties();
- Object oldValue =
properties.removeProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()));
+ Object oldValue =
checkProperties().removeProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()));
--- End diff --
delegate to
public Object removeProperty(final SimpleString 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=16686687#comment-16686687
]
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_r233491975
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -1143,20 +1167,17 @@ public Object removeProperty(final String key) {
@Override
public boolean containsProperty(final SimpleString key) {
- checkProperties();
- return properties.containsProperty(key);
+ return checkProperties().containsProperty(key);
}
@Override
public boolean containsProperty(final String key) {
- checkProperties();
- return properties.containsProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()));
+ return
checkProperties().containsProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()));
--- End diff --
delegate to:
public boolean containsProperty(final SimpleString key) {
Just repeat this review comment on all methods taking a String key ;) to
delegate to the SimpleString equiv.
> 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=16686678#comment-16686678
]
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_r233491363
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -1070,26 +1102,22 @@ public CoreMessage putObjectProperty(final String
key, final Object value) throw
@Override
public Short getShortProperty(final SimpleString key) throws
ActiveMQPropertyConversionException {
- checkProperties();
- return properties.getShortProperty(key);
+ return checkProperties().getShortProperty(key);
}
@Override
public Short getShortProperty(final String key) throws
ActiveMQPropertyConversionException {
- checkProperties();
- return properties.getShortProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()));
+ return
checkProperties().getShortProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()));
--- End diff --
delegate to
public Short getShortProperty(final SimpleString key) throws
ActiveMQPropertyConversionException {
> 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=16686675#comment-16686675
]
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_r233491147
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -946,119 +994,103 @@ public Integer getIntProperty(final String key)
throws ActiveMQPropertyConversio
@Override
public CoreMessage putLongProperty(final SimpleString key, final long
value) {
messageChanged();
- checkProperties();
- properties.putLongProperty(key, value);
+ checkProperties().putLongProperty(key, value);
return this;
}
@Override
public CoreMessage putLongProperty(final String key, final long value) {
messageChanged();
- checkProperties();
- properties.putLongProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()), value);
+ checkProperties().putLongProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()), value);
return this;
}
@Override
public Long getLongProperty(final SimpleString key) throws
ActiveMQPropertyConversionException {
- checkProperties();
- return properties.getLongProperty(key);
+ return checkProperties().getLongProperty(key);
}
@Override
public Long getLongProperty(final String key) throws
ActiveMQPropertyConversionException {
- checkProperties();
return getLongProperty(SimpleString.toSimpleString(key));
}
@Override
public CoreMessage putFloatProperty(final SimpleString key, final float
value) {
messageChanged();
- checkProperties();
- properties.putFloatProperty(key, value);
+ checkProperties().putFloatProperty(key, value);
return this;
}
@Override
public CoreMessage putFloatProperty(final String key, final float
value) {
messageChanged();
- checkProperties();
- properties.putFloatProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()), value);
+ checkProperties().putFloatProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()), value);
return this;
}
@Override
public CoreMessage putDoubleProperty(final SimpleString key, final
double value) {
messageChanged();
- checkProperties();
- properties.putDoubleProperty(key, value);
+ checkProperties().putDoubleProperty(key, value);
return this;
}
@Override
public CoreMessage putDoubleProperty(final String key, final double
value) {
messageChanged();
- checkProperties();
- properties.putDoubleProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()), value);
+ checkProperties().putDoubleProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()), value);
return this;
}
@Override
public Double getDoubleProperty(final SimpleString key) throws
ActiveMQPropertyConversionException {
- checkProperties();
- return properties.getDoubleProperty(key);
+ return checkProperties().getDoubleProperty(key);
}
@Override
public Double getDoubleProperty(final String key) throws
ActiveMQPropertyConversionException {
- checkProperties();
return getDoubleProperty(SimpleString.toSimpleString(key));
}
@Override
public CoreMessage putStringProperty(final SimpleString key, final
SimpleString value) {
messageChanged();
- checkProperties();
- properties.putSimpleStringProperty(key, value);
+ checkProperties().putSimpleStringProperty(key, value);
return this;
}
@Override
public CoreMessage putStringProperty(final SimpleString key, final
String value) {
messageChanged();
- checkProperties();
- properties.putSimpleStringProperty(key,
SimpleString.toSimpleString(value, getPropertyValuesPool()));
+ checkProperties().putSimpleStringProperty(key,
SimpleString.toSimpleString(value, getPropertyValuesPool()));
return this;
}
@Override
public CoreMessage putStringProperty(final String key, final String
value) {
messageChanged();
- checkProperties();
- properties.putSimpleStringProperty(SimpleString.toSimpleString(key,
getPropertyKeysPool()), SimpleString.toSimpleString(value,
getPropertyValuesPool()));
+
[jira] [Commented] (ARTEMIS-2104) Implement tests for Import/Export (replay) of messages
[ https://issues.apache.org/jira/browse/ARTEMIS-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686674#comment-16686674 ] ASF subversion and git services commented on ARTEMIS-2104: -- Commit be9676c0d397384bd2ab647311fcd19729cb080a in activemq-artemis's branch refs/heads/master from feuillemorte [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=be9676c ] ARTEMIS-2104 Added tests in artemis-cli//MessageSerializerTest Added new cases: - export from anycast queue, then import to multicast topic where number of queues > 1 - export from anycast queue, then import to multicast fqqn where number of queues > 1 - export from multicast topic, then import to anycast queue (both address) - export from anycast queue, then import to multicast topic (both address) > Implement tests for Import/Export (replay) of messages > -- > > Key: ARTEMIS-2104 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2104 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Broker >Reporter: Oleg Sushchenko >Priority: Major > -- 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=16686667#comment-16686667
]
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_r233490350
--- 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 {
--- End diff --
is this really needed, the way i see it, looking through the usage, these
internal properties, are a bit like the extra properties that exist and
introduced on AMQPMessage, e.g. theyre bits added onto the message but not part
of the core message, could there just be two fields of type TypeProperties in
core message, one (existing) for normal properties, and another for Internal
Properties, which are these things, that then would make cleaning up / not
forwarding on far easier, as then simply you clear them.
> 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=1668#comment-1668
]
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_r233490193
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/message/impl/CoreMessage.java
---
@@ -564,34 +604,59 @@ public CoreMessage setUserID(UUID userID) {
/**
* I am keeping this synchronized as the decode of the Properties is
lazy
*/
- protected TypedProperties checkProperties() {
+ protected final TypedProperties checkProperties() {
--- End diff --
could this be renamed getProperties as it seems much like a getter 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] (AMQ-7093) KahaDB index, recover free pages in parallel with start (Continued)
[
https://issues.apache.org/jira/browse/AMQ-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686659#comment-16686659
]
Christopher L. Shannon commented on AMQ-7093:
-
[~gtully] - The PageFileTest is failing for me on the 5.15.x branch but it
works in master. I'm wondering if we missed backporting something, there have
been a lot of changes.
Specifically the testBackgroundWillNotMarkEaslyPagesAsFree test is not passing
this assertion:
{noformat}
assertTrue("We have 10 free pages", Wait.waitFor(new Wait.Condition() {
@Override
public boolean isSatisified() throws Exception {
pf2.flush();
long freePages = pf2.getFreePageCount();
LOG.info("free page count: " + freePages);
return freePages == 100100;
}
}, 1200));{noformat}
> KahaDB index, recover free pages in parallel with start (Continued)
> ---
>
> Key: AMQ-7093
> URL: https://issues.apache.org/jira/browse/AMQ-7093
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB
>Affects Versions: 5.15.7
>Reporter: Jeff Genender
>Priority: Major
> Fix For: 5.16.0, 5.15.8
>
>
> AMQ-7082 was implemented to create a concurrent thread to handle the free
> page recovery. It was included as a part of 5.15.7. There was some
> additional add-on coding that was not a part of that release which had
> introduced some potential bugs. This was made to track the additional
> commits for this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2163) Classloading issue if artemis-commons is not in ther same classloader as artemis-client-* or artemis-server
[
https://issues.apache.org/jira/browse/ARTEMIS-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686643#comment-16686643
]
ASF GitHub Bot commented on ARTEMIS-2163:
-
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2416#discussion_r233483727
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientSessionFactoryImpl.java
---
@@ -982,7 +982,13 @@ protected ConnectorFactory
instantiateConnectorFactory(final String connectorFac
return AccessController.doPrivileged(new
PrivilegedAction() {
@Override
public ConnectorFactory run() {
-return (ConnectorFactory)
ClassloadingUtil.newInstanceFromClassLoader(connectorFactoryClassName);
+ClassLoader cl =
Thread.currentThread().getContextClassLoader();
--- End diff --
Couldn't you change ClassLoadingUtil as
```java
public static Object newInstanceFromClassLoader(final String className) {
return newInstanceFromClassLoader(ClassloadingUtil.class, className);
}
public static Object newInstanceFromClassLoader(Class classOwner, final
String className) {
ClassLoader loader = classOwner.getClassLoader();
try {
Class clazz = loader.loadClass(className);
return clazz.newInstance();
} catch (Throwable t) {
if (t instanceof InstantiationException) {
System.out.println(INSTANTIATION_EXCEPTION_MESSAGE);
}
loader = Thread.currentThread().getContextClassLoader();
if (loader == null)
throw new RuntimeException("No local context classloader", t);
try {
return loader.loadClass(className).newInstance();
} catch (InstantiationException e) {
throw new RuntimeException(INSTANTIATION_EXCEPTION_MESSAGE + "
" + className, e);
} catch (ClassNotFoundException e) {
throw new IllegalStateException(e);
} catch (IllegalAccessException e) {
throw new RuntimeException(e);
}
}
}
```
and pass in the class parameter on these cases?
Or would this have issues with Security on the JDK?
If there are no issues I would prefer the parameter added?
> Classloading issue if artemis-commons is not in ther same classloader as
> artemis-client-* or artemis-server
> ---
>
> Key: ARTEMIS-2163
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2163
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Broker
>Affects Versions: 2.6.3
>Reporter: Emmanuel Hugonnet
>Priority: Major
>
> The class org.apache.activemq.artemis.utils.ClassLoadingUtil is defined in
> artemis-commons. In a jboss-modules environment this creates a loop to be
> able to load classes from another module.
> Setting the ThreadContext classloader to the calling class before invoking
> ClassLoadingUtil
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2142) Support JMSXGroupSeq -1 to close/reset Groups
[ https://issues.apache.org/jira/browse/ARTEMIS-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686628#comment-16686628 ] ASF GitHub Bot commented on ARTEMIS-2142: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2424 > Support JMSXGroupSeq -1 to close/reset Groups > - > > Key: ARTEMIS-2142 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2142 > Project: ActiveMQ Artemis > Issue Type: Sub-task >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Support Closing groups as per ActiveMQ 5 , > [http://activemq.apache.org/message-groups.html] using -1 on groupsequence to > as the signal -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2142) Support JMSXGroupSeq -1 to close/reset Groups
[ https://issues.apache.org/jira/browse/ARTEMIS-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686636#comment-16686636 ] ASF subversion and git services commented on ARTEMIS-2142: -- Commit 5ac87609e70e85397b81b170d6337ada9fa9e89f in activemq-artemis's branch refs/heads/master from [~teaandcoffee] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=5ac8760 ] ARTEMIS-2142 Refactor of Patchfix ServerJMSMessage Refactor ServerJMSMessage so it correctly transposes all JMSX headers. Push common JMSX mappings for JMS to Message Interface mappings into MessageUtil to avoid duplication in ActiveMQMessage and ServerJMSMessage > Support JMSXGroupSeq -1 to close/reset Groups > - > > Key: ARTEMIS-2142 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2142 > Project: ActiveMQ Artemis > Issue Type: Sub-task >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Support Closing groups as per ActiveMQ 5 , > [http://activemq.apache.org/message-groups.html] using -1 on groupsequence to > as the signal -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2142) Support JMSXGroupSeq -1 to close/reset Groups
[ https://issues.apache.org/jira/browse/ARTEMIS-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686635#comment-16686635 ] ASF GitHub Bot commented on ARTEMIS-2142: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2425 I am a bit confused on how to merge this into 2.6.x. If you want a 2.6.x patch can you pull it yourself? > Support JMSXGroupSeq -1 to close/reset Groups > - > > Key: ARTEMIS-2142 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2142 > Project: ActiveMQ Artemis > Issue Type: Sub-task >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Support Closing groups as per ActiveMQ 5 , > [http://activemq.apache.org/message-groups.html] using -1 on groupsequence to > as the signal -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7087) Add Java 11 Support
[ https://issues.apache.org/jira/browse/AMQ-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686632#comment-16686632 ] Christopher L. Shannon commented on AMQ-7087: - Ok thanks I will try it > Add Java 11 Support > --- > > Key: AMQ-7087 > URL: https://issues.apache.org/jira/browse/AMQ-7087 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.15.6 > Environment: Windows 10 with the OpenJDK 11 "bin" directory on the > path. >Reporter: Jeff Gullett >Assignee: Christopher L. Shannon >Priority: Critical > Fix For: 5.16.0 > > > Java 8 support is ending in January, 2019 (in 2 months). Currently, the > ActiveMQ Broker only supports Java 8. When I try to start the broker using > Java 11 (the latest long-term-support version), I get the following error: > Unable to execute Java command. The system cannot find the file specified. > (0x2) > Critical error: wait for JVM process failed > Since both Java 9 and Java 10 are already EOL, support for Java 11 needs to > be added by January 2019. The issue to add Java 9 support (AMQ-6864) is OBE, > and should be replaced by this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2142) Support JMSXGroupSeq -1 to close/reset Groups
[ https://issues.apache.org/jira/browse/ARTEMIS-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686626#comment-16686626 ] ASF subversion and git services commented on ARTEMIS-2142: -- Commit 14451a79eb11294dec6571bf54fe8da84446e931 in activemq-artemis's branch refs/heads/master from [~teaandcoffee] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=14451a7 ] ARTEMIS-2142 Patch Fix ServerJMSMessage for JMSXGROUPSEQ This is a patch fix for JMSXGROUPSEQ. > Support JMSXGroupSeq -1 to close/reset Groups > - > > Key: ARTEMIS-2142 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2142 > Project: ActiveMQ Artemis > Issue Type: Sub-task >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > Support Closing groups as per ActiveMQ 5 , > [http://activemq.apache.org/message-groups.html] using -1 on groupsequence to > as the signal -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7087) Add Java 11 Support
[ https://issues.apache.org/jira/browse/AMQ-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686612#comment-16686612 ] Daniel Kulp commented on AMQ-7087: -- The xic-utils use it's own version numbers and release schedule. No different than ActiveMQ vs Artemis. 3.2.3 should work. > Add Java 11 Support > --- > > Key: AMQ-7087 > URL: https://issues.apache.org/jira/browse/AMQ-7087 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.15.6 > Environment: Windows 10 with the OpenJDK 11 "bin" directory on the > path. >Reporter: Jeff Gullett >Assignee: Christopher L. Shannon >Priority: Critical > Fix For: 5.16.0 > > > Java 8 support is ending in January, 2019 (in 2 months). Currently, the > ActiveMQ Broker only supports Java 8. When I try to start the broker using > Java 11 (the latest long-term-support version), I get the following error: > Unable to execute Java command. The system cannot find the file specified. > (0x2) > Critical error: wait for JVM process failed > Since both Java 9 and Java 10 are already EOL, support for Java 11 needs to > be added by January 2019. The issue to add Java 9 support (AMQ-6864) is OBE, > and should be replaced by this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2165) Not having backup available after restart in colocated configuration
[
https://issues.apache.org/jira/browse/ARTEMIS-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686610#comment-16686610
]
Dmitry Smeliansky commented on ARTEMIS-2165:
Is it possible to get some update for this one?
As I mentioned in the ticket description, this exactly the same question was
asked multiple times in stackoverflow but no clear answer was provided.
This is one of our decision makers about using Artemis as a queue
infrastructure of our product.
Thanks
> Not having backup available after restart in colocated configuration
>
>
> Key: ARTEMIS-2165
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2165
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.6.0
>Reporter: Dmitry Smeliansky
>Priority: Major
>
> We use colocated HA-policy and trying to achieve the following:
> # We have 2 servers and want each one of them will hold a) 1 master b) 1
> slave for the master of each other
> # When we start the servers we have the above as we wanted
> # When one of the server is going down, the slave on the second becomes a
> live master - till now everything is ok
> # When the second server (which was down in step 3) is up, the slave from
> server 1 remains a live master and a slave for master 1 is not created in
> server 2.
> All we want is : how the system should be configured, so after the step 4 we
> will have the exact topology as after the step 1.
> # Start server 1 and server 2: server 1 has 1 master and 1 slave, server 2
> has one master and one slave
> # Restart server 2: server 1 has one master and one slave, server 2 has one
> master and one slave
>
>
>
> This issue was asked multiple times in stackoverflow, but was never answered.
> When using a co-located HA policy, the backups, maintained by some node are
> not restored after this node is restarted (not on this node and not on any
> other).
> [https://stackoverflow.com/questions/52839706/artemis-2-6-0-colocated-ha-issues]
> [https://stackoverflow.com/questions/52000662/artemis-colocated-ha-policy]
> Our configuration was as the following:
> {code:java}
>
>
>
> 100
> true
> 2
> -1
>
> 5000
>
>
>
>
> {code}
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7087) Add Java 11 Support
[ https://issues.apache.org/jira/browse/AMQ-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686596#comment-16686596 ] Christopher L. Shannon commented on AMQ-7087: - Right but I don't see 3.3 yet: https://mvnrepository.com/artifact/org.apache.cxf/cxf-xjc-plugin > Add Java 11 Support > --- > > Key: AMQ-7087 > URL: https://issues.apache.org/jira/browse/AMQ-7087 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.15.6 > Environment: Windows 10 with the OpenJDK 11 "bin" directory on the > path. >Reporter: Jeff Gullett >Assignee: Christopher L. Shannon >Priority: Critical > Fix For: 5.16.0 > > > Java 8 support is ending in January, 2019 (in 2 months). Currently, the > ActiveMQ Broker only supports Java 8. When I try to start the broker using > Java 11 (the latest long-term-support version), I get the following error: > Unable to execute Java command. The system cannot find the file specified. > (0x2) > Critical error: wait for JVM process failed > Since both Java 9 and Java 10 are already EOL, support for Java 11 needs to > be added by January 2019. The issue to add Java 9 support (AMQ-6864) is OBE, > and should be replaced by this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7087) Add Java 11 Support
[ https://issues.apache.org/jira/browse/AMQ-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686589#comment-16686589 ] Daniel Kulp commented on AMQ-7087: -- I believe AMQ only used the cxf-xjc-plugin. That was released a couple weeks ago. > Add Java 11 Support > --- > > Key: AMQ-7087 > URL: https://issues.apache.org/jira/browse/AMQ-7087 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.15.6 > Environment: Windows 10 with the OpenJDK 11 "bin" directory on the > path. >Reporter: Jeff Gullett >Assignee: Christopher L. Shannon >Priority: Critical > Fix For: 5.16.0 > > > Java 8 support is ending in January, 2019 (in 2 months). Currently, the > ActiveMQ Broker only supports Java 8. When I try to start the broker using > Java 11 (the latest long-term-support version), I get the following error: > Unable to execute Java command. The system cannot find the file specified. > (0x2) > Critical error: wait for JVM process failed > Since both Java 9 and Java 10 are already EOL, support for Java 11 needs to > be added by January 2019. The issue to add Java 9 support (AMQ-6864) is OBE, > and should be replaced by this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7096) ActiveMQ lose messages on broker restarts
[ https://issues.apache.org/jira/browse/AMQ-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686573#comment-16686573 ] Gary Tully commented on AMQ-7096: - Please provide a standalone test case that asserts that the bug is in activemq. There are loads of tests in the activemq-unit-test module that can provide inspiration > ActiveMQ lose messages on broker restarts > - > > Key: AMQ-7096 > URL: https://issues.apache.org/jira/browse/AMQ-7096 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.7 >Reporter: Veaceslav Doina >Priority: Critical > > Hello, > We recently performed ActiveMQ reliability test in order to verify if it can > guarantee 0 messages loss. Results show, that if the broker is restarted in > the process of producing/consuming we lose messages. > Testing environment: > AWS > Hardware: > |Broker|m5.large|2vCPU / 8GiB| > |Producer/Consumer|t3.large|2vCPU / 8GiB| > Software: > OS: CentOS Linux release 7.5.1804 > Java: Oracle JDK SE 8 Update 192 > ActiveMQ: ActiveMQ 5.15.7 > Client: [JmsTools|https://github.com/erik-wramner/JmsTools] > Default ActiveMQ configuration was used with only [unique DLQ > configuration|http://activemq.apache.org/message-redelivery-and-dlq-handling.html]. > > > The result and project with all required data for issue reproducing may be > found on GitHub: [https://github.com/veaceslavdoina/messages-brokers-testing] > Discussion on the Mailing list: > [http://activemq.2283324.n4.nabble.com/ActiveMQ-and-Artemis-reliability-Messages-lost-tt4744881.html] > > Thank you! > > Slava. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMQ-7009) ActiveMQ stop delivering messages
[ https://issues.apache.org/jira/browse/AMQ-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-7009. - Resolution: Fixed Assignee: Gary Tully Fix Version/s: 5.16.0 Thanks for the test case and suggested fix. A little tweak to the test case to better manage memory usage made it clear that your fix is good. > ActiveMQ stop delivering messages > - > > Key: AMQ-7009 > URL: https://issues.apache.org/jira/browse/AMQ-7009 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.4 >Reporter: Nezih BEN FREDJ >Assignee: Gary Tully >Priority: Critical > Fix For: 5.16.0 > > Attachments: MemoryMessageStore.java, > MemoryMessageStoreQueueCursorTest.java, activemq.log > > > We have a problem with ActiveMQ 5.15.4, it stop deliver messages to clients. > This happens completely randomly and we are not able to give a test case that > reproduce the problem > Activemq is configured to use the « memoryPersistenceAdapter » > > When examining memory dumps, we identified incoherent situation in the class > MemoryMessageStore that can lead to stop delivering messages. When : > - MemoryMessageStore.recoverNextMessages(...) is called > - « lastBatchId » is not null > - « messageTable » does not contains any entry with « lastBatchId » as key > no messages are recovered > > We added logs to try to understand how it is possible to have a non null « > lastBatchId » and « messageTable » with no entry having « lastBatchId » as > key. > > We noticed that the method setBatch is called with a non null « messageId » > parameter, but no message with this id is inserted in « messageTable ». After > that, when the method MemoryMessageStore.recoverNextMessages(...) is called, > it does nothing and no messages are recoverd. And the system go in a what > looks like an endless loop. > > We are testing a temporary solution by resetting « lastBatchId » to null when > the incoherent situation is detected. > > Can you help us resolving the problem at the source and not just get around. > I joined modified source code of the class MemoryMessageStore and an extract > of the log file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7009) ActiveMQ stop delivering messages
[ https://issues.apache.org/jira/browse/AMQ-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686570#comment-16686570 ] ASF subversion and git services commented on AMQ-7009: -- Commit bc8c78cd32b27dd1806fe2246c21241ab68a1fde in activemq's branch refs/heads/master from gtully [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=bc8c78c ] AMQ-7009 - apply fix to memorymessagestore setBatch with thanks to Nezih BEN FREDJ for test and suggestion > ActiveMQ stop delivering messages > - > > Key: AMQ-7009 > URL: https://issues.apache.org/jira/browse/AMQ-7009 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.4 >Reporter: Nezih BEN FREDJ >Priority: Critical > Attachments: MemoryMessageStore.java, > MemoryMessageStoreQueueCursorTest.java, activemq.log > > > We have a problem with ActiveMQ 5.15.4, it stop deliver messages to clients. > This happens completely randomly and we are not able to give a test case that > reproduce the problem > Activemq is configured to use the « memoryPersistenceAdapter » > > When examining memory dumps, we identified incoherent situation in the class > MemoryMessageStore that can lead to stop delivering messages. When : > - MemoryMessageStore.recoverNextMessages(...) is called > - « lastBatchId » is not null > - « messageTable » does not contains any entry with « lastBatchId » as key > no messages are recovered > > We added logs to try to understand how it is possible to have a non null « > lastBatchId » and « messageTable » with no entry having « lastBatchId » as > key. > > We noticed that the method setBatch is called with a non null « messageId » > parameter, but no message with this id is inserted in « messageTable ». After > that, when the method MemoryMessageStore.recoverNextMessages(...) is called, > it does nothing and no messages are recoverd. And the system go in a what > looks like an endless loop. > > We are testing a temporary solution by resetting « lastBatchId » to null when > the incoherent situation is detected. > > Can you help us resolving the problem at the source and not just get around. > I joined modified source code of the class MemoryMessageStore and an extract > of the log file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6903) Issue With Master and Slave Mode
[
https://issues.apache.org/jira/browse/AMQ-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686557#comment-16686557
]
Veaceslav Doina commented on AMQ-6903:
--
[~gtully], thank you for pointing in the right direction:
{code:java}
{code}
> Issue With Master and Slave Mode
>
>
> Key: AMQ-6903
> URL: https://issues.apache.org/jira/browse/AMQ-6903
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.15.2
>Reporter: CHAKRADHAR REDDY
>Priority: Critical
>
> Hi All,
> We have installed Apache AMQ in master slave mode we could see that slave is
> not becoming up immediately after master is shutdown and we could see below
> exception.
>
> FYI: We have many messages in queues and this slave is not up till we clear
> data in kahadb location and once we have cleaned data in kahadb location
> there no messages in queues any longer.
> we have lost all messages from queues is there any option we can get messages
> from db.log etc.. files from kahadb location
> We have received below transport Errors this is reason we have shutdown
> master to make slave up
> 2018-01-13 04:33:04,032 | ERROR | Could not accept connection from tcp://IP
> of server containing interfaces accessing AMQ server:52808 : {} |
> org.apache.activemq.broker.TransportConnector | ActiveMQ BrokerServ
> ice[ip] Task-15549
> java.lang.IllegalStateException: Timer already cancelled.
> at java.util.Timer.sched(Timer.java:397)[:1.8.0_151]
> at java.util.Timer.schedule(Timer.java:193)[:1.8.0_151]
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.startConnectCheckTask(AbstractInactivityMonitor.java:425)[activemq-client-5.15.2.jar:5.15.2]
> at org.apache.activemq.transport.AbstractInactivityMonitor.startConne
> After shutdown of master slave is not up with below error and we lost all
> data in queues.
> 2018-02-21 20:09:18,135 | ERROR | File system space reported by:
> /DBA/EFS/activemq/kahadb was negative, possibly a huge file system, set a
> sane usage.total to provide some guidance |
> org.apache.activemq.broker.BrokerService | main
> 2018-02-21 20:09:18,139 | ERROR | Failed to start Apache ActiveMQ (IP, ID:DNS
> of activemq server) | org.apache.activemq.broker.BrokerService | main
> org.apache.activemq.ConfigurationException: File system space reported by:
> /DBA/EFS/activemq/kahadb was negative, possibly a huge file system, set a
> sane usage.total to provide some guidance
> at
> org.apache.activemq.broker.BrokerService.checkUsageLimit(BrokerService.java:2092)[activemq-broker-5.15.2.jar:5.15.2]
> at
> org.apache.activemq.broker.BrokerService.checkStoreUsageLimits(BrokerService.java:2029)[activemq-broker-5.15.2.jar:5.15.2]
> at
> org.apache.activemq.broker.BrokerService.checkStoreSystemUsageLimits(BrokerService.java:2202)[activemq-broker-5.15.2.jar:5.15.2]
> at
> org.apache.activemq.broker.BrokerService.doStartBroker(BrokerService.java:777)[activemq-broker-5.15.2.jar:5.15.2]
> at
> org.apache.activemq.broker.BrokerService.startBroker(BrokerService.java:733)[activemq-broker-5.15.2.jar:5.15.2]
> at
> org.apache.activemq.broker.BrokerService.start(BrokerService.java:636)[activemq-broker-5.15.2.jar:5.15.2]
> at
> org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:73)[activemq-spring-5.15.2.jar:5.15.2]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_151]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_151]
> :
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7097) AMQP: Update Qpid JMS, Proton-J and Netty to latest releases
[ https://issues.apache.org/jira/browse/AMQ-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686517#comment-16686517 ] Timothy Bish commented on AMQ-7097: --- This can wait until the next release as the JMS release is still a day or two away. > AMQP: Update Qpid JMS, Proton-J and Netty to latest releases > > > Key: AMQ-7097 > URL: https://issues.apache.org/jira/browse/AMQ-7097 > Project: ActiveMQ > Issue Type: Task > Components: AMQP >Affects Versions: 5.15.7 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.15.9 > > > Update AMQP libraries to latest > * Qpid JMS 0.38.0 > * Proton-j 0.30.0 > * Netty 4.1.31.Final -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7097) AMQP: Update Qpid JMS, Proton-J and Netty to latest releases
[ https://issues.apache.org/jira/browse/AMQ-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-7097: -- Fix Version/s: (was: 5.15.8) 5.15.9 > AMQP: Update Qpid JMS, Proton-J and Netty to latest releases > > > Key: AMQ-7097 > URL: https://issues.apache.org/jira/browse/AMQ-7097 > Project: ActiveMQ > Issue Type: Task > Components: AMQP >Affects Versions: 5.15.7 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.15.9 > > > Update AMQP libraries to latest > * Qpid JMS 0.38.0 > * Proton-j 0.30.0 > * Netty 4.1.31.Final -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7087) Add Java 11 Support
[ https://issues.apache.org/jira/browse/AMQ-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686461#comment-16686461 ] Christopher L. Shannon commented on AMQ-7087: - We need CXF version 3.3 to be released for our xsd generation: https://issues.apache.org/jira/browse/CXF-7852 I ran into code generation issues on JDK 11 but will be fixed in 3.3 > Add Java 11 Support > --- > > Key: AMQ-7087 > URL: https://issues.apache.org/jira/browse/AMQ-7087 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.15.6 > Environment: Windows 10 with the OpenJDK 11 "bin" directory on the > path. >Reporter: Jeff Gullett >Assignee: Christopher L. Shannon >Priority: Critical > Fix For: 5.16.0 > > > Java 8 support is ending in January, 2019 (in 2 months). Currently, the > ActiveMQ Broker only supports Java 8. When I try to start the broker using > Java 11 (the latest long-term-support version), I get the following error: > Unable to execute Java command. The system cannot find the file specified. > (0x2) > Critical error: wait for JVM process failed > Since both Java 9 and Java 10 are already EOL, support for Java 11 needs to > be added by January 2019. The issue to add Java 9 support (AMQ-6864) is OBE, > and should be replaced by this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7097) AMQP: Update Qpid JMS, Proton-J and Netty to latest releases
[ https://issues.apache.org/jira/browse/AMQ-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686442#comment-16686442 ] Christopher L. Shannon commented on AMQ-7097: - [~tabish121] - After you update these I will start the 5.15.8 release. > AMQP: Update Qpid JMS, Proton-J and Netty to latest releases > > > Key: AMQ-7097 > URL: https://issues.apache.org/jira/browse/AMQ-7097 > Project: ActiveMQ > Issue Type: Task > Components: AMQP >Affects Versions: 5.15.7 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 5.15.8 > > > Update AMQP libraries to latest > * Qpid JMS 0.38.0 > * Proton-j 0.30.0 > * Netty 4.1.31.Final -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (AMQ-7098) Need enhacement for the existing queue
[ https://issues.apache.org/jira/browse/AMQ-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon closed AMQ-7098. --- Resolution: Won't Fix I am closing this for now as anything having to do with the webconsole is not going to be worked on as is mostly un-maintained at this point. Also the description of the issue doesn't accurately reflect the issue and should be changed if re-opened at some point. Your best bet is to create a pull request if you want a feature for the webconsole and make sure it is generic enough to be included that it is helpful for others. If you want to work on it yourself then you can re-open with a pull request. > Need enhacement for the existing queue > -- > > Key: AMQ-7098 > URL: https://issues.apache.org/jira/browse/AMQ-7098 > Project: ActiveMQ > Issue Type: Improvement > Components: activemq-camel >Affects Versions: 5.14.0 >Reporter: Bala Subramanyam Mangipudi >Priority: Minor > Attachments: Requirements.docx > > > Please see the requirements document attached -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2174) Broker reconnect to another with scale down policy cause OOM
[ https://issues.apache.org/jira/browse/ARTEMIS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686389#comment-16686389 ] ASF GitHub Bot commented on ARTEMIS-2174: - GitHub user gaohoward opened a pull request: https://github.com/apache/activemq-artemis/pull/2430 ARTEMIS-2174 Broker reconnect cause OOM with scale down When a node tries to reconnects to another node in a scale down cluster, the reconnect request gets denied by the other node and keeps retrying, which causes tasks in the ordered executor accumulate and eventually OOM. The fix is to change the ActiveMQPacketHandler#handleCheckForFailover to allow reconnect if the scale down node is the node itself. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gaohoward/activemq-artemis e_2174 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2430.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 #2430 commit 2a108ac8817cb6c2ca3b29092108a3e35e7f5690 Author: Howard Gao Date: 2018-11-14T11:21:48Z ARTEMIS-2174 Broker reconnect cause OOM with scale down When a node tries to reconnects to another node in a scale down cluster, the reconnect request gets denied by the other node and keeps retrying, which causes tasks in the ordered executor accumulate and eventually OOM. The fix is to change the ActiveMQPacketHandler#handleCheckForFailover to allow reconnect if the scale down node is the node itself. > Broker reconnect to another with scale down policy cause OOM > > > Key: ARTEMIS-2174 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2174 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.6.4 > > > When a node tries to reconnects to another node in a scale down cluster, the > reconnect request gets denied by the other node and keeps retrying, which > causes tasks in the ordered executor accumulate and eventually OOM. > To reproduce: > # Start 2 nodes (node1 and 2) cluster configured in scale down mode. > # stop node2 and restart it. > # node1 will try to reconnect to node2 repeatedly and ever succeed. > # Inspect the connecting ClientSessionFactory (like adding log) and its > threadpool (closeExecutor an object of OrderedExecutor) keeps adding tasks to > its queue. > Over the time the queue keeps ever growing, and will exhaust the heap memory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
