[jira] [Work logged] (AMQ-8316) Remove deprecated BrokerService methods

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/AMQ-8316?focusedWorklogId=640396=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640396
 ]

ASF GitHub Bot logged work on AMQ-8316:
---

Author: ASF GitHub Bot
Created on: 20/Aug/21 21:17
Start Date: 20/Aug/21 21:17
Worklog Time Spent: 10m 
  Work Description: mattrpav commented on a change in pull request #700:
URL: https://github.com/apache/activemq/pull/700#discussion_r693222941



##
File path: 
activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
##
@@ -153,9 +153,7 @@
 private boolean useLoggingForShutdownErrors;
 private boolean shutdownOnMasterFailure;
 private boolean shutdownOnSlaveFailure;
-private boolean waitForSlave;
 private long waitForSlaveTimeout = DEFAULT_START_TIMEOUT;

Review comment:
   If waitForSlave can be removed, can waitForSlaveTimeout also be removed? 




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 640396)
Time Spent: 20m  (was: 10m)

> Remove deprecated BrokerService methods 
> 
>
> Key: AMQ-8316
> URL: https://issues.apache.org/jira/browse/AMQ-8316
> Project: ActiveMQ
>  Issue Type: Sub-task
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Legacy BrokerService methods are unused and should be removed
> Methods targeted for removal:
> isWaitForSlave()



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (ARTEMIS-3438) Legacy updateQueue doesn't respect ringSize

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3438?focusedWorklogId=640391=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640391
 ]

ASF GitHub Bot logged work on ARTEMIS-3438:
---

Author: ASF GitHub Bot
Created on: 20/Aug/21 21:00
Start Date: 20/Aug/21 21:00
Worklog Time Spent: 10m 
  Work Description: asfgit closed pull request #3703:
URL: https://github.com/apache/activemq-artemis/pull/3703


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 640391)
Remaining Estimate: 0h
Time Spent: 10m

> Legacy updateQueue doesn't respect ringSize
> ---
>
> Key: ARTEMIS-3438
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3438
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARTEMIS-3438) Legacy updateQueue doesn't respect ringSize

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402419#comment-17402419
 ] 

ASF subversion and git services commented on ARTEMIS-3438:
--

Commit 3fd0eea66704793927b42e88e46c3f08f27f372b in activemq-artemis's branch 
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3fd0eea ]

ARTEMIS-3438 legacy updateQueue doesn't respect ringSize


> Legacy updateQueue doesn't respect ringSize
> ---
>
> Key: ARTEMIS-3438
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3438
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (AMQ-7514) Replace use of non-inclusive terms throughout source code, comments and documentation

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/AMQ-7514?focusedWorklogId=640390=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640390
 ]

ASF GitHub Bot logged work on AMQ-7514:
---

Author: ASF GitHub Bot
Created on: 20/Aug/21 20:58
Start Date: 20/Aug/21 20:58
Worklog Time Spent: 10m 
  Work Description: ehossack-aws commented on a change in pull request #679:
URL: https://github.com/apache/activemq/pull/679#discussion_r693215288



##
File path: 
activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
##
@@ -485,15 +490,15 @@ public JmsConnector removeJmsConnector(JmsConnector 
connector) {
 }
 
 public void masterFailed() {
-if (shutdownOnMasterFailure) {
-LOG.error("The Master has failed ... shutting down");
+if (shutdownOnActiveFailure) {
+LOG.error("The Active has failed ... shutting down");

Review comment:
   as per @mattrpav 's AMQ-8316, moved the two concretely deprecated 
messages out of this PR

##
File path: 
activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
##
@@ -485,15 +490,15 @@ public JmsConnector removeJmsConnector(JmsConnector 
connector) {
 }
 
 public void masterFailed() {
-if (shutdownOnMasterFailure) {
-LOG.error("The Master has failed ... shutting down");
+if (shutdownOnActiveFailure) {
+LOG.error("The Active has failed ... shutting down");

Review comment:
   as per @mattrpav 's AMQ-8316, moved the two concretely deprecated 
messages out of this PR into https://github.com/apache/activemq/pull/700




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 640390)
Time Spent: 4h 50m  (was: 4h 40m)

> Replace use of non-inclusive terms throughout source code, comments and 
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
>  Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must 
> pull together to create a plan for changing any such terms throughout all the 
> ActiveMQ projects and in the git repos themselves.
>   
>  Example: [https://activemq.apache.org/masterslave.html]
>   
>  Here are just a few terms that should be changed: * The following terms are 
> being targeted for change:
>  * 
>  ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
>  ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' 
> and 'denylist'
>  * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1: 
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2: 
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ 
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (AMQ-8316) Remove deprecated BrokerService methods

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/AMQ-8316?focusedWorklogId=640389=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640389
 ]

ASF GitHub Bot logged work on AMQ-8316:
---

Author: ASF GitHub Bot
Created on: 20/Aug/21 20:55
Start Date: 20/Aug/21 20:55
Worklog Time Spent: 10m 
  Work Description: ehossack-aws opened a new pull request #700:
URL: https://github.com/apache/activemq/pull/700


   This removes passiveSlave and waitForSlave which are no longer used


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 640389)
Remaining Estimate: 0h
Time Spent: 10m

> Remove deprecated BrokerService methods 
> 
>
> Key: AMQ-8316
> URL: https://issues.apache.org/jira/browse/AMQ-8316
> Project: ActiveMQ
>  Issue Type: Sub-task
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Legacy BrokerService methods are unused and should be removed
> Methods targeted for removal:
> isWaitForSlave()



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (ARTEMIS-3422) Message deletion via web console causes NullPointerException if log level >= INFO

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3422?focusedWorklogId=640379=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640379
 ]

ASF GitHub Bot logged work on ARTEMIS-3422:
---

Author: ASF GitHub Bot
Created on: 20/Aug/21 20:33
Start Date: 20/Aug/21 20:33
Worklog Time Spent: 10m 
  Work Description: asfgit closed pull request #3705:
URL: https://github.com/apache/activemq-artemis/pull/3705


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 640379)
Remaining Estimate: 0h
Time Spent: 10m

> Message deletion via web console causes NullPointerException if log level >= 
> INFO
> -
>
> Key: ARTEMIS-3422
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3422
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: JMX, Web Console
>Affects Versions: 2.18.0
> Environment: Embedded Apache Artemis 2.18.0
> Windows Server 2016 Standard (10.0.14393)
> Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
>Reporter: Christian Danner
>Assignee: Justin Bertram
>Priority: Minor
> Attachments: full_stack.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When deleting a message from a queue using the web console a 
> NullPointerException is thrown on the server side when committing the 
> transaction.
> This only happens in case logger.level=INFO or higher is used because the 
> Exception occurs when trying to log the acknowledge for the deleted message.
> The reason is that the ServerConsumer used to determine the session is null 
> at this point as it is not provided by the caller.
> The attached stack trace shows the exact location.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARTEMIS-3422) Message deletion via web console causes NullPointerException if log level >= INFO

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402406#comment-17402406
 ] 

ASF subversion and git services commented on ARTEMIS-3422:
--

Commit c8d71cbebc2a109bd3256c1d8f405b8ea31a1c50 in activemq-artemis's branch 
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c8d71cb ]

ARTEMIS-3422 mitigate NPE for audit logging


> Message deletion via web console causes NullPointerException if log level >= 
> INFO
> -
>
> Key: ARTEMIS-3422
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3422
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: JMX, Web Console
>Affects Versions: 2.18.0
> Environment: Embedded Apache Artemis 2.18.0
> Windows Server 2016 Standard (10.0.14393)
> Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
>Reporter: Christian Danner
>Assignee: Justin Bertram
>Priority: Minor
> Attachments: full_stack.txt
>
>
> When deleting a message from a queue using the web console a 
> NullPointerException is thrown on the server side when committing the 
> transaction.
> This only happens in case logger.level=INFO or higher is used because the 
> Exception occurs when trying to log the acknowledge for the deleted message.
> The reason is that the ServerConsumer used to determine the session is null 
> at this point as it is not provided by the caller.
> The attached stack trace shows the exact location.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARTEMIS-3422) Message deletion via web console causes NullPointerException if log level >= INFO

[Justin Bertram (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402389#comment-17402389
 ] 

Justin Bertram commented on ARTEMIS-3422:
-

Thanks for the report, [~perdurabo]!

> Message deletion via web console causes NullPointerException if log level >= 
> INFO
> -
>
> Key: ARTEMIS-3422
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3422
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: JMX, Web Console
>Affects Versions: 2.18.0
> Environment: Embedded Apache Artemis 2.18.0
> Windows Server 2016 Standard (10.0.14393)
> Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
>Reporter: Christian Danner
>Assignee: Justin Bertram
>Priority: Minor
> Attachments: full_stack.txt
>
>
> When deleting a message from a queue using the web console a 
> NullPointerException is thrown on the server side when committing the 
> transaction.
> This only happens in case logger.level=INFO or higher is used because the 
> Exception occurs when trying to log the acknowledge for the deleted message.
> The reason is that the ServerConsumer used to determine the session is null 
> at this point as it is not provided by the caller.
> The attached stack trace shows the exact location.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (ARTEMIS-3422) Message deletion via web console causes NullPointerException if log level >= INFO

[Justin Bertram (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram reassigned ARTEMIS-3422:
---

Assignee: Justin Bertram

> Message deletion via web console causes NullPointerException if log level >= 
> INFO
> -
>
> Key: ARTEMIS-3422
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3422
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: JMX, Web Console
>Affects Versions: 2.18.0
> Environment: Embedded Apache Artemis 2.18.0
> Windows Server 2016 Standard (10.0.14393)
> Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
>Reporter: Christian Danner
>Assignee: Justin Bertram
>Priority: Minor
> Attachments: full_stack.txt
>
>
> When deleting a message from a queue using the web console a 
> NullPointerException is thrown on the server side when committing the 
> transaction.
> This only happens in case logger.level=INFO or higher is used because the 
> Exception occurs when trying to log the acknowledge for the deleted message.
> The reason is that the ServerConsumer used to determine the session is null 
> at this point as it is not provided by the caller.
> The attached stack trace shows the exact location.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (ARTEMIS-3436) Expose Retention as a JMX Operation replay

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3436?focusedWorklogId=640351=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640351
 ]

ASF GitHub Bot logged work on ARTEMIS-3436:
---

Author: ASF GitHub Bot
Created on: 20/Aug/21 18:58
Start Date: 20/Aug/21 18:58
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on a change in pull request 
#3704:
URL: https://github.com/apache/activemq-artemis/pull/3704#discussion_r693157727



##
File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
##
@@ -480,8 +481,14 @@ public NetworkHealthCheck getNetworkHealthCheck() {
   return networkHealthCheck;
}
 
-   // life-cycle methods
-   // 
+
+   @Override
+   public void replay(Date start, Date end, String address, String target, 
String filter) throws Exception {
+  if (replayManager == null) {
+ throw new NullPointerException("replayManager not set");

Review comment:
   I will use the logger...




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 640351)
Time Spent: 40m  (was: 0.5h)

> Expose Retention as a JMX Operation replay
> --
>
> Key: ARTEMIS-3436
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3436
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Clebert Suconic
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This should expose the journal retention as an operation replay on the JMX 
> Console.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (ARTEMIS-3436) Expose Retention as a JMX Operation replay

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3436?focusedWorklogId=640350=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640350
 ]

ASF GitHub Bot logged work on ARTEMIS-3436:
---

Author: ASF GitHub Bot
Created on: 20/Aug/21 18:57
Start Date: 20/Aug/21 18:57
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on a change in pull request 
#3704:
URL: https://github.com/apache/activemq-artemis/pull/3704#discussion_r693157255



##
File path: 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/management/ActiveMQServerControlTest.java
##
@@ -4048,6 +4053,109 @@ public void testResetUser() throws Exception {
   }
}
 
+   @Test
+   public void testReplayWithoutDate() throws Exception {
+  testReplaySimple(false);
+   }
+
+   @Test
+   public void testReplayWithDate() throws Exception {
+  testReplaySimple(true);
+   }
+
+   private void testReplaySimple(boolean useDate) throws Exception {
+  ActiveMQServerControl serverControl = createManagementControl();
+  String queue = "testQueue" + RandomUtil.randomString();
+  server.addAddressInfo(new 
AddressInfo(queue).addRoutingType(RoutingType.ANYCAST));
+  server.createQueue(new 
QueueConfiguration(queue).setRoutingType(RoutingType.ANYCAST).setAddress(queue));
+
+  ConnectionFactory factory = CFUtil.createConnectionFactory("core", 
"tcp://localhost:61616");
+  try (Connection connection = factory.createConnection()) {
+ Session session = connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);
+ javax.jms.Queue jmsQueue = session.createQueue(queue);
+ MessageProducer producer = session.createProducer(jmsQueue);
+ producer.send(session.createTextMessage("before"));
+
+ connection.start();
+ MessageConsumer consumer = session.createConsumer(jmsQueue);
+ Assert.assertNotNull(consumer.receive(5000));
+ Assert.assertNull(consumer.receiveNoWait());
+
+ serverControl.replay(queue, queue, null);
+ Assert.assertNotNull(consumer.receive(5000));
+ Assert.assertNull(consumer.receiveNoWait());
+
+ if (useDate) {
+serverControl.replay("dontexist", "dontexist", null); // just to 
force a move next file, and copy stuff into place
+SimpleDateFormat format = new SimpleDateFormat("MMddHHmmss");
+Thread.sleep(1000); // waiting a second just to have the timestamp 
change
+String dateEnd = format.format(new Date());
+Thread.sleep(1000); // waiting a second just to have the timestamp 
change
+System.out.println("Date End " + dateEnd);

Review comment:
   remove this...




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 640350)
Time Spent: 0.5h  (was: 20m)

> Expose Retention as a JMX Operation replay
> --
>
> Key: ARTEMIS-3436
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3436
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Clebert Suconic
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This should expose the journal retention as an operation replay on the JMX 
> Console.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (ARTEMIS-3436) Expose Retention as a JMX Operation replay

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3436?focusedWorklogId=640349=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640349
 ]

ASF GitHub Bot logged work on ARTEMIS-3436:
---

Author: ASF GitHub Bot
Created on: 20/Aug/21 18:57
Start Date: 20/Aug/21 18:57
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on a change in pull request 
#3704:
URL: https://github.com/apache/activemq-artemis/pull/3704#discussion_r693156951



##
File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/ActiveMQServerControlImpl.java
##
@@ -4438,5 +4440,24 @@ private PropertiesLoginModuleConfigurator 
getPropertiesLoginModuleConfigurator()
public void reloadConfigurationFile() throws Exception {
   server.reloadConfigurationFile();
}
+
+   @Override
+   public void replay(String address, String target, String filter) throws 
Exception {
+  server.replay(null, null, address, target, filter);
+   }
+
+   @Override
+   public void replay(String startScan, String endScan, String address, String 
target, String filter) throws Exception {
+
+  SimpleDateFormat format = ReplayManager.newRetentionSimpleDateFormat();
+
+  Date startScanDate = format.parse(startScan);
+  Date endScanDate = format.parse(endScan);
+
+  System.out.println("Start date :: " + startScanDate + " formatted as " + 
format.format(startScanDate));

Review comment:
   forgot some system.out here.. I will remove it.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 640349)
Time Spent: 20m  (was: 10m)

> Expose Retention as a JMX Operation replay
> --
>
> Key: ARTEMIS-3436
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3436
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Clebert Suconic
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This should expose the journal retention as an operation replay on the JMX 
> Console.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (ARTEMIS-3436) Expose Retention as a JMX Operation replay

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3436?focusedWorklogId=640348=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640348
 ]

ASF GitHub Bot logged work on ARTEMIS-3436:
---

Author: ASF GitHub Bot
Created on: 20/Aug/21 18:56
Start Date: 20/Aug/21 18:56
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on a change in pull request 
#3704:
URL: https://github.com/apache/activemq-artemis/pull/3704#discussion_r693156764



##
File path: 
artemis-journal/src/main/java/org/apache/activemq/artemis/core/journal/impl/JournalImpl.java
##
@@ -2891,6 +2891,21 @@ public void forceMoveNextFile() throws Exception {
   }
}
 
+   @Override
+   public void forceBackup() throws Exception {

Review comment:
   Doing my own review here, I'm going to send a parameter to the wait 
latch...




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 640348)
Remaining Estimate: 0h
Time Spent: 10m

> Expose Retention as a JMX Operation replay
> --
>
> Key: ARTEMIS-3436
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3436
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Clebert Suconic
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This should expose the journal retention as an operation replay on the JMX 
> Console.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARTEMIS-3437) java.lang.NumberFormatException STOMP/AMQP interop

[Justin Bertram (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402378#comment-17402378
 ] 

Justin Bertram commented on ARTEMIS-3437:
-

Looking at the exception more closely I see that it's simply caught and logged 
at {{DEBUG}}. Therefore it would seem this doesn't actually pose a problem.

Do you have a way to reproduce the behavior you're seeing which you could share 
here?

> java.lang.NumberFormatException STOMP/AMQP interop
> --
>
> Key: ARTEMIS-3437
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3437
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.18.0
> Environment: win10 21h1 x64
> jdk-15.0.1
> Artemis 2.18.0
>Reporter: daves
>Priority: Major
>
> I’ve a client which sends STOMP messages to a Artemis broker (2.18.0).
> The server is currently consuming the messages using STOMP as well.
> I’m not happy with my STOMP library and there are no good alternatives.
> Therefore, I would like to switch to AMQP for the server. 
> …as far as I understand the client and server can use a different 
> protocol…right? 
> Consuming messages with the new AMQP code works…but after a few messages the 
> broker stops sending new messages to my client. The current implementation 
> consumes one message at a time and sends a accept after each message… 
> In the Artemis Log I can find entry like this when the broker stops sending 
> messages to my AMQP client:
>  
> {noformat}
> 2021-08-20 19:40:54,946 DEBUG 
> [org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMessageWrapper]
>  null: java.lang.NumberFormatException: null
> at java.base/java.lang.Integer.parseInt(Integer.java:614) [java.base:]
> at java.base/java.lang.Short.parseShort(Short.java:130) [java.base:]
> at java.base/java.lang.Short.valueOf(Short.java:186) [java.base:]
> at java.base/java.lang.Short.valueOf(Short.java:212) [java.base:]
> at 
> org.apache.activemq.artemis.utils.collections.TypedProperties.getShortProperty(TypedProperties.java:257)
>  [artemis-commons-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.core.message.impl.CoreMessage.getShortProperty(CoreMessage.java:1044)
>  [artemis-core-client-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.core.message.impl.CoreMessage.getShortProperty(CoreMessage.java:1049)
>  [artemis-core-client-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMessageWrapper.getOrignalEncoding(CoreMessageWrapper.java:78)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreBytesMessageWrapper.createAMQPSection(CoreBytesMessageWrapper.java:77)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:108)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:83)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.executeDelivery(ProtonServerSenderContext.java:537)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
>  [artemis-server-2.18.0.jar:2.18.0]
> at 
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
>  [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
>  [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500) 
> [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
>  [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) 
> [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
>  [artemis-commons-2.18.0.jar:2.18.0]{noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (ARTEMIS-3437) java.lang.NumberFormatException STOMP/AMQP interop

[Justin Bertram (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram updated ARTEMIS-3437:

Environment: 
win10 21h1 x64
jdk-15.0.1

  was:
win10 21h1 x64

jdk-15.0.1

Artemis 2.18.0


> java.lang.NumberFormatException STOMP/AMQP interop
> --
>
> Key: ARTEMIS-3437
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3437
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.18.0
> Environment: win10 21h1 x64
> jdk-15.0.1
>Reporter: daves
>Priority: Major
>
> I’ve a client which sends STOMP messages to a Artemis broker (2.18.0).
> The server is currently consuming the messages using STOMP as well.
> I’m not happy with my STOMP library and there are no good alternatives.
> Therefore, I would like to switch to AMQP for the server. 
> …as far as I understand the client and server can use a different 
> protocol…right? 
> Consuming messages with the new AMQP code works…but after a few messages the 
> broker stops sending new messages to my client. The current implementation 
> consumes one message at a time and sends a accept after each message… 
> In the Artemis Log I can find entry like this when the broker stops sending 
> messages to my AMQP client:
>  
> {noformat}
> 2021-08-20 19:40:54,946 DEBUG 
> [org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMessageWrapper]
>  null: java.lang.NumberFormatException: null
> at java.base/java.lang.Integer.parseInt(Integer.java:614) [java.base:]
> at java.base/java.lang.Short.parseShort(Short.java:130) [java.base:]
> at java.base/java.lang.Short.valueOf(Short.java:186) [java.base:]
> at java.base/java.lang.Short.valueOf(Short.java:212) [java.base:]
> at 
> org.apache.activemq.artemis.utils.collections.TypedProperties.getShortProperty(TypedProperties.java:257)
>  [artemis-commons-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.core.message.impl.CoreMessage.getShortProperty(CoreMessage.java:1044)
>  [artemis-core-client-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.core.message.impl.CoreMessage.getShortProperty(CoreMessage.java:1049)
>  [artemis-core-client-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMessageWrapper.getOrignalEncoding(CoreMessageWrapper.java:78)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreBytesMessageWrapper.createAMQPSection(CoreBytesMessageWrapper.java:77)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:108)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:83)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.executeDelivery(ProtonServerSenderContext.java:537)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
>  [artemis-server-2.18.0.jar:2.18.0]
> at 
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
>  [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
>  [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500) 
> [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
>  [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) 
> [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
>  [artemis-commons-2.18.0.jar:2.18.0]{noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARTEMIS-3437) java.lang.NumberFormatException STOMP/AMQP interop

[Justin Bertram (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402377#comment-17402377
 ] 

Justin Bertram commented on ARTEMIS-3437:
-

bq. …as far as I understand the client and server can use a different 
protocol…right? 

That's correct.

Do you have an example of the kind of STOMP {{SEND}} frame that triggers this 
exception?

> java.lang.NumberFormatException STOMP/AMQP interop
> --
>
> Key: ARTEMIS-3437
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3437
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.18.0
> Environment: win10 21h1 x64
> jdk-15.0.1
> Artemis 2.18.0
>Reporter: daves
>Priority: Major
>
> I’ve a client which sends STOMP messages to a Artemis broker (2.18.0).
> The server is currently consuming the messages using STOMP as well.
> I’m not happy with my STOMP library and there are no good alternatives.
> Therefore, I would like to switch to AMQP for the server. 
> …as far as I understand the client and server can use a different 
> protocol…right? 
> Consuming messages with the new AMQP code works…but after a few messages the 
> broker stops sending new messages to my client. The current implementation 
> consumes one message at a time and sends a accept after each message… 
> In the Artemis Log I can find entry like this when the broker stops sending 
> messages to my AMQP client:
>  
> {noformat}
> 2021-08-20 19:40:54,946 DEBUG 
> [org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMessageWrapper]
>  null: java.lang.NumberFormatException: null
> at java.base/java.lang.Integer.parseInt(Integer.java:614) [java.base:]
> at java.base/java.lang.Short.parseShort(Short.java:130) [java.base:]
> at java.base/java.lang.Short.valueOf(Short.java:186) [java.base:]
> at java.base/java.lang.Short.valueOf(Short.java:212) [java.base:]
> at 
> org.apache.activemq.artemis.utils.collections.TypedProperties.getShortProperty(TypedProperties.java:257)
>  [artemis-commons-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.core.message.impl.CoreMessage.getShortProperty(CoreMessage.java:1044)
>  [artemis-core-client-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.core.message.impl.CoreMessage.getShortProperty(CoreMessage.java:1049)
>  [artemis-core-client-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMessageWrapper.getOrignalEncoding(CoreMessageWrapper.java:78)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreBytesMessageWrapper.createAMQPSection(CoreBytesMessageWrapper.java:77)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:108)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:83)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.executeDelivery(ProtonServerSenderContext.java:537)
>  [artemis-amqp-protocol-2.18.0.jar:2.18.0]
> at 
> org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
>  [artemis-server-2.18.0.jar:2.18.0]
> at 
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
>  [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
>  [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500) 
> [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
>  [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) 
> [netty-all-4.1.66.Final.jar:4.1.66.Final]
> at 
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
>  [artemis-commons-2.18.0.jar:2.18.0]{noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (ARTEMIS-3437) java.lang.NumberFormatException STOMP/AMQP interop

[Justin Bertram (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram updated ARTEMIS-3437:

Description: 
I’ve a client which sends STOMP messages to a Artemis broker (2.18.0).

The server is currently consuming the messages using STOMP as well.

I’m not happy with my STOMP library and there are no good alternatives.

Therefore, I would like to switch to AMQP for the server. 

…as far as I understand the client and server can use a different 
protocol…right? 

Consuming messages with the new AMQP code works…but after a few messages the 
broker stops sending new messages to my client. The current implementation 
consumes one message at a time and sends a accept after each message… 

In the Artemis Log I can find entry like this when the broker stops sending 
messages to my AMQP client:
 
{noformat}
2021-08-20 19:40:54,946 DEBUG 
[org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMessageWrapper]
 null: java.lang.NumberFormatException: null
at java.base/java.lang.Integer.parseInt(Integer.java:614) [java.base:]
at java.base/java.lang.Short.parseShort(Short.java:130) [java.base:]
at java.base/java.lang.Short.valueOf(Short.java:186) [java.base:]
at java.base/java.lang.Short.valueOf(Short.java:212) [java.base:]
at 
org.apache.activemq.artemis.utils.collections.TypedProperties.getShortProperty(TypedProperties.java:257)
 [artemis-commons-2.18.0.jar:2.18.0]
at 
org.apache.activemq.artemis.core.message.impl.CoreMessage.getShortProperty(CoreMessage.java:1044)
 [artemis-core-client-2.18.0.jar:2.18.0]
at 
org.apache.activemq.artemis.core.message.impl.CoreMessage.getShortProperty(CoreMessage.java:1049)
 [artemis-core-client-2.18.0.jar:2.18.0]
at 
org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMessageWrapper.getOrignalEncoding(CoreMessageWrapper.java:78)
 [artemis-amqp-protocol-2.18.0.jar:2.18.0]
at 
org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreBytesMessageWrapper.createAMQPSection(CoreBytesMessageWrapper.java:77)
 [artemis-amqp-protocol-2.18.0.jar:2.18.0]
at 
org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:108)
 [artemis-amqp-protocol-2.18.0.jar:2.18.0]
at 
org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:83)
 [artemis-amqp-protocol-2.18.0.jar:2.18.0]
at 
org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.executeDelivery(ProtonServerSenderContext.java:537)
 [artemis-amqp-protocol-2.18.0.jar:2.18.0]
at 
org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
 [artemis-server-2.18.0.jar:2.18.0]
at 
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
 [netty-all-4.1.66.Final.jar:4.1.66.Final]
at 
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
 [netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500) 
[netty-all-4.1.66.Final.jar:4.1.66.Final]
at 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
 [netty-all-4.1.66.Final.jar:4.1.66.Final]
at 
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) 
[netty-all-4.1.66.Final.jar:4.1.66.Final]
at 
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
 [artemis-commons-2.18.0.jar:2.18.0]{noformat}
 

  was:
I’ve a client which sends STOMP messages to a Artemis broker (2.18.0).

The server is currently consuming the messages using STOMP as well.

I’m not happy with my STOMP library and there are no good alternatives.

Therefore, I would like to switch to AMQP for the server.

 

…as far as I understand the client and server can use a different 
protocol…right?

 

Consuming messages with the new AMQP code works…but after a few messages the 
broker stops sending new messages to my client. The current implementation 
consumes one message at a time and sends a accept after each message…

 

In the Artemis Log I can find entry like this when the broker stops sending 
messages to my AMQP client:

 

 
{code:java}
2021-08-20 19:40:54,946 DEBUG 
[org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMessageWrapper]
 null: java.lang.NumberFormatException: nullat 
java.base/java.lang.Integer.parseInt(Integer.java:614) [java.base:]at 
java.base/java.lang.Short.parseShort(Short.java:130) [java.base:]at 
java.base/java.lang.Short.valueOf(Short.java:186) [java.base:]at 
java.base/java.lang.Short.valueOf(Short.java:212) [java.base:]at 
org.apache.activemq.artemis.utils.collections.TypedProperties.getShortProperty(TypedProperties.java:257)
 [artemis-commons-2.18.0.jar:2.18.0]at 

[jira] [Created] (ARTEMIS-3438) Legacy updateQueue doesn't respect ringSize

[Justin Bertram (Jira)]

Justin Bertram created ARTEMIS-3438:
---

 Summary: Legacy updateQueue doesn't respect ringSize
 Key: ARTEMIS-3438
 URL: https://issues.apache.org/jira/browse/ARTEMIS-3438
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Reporter: Justin Bertram
Assignee: Justin Bertram






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (ARTEMIS-3437) java.lang.NumberFormatException STOMP/AMQP interop

[daves (Jira)]

daves created ARTEMIS-3437:
--

 Summary: java.lang.NumberFormatException STOMP/AMQP interop
 Key: ARTEMIS-3437
 URL: https://issues.apache.org/jira/browse/ARTEMIS-3437
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: AMQP
Affects Versions: 2.18.0
 Environment: win10 21h1 x64

jdk-15.0.1

Artemis 2.18.0
Reporter: daves


I’ve a client which sends STOMP messages to a Artemis broker (2.18.0).

The server is currently consuming the messages using STOMP as well.

I’m not happy with my STOMP library and there are no good alternatives.

Therefore, I would like to switch to AMQP for the server.

 

…as far as I understand the client and server can use a different 
protocol…right?

 

Consuming messages with the new AMQP code works…but after a few messages the 
broker stops sending new messages to my client. The current implementation 
consumes one message at a time and sends a accept after each message…

 

In the Artemis Log I can find entry like this when the broker stops sending 
messages to my AMQP client:

 

 
{code:java}
2021-08-20 19:40:54,946 DEBUG 
[org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMessageWrapper]
 null: java.lang.NumberFormatException: nullat 
java.base/java.lang.Integer.parseInt(Integer.java:614) [java.base:]at 
java.base/java.lang.Short.parseShort(Short.java:130) [java.base:]at 
java.base/java.lang.Short.valueOf(Short.java:186) [java.base:]at 
java.base/java.lang.Short.valueOf(Short.java:212) [java.base:]at 
org.apache.activemq.artemis.utils.collections.TypedProperties.getShortProperty(TypedProperties.java:257)
 [artemis-commons-2.18.0.jar:2.18.0]at 
org.apache.activemq.artemis.core.message.impl.CoreMessage.getShortProperty(CoreMessage.java:1044)
 [artemis-core-client-2.18.0.jar:2.18.0]at 
org.apache.activemq.artemis.core.message.impl.CoreMessage.getShortProperty(CoreMessage.java:1049)
 [artemis-core-client-2.18.0.jar:2.18.0]at 
org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMessageWrapper.getOrignalEncoding(CoreMessageWrapper.java:78)
 [artemis-amqp-protocol-2.18.0.jar:2.18.0]at 
org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreBytesMessageWrapper.createAMQPSection(CoreBytesMessageWrapper.java:77)
 [artemis-amqp-protocol-2.18.0.jar:2.18.0]at 
org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:108)
 [artemis-amqp-protocol-2.18.0.jar:2.18.0]at 
org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:83)
 [artemis-amqp-protocol-2.18.0.jar:2.18.0]at 
org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.executeDelivery(ProtonServerSenderContext.java:537)
 [artemis-amqp-protocol-2.18.0.jar:2.18.0]at 
org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:136)
 [artemis-server-2.18.0.jar:2.18.0]at 
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
 [netty-all-4.1.66.Final.jar:4.1.66.Final]at 
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
 [netty-all-4.1.66.Final.jar:4.1.66.Final]at 
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500) 
[netty-all-4.1.66.Final.jar:4.1.66.Final]at 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
 [netty-all-4.1.66.Final.jar:4.1.66.Final]at 
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) 
[netty-all-4.1.66.Final.jar:4.1.66.Final]at 
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
 [artemis-commons-2.18.0.jar:2.18.0]{code}
 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARTEMIS-3435) ActiveMQTestBase.checkLibaio waits can cause hours to be added to failing test suite

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402276#comment-17402276
 ] 

ASF subversion and git services commented on ARTEMIS-3435:
--

Commit 02a829682130e7899f58845baca245b0264ebfcb in activemq-artemis's branch 
refs/heads/main from Robbie Gemmell
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=02a8296 ]

ARTEMIS-3435: fail-fast if AIO check fouls, rather than burning hours and still 
failing, and report/log detals to aid analysis


> ActiveMQTestBase.checkLibaio waits can cause hours to be added to failing 
> test suite
> 
>
> Key: ARTEMIS-3435
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3435
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: Tests
>Affects Versions: 2.18.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> I recently observered a 'full test' run take over an extra 3 hours, 
> essentially doubling the time to 6hrs 40mins (repeated, it took 3hrs 30mins), 
> with nearly 450 failures in the integration-tests module mostly all due to 
> the same 'test did not close all its files 4096' reason.
> Investigating, I found that all the failures appeared linked and were likely 
> caused by a single prior test having done something awry, with the effect 
> then continuing to fail all subsequent tests classes (after they had run 
> their tests, successfully or otherwise) using the same ActiveMQTestBase 
> parent class for the same reason. Before invoking the fail it waits 30 
> seconds for the ActiveMQTestBase.checkLibaio check to assert a value hits 
> 0after the test class, which it repeatedly didnt. This added 400+ 30sec waits 
> to the test run, failing those 400+ test classes.
> I wasnt able to get all the classes in the output summary, the continued test 
> output filled the buffer, but I got a couple snippets:
> {noformat}
> [ERROR] Failures: 
> [ERROR] 
> QuorumFailOverTest.testQuorumVotingLiveNotDead:143->ClusterTestBase.verifyReceiveRoundRobinInSomeOrder:1167->Assert.assertNotNull:713->Assert.assertTrue:42->Assert.fail:89
>  msg must exist
> [ERROR] 
> PluggableQuorumReplicaTimeoutTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> PluggableQuorumReplicatedDistributionTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> PluggableQuorumReplicatedLargeMessageFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> PluggableQuorumReplicatedLargeMessageWithDelayFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> PluggableQuorumReplicatedPagingFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> FailoverWithSharedStoreTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> [ERROR] 
> MultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> NettyMultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] OrderReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> [ERROR] RandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> ...lots missing...
> {noformat}
> {noformat}
> ...lots missing...
> [ERROR] 
> FederationBrokerPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> [ERROR] JvmMetricsTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
> did not close all its files 4096
> [ERROR] MetricsPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> [ERROR] MqttPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
> did not close all its files 4096
> [ERROR] OpenwirePluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> [ERROR] 
> ResourceBrokerPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> [ERROR] StompPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> [ERROR] XmlConfigPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> [ERROR] 
> ActiveMQActivationTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
> did not close all its files 4096
> [ERROR] 
> ActiveMQClusteredTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
> did not 

[jira] [Commented] (ARTEMIS-3435) ActiveMQTestBase.checkLibaio waits can cause hours to be added to failing test suite

[Robbie Gemmell (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402275#comment-17402275
 ] 

Robbie Gemmell commented on ARTEMIS-3435:
-

The check is operating on a static valid that is incremented and decremented as 
the LibaioContext instances are created and closed. If a single instance fails 
to be cleaned up correct, all subsequent test classes using ActiveMQTestBase 
fail, after 30 seconds of waiting in the cleanup.

The fact it is static means it isnt easy to account around a prior failure as 
change may still happen after a delayed time, and it is hard to identify 
whether it happened in the detecting class or a previous one that perhaps 
doesnt use ActiveMQTestBase, so I think the simplest thing for now is to make 
the detail available the clearest it can be, and fail things as fast as 
possible instead of taking hours extra, helping reduce the vast amount of 
output and narrowing down a window when the issue occurred that could then be 
looked at more closely.

I have prepared a patch so the after class check will now record the failure if 
it is >0 after 1 wait, then future classes will fail immediately without 
running, reporting the class that detected the issue so its logs can be 
checked. Prior to this they will also log if the value was 0 before the class 
started (in case it is a non-ActiveMQTestBase class causing it).

> ActiveMQTestBase.checkLibaio waits can cause hours to be added to failing 
> test suite
> 
>
> Key: ARTEMIS-3435
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3435
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: Tests
>Affects Versions: 2.18.0
>Reporter: Robbie Gemmell
>Priority: Major
>
> I recently observered a 'full test' run take over an extra 3 hours, 
> essentially doubling the time to 6hrs 40mins (repeated, it took 3hrs 30mins), 
> with nearly 450 failures in the integration-tests module mostly all due to 
> the same 'test did not close all its files 4096' reason.
> Investigating, I found that all the failures appeared linked and were likely 
> caused by a single prior test having done something awry, with the effect 
> then continuing to fail all subsequent tests classes (after they had run 
> their tests, successfully or otherwise) using the same ActiveMQTestBase 
> parent class for the same reason. Before invoking the fail it waits 30 
> seconds for the ActiveMQTestBase.checkLibaio check to assert a value hits 
> 0after the test class, which it repeatedly didnt. This added 400+ 30sec waits 
> to the test run, failing those 400+ test classes.
> I wasnt able to get all the classes in the output summary, the continued test 
> output filled the buffer, but I got a couple snippets:
> {noformat}
> [ERROR] Failures: 
> [ERROR] 
> QuorumFailOverTest.testQuorumVotingLiveNotDead:143->ClusterTestBase.verifyReceiveRoundRobinInSomeOrder:1167->Assert.assertNotNull:713->Assert.assertTrue:42->Assert.fail:89
>  msg must exist
> [ERROR] 
> PluggableQuorumReplicaTimeoutTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> PluggableQuorumReplicatedDistributionTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> PluggableQuorumReplicatedLargeMessageFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> PluggableQuorumReplicatedLargeMessageWithDelayFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> PluggableQuorumReplicatedPagingFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> FailoverWithSharedStoreTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> [ERROR] 
> MultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] 
> NettyMultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
>  test did not close all its files 4096
> [ERROR] OrderReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> [ERROR] RandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> ...lots missing...
> {noformat}
> {noformat}
> ...lots missing...
> [ERROR] 
> FederationBrokerPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> test did not close all its files 4096
> [ERROR] JvmMetricsTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
> did not close all its files 4096
> [ERROR] MetricsPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
> 

[jira] [Created] (ARTEMIS-3436) Expose Retention as a JMX Operation replay

[Clebert Suconic (Jira)]

Clebert Suconic created ARTEMIS-3436:


 Summary: Expose Retention as a JMX Operation replay
 Key: ARTEMIS-3436
 URL: https://issues.apache.org/jira/browse/ARTEMIS-3436
 Project: ActiveMQ Artemis
  Issue Type: New Feature
Reporter: Clebert Suconic


This should expose the journal retention as an operation replay on the JMX 
Console.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARTEMIS-3434) Journal Retention is using a wrong month

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402272#comment-17402272
 ] 

ASF subversion and git services commented on ARTEMIS-3434:
--

Commit ed4c915d5001fa64e07288055ef514ff97296996 in activemq-artemis's branch 
refs/heads/main from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=ed4c915 ]

ARTEMIS-3434 Fixing Journal Retention Wrong month


> Journal Retention is using a wrong month
> 
>
> Key: ARTEMIS-3434
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3434
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Clebert Suconic
>Priority: Major
>
> Calendar.getMonth() returns the method between 0 and 11.
> I made a mistake, and the month on the files is being set as one month 
> earlier.
> I am planning to create a new replay method, and that would cause issues on 
> the proper date.
> Beware that when you update the broker, some files will be removed based on 
> the age of the files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (ARTEMIS-3434) Journal Retention is using a wrong month

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3434?focusedWorklogId=640280=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640280
 ]

ASF GitHub Bot logged work on ARTEMIS-3434:
---

Author: ASF GitHub Bot
Created on: 20/Aug/21 15:22
Start Date: 20/Aug/21 15:22
Worklog Time Spent: 10m 
  Work Description: asfgit closed pull request #3702:
URL: https://github.com/apache/activemq-artemis/pull/3702


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 640280)
Remaining Estimate: 0h
Time Spent: 10m

> Journal Retention is using a wrong month
> 
>
> Key: ARTEMIS-3434
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3434
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Clebert Suconic
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Calendar.getMonth() returns the method between 0 and 11.
> I made a mistake, and the month on the files is being set as one month 
> earlier.
> I am planning to create a new replay method, and that would cause issues on 
> the proper date.
> Beware that when you update the broker, some files will be removed based on 
> the age of the files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (ARTEMIS-3435) ActiveMQTestBase.checkLibaio waits can cause hours to be added to failing test suite

[Robbie Gemmell (Jira)]

Robbie Gemmell created ARTEMIS-3435:
---

 Summary: ActiveMQTestBase.checkLibaio waits can cause hours to be 
added to failing test suite
 Key: ARTEMIS-3435
 URL: https://issues.apache.org/jira/browse/ARTEMIS-3435
 Project: ActiveMQ Artemis
  Issue Type: Test
  Components: Tests
Affects Versions: 2.18.0
Reporter: Robbie Gemmell


I recently observered a 'full test' run take over an extra 3 hours, essentially 
doubling the time to 6hrs 40mins (repeated, it took 3hrs 30mins), with nearly 
450 failures in the integration-tests module mostly all due to the same 'test 
did not close all its files 4096' reason.

Investigating, I found that all the failures appeared linked and were likely 
caused by a single prior test having done something awry, with the effect then 
continuing to fail all subsequent tests classes (after they had run their 
tests, successfully or otherwise) using the same ActiveMQTestBase parent class 
for the same reason. Before invoking the fail it waits 30 seconds for the 
ActiveMQTestBase.checkLibaio check to assert a value hits 0after the test 
class, which it repeatedly didnt. This added 400+ 30sec waits to the test run, 
failing those 400+ test classes.

I wasnt able to get all the classes in the output summary, the continued test 
output filled the buffer, but I got a couple snippets:

{noformat}
[ERROR] Failures: 
[ERROR] 
QuorumFailOverTest.testQuorumVotingLiveNotDead:143->ClusterTestBase.verifyReceiveRoundRobinInSomeOrder:1167->Assert.assertNotNull:713->Assert.assertTrue:42->Assert.fail:89
 msg must exist
[ERROR] 
PluggableQuorumReplicaTimeoutTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
 test did not close all its files 4096
[ERROR] 
PluggableQuorumReplicatedDistributionTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
 test did not close all its files 4096
[ERROR] 
PluggableQuorumReplicatedLargeMessageFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
 test did not close all its files 4096
[ERROR] 
PluggableQuorumReplicatedLargeMessageWithDelayFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
 test did not close all its files 4096
[ERROR] 
PluggableQuorumReplicatedPagingFailoverTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
 test did not close all its files 4096
[ERROR] 
FailoverWithSharedStoreTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
[ERROR] 
MultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
[ERROR] 
NettyMultiThreadRandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
 test did not close all its files 4096
[ERROR] OrderReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
[ERROR] RandomReattachTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
...lots missing...
{noformat}
{noformat}
...lots missing...
[ERROR] 
FederationBrokerPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
[ERROR] JvmMetricsTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
did not close all its files 4096
[ERROR] MetricsPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
[ERROR] MqttPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
did not close all its files 4096
[ERROR] OpenwirePluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
[ERROR] 
ResourceBrokerPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
did not close all its files 4096
[ERROR] StompPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
did not close all its files 4096
[ERROR] XmlConfigPluginTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
[ERROR] 
ActiveMQActivationTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
did not close all its files 4096
[ERROR] ActiveMQClusteredTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
[ERROR] 
ActiveMQMessageHandlerSecurityTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89
 test did not close all its files 4096
[ERROR] 
ActiveMQMessageHandlerTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
[ERROR] 
ActiveMQMessageHandlerXATest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
[ERROR] IgnoreJTATest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
did not close all its files 4096
[ERROR] JMSContextTest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 test 
did not close all its files 4096
[ERROR] 
OutgoingConnectionJTATest>ActiveMQTestBase.checkLibaio:2061->Assert.fail:89 
test did not close all its files 4096
[ERROR] 

[jira] [Created] (ARTEMIS-3434) Journal Retention is using a wrong month

[Clebert Suconic (Jira)]

Clebert Suconic created ARTEMIS-3434:


 Summary: Journal Retention is using a wrong month
 Key: ARTEMIS-3434
 URL: https://issues.apache.org/jira/browse/ARTEMIS-3434
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Clebert Suconic


Calendar.getMonth() returns the method between 0 and 11.

I made a mistake, and the month on the files is being set as one month earlier.


I am planning to create a new replay method, and that would cause issues on the 
proper date.



Beware that when you update the broker, some files will be removed based on the 
age of the files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARTEMIS-3432) Use batavia to produce transformed source code instead of transformed binaries

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402205#comment-17402205
 ] 

ASF subversion and git services commented on ARTEMIS-3432:
--

Commit bafc511d6699292af19a09de7bac6c35247903d0 in activemq-artemis's branch 
refs/heads/main from Emmanuel Hugonnet
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=bafc511 ]

[ARTEMIS-3432]: Use batavia to produce transformed source code instead of 
transformed binaries.

 * producings sources from jms modules source code.
 * compliling and testing the resulting sources

Issue: https://issues.apache.org/jira/browse/ARTEMIS-3432


> Use batavia to produce transformed source code instead of transformed binaries
> --
>
> Key: ARTEMIS-3432
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3432
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: JMS
>Affects Versions: 2.18.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The binary transformation doesn't produce the sources artefacts. using the 
> updated batavia maven plugin we can transform the source code thus producing 
> artefacts in a classic maven way. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (ARTEMIS-3432) Use batavia to produce transformed source code instead of transformed binaries

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402204#comment-17402204
 ] 

ASF subversion and git services commented on ARTEMIS-3432:
--

Commit bafc511d6699292af19a09de7bac6c35247903d0 in activemq-artemis's branch 
refs/heads/main from Emmanuel Hugonnet
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=bafc511 ]

[ARTEMIS-3432]: Use batavia to produce transformed source code instead of 
transformed binaries.

 * producings sources from jms modules source code.
 * compliling and testing the resulting sources

Issue: https://issues.apache.org/jira/browse/ARTEMIS-3432


> Use batavia to produce transformed source code instead of transformed binaries
> --
>
> Key: ARTEMIS-3432
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3432
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: JMS
>Affects Versions: 2.18.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The binary transformation doesn't produce the sources artefacts. using the 
> updated batavia maven plugin we can transform the source code thus producing 
> artefacts in a classic maven way. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (ARTEMIS-3432) Use batavia to produce transformed source code instead of transformed binaries

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3432?focusedWorklogId=640247=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-640247
 ]

ASF GitHub Bot logged work on ARTEMIS-3432:
---

Author: ASF GitHub Bot
Created on: 20/Aug/21 13:22
Start Date: 20/Aug/21 13:22
Worklog Time Spent: 10m 
  Work Description: asfgit closed pull request #3700:
URL: https://github.com/apache/activemq-artemis/pull/3700


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 640247)
Time Spent: 20m  (was: 10m)

> Use batavia to produce transformed source code instead of transformed binaries
> --
>
> Key: ARTEMIS-3432
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3432
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: JMS
>Affects Versions: 2.18.0
>Reporter: Emmanuel Hugonnet
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The binary transformation doesn't produce the sources artefacts. using the 
> updated batavia maven plugin we can transform the source code thus producing 
> artefacts in a classic maven way. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered

[Rico Neubauer (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rico Neubauer updated ARTEMIS-3433:
---
Description: 
ARTEMIS-3117 introduced code in 2.18.0 to invoke 
_OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();_ 
during stop of _RemotingServiceImpl_. See below for whole stacktrace.

This throws a NullPointerException for us running inside Karaf on stop due to 
the OpenSSLContextFactory being null at that point in time.

 

ARTEMIS-2791 was somewhat similar to this.

Requesting to not fail on the OpenSSLContextFactory being null during stop.
{code:java}
{code:java}
INFO  org.apache.activemq.artemis.osgi  FelixStartLevel  
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1]  AMQ581002: 
Required protocol OPENWIRE was removed for broker local. Stopping broker. INFO  
org.apache.activemq.artemis.osgi  FelixStartLevel  
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1]  AMQ581002: 
Required protocol OPENWIRE was removed for broker local. Stopping broker. ERROR 
 org.apache.activemq.artemis.core.server  FelixStartLevel  
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1]  AMQ224068: 
Unable to stop component: 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
 null at 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
 ~[?:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) 
~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) 
~[osgi.core-7.0.0.jar:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 ~[?:?] at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) 
~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718)
 ~[?:?] at 
org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487)
 ~[?:?] at 
org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:613) 
~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:70) 
~[?:?] at 

[jira] [Updated] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered

[Rico Neubauer (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rico Neubauer updated ARTEMIS-3433:
---
Description: 
ARTEMIS-3117 introduced code in 2.18.0 to invoke 
´´OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();´´
 during stop of ``RemotingServiceImpl``. See below for whole stacktrace.

This throws a NullPointerException for us running inside Karaf on stop due to 
the OpenSSLContextFactory being null at that point in time.

 

ARTEMIS-2791 was somewhat similar to this.

Requesting to not fail on the OpenSSLContextFactory being null during stop.

{code:java}
{code:java}
INFO  org.apache.activemq.artemis.osgi  FelixStartLevel  
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1]  AMQ581002: 
Required protocol OPENWIRE was removed for broker local. Stopping broker. INFO  
org.apache.activemq.artemis.osgi  FelixStartLevel  
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1]  AMQ581002: 
Required protocol OPENWIRE was removed for broker local. Stopping broker. ERROR 
 org.apache.activemq.artemis.core.server  FelixStartLevel  
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1]  AMQ224068: 
Unable to stop component: 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
 null at 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
 ~[?:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) 
~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) 
~[osgi.core-7.0.0.jar:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 ~[?:?] at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) 
~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718)
 ~[?:?] at 
org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487)
 ~[?:?] at 
org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:613) 
~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:70) 
~[?:?] at 

[jira] [Updated] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered

[Rico Neubauer (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rico Neubauer updated ARTEMIS-3433:
---
Description: 
ARTEMIS-3117 introduced code in 2.18.0 to invoke 
´´OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();´´
 during stop of ``RemotingServiceImpl``. See below for whole stacktrace.

This throws a NullPointerException for us running inside Karaf on stop due to 
the OpenSSLContextFactory being null at that point in time.

 

ARTEMIS-2791 was somewhat similar to this.

Requesting to not fail on the OpenSSLContextFactory being null during stop.

 \{code}

INFO org.apache.activemq.artemis.osgi FelixStartLevel 
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required 
protocol OPENWIRE was removed for broker local. Stopping broker. INFO 
org.apache.activemq.artemis.osgi FelixStartLevel 
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required 
protocol OPENWIRE was removed for broker local. Stopping broker. ERROR 
org.apache.activemq.artemis.core.server FelixStartLevel 
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: Unable to stop 
component: 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
 null at 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
 ~[?:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) 
~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) 
~[osgi.core-7.0.0.jar:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 ~[?:?] at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) 
~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718)
 ~[?:?] at 
org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487)
 ~[?:?] at 
org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:613) 
~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:70) 
~[?:?] at 
org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:451) 
~[?:?] at 

[jira] [Updated] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered

[Rico Neubauer (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rico Neubauer updated ARTEMIS-3433:
---
Description: 
ARTEMIS-3117 introduced code in 2.18.0 to invoke 
´´OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();´´
 during stop of ``RemotingServiceImpl``. See below for whole stacktrace.

This throws a NullPointerException for us running inside Karaf on stop due to 
the OpenSSLContextFactory being null at that point in time.

 

ARTEMIS-2791 was somewhat similar to this.

Requesting to not fail on the OpenSSLContextFactory being null during stop.

 
{noformat}
INFO  org.apache.activemq.artemis.osgi  FelixStartLevel  
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1]  AMQ581002: 
Required protocol OPENWIRE was removed for broker local. Stopping broker. INFO  
org.apache.activemq.artemis.osgi  FelixStartLevel  
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1]  AMQ581002: 
Required protocol OPENWIRE was removed for broker local. Stopping broker. 
2021-08-18T19:23:30.876+0200  ERROR  org.apache.activemq.artemis.core.server  
FelixStartLevel  [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1]  
AMQ224068: Unable to stop component: 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
 null at 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
 ~[?:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) 
~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) 
~[osgi.core-7.0.0.jar:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 ~[?:?] at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) 
~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718)
 ~[?:?] at 
org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487)
 ~[?:?] at 
org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:613) 
~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:70) 
~[?:?] at 

[jira] [Updated] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered

[Rico Neubauer (Jira)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rico Neubauer updated ARTEMIS-3433:
---
Description: 
ARTEMIS-3117 introduced code in 2.18.0 to invoke 
´´OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();´´
 during stop of ``RemotingServiceImpl``. See below for whole stacktrace.

This throws a NullPointerException for us running inside Karaf on stop due to 
the OpenSSLContextFactory being null at that point in time.

 

ARTEMIS-2791 was somewhat similar to this.

Requesting to not fail on the OpenSSLContextFactory being null during stop.

 

{{INFO org.apache.activemq.artemis.osgi FelixStartLevel 
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required 
protocol OPENWIRE was removed for broker local. Stopping broker. INFO 
org.apache.activemq.artemis.osgi FelixStartLevel 
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required 
protocol OPENWIRE was removed for broker local. Stopping broker. ERROR 
org.apache.activemq.artemis.core.server FelixStartLevel 
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: Unable to stop 
component: 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
 null at 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
 ~[?:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) 
~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) 
~[osgi.core-7.0.0.jar:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 ~[?:?] at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) 
~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718)
 ~[?:?] at 
org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487)
 ~[?:?] at 
org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:613) 
~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:70) 
~[?:?] at 
org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:451) 
~[?:?] at 

[jira] [Created] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered

[Rico Neubauer (Jira)]

Rico Neubauer created ARTEMIS-3433:
--

 Summary: AMQ224068 on stop due to No OpenSSLContextFactory 
registered
 Key: ARTEMIS-3433
 URL: https://issues.apache.org/jira/browse/ARTEMIS-3433
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Affects Versions: 2.18.0
Reporter: Rico Neubauer


ARTEMIS-3117 introduced code in 2.18.0 to invoke 
``OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();``
 during stop of ``RemotingServiceImpl``. See below for whole stacktrace.

This throws a NullPointerException for us running inside Karaf on stop due to 
the OpenSSLContextFactory being null at that point in time.

 

ARTEMIS-2791 was somewhat similar to this.

Requesting to not fail on the OpenSSLContextFactory being null during stop.

 

{{INFO org.apache.activemq.artemis.osgi FelixStartLevel 
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required 
protocol OPENWIRE was removed for broker local. Stopping broker. INFO 
org.apache.activemq.artemis.osgi FelixStartLevel 
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required 
protocol OPENWIRE was removed for broker local. Stopping broker. ERROR 
org.apache.activemq.artemis.core.server FelixStartLevel 
[org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: Unable to stop 
component: 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
 null at 
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
 ~[?:?] at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
 ~[?:?] at 
org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
 ~[?:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
 ~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) 
~[osgi.core-7.0.0.jar:?] at 
org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) 
~[osgi.core-7.0.0.jar:?] at 
org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 ~[?:?] at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) 
~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
 ~[?:?] at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589)
 ~[?:?] at 
org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718)
 ~[?:?] at 
org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487)
 ~[?:?] at 

[jira] [Commented] (AMQCPP-564) OS thread handles are kept forever

[Dusan Kutnik (Jira)]

[ 
https://issues.apache.org/jira/browse/AMQCPP-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402062#comment-17402062
 ] 

Dusan Kutnik commented on AMQCPP-564:
-

If I remember correctly, the problem with the significant memory growth occurs 
as a severe issue if you have a client that continuously opens new JMS 
connections in new threads. In this case it is really sufficient to call the 
"new" method in your own thread destructor implementation. That solved the 
issue flawlessly for me.

> OS thread handles are kept forever
> --
>
> Key: AMQCPP-564
> URL: https://issues.apache.org/jira/browse/AMQCPP-564
> Project: ActiveMQ C++ Client
>  Issue Type: Improvement
>  Components: Decaf
>Affects Versions: 3.8.3
> Environment: All
>Reporter: Dusan Kutnik
>Assignee: Timothy A. Bish
>Priority: Major
> Fix For: 3.9.0
>
> Attachments: Threading.cpp.diff, Threading.h.diff
>
>
> The method 
> decaf::internal::util::concurrent::Threading::attachToCurrentThread() creates 
> a proxy thread object for a new OS thread and keeps it in a vector:
> 
> ThreadHandle* Threading::attachToCurrentThread() {
> Pointer thread(initThreadHandle(new ThreadHandle()));
> thread->handle = PlatformThread::getCurrentThread();
> thread->state = Thread::RUNNABLE;
> thread->stackSize = PlatformThread::getStackSize(thread->handle);
> thread->name = ::strdup(
> std::string(std::string("OS-Thread") + 
> Integer::toString(library->osThreadId.getAndIncrement())).c_str());
> thread->threadId = PlatformThread::getCurrentThreadId();
> // An OS Thread doesn't have a running thread, this is only a proxy to 
> only one ref.
> thread->references = 1;
> // Now create a Decaf Thread as a proxy to the OS thread.
> Pointer osThread(new Thread(thread.get()));
> thread->parent = osThread.get();
> thread->osThread = true;
> PlatformThread::setTlsValue(library->threadKey, osThread.get());
> PlatformThread::setTlsValue(library->selfKey, thread.get());
> // Store the Thread that wraps this OS thread for later deletion since
> // no other owners exist.
> PlatformThread::lockMutex(library->globalLock);
> library->osThreads.push_back(osThread.release());
> PlatformThread::unlockMutex(library->globalLock);
> return thread.release();
> }
> This method is part of the mutex machinery in the AMQ CPP. The only way how 
> to free this memory is to invoke the method 
> decaf::internal::util::concurrent::Threading::shutdown(). In our scenario we 
> create continuously new worker threads that communicate with ActiveMQ broker. 
> This leads to the situation that new OS thread handles are still being 
> created and never freed. The consumed RAM is rapidly growing since the size 
> of the thread object is on our platform (Win 64bit) 1632 Bytes. We would need 
> to have possibility to explicitly free this OS thread object before it 
> terminates, for instance something like:
> void decaf::internal::util::concurrent::Threading::detachFromCurrentThread()
> Is there a reasonable workaround or another way how to free this OS thread?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)