[jira] [Work logged] (ARTEMIS-3759) Allow for Mirroring (Broker Connections) to specify a specific set of addresses to send events, as is done for a cluster connection
[ https://issues.apache.org/jira/browse/ARTEMIS-3759?focusedWorklogId=763166=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-763166 ] ASF GitHub Bot logged work on ARTEMIS-3759: --- Author: ASF GitHub Bot Created on: 27/Apr/22 21:54 Start Date: 27/Apr/22 21:54 Worklog Time Spent: 10m Work Description: iliya-gr commented on code in PR #4054: URL: https://github.com/apache/activemq-artemis/pull/4054#discussion_r860274253 ## artemis-server/src/main/resources/schema/artemis-configuration.xsd: ## @@ -2442,6 +2442,13 @@ + + + + name of the address this mirror connection applies to Review Comment: I agree with all of this, maybe except reusing `address-match`. I think using the same term that has different semantic/behaviour is bad and will lead users to misconfiguration. Anyway, I have opted for `address-filter`, but if there are any objections I can change it to anything else. Issue Time Tracking --- Worklog Id: (was: 763166) Time Spent: 1h 20m (was: 1h 10m) > Allow for Mirroring (Broker Connections) to specify a specific set of > addresses to send events, as is done for a cluster connection > - > > Key: ARTEMIS-3759 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3759 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.19.1, 2.21.0 >Reporter: Mikhail Lukyanov >Priority: Major > Attachments: ImageAddressSyntax.png, ImageInternalQueues.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > If a target broker of mirroring is in a cluster, then mirroring of the > broker's internal queues also occurs, and often messages accumulate in such > queues. In theory, internal cluster queues should not be mirrored, this does > not make much sense. > Therefore, it would be convenient to allow you to configure for which > addresses and their queues mirroring will be performed, events will be sent > (message-acknowledgements, queue-removal, queue-creation). The syntax that is > used to specify the *_addresses_* of the *_cluster connection_* is well > suited for this. > Mirrored internal cluster queues > !ImageInternalQueues.png! > Address syntax > !ImageAddressSyntax.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (AMQ-8322) Implement JMS 2.0 Connection createContext methods
[
https://issues.apache.org/jira/browse/AMQ-8322?focusedWorklogId=763133=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-763133
]
ASF GitHub Bot logged work on AMQ-8322:
---
Author: ASF GitHub Bot
Created on: 27/Apr/22 19:48
Start Date: 27/Apr/22 19:48
Worklog Time Spent: 10m
Work Description: mattrpav commented on code in PR #729:
URL: https://github.com/apache/activemq/pull/729#discussion_r860186493
##
activemq-client/src/main/java/org/apache/activemq/ActiveMQConsumer.java:
##
@@ -0,0 +1,106 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.activemq;
+
+import javax.jms.JMSConsumer;
+import javax.jms.JMSException;
+import javax.jms.JMSRuntimeException;
+import javax.jms.Message;
+import javax.jms.MessageConsumer;
+import javax.jms.MessageListener;
+
+import org.apache.activemq.util.JMSExceptionSupport;
+
+public class ActiveMQConsumer implements JMSConsumer {
+
+private final ActiveMQContext activemqContext;
+private final MessageConsumer activemqMessageConsumer;
+
+ActiveMQConsumer(ActiveMQContext activemqContext, MessageConsumer
activemqMessageConsumer) {
+this.activemqContext = activemqContext;
+this.activemqMessageConsumer = activemqMessageConsumer;
+}
+
+@Override
+public String getMessageSelector() {
+throw new UnsupportedOperationException("getMessageSelector() is not
supported");
+}
+
+@Override
+public MessageListener getMessageListener() throws JMSRuntimeException {
+throw new UnsupportedOperationException("getMessageListener() is not
supported");
+}
+
+@Override
+public void setMessageListener(MessageListener listener) throws
JMSRuntimeException {
+throw new
UnsupportedOperationException("setMessageListener(MessageListener) is not
supported");
Review Comment:
This is done
Issue Time Tracking
---
Worklog Id: (was: 763133)
Time Spent: 11.5h (was: 11h 20m)
> Implement JMS 2.0 Connection createContext methods
> --
>
> Key: AMQ-8322
> URL: https://issues.apache.org/jira/browse/AMQ-8322
> Project: ActiveMQ
> Issue Type: New Feature
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Major
> Labels: #jms2
> Fix For: 5.18.0
>
> Time Spent: 11.5h
> Remaining Estimate: 0h
>
> Add support for JMSContext, JMSProducer and JMSConsumer for working with
> queues
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (ARTEMIS-3064) Disable useTopologyForLoadBalancing for non HA federation connections between clusters
[ https://issues.apache.org/jira/browse/ARTEMIS-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528910#comment-17528910 ] Ryan Yeats commented on ARTEMIS-3064: - Sorry, I was trying to find someone who would have an opinion on connector URI usage before i embarked on changing this but i probably should have just taken it to the developer or user list > Disable useTopologyForLoadBalancing for non HA federation connections between > clusters > -- > > Key: ARTEMIS-3064 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3064 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.16.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.17.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > The core client respects the topology for loadbalancing by default. A > federation connection configures and reuses a server locator via it's circuit > breaker. > With ha = false, it looks like we should disable useTopologyForLoadBalancing > such that the circuit reconnect gets back to the original broker even when > clustered. > With ha=true, the reconnect can be to any broker in the cluster in the normal > way. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ARTEMIS-3803) The first NetworkHealthCheck execution uses default commands
[ https://issues.apache.org/jira/browse/ARTEMIS-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino updated ARTEMIS-3803: - Fix Version/s: 2.22.0 > The first NetworkHealthCheck execution uses default commands > > > Key: ARTEMIS-3803 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3803 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.22.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (ARTEMIS-3803) The first NetworkHealthCheck execution uses default commands
[ https://issues.apache.org/jira/browse/ARTEMIS-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino resolved ARTEMIS-3803. -- Resolution: Fixed > The first NetworkHealthCheck execution uses default commands > > > Key: ARTEMIS-3803 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3803 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.22.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work started] (ARTEMIS-3803) The first NetworkHealthCheck execution uses default commands
[ https://issues.apache.org/jira/browse/ARTEMIS-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTEMIS-3803 started by Domenico Francesco Bruscino. > The first NetworkHealthCheck execution uses default commands > > > Key: ARTEMIS-3803 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3803 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.22.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ARTEMIS-3700) Provide JakartaEE 10 artefacts and support
[ https://issues.apache.org/jira/browse/ARTEMIS-3700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528903#comment-17528903 ] Emmanuel Hugonnet commented on ARTEMIS-3700: Upgrading the API versions doesn't break the build. > Provide JakartaEE 10 artefacts and support > -- > > Key: ARTEMIS-3700 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3700 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: API >Affects Versions: 2.20.0 >Reporter: Emmanuel Hugonnet >Priority: Major > > With Jakarta Messaging 3.1 to be released we should plan to provide support > of the new set of APIs. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ARTEMIS-3064) Disable useTopologyForLoadBalancing for non HA federation connections between clusters
[ https://issues.apache.org/jira/browse/ARTEMIS-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528883#comment-17528883 ] Justin Bertram commented on ARTEMIS-3064: - [~ryeats], did you mean to address [~gtully] on this? I haven't been involved in this issue thus far. > Disable useTopologyForLoadBalancing for non HA federation connections between > clusters > -- > > Key: ARTEMIS-3064 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3064 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.16.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.17.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > The core client respects the topology for loadbalancing by default. A > federation connection configures and reuses a server locator via it's circuit > breaker. > With ha = false, it looks like we should disable useTopologyForLoadBalancing > such that the circuit reconnect gets back to the original broker even when > clustered. > With ha=true, the reconnect can be to any broker in the cluster in the normal > way. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ARTEMIS-3064) Disable useTopologyForLoadBalancing for non HA federation connections between clusters
[ https://issues.apache.org/jira/browse/ARTEMIS-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528878#comment-17528878 ] Ryan Yeats commented on ARTEMIS-3064: - [~jbertram] I am wondering if it would have been better to bring the circuit breaking configuration (useTopologyForLoadBalancing and circuit-breaker-timeout) into the connector URI instead. So that it is common to Artemis' existing configuration for connections and not tied to federation. I am thinking this because as I tried to use federation and i did not find it intuitive to realize topology is turned off by default since ha is off by default in federation. It is also unintuitive that ha=true in a connector UI would be ignored and i would have to use an undocumented true in my federation configuration. > Disable useTopologyForLoadBalancing for non HA federation connections between > clusters > -- > > Key: ARTEMIS-3064 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3064 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.16.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.17.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > The core client respects the topology for loadbalancing by default. A > federation connection configures and reuses a server locator via it's circuit > breaker. > With ha = false, it looks like we should disable useTopologyForLoadBalancing > such that the circuit reconnect gets back to the original broker even when > clustered. > With ha=true, the reconnect can be to any broker in the cluster in the normal > way. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3759) Allow for Mirroring (Broker Connections) to specify a specific set of addresses to send events, as is done for a cluster connection
[ https://issues.apache.org/jira/browse/ARTEMIS-3759?focusedWorklogId=762889=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-762889 ] ASF GitHub Bot logged work on ARTEMIS-3759: --- Author: ASF GitHub Bot Created on: 27/Apr/22 13:56 Start Date: 27/Apr/22 13:56 Worklog Time Spent: 10m Work Description: gemmellr commented on code in PR #4054: URL: https://github.com/apache/activemq-artemis/pull/4054#discussion_r859833745 ## artemis-server/src/main/resources/schema/artemis-configuration.xsd: ## @@ -2442,6 +2442,13 @@ + + + + name of the address this mirror connection applies to Review Comment: I dont think the use case for this configuration is all that different, in this case its about what things you want to mirror from, vs the others being about what you want to send from or recieve to. An address 'match' for a mirror definition certainly doesnt need to mean 'create a seperate mirror for every address' just because it might mean that for e.g a sender. I also presume it couldnt really mean that given each mirror uses a specific queue named based on its parent broker-connections name. Using *address-match*, *address-pattern(s)*, *address-filter(s)*, or anything to similar effect, all seem equally reasonable and far more appropriate to me than just "address" does for a configuration that generally seems to be expected _not_ to just have a single address in it. I'm not saying the config has to be the same, but I am saying it seems more obvious, and I dont as yet see any compelling reason it should be entirely different when its basically for doing entirely equivalent things, configuring applicable addresses of interest. In any case how it is configured and what it does should be documented. Issue Time Tracking --- Worklog Id: (was: 762889) Time Spent: 1h 10m (was: 1h) > Allow for Mirroring (Broker Connections) to specify a specific set of > addresses to send events, as is done for a cluster connection > - > > Key: ARTEMIS-3759 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3759 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.19.1, 2.21.0 >Reporter: Mikhail Lukyanov >Priority: Major > Attachments: ImageAddressSyntax.png, ImageInternalQueues.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > If a target broker of mirroring is in a cluster, then mirroring of the > broker's internal queues also occurs, and often messages accumulate in such > queues. In theory, internal cluster queues should not be mirrored, this does > not make much sense. > Therefore, it would be convenient to allow you to configure for which > addresses and their queues mirroring will be performed, events will be sent > (message-acknowledgements, queue-removal, queue-creation). The syntax that is > used to specify the *_addresses_* of the *_cluster connection_* is well > suited for this. > Mirrored internal cluster queues > !ImageInternalQueues.png! > Address syntax > !ImageAddressSyntax.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (AMQNET-637) NMS 2.0
[ https://issues.apache.org/jira/browse/AMQNET-637?focusedWorklogId=762829=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-762829 ] ASF GitHub Bot logged work on AMQNET-637: - Author: ASF GitHub Bot Created on: 27/Apr/22 12:16 Start Date: 27/Apr/22 12:16 Worklog Time Spent: 10m Work Description: lukeabsent commented on PR #18: URL: https://github.com/apache/activemq-nms-openwire/pull/18#issuecomment-1110929554 Here is my tests run on my local machine, the ones that are failing on the pre-2.0/old version: On the current PR version I can see the same tests failing. nms-openwire-test (31 tests) Failed: 31 tests failed Apache.NMS.ActiveMQ.Test (31 tests) Failed: 31 tests failed Commands (2 tests) Failed: 2 tests failed ActiveMQMessageTest (net472) (1 test) Failed: One or more child tests had errors: 1 test failed TestSetEmptyPropertyName Failed: Should have thrown exception ActiveMQMessageTest (netcoreapp3.1) (1 test) Failed: One or more child tests had errors: 1 test failed TestSetEmptyPropertyName Failed: Should have thrown exception DtcBasicTransactionsTest (netcoreapp3.1) (2 tests) Failed: One or more child tests had errors: 2 tests failed TestTransacteDequeueAndDbWrite Failed: wrong number of rows in DB TestTransactedDBReadAndProduce Failed: wrong number of rows in DB DtcConsumerTransactionsTest (netcoreapp3.1) (13 tests) Failed: One or more child tests had errors: 13 tests failed TestConsumeWithDBInsertLogLocation Failed: Expected: 1 TestIterativeTransactedConsume Failed: wrong number of rows in DB TestRecoverAfterFailOnTransactionAfterPrepareSent Failed: Expected: 0 TestRecoverAfterFailOnTransactionBeforePrepareSent Failed: Expected: 5 TestRecoverAfterRollbackFailWhenScopeAborted Failed: Expected: 5 TestRecoverAfterTransactionScopeAborted Failed: Expected: 5 TestRecoveryAfterCommitFailsAfterSent Failed: Expected: 0 TestRecoveryAfterCommitFailsBeforeSent Failed: Expected: 0 TestRedelivered Failed: System.PlatformNotSupportedException : This platform does not support distributed transactions. TestRedeliveredCase2 Failed: System.PlatformNotSupportedException : This platform does not support distributed transactions. TestRedeliveredCase3 Failed: System.PlatformNotSupportedException : This platform does not support distributed transactions. TestRedeliveredNoComplete Failed: System.PlatformNotSupportedException : This platform does not support distributed transactions. TestTransactedAsyncConsumption Failed: System.Transactions.TransactionAbortedException : The transaction has aborted. DtcProducerTransactionsTest (netcoreapp3.1) (4 tests) Failed: One or more child tests had errors: 4 tests failed TestIterativeTransactedProduceWithDBDelete Failed: wrong number of rows in DB TestNoRecoverAfterFailOnTransactionWhenLogDeleted Failed: wrong number of rows in DB TestRecoverAfterFailOnTransactionCommit Failed: wrong number of rows in DB TestRecoverAfterFailOnTransactionPostCommitSend Failed: Expected: 5 InactivityMonitorTest (net472) (1 test) Failed: One or more child tests had errors: 1 test failed TestWriteMessageFail Failed: Should have thrown an exception InactivityMonitorTest (netcoreapp3.1) (1 test) Failed: One or more child tests had errors: 1 test failed TestWriteMessageFail Failed: Should have thrown an exception InvalidCredentialsTest (net472) (1 test) Failed: One or more child tests had errors: 1 test failed TestRestartInvalidCredentialsWithFailover Failed: You may not have enabled credential login on the broker. Credentials must be enabled for this test to pass. InvalidCredentialsTest (netcoreapp3.1) (1 test) Failed: One or more child tests had errors: 1 test failed TestRestartInvalidCredentialsWithFailover Failed: You may not have enabled credential login on the broker. Credentials must be enabled for this test to pass. MaxInactivityDurationTest (net472) (2 tests) Failed: One or more child tests had errors: 2 tests failed TestInactivityMonitorThreadLeak (2 tests) Failed: One or more child tests had errors: 2 tests failed TestInactivityMonitorThreadLeak(0) Failed: Handle count grew beyond maximum of 500 on iteration #19. TestInactivityMonitorThreadLeak(1000) Failed: Handle count grew beyond maximum of 500 on iteration #15. MaxInactivityDurationTest (netcoreapp3.1) (2 tests) Failed: One or more child tests had errors: 2 tests failed TestInactivityMonitorThreadLeak (2 tests) Failed: One or more child tests had errors: 2 tests failed
[jira] [Resolved] (AMQNET-637) NMS 2.0
[ https://issues.apache.org/jira/browse/AMQNET-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved AMQNET-637. --- Resolution: Fixed As the 2.0.0 API was released over a year ago I am resolving this. > NMS 2.0 > --- > > Key: AMQNET-637 > URL: https://issues.apache.org/jira/browse/AMQNET-637 > Project: ActiveMQ .Net > Issue Type: Improvement > Components: NMS >Affects Versions: 1.8.0 >Reporter: Michael Andre Pearce >Priority: Major > Fix For: API-2.0.0 > > Time Spent: 19h 20m > Remaining Estimate: 0h > > NMS API is still at JMS 1.1 api level, this is to update the NMS api to the > latest JMS 2.0 api -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (AMQNET-626) TriggerReconnectionAttempt method in FailoverProvider is not awaited
[ https://issues.apache.org/jira/browse/AMQNET-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated AMQNET-626: -- Fix Version/s: (was: 1.8.0) > TriggerReconnectionAttempt method in FailoverProvider is not awaited > > > Key: AMQNET-626 > URL: https://issues.apache.org/jira/browse/AMQNET-626 > Project: ActiveMQ .Net > Issue Type: Bug > Components: AMQP >Reporter: Krzysztof Porębski >Priority: Minor > > **We should revisit FailoverProvider implementation and resolve the issue > with TriggerReconnectionAttempt method not being awaited. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (AMQNET-745) Apache.NMS has an exception for application launched in single file mode
[
https://issues.apache.org/jira/browse/AMQNET-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated AMQNET-745:
--
Affects Version/s: 1.8.0
> Apache.NMS has an exception for application launched in single file mode
>
>
> Key: AMQNET-745
> URL: https://issues.apache.org/jira/browse/AMQNET-745
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
>Affects Versions: 1.8.0
>Reporter: Iuliia Fatkullina
>Priority: Critical
> Fix For: API-1.8.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Apache.NMS library version 1.8.0 and higher has an exception,
> when trying to instantiate the NMSConnectionFactory class,
> if the application is launched in single file mode.
> An example of an exception can be seen when using Apache.NMS.ActiveMQ
> [https://github.com/i7nfinity/apache-nms-singlefile-error]
> Need to fix GetConfigSearchPaths method because
> Path.GetDirectoryName(executingAssembly.Location) returns null in the file
> [https://github.com/apache/activemq-nms-api/blob/main/src/nms-api/NMSConnectionFactory.cs]
> You can read more about the problem here
> [https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file]
> {code:java}
> Could not create the IConnectionFactory implementation: Value cannot be null.
> (Parameter 'path1')
>at Apache.NMS.NMSConnectionFactory.CreateConnectionFactory(Uri
> uriProvider, Object[] constructorParams)
>at Apache.NMS.NMSConnectionFactory..ctor(Uri uriProvider, Object[]
> constructorParams)
>at Apache.NMS.NMSConnectionFactory..ctor(String providerURI, Object[]
> constructorParams)
>at ApacheNmsSingleAppError.Program.Main()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (AMQNET-745) Apache.NMS has an exception for application launched in single file mode
[
https://issues.apache.org/jira/browse/AMQNET-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated AMQNET-745:
--
Affects Version/s: (was: OpenWire-1.8.0)
> Apache.NMS has an exception for application launched in single file mode
>
>
> Key: AMQNET-745
> URL: https://issues.apache.org/jira/browse/AMQNET-745
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
>Reporter: Iuliia Fatkullina
>Priority: Critical
> Fix For: API-1.8.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Apache.NMS library version 1.8.0 and higher has an exception,
> when trying to instantiate the NMSConnectionFactory class,
> if the application is launched in single file mode.
> An example of an exception can be seen when using Apache.NMS.ActiveMQ
> [https://github.com/i7nfinity/apache-nms-singlefile-error]
> Need to fix GetConfigSearchPaths method because
> Path.GetDirectoryName(executingAssembly.Location) returns null in the file
> [https://github.com/apache/activemq-nms-api/blob/main/src/nms-api/NMSConnectionFactory.cs]
> You can read more about the problem here
> [https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file]
> {code:java}
> Could not create the IConnectionFactory implementation: Value cannot be null.
> (Parameter 'path1')
>at Apache.NMS.NMSConnectionFactory.CreateConnectionFactory(Uri
> uriProvider, Object[] constructorParams)
>at Apache.NMS.NMSConnectionFactory..ctor(Uri uriProvider, Object[]
> constructorParams)
>at Apache.NMS.NMSConnectionFactory..ctor(String providerURI, Object[]
> constructorParams)
>at ApacheNmsSingleAppError.Program.Main()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (ARTEMIS-3799) Ping command is wrong on Windows
[ https://issues.apache.org/jira/browse/ARTEMIS-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528750#comment-17528750 ] ASF subversion and git services commented on ARTEMIS-3799: -- Commit 72251dc94798cd1c964286118b4bd206d497ebcd in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=72251dc947 ] ARTEMIS-3799 Fix default ping command pipe error for Windows > Ping command is wrong on Windows > > > Key: ARTEMIS-3799 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3799 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > The ping command used is not working properly on Windows, we should be using > 'ping -n 1 -w %d %s' as the -c option on windows is *Routing compartment > identifier* not the ping count. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3799) Ping command is wrong on Windows
[ https://issues.apache.org/jira/browse/ARTEMIS-3799?focusedWorklogId=762820=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-762820 ] ASF GitHub Bot logged work on ARTEMIS-3799: --- Author: ASF GitHub Bot Created on: 27/Apr/22 11:58 Start Date: 27/Apr/22 11:58 Worklog Time Spent: 10m Work Description: brusdev merged PR #4056: URL: https://github.com/apache/activemq-artemis/pull/4056 Issue Time Tracking --- Worklog Id: (was: 762820) Time Spent: 50m (was: 40m) > Ping command is wrong on Windows > > > Key: ARTEMIS-3799 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3799 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Emmanuel Hugonnet >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > The ping command used is not working properly on Windows, we should be using > 'ping -n 1 -w %d %s' as the -c option on windows is *Routing compartment > identifier* not the ping count. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (AMQNET-745) Apache.NMS has an exception for application launched in single file mode
[
https://issues.apache.org/jira/browse/AMQNET-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved AMQNET-745.
---
Resolution: Fixed
> Apache.NMS has an exception for application launched in single file mode
>
>
> Key: AMQNET-745
> URL: https://issues.apache.org/jira/browse/AMQNET-745
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
>Affects Versions: OpenWire-1.8.0
>Reporter: Iuliia Fatkullina
>Priority: Critical
> Fix For: API-1.8.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Apache.NMS library version 1.8.0 and higher has an exception,
> when trying to instantiate the NMSConnectionFactory class,
> if the application is launched in single file mode.
> An example of an exception can be seen when using Apache.NMS.ActiveMQ
> [https://github.com/i7nfinity/apache-nms-singlefile-error]
> Need to fix GetConfigSearchPaths method because
> Path.GetDirectoryName(executingAssembly.Location) returns null in the file
> [https://github.com/apache/activemq-nms-api/blob/main/src/nms-api/NMSConnectionFactory.cs]
> You can read more about the problem here
> [https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file]
> {code:java}
> Could not create the IConnectionFactory implementation: Value cannot be null.
> (Parameter 'path1')
>at Apache.NMS.NMSConnectionFactory.CreateConnectionFactory(Uri
> uriProvider, Object[] constructorParams)
>at Apache.NMS.NMSConnectionFactory..ctor(Uri uriProvider, Object[]
> constructorParams)
>at Apache.NMS.NMSConnectionFactory..ctor(String providerURI, Object[]
> constructorParams)
>at ApacheNmsSingleAppError.Program.Main()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (AMQNET-745) Apache.NMS has an exception for application launched in single file mode
[
https://issues.apache.org/jira/browse/AMQNET-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated AMQNET-745:
--
Fix Version/s: API-1.8.1
> Apache.NMS has an exception for application launched in single file mode
>
>
> Key: AMQNET-745
> URL: https://issues.apache.org/jira/browse/AMQNET-745
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
>Affects Versions: OpenWire-1.8.0
>Reporter: Iuliia Fatkullina
>Priority: Critical
> Fix For: API-1.8.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Apache.NMS library version 1.8.0 and higher has an exception,
> when trying to instantiate the NMSConnectionFactory class,
> if the application is launched in single file mode.
> An example of an exception can be seen when using Apache.NMS.ActiveMQ
> [https://github.com/i7nfinity/apache-nms-singlefile-error]
> Need to fix GetConfigSearchPaths method because
> Path.GetDirectoryName(executingAssembly.Location) returns null in the file
> [https://github.com/apache/activemq-nms-api/blob/main/src/nms-api/NMSConnectionFactory.cs]
> You can read more about the problem here
> [https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file]
> {code:java}
> Could not create the IConnectionFactory implementation: Value cannot be null.
> (Parameter 'path1')
>at Apache.NMS.NMSConnectionFactory.CreateConnectionFactory(Uri
> uriProvider, Object[] constructorParams)
>at Apache.NMS.NMSConnectionFactory..ctor(Uri uriProvider, Object[]
> constructorParams)
>at Apache.NMS.NMSConnectionFactory..ctor(String providerURI, Object[]
> constructorParams)
>at ApacheNmsSingleAppError.Program.Main()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3759) Allow for Mirroring (Broker Connections) to specify a specific set of addresses to send events, as is done for a cluster connection
[ https://issues.apache.org/jira/browse/ARTEMIS-3759?focusedWorklogId=762812=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-762812 ] ASF GitHub Bot logged work on ARTEMIS-3759: --- Author: ASF GitHub Bot Created on: 27/Apr/22 11:41 Start Date: 27/Apr/22 11:41 Worklog Time Spent: 10m Work Description: iliya-gr commented on code in PR #4054: URL: https://github.com/apache/activemq-artemis/pull/4054#discussion_r859692047 ## artemis-server/src/main/resources/schema/artemis-configuration.xsd: ## @@ -2442,6 +2442,13 @@ + + + + name of the address this mirror connection applies to Review Comment: This is still questionable for me. I don't know what is the better name for this attribute. Because any *-match name will suggest same behavior as in receiver/sender and I suspect that nobody will want to create mirror for each address. I chose this name because it has same meaning as in the cluster configuration and I didn't want to expand terminology. So I am still in doubt. I don't think we should align mirror and receiver/sender filter behavior because they have different use cases. Issue Time Tracking --- Worklog Id: (was: 762812) Time Spent: 1h (was: 50m) > Allow for Mirroring (Broker Connections) to specify a specific set of > addresses to send events, as is done for a cluster connection > - > > Key: ARTEMIS-3759 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3759 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.19.1, 2.21.0 >Reporter: Mikhail Lukyanov >Priority: Major > Attachments: ImageAddressSyntax.png, ImageInternalQueues.png > > Time Spent: 1h > Remaining Estimate: 0h > > If a target broker of mirroring is in a cluster, then mirroring of the > broker's internal queues also occurs, and often messages accumulate in such > queues. In theory, internal cluster queues should not be mirrored, this does > not make much sense. > Therefore, it would be convenient to allow you to configure for which > addresses and their queues mirroring will be performed, events will be sent > (message-acknowledgements, queue-removal, queue-creation). The syntax that is > used to specify the *_addresses_* of the *_cluster connection_* is well > suited for this. > Mirrored internal cluster queues > !ImageInternalQueues.png! > Address syntax > !ImageAddressSyntax.png! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (ARTEMIS-3759) Allow for Mirroring (Broker Connections) to specify a specific set of addresses to send events, as is done for a cluster connection
[
https://issues.apache.org/jira/browse/ARTEMIS-3759?focusedWorklogId=762792=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-762792
]
ASF GitHub Bot logged work on ARTEMIS-3759:
---
Author: ASF GitHub Bot
Created on: 27/Apr/22 10:45
Start Date: 27/Apr/22 10:45
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4054:
URL: https://github.com/apache/activemq-artemis/pull/4054#discussion_r859618348
##
artemis-server/src/main/resources/schema/artemis-configuration.xsd:
##
@@ -2442,6 +2442,13 @@
+
+
+
+ name of the address this mirror connection applies to
Review Comment:
Its not just a simple address name it is taking, so this feels like the
wrong attribute name and description. Something conveying the 'filter' nature
would seem appropriate. The format of what it does take isnt mentioned , so
besides the test usage its unclear how anyone would know. There should be doc
updates to e.g
https://github.com/apache/activemq-artemis/blob/2.21.0/docs/user-manual/en/amqp-broker-connections.md#mirror-configuration
to cover whatever the changes ends up being.
Other 'broker connections' stuff such as the sender+receiver already take
"address-match" or "queue-match", as shown in the context of the config change
in ConfigurationTest-full-config.xml. It would also seem reasonable to align
the terminology between them if possible (and perhaps even the syntax and/or
implementation; they are implemented a _completely_ different way currently,
which doesnt seem that obvious).
##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/connect/mirror/AMQPMirrorControllerSource.java:
##
@@ -337,4 +368,52 @@ public boolean isMirrorController() {
return true;
}
}
+
+ public static class AddressFilter {
Review Comment:
This seems like it could be private, or just be its own class, rather than
being public so that AMQPMirrorControllerSourceTest can use it for testing,
without ever testing anything general of AMQPMirrorControllerSource itself.
##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/connect/AMQPReplicaTest.java:
##
@@ -473,6 +473,52 @@ public void testNoAddressWithAnnotations() throws
Exception {
}
}
+ @Test
+ public void testAddressFilterMet() throws Exception {
+ addressTest("test", true, 0);
Review Comment:
Using a 0 wait seems potentially susceptible to failure, as the mirroring
isnt synchronous. I know its only checking for > 0 messages being mirrored, but
I'd still make it more robust personally. Perhaps just changing it to wait for
them all to be mirrored as we do expect them to quickly be. Actually, no need
for sending 200 messages either given it doesnt actually look at any of them,
sending a couple is enough, and it should look.
I would also remove the 1 second wait in the 'no match' case and replace it
with better verification by other means, e.g monitor the mirroring SnF queue
having not had any messages added when the send is done, or just nothing being
present for that target even when subsequently-sent matching stuff has already
been received from the other, or both
E.g combine this into one test that sends a non-matching and then matching
message in that order and then in the reverse order checks the matching
consumer does get a message (receive(timeout)) and the non-matching consumer
does not (receiveNoWait) from their respective target queues. Faster and more
reliable, verification of what actually happened / actual use. (It could
perhaps even monitor the mirror SnF queue during and after, verifying nothing
got added to the SnF queue for the non-matching case, and is added for the
matching case).
Issue Time Tracking
---
Worklog Id: (was: 762792)
Time Spent: 50m (was: 40m)
> Allow for Mirroring (Broker Connections) to specify a specific set of
> addresses to send events, as is done for a cluster connection
> -
>
> Key: ARTEMIS-3759
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3759
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: AMQP
>Affects Versions: 2.19.1, 2.21.0
>Reporter: Mikhail Lukyanov
>Priority: Major
> Attachments: ImageAddressSyntax.png, ImageInternalQueues.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If a target broker of mirroring is in a cluster, then mirroring of the
> broker's internal queues also occurs, and often
