[jira] [Work logged] (ARTEMIS-4657) Support correlation ID compatibility between JMS clients

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 01/Mar/24 03:42
Start Date: 01/Mar/24 03:42
Worklog Time Spent: 10m 
  Work Description: jbertram commented on code in PR #4833:
URL: https://github.com/apache/activemq-artemis/pull/4833#discussion_r1508444762


##
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/converter/AMQPMessageIdHelper.java:
##
@@ -130,6 +130,8 @@ public String toCorrelationIdString(Object idObject) {
 // It has "ID:" prefix and doesn't have encoding prefix, use it 
as-is.
 return stringId;
  }
+  } else if (idObject instanceof Binary) {
+ return ((Binary)idObject).getArray();

Review Comment:
   I think I get what you mean. Check the latest push.





Issue Time Tracking
---

Worklog Id: (was: 907713)
Time Spent: 1h 20m  (was: 1h 10m)

> Support correlation ID compatibility between JMS clients
> 
>
> Key: ARTEMIS-4657
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4657
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Currently there are some use-cases with both {{String}} and {{byte[]}} values 
> of JMS correlation ID that don't work between Core, OpenWire, and AMQP. We 
> should support as many as possible.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4655) Report logging metrics

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 01/Mar/24 01:46
Start Date: 01/Mar/24 01:46
Worklog Time Spent: 10m 
  Work Description: jbertram commented on code in PR #4830:
URL: https://github.com/apache/activemq-artemis/pull/4830#discussion_r1508389800


##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/metrics/MetricsManager.java:
##
@@ -86,6 +87,9 @@ public MetricsManager(String brokerName,
  if (metricsConfiguration.isUptime()) {
 new UptimeMetrics().bindTo(meterRegistry);
  }
+ if (metricsConfiguration.isLogging()) {
+new Log4j2Metrics().bindTo(meterRegistry);
+ }

Review Comment:
   See the latest update.





Issue Time Tracking
---

Worklog Id: (was: 907704)
Time Spent: 1h  (was: 50m)

> Report logging metrics
> --
>
> Key: ARTEMIS-4655
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4655
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> External systems (e.g. Prometheus & Grafana) can consume metrics to visualize 
> and monitor the health and performance of the broker. These systems often 
> support configurable alerts to inform administrators of problems (e.g. long 
> GC pauses, message accumulation, etc.). It may be useful to configure alerts 
> for {{ERROR}} or {{WARN}} events in the log which may go unnoticed otherwise. 
> The 
> [Log4j2Metrics.java|https://github.com/micrometer-metrics/micrometer/blob/main/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/logging/Log4j2Metrics.java]
>  provided by Micrometer will report metrics for each logging category so 
> administrators can see when unexpected events occur.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (ARTEMIS-4665) Fix intermittent failures in a few AMQP federation address tests

2024-02-29 Thread Timothy A. Bish (Jira)


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

Timothy A. Bish resolved ARTEMIS-4665.
--
Resolution: Fixed

> Fix intermittent failures in a few AMQP federation address tests
> 
>
> Key: ARTEMIS-4665
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4665
> Project: ActiveMQ Artemis
>  Issue Type: Task
>  Components: AMQP
>Affects Versions: 2.32.0
>Reporter: Timothy A. Bish
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 2.33.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add some additional state checks in the server to server test for AMQP 
> federation ensure an address send isn't discard before the remote receiver 
> has attached which is causing some intermittent test failures



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (ARTEMIS-4665) Fix intermittent failures in a few AMQP federation address tests

2024-02-29 Thread ASF subversion and git services (Jira)


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

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

Commit cffc72fd513815b9c99a30b53b99ac0aa28b463a in activemq-artemis's branch 
refs/heads/main from Timothy Bish
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=cffc72fd51 ]

ARTEMIS-4665 Add additional state checks to fix test failures in CI

Tests need to ensure federation links are up before sending to and address
or the sent message can get discarded before the federation consumer is there
to receive it.


> Fix intermittent failures in a few AMQP federation address tests
> 
>
> Key: ARTEMIS-4665
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4665
> Project: ActiveMQ Artemis
>  Issue Type: Task
>  Components: AMQP
>Affects Versions: 2.32.0
>Reporter: Timothy A. Bish
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 2.33.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add some additional state checks in the server to server test for AMQP 
> federation ensure an address send isn't discard before the remote receiver 
> has attached which is causing some intermittent test failures



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4665) Fix intermittent failures in a few AMQP federation address tests

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 21:45
Start Date: 29/Feb/24 21:45
Worklog Time Spent: 10m 
  Work Description: tabish121 merged PR #4837:
URL: https://github.com/apache/activemq-artemis/pull/4837




Issue Time Tracking
---

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

> Fix intermittent failures in a few AMQP federation address tests
> 
>
> Key: ARTEMIS-4665
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4665
> Project: ActiveMQ Artemis
>  Issue Type: Task
>  Components: AMQP
>Affects Versions: 2.32.0
>Reporter: Timothy A. Bish
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 2.33.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add some additional state checks in the server to server test for AMQP 
> federation ensure an address send isn't discard before the remote receiver 
> has attached which is causing some intermittent test failures



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4665) Fix intermittent failures in a few AMQP federation address tests

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 21:25
Start Date: 29/Feb/24 21:25
Worklog Time Spent: 10m 
  Work Description: tabish121 opened a new pull request, #4837:
URL: https://github.com/apache/activemq-artemis/pull/4837

   Tests need to ensure federation links are up before sending to and address 
or the sent message can get discarded before the federation consumer is there 
to receive it.




Issue Time Tracking
---

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

> Fix intermittent failures in a few AMQP federation address tests
> 
>
> Key: ARTEMIS-4665
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4665
> Project: ActiveMQ Artemis
>  Issue Type: Task
>  Components: AMQP
>Affects Versions: 2.32.0
>Reporter: Timothy A. Bish
>Assignee: Timothy A. Bish
>Priority: Minor
> Fix For: 2.33.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add some additional state checks in the server to server test for AMQP 
> federation ensure an address send isn't discard before the remote receiver 
> has attached which is causing some intermittent test failures



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (ARTEMIS-4665) Fix intermittent failures in a few AMQP federation address tests

2024-02-29 Thread Timothy A. Bish (Jira)
Timothy A. Bish created ARTEMIS-4665:


 Summary: Fix intermittent failures in a few AMQP federation 
address tests
 Key: ARTEMIS-4665
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4665
 Project: ActiveMQ Artemis
  Issue Type: Task
  Components: AMQP
Affects Versions: 2.32.0
Reporter: Timothy A. Bish
Assignee: Timothy A. Bish
 Fix For: 2.33.0


Add some additional state checks in the server to server test for AMQP 
federation ensure an address send isn't discard before the remote receiver has 
attached which is causing some intermittent test failures



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (AMQ-9166) Add destination field to Job

2024-02-29 Thread Matt Pavlovich (Jira)


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

Matt Pavlovich updated AMQ-9166:

Fix Version/s: 5.18.4
   5.17.7

> Add destination field to Job
> 
>
> Key: AMQ-9166
> URL: https://issues.apache.org/jira/browse/AMQ-9166
> Project: ActiveMQ Classic
>  Issue Type: Improvement
>  Components: JMX, Job Scheduler
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 6.1.0, 5.18.4, 5.17.7
>
>
> This allows better observability to users can see for a given Job, what the 
> target destination will be



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4582) add view and update permissions to augment the manage rbac for control resources

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 17:53
Start Date: 29/Feb/24 17:53
Worklog Time Spent: 10m 
  Work Description: gtully commented on PR #4820:
URL: 
https://github.com/apache/activemq-artemis/pull/4820#issuecomment-1971659697

   I think this is good for comments and more eyes. 
   The MBean rbac uses `jmx.` prefixed settings.
   the Management messages use a suffix on activemq.management to provide the 
root of the hierarchy. The suffix enabled the feature. I wonder if using a 
different prefix would be more consistent, rather than hanging off of the 
activemq.management address. It would maybe be more consistent but 
activemq.management is the target of those messages. Thoughts welcome.




Issue Time Tracking
---

Worklog Id: (was: 907660)
Time Spent: 1h 10m  (was: 1h)

> add view and update permissions to augment the manage rbac for control 
> resources
> 
>
> Key: ARTEMIS-4582
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4582
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker, Configuration, JMX, Web Console
>Affects Versions: 2.31.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> we have the manage permission that allows sending to the management address, 
> to access any control resource. We don't however distinguish what a user can 
> do.
> We should segment control operations into categories: CRUD provides a basis
> view for get/is (Read)
> update for set or operations that mutate or modify.
> We allow this sort of configuration via management.xml for jmx mbean access 
> but using a different model based on object name.
> All of the mbeans delegate to the control resources.
> If we add these two additional permissions then we can have a single rbac 
> model (that supports config reload) and more granularity on control resource 
> access from the management address.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4658) AMQP Federation should prevent reflection of multicast messages between nodes

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 17:04
Start Date: 29/Feb/24 17:04
Worklog Time Spent: 10m 
  Work Description: gemmellr merged PR #6:
URL: https://github.com/apache/activemq-artemis-examples/pull/6




Issue Time Tracking
---

Worklog Id: (was: 907658)
Time Spent: 1h  (was: 50m)

> AMQP Federation should prevent reflection of multicast messages between nodes
> -
>
> Key: ARTEMIS-4658
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4658
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: AMQP
>Affects Versions: 2.32.0
>Reporter: Timothy A. Bish
>Assignee: Timothy A. Bish
>Priority: Major
> Fix For: 2.33.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When using a topology where brokers are dual federating messages for 
> addresses the federation producers and consumers should prevent reflection 
> between the two nodes.  This allows for more complex configuration where the 
> max hops value is insufficient to prevent duplicates and cases of infinite 
> reflection if the user forgets to configure max hops. 
> Such a case would be a hub and spoke type setup where the producers and 
> consumers are on each of the spokes and the hub is the way point, here the 
> max hops needs to be set to '2' but this allows for a reflection from the hub 
> back to the sending spoke. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4658) AMQP Federation should prevent reflection of multicast messages between nodes

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 17:03
Start Date: 29/Feb/24 17:03
Worklog Time Spent: 10m 
  Work Description: gemmellr commented on PR #6:
URL: 
https://github.com/apache/activemq-artemis-examples/pull/6#issuecomment-1971576611

   Rebased and updated some IDs to make the output more consistent / easier to 
follow




Issue Time Tracking
---

Worklog Id: (was: 907653)
Time Spent: 50m  (was: 40m)

> AMQP Federation should prevent reflection of multicast messages between nodes
> -
>
> Key: ARTEMIS-4658
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4658
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: AMQP
>Affects Versions: 2.32.0
>Reporter: Timothy A. Bish
>Assignee: Timothy A. Bish
>Priority: Major
> Fix For: 2.33.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> When using a topology where brokers are dual federating messages for 
> addresses the federation producers and consumers should prevent reflection 
> between the two nodes.  This allows for more complex configuration where the 
> max hops value is insufficient to prevent duplicates and cases of infinite 
> reflection if the user forgets to configure max hops. 
> Such a case would be a hub and spoke type setup where the producers and 
> consumers are on each of the spokes and the hub is the way point, here the 
> max hops needs to be set to '2' but this allows for a reflection from the hub 
> back to the sending spoke. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (ARTEMIS-4631) Upgrade Spring to 5.3.32

2024-02-29 Thread ASF subversion and git services (Jira)


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

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

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

ARTEMIS-4631: update to Spring 5.3.32


> Upgrade Spring to 5.3.32
> 
>
> Key: ARTEMIS-4631
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4631
> Project: ActiveMQ Artemis
>  Issue Type: Dependency upgrade
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.33.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (ARTEMIS-4621) Upgrade PostgreSQL to 42.7.2

2024-02-29 Thread ASF subversion and git services (Jira)


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

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

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

ARTEMIS-4621: update to PostgreSQL 42.7.2


> Upgrade PostgreSQL to 42.7.2
> 
>
> Key: ARTEMIS-4621
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4621
> Project: ActiveMQ Artemis
>  Issue Type: Dependency upgrade
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.33.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (ARTEMIS-4621) Upgrade PostgreSQL to 42.7.2

2024-02-29 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell resolved ARTEMIS-4621.
-
Resolution: Fixed

> Upgrade PostgreSQL to 42.7.2
> 
>
> Key: ARTEMIS-4621
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4621
> Project: ActiveMQ Artemis
>  Issue Type: Dependency upgrade
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.33.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (ARTEMIS-4631) Upgrade Spring to 5.3.32

2024-02-29 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell resolved ARTEMIS-4631.
-
Resolution: Fixed

> Upgrade Spring to 5.3.32
> 
>
> Key: ARTEMIS-4631
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4631
> Project: ActiveMQ Artemis
>  Issue Type: Dependency upgrade
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.33.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Reopened] (ARTEMIS-4631) Upgrade Spring to 5.3.31

2024-02-29 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell reopened ARTEMIS-4631:
-

> Upgrade Spring to 5.3.31
> 
>
> Key: ARTEMIS-4631
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4631
> Project: ActiveMQ Artemis
>  Issue Type: Dependency upgrade
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.33.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (ARTEMIS-4621) Upgrade PostgreSQL to 42.7.2

2024-02-29 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell updated ARTEMIS-4621:

Summary: Upgrade PostgreSQL to 42.7.2  (was: Upgrade PostgreSQL to 42.7.1)

> Upgrade PostgreSQL to 42.7.2
> 
>
> Key: ARTEMIS-4621
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4621
> Project: ActiveMQ Artemis
>  Issue Type: Dependency upgrade
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.33.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (ARTEMIS-4631) Upgrade Spring to 5.3.32

2024-02-29 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell updated ARTEMIS-4631:

Summary: Upgrade Spring to 5.3.32  (was: Upgrade Spring to 5.3.31)

> Upgrade Spring to 5.3.32
> 
>
> Key: ARTEMIS-4631
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4631
> Project: ActiveMQ Artemis
>  Issue Type: Dependency upgrade
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.33.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Reopened] (ARTEMIS-4621) Upgrade PostgreSQL to 42.7.1

2024-02-29 Thread Robbie Gemmell (Jira)


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

Robbie Gemmell reopened ARTEMIS-4621:
-

> Upgrade PostgreSQL to 42.7.1
> 
>
> Key: ARTEMIS-4621
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4621
> Project: ActiveMQ Artemis
>  Issue Type: Dependency upgrade
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.33.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4658) AMQP Federation should prevent reflection of multicast messages between nodes

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 15:36
Start Date: 29/Feb/24 15:36
Worklog Time Spent: 10m 
  Work Description: tabish121 opened a new pull request, #6:
URL: https://github.com/apache/activemq-artemis-examples/pull/6

   Adds an example showing how AMQP federation can be used to federate 
multicast messages over a hub and spoke topology with bi-directional federation.
   
   Also adds the AMQP federation examples to the run script




Issue Time Tracking
---

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

> AMQP Federation should prevent reflection of multicast messages between nodes
> -
>
> Key: ARTEMIS-4658
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4658
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: AMQP
>Affects Versions: 2.32.0
>Reporter: Timothy A. Bish
>Assignee: Timothy A. Bish
>Priority: Major
> Fix For: 2.33.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When using a topology where brokers are dual federating messages for 
> addresses the federation producers and consumers should prevent reflection 
> between the two nodes.  This allows for more complex configuration where the 
> max hops value is insufficient to prevent duplicates and cases of infinite 
> reflection if the user forgets to configure max hops. 
> Such a case would be a hub and spoke type setup where the producers and 
> consumers are on each of the spokes and the hub is the way point, here the 
> max hops needs to be set to '2' but this allows for a reflection from the hub 
> back to the sending spoke. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4664) autoCreatedResource can get removed while receiving batch of messages

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 14:15
Start Date: 29/Feb/24 14:15
Worklog Time Spent: 10m 
  Work Description: AntonRoskvist opened a new pull request, #4836:
URL: https://github.com/apache/activemq-artemis/pull/4836

   …tch of messages
   
   This is probably not all that likely to ever happen to anyone. I stumbled on 
this issue while working on something else but I figured it would be better to 
handle it.
   
   From what I can tell the auto created resource would have to have been empty 
for one pass of the "AddressQueueReaper" to be marked as "swept", then a large 
batch of messages would get sent to the resource just as the next pass of  
"AddressQueueReaper" begins and finishes before the message batch finishes.




Issue Time Tracking
---

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

> autoCreatedResource can get removed while receiving batch of messages
> -
>
> Key: ARTEMIS-4664
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4664
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Anton Roskvist
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There is a very small window where an auto created resource can get 
> auto-removed while receiving a batch of new messages.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (ARTEMIS-4664) autoCreatedResource can get removed while receiving batch of messages

2024-02-29 Thread Anton Roskvist (Jira)
Anton Roskvist created ARTEMIS-4664:
---

 Summary: autoCreatedResource can get removed while receiving batch 
of messages
 Key: ARTEMIS-4664
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4664
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Anton Roskvist


There is a very small window where an auto created resource can get 
auto-removed while receiving a batch of new messages.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (AMQ-9438) FailoverTransport throws UnknowHostException on compareURIs

2024-02-29 Thread Jira


[ 
https://issues.apache.org/jira/browse/AMQ-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822137#comment-17822137
 ] 

Jean-Baptiste Onofré commented on AMQ-9438:
---

[~gmccone] That's a fair point about log message. Currently, when 
{{IOException}} is catched, we log a {{error}} message. It's probably too high.

I propose to log a {{warn}} instead of an {{{}error{}}}. You can always create 
a logger specific to {{FailoverTransport}} to select the level.

Thoughts ?

> FailoverTransport throws UnknowHostException on compareURIs
> ---
>
> Key: AMQ-9438
> URL: https://issues.apache.org/jira/browse/AMQ-9438
> Project: ActiveMQ Classic
>  Issue Type: Improvement
>  Components: Transport
>Affects Versions: 5.18.3, 5.17.6, 5.16.7
> Environment: This occurs using OpenJDK 11 on both Windows and Linux 
> environments.
>Reporter: George McCone
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
>
> In the 
> org.apache.activemq.transport.failover.FailoverTransport.compareURIs(), it is 
> trying to compare 2 hosts to see if they are the same.
> To accomplish this, the function InetAddress.getByName() used to help extract 
> out the the IP address of each of the hosts to see if they are the same.
> In the event one of the hosts is not resolvable,  InetAddress.getByName() 
> throws a UnknownHostException.
> This UnknownHostException is not being caught in the try/catch block, only 
> IOException.
> I believe the exception catch block should be extended to catch 
> UnknownHostException as it is simply doing a string compare that the 2 hosts 
> are the same at that point.
> For example, in the stacktrace below the uri was, 
> failover:(tcp://UNKNOWN:61616,tcp://AMQ1:61616)?randomize=false/org.apache.activemq.jndi.ActiveMQInitialContextFactory/ConnectionFactory
> {code:java}
> 2024-02-27T19:37:20,311 | ERROR | FelixStartLevel  | FailoverTransport        
>         | 28 - org.apache.activemq.osgi - 5.18.3 | Failed to Lookup 
> INetAddress for URI[tcp://UNKNOWN:61616] : {}
> java.net.UnknownHostException: No such host is known (UNKNOWN)
>     at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method) ~[?:?]
>     at 
> java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:929)
>  ~[?:?]
>     at 
> java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1519) ~[?:?]
>     at java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:848) 
> ~[?:?]
>     at java.net.InetAddress.getAllByName0(InetAddress.java:1509) ~[?:?]
>     at java.net.InetAddress.getAllByName(InetAddress.java:1368) ~[?:?]
>     at java.net.InetAddress.getAllByName(InetAddress.java:1302) ~[?:?]
>     at java.net.InetAddress.getByName(InetAddress.java:1252) ~[?:?]
>     at 
> org.apache.activemq.transport.failover.FailoverTransport.compareURIs(FailoverTransport.java:1393)
>  ~[?:?] {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (AMQ-9442) Upgrade to Spring 6.0.17

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 13:41
Start Date: 29/Feb/24 13:41
Worklog Time Spent: 10m 
  Work Description: jbonofre opened a new pull request, #1161:
URL: https://github.com/apache/activemq/pull/1161

   (no comment)




Issue Time Tracking
---

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

> Upgrade to Spring 6.0.17
> 
>
> Key: AMQ-9442
> URL: https://issues.apache.org/jira/browse/AMQ-9442
> Project: ActiveMQ Classic
>  Issue Type: Dependency upgrade
>  Components: Broker
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 6.0.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (AMQ-9442) Upgrade to Spring 6.0.17

2024-02-29 Thread Jira
Jean-Baptiste Onofré created AMQ-9442:
-

 Summary: Upgrade to Spring 6.0.17
 Key: AMQ-9442
 URL: https://issues.apache.org/jira/browse/AMQ-9442
 Project: ActiveMQ Classic
  Issue Type: Dependency upgrade
  Components: Broker
Reporter: Jean-Baptiste Onofré
Assignee: Jean-Baptiste Onofré
 Fix For: 6.0.2






--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (AMQ-9440) Upgrade to Jetty 11.0.20

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 12:51
Start Date: 29/Feb/24 12:51
Worklog Time Spent: 10m 
  Work Description: jbonofre opened a new pull request, #1160:
URL: https://github.com/apache/activemq/pull/1160

   (no comment)




Issue Time Tracking
---

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

> Upgrade to Jetty 11.0.20
> 
>
> Key: AMQ-9440
> URL: https://issues.apache.org/jira/browse/AMQ-9440
> Project: ActiveMQ Classic
>  Issue Type: Dependency upgrade
>  Components: Broker, Transport, Web Console
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 6.1.0, 6.0.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4655) Report logging metrics

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 11:24
Start Date: 29/Feb/24 11:24
Worklog Time Spent: 10m 
  Work Description: gemmellr commented on code in PR #4830:
URL: https://github.com/apache/activemq-artemis/pull/4830#discussion_r1507414681


##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/plugin/LoggingMetricsTest.java:
##
@@ -0,0 +1,99 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ * 
+ * http://www.apache.org/licenses/LICENSE-2.0
+ * 

Review Comment:
   Shouldnt have the \ tags in the licence comment and the URL isnt 
indented as it normally is. See most other java files in the codebase (and if 
using an auto-insert, perhaps update it).





Issue Time Tracking
---

Worklog Id: (was: 907592)
Time Spent: 50m  (was: 40m)

> Report logging metrics
> --
>
> Key: ARTEMIS-4655
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4655
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> External systems (e.g. Prometheus & Grafana) can consume metrics to visualize 
> and monitor the health and performance of the broker. These systems often 
> support configurable alerts to inform administrators of problems (e.g. long 
> GC pauses, message accumulation, etc.). It may be useful to configure alerts 
> for {{ERROR}} or {{WARN}} events in the log which may go unnoticed otherwise. 
> The 
> [Log4j2Metrics.java|https://github.com/micrometer-metrics/micrometer/blob/main/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/logging/Log4j2Metrics.java]
>  provided by Micrometer will report metrics for each logging category so 
> administrators can see when unexpected events occur.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4655) Report logging metrics

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 11:23
Start Date: 29/Feb/24 11:23
Worklog Time Spent: 10m 
  Work Description: gemmellr commented on code in PR #4830:
URL: https://github.com/apache/activemq-artemis/pull/4830#discussion_r1507420822


##
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/metrics/MetricsManager.java:
##
@@ -86,6 +87,9 @@ public MetricsManager(String brokerName,
  if (metricsConfiguration.isUptime()) {
 new UptimeMetrics().bindTo(meterRegistry);
  }
+ if (metricsConfiguration.isLogging()) {
+new Log4j2Metrics().bindTo(meterRegistry);
+ }

Review Comment:
   Not sure the new doc is clear enough / goes far enough. This thing actually 
depends on Log4J API and Log4J Core, but neither the broker (no dep at all) or 
micrometer core (optional dep) have a hard dep on them to bring them in...so 
for anyone e.g embedding, it seems likely to blow up at this point unless some 
other dep has actually brought in log4j-core. Our tests happen to do that and 
so wont show any issue.
   
   
https://github.com/micrometer-metrics/micrometer/blob/v1.12.2/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/logging/Log4j2Metrics.java



##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/plugin/LoggingMetricsTest.java:
##
@@ -0,0 +1,99 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ * 
+ * http://www.apache.org/licenses/LICENSE-2.0
+ * 

Review Comment:
   Shouldnt have the  tags in the licence comment and the URL isnt indented 
as it normally is. See most other java files in the codebase (and if using an 
auto-insert, perhaps update it).





Issue Time Tracking
---

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

> Report logging metrics
> --
>
> Key: ARTEMIS-4655
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4655
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> External systems (e.g. Prometheus & Grafana) can consume metrics to visualize 
> and monitor the health and performance of the broker. These systems often 
> support configurable alerts to inform administrators of problems (e.g. long 
> GC pauses, message accumulation, etc.). It may be useful to configure alerts 
> for {{ERROR}} or {{WARN}} events in the log which may go unnoticed otherwise. 
> The 
> [Log4j2Metrics.java|https://github.com/micrometer-metrics/micrometer/blob/main/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/logging/Log4j2Metrics.java]
>  provided by Micrometer will report metrics for each logging category so 
> administrators can see when unexpected events occur.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4648) Support typed properties on CLI producer

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 10:22
Start Date: 29/Feb/24 10:22
Worklog Time Spent: 10m 
  Work Description: gemmellr commented on code in PR #4824:
URL: https://github.com/apache/activemq-artemis/pull/4824#discussion_r1507347730


##
artemis-cli/src/test/java/org/apache/activemq/cli/test/CliProducerTest.java:
##
@@ -88,6 +91,138 @@ public void testSendMessage() throws Exception {
   checkSentMessages(session, address, null);
}
 
+   @Test
+   public void testBooleanMessageProperties() throws Exception {
+  Message m;
+  String address = "test";
+  Session session = createSession(connection);
+
+  assertEquals(1L, produceMessages(address, null, 1, 
"[{'type':'boolean','key':'myTrueBoolean','value':'true'},{'type':'boolean','key':'myFalseBoolean','value':'false'}]".replaceAll("'",
 "\"")));
+
+  m = consumeMessages(session, address, 1).get(0);
+  Assert.assertTrue(m.propertyExists("myTrueBoolean"));
+  Assert.assertTrue(m.getBooleanProperty("myTrueBoolean"));
+  Assert.assertTrue(m.propertyExists("myFalseBoolean"));
+  Assert.assertFalse(m.getBooleanProperty("myFalseBoolean"));
+   }
+
+   @Test
+   public void testIntMessageProperties() throws Exception {
+  Message m;
+  String address = "test";
+  Session session = createSession(connection);
+
+  assertEquals(1L, produceMessages(address, null, 1, 
("[{'type':'int','key':'myInt','value':'" + Integer.MAX_VALUE + 
"'}]").replaceAll("'", "\"")));
+
+  m = consumeMessages(session, address, 1).get(0);
+  Assert.assertTrue(m.propertyExists("myInt"));
+  Assert.assertEquals(Integer.MAX_VALUE, m.getIntProperty("myInt"));
+
+  assertEquals(0L, produceMessages(address, null, 1, 
("[{'type':'int','key':'myInt','value':'" + Integer.MAX_VALUE + 1 + 
"'}]").replaceAll("'", "\"")));
+   }
+
+   @Test
+   public void testLongMessageProperties() throws Exception {
+  Message m;
+  String address = "test";
+  Session session = createSession(connection);
+
+  assertEquals(1L, produceMessages(address, null, 1, 
("[{'type':'long','key':'myLong','value':'" + Long.MAX_VALUE + 
"'}]").replaceAll("'", "\"")));
+
+  m = consumeMessages(session, address, 1).get(0);
+  Assert.assertTrue(m.propertyExists("myLong"));
+  Assert.assertEquals(Long.MAX_VALUE, m.getLongProperty("myLong"));
+
+  assertEquals(0L, produceMessages(address, null, 1, 
("[{'type':'long','key':'myLong','value':'" + Long.MAX_VALUE + 1 + 
"'}]").replaceAll("'", "\"")));
+   }
+
+   @Test
+   public void testByteMessageProperties() throws Exception {
+  Message m;
+  String address = "test";
+  Session session = createSession(connection);
+
+  assertEquals(1L, produceMessages(address, null, 1, 
"[{'type':'byte','key':'myByte','value':'127'}]".replaceAll("'", "\"")));
+
+  m = consumeMessages(session, address, 1).get(0);
+  Assert.assertTrue(m.propertyExists("myByte"));
+  Assert.assertEquals((byte) 127, m.getByteProperty("myByte"));
+
+  assertEquals(0L, produceMessages(address, null, 1, 
"[{'type':'byte','key':'myByte','value':'128'}]".replaceAll("'", "\"")));
+   }
+
+   @Test
+   public void testShortMessageProperties() throws Exception {
+  Message m;
+  String address = "test";
+  Session session = createSession(connection);
+
+  assertEquals(1L, produceMessages(address, null, 1, 
("[{'type':'short','key':'myShort','value':'" + Short.MAX_VALUE + 
"'}]").replaceAll("'", "\"")));
+
+  m = consumeMessages(session, address, 1).get(0);
+  Assert.assertTrue(m.propertyExists("myShort"));
+  Assert.assertEquals(Short.MAX_VALUE, m.getShortProperty("myShort"));
+
+  assertEquals(0L, produceMessages(address, null, 1, 
("[{'type':'short','key':'myShort','value':'" + Short.MAX_VALUE + 1 + 
"'}]").replaceAll("'", "\"")));
+   }
+
+   @Test
+   public void testFloatMessageProperties() throws Exception {
+  Message m;
+  String address = "test";
+  Session session = createSession(connection);
+
+  assertEquals(1L, produceMessages(address, null, 1, 
("[{'type':'float','key':'myFloat','value':'" + Float.MAX_VALUE + 
"'}]").replaceAll("'", "\"")));
+
+  m = consumeMessages(session, address, 1).get(0);
+  Assert.assertTrue(m.propertyExists("myFloat"));
+  Assert.assertEquals(Float.MAX_VALUE, m.getFloatProperty("myFloat"), 0.0);
+
+  assertEquals(0L, produceMessages(address, null, 1, 
("[{'type':'float','key':'myFloat','value':'badFloat'}]").replaceAll("'", 
"\"")));
+   }
+
+   @Test
+   public void testDoubleMessageProperties() throws Exception {
+  Message m;
+  String address = "test";
+   

[jira] [Work logged] (ARTEMIS-4648) Support typed properties on CLI producer

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 10:09
Start Date: 29/Feb/24 10:09
Worklog Time Spent: 10m 
  Work Description: gemmellr commented on code in PR #4824:
URL: https://github.com/apache/activemq-artemis/pull/4824#discussion_r1507323452


##
artemis-cli/src/test/java/org/apache/activemq/cli/test/CliProducerTest.java:
##
@@ -88,6 +90,124 @@ public void testSendMessage() throws Exception {
   checkSentMessages(session, address, null);
}
 
+   @Test
+   public void testBooleanMessageProperties() throws Exception {

Review Comment:
   I'd guess that Clebert was just thinking about it starting X brokers and 
making X connections, sessions, producers, consumers currently to test 
something carried on the message alone that could still be done with 1 of each.
   
   I tend to prefer more granular tests. Although, I'd personally go further 
and think the CLI bits could probably have been unit tested without any broker 
etc since its just a case of verifying the arg is decoded as expected, and 
ensuring things are set as expected on the message before it is sent...the 
clients sending of a message with props is covered elsewhere already)





Issue Time Tracking
---

Worklog Id: (was: 907556)
Time Spent: 1h 50m  (was: 1h 40m)

> Support typed properties on CLI producer
> 
>
> Key: ARTEMIS-4648
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4648
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4648) Support typed properties on CLI producer

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 10:06
Start Date: 29/Feb/24 10:06
Worklog Time Spent: 10m 
  Work Description: gemmellr commented on code in PR #4824:
URL: https://github.com/apache/activemq-artemis/pull/4824#discussion_r1507323452


##
artemis-cli/src/test/java/org/apache/activemq/cli/test/CliProducerTest.java:
##
@@ -88,6 +90,124 @@ public void testSendMessage() throws Exception {
   checkSentMessages(session, address, null);
}
 
+   @Test
+   public void testBooleanMessageProperties() throws Exception {

Review Comment:
   I'd guess that Clebert was just thinking about it starting X brokers and 
making X connections, sessions, producers currently to test something carried 
on the message alone that could still be done with 1 of each.
   
   I tend to prefer more granular tests. Although, I'd personally go further 
and think the CLI bits could probably have been unit tested without any broker 
etc since its just a case of verifying the arg is decoded as expected, and 
ensuring things are set as expected on the message before it is sent...the 
clients sending of a message with props is covered elsewhere already)





Issue Time Tracking
---

Worklog Id: (was: 907555)
Time Spent: 1h 40m  (was: 1.5h)

> Support typed properties on CLI producer
> 
>
> Key: ARTEMIS-4648
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4648
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (ARTEMIS-4663) Possible dereference of null in MQTTPublishManager

2024-02-29 Thread Andrey Slepykh (Jira)


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

Andrey Slepykh updated ARTEMIS-4663:

Labels: dereference-of-null  (was: )

> Possible dereference of null in MQTTPublishManager
> --
>
> Key: ARTEMIS-4663
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4663
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: ActiveMQ-Artemis-Native
>Affects Versions: 2.32.0
>Reporter: Andrey Slepykh
>Priority: Major
>  Labels: dereference-of-null
>
> Return value of a function 
> [readNullableSimpleString|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L377]
>  is dereferenced at 
> [MQTTPublishManager.java:378|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L378]
>  without checking for null, but it is usually checked for this function.
> Since the readNullableSimpleString() function can return a null value, it may 
> be worth adding a null check before using it on line 378.
> The 
> [publishToClient|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L371]
>  private function can throw exceptions, but they are not handled anywhere in 
> the class.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author A. Burke.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (ARTEMIS-4663) Possible dereference of null in MQTTPublishManager

2024-02-29 Thread Andrey Slepykh (Jira)


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

Andrey Slepykh updated ARTEMIS-4663:

Component/s: ActiveMQ-Artemis-Native

> Possible dereference of null in MQTTPublishManager
> --
>
> Key: ARTEMIS-4663
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4663
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: ActiveMQ-Artemis-Native
>Affects Versions: 2.32.0
>Reporter: Andrey Slepykh
>Priority: Major
>
> Return value of a function 
> [readNullableSimpleString|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L377]
>  is dereferenced at 
> [MQTTPublishManager.java:378|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L378]
>  without checking for null, but it is usually checked for this function.
> Since the readNullableSimpleString() function can return a null value, it may 
> be worth adding a null check before using it on line 378.
> The 
> [publishToClient|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L371]
>  private function can throw exceptions, but they are not handled anywhere in 
> the class.
>  
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author A. Burke.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Work logged] (ARTEMIS-4657) Support correlation ID compatibility between JMS clients

2024-02-29 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 29/Feb/24 09:47
Start Date: 29/Feb/24 09:47
Worklog Time Spent: 10m 
  Work Description: gemmellr commented on PR #4833:
URL: 
https://github.com/apache/activemq-artemis/pull/4833#issuecomment-1970769791

   Sacrificing any of the existing widely-used working String-based correlation 
ID interop in favour of the non-portable little-used byte[] versions, that dont 
work currently, simply does not strike me as an improvement whatsoever.
   
   String based JMSCorrelationID is the _primary, required_ form of 
JMSCorrelationID. Its what JMS providers _must_ implement. Its the only way to 
correlate using the String-only JMSMessageID values. Its what people use in 
selectors. Its what applications just tend to use in general (I dont think I 
have ever come across a real world application that used the byte[], whereas I 
know I have come across lots that use the String).
   
   Its also what frameworks tend to use, because they simply cant depend on the 
byte[] method and thus avoid it. The Camel repo for example is littered with 
String-based setJMSCorrelationID usage, but doesnt seem to have a single 
setJMSCorrelationIDAsBytes usage (according to a couple searches of their git 
repo). Ditto for Spring.
   
   The byte[] method is optional, you do not need to implement it at all and 
are simply allowed to throw UnsupportedOperationException. The API expressly 
notes that it is non-portable to discourage its use. The TCK only has 1 test 
variant (only only added with JMS 2) that uses it, and it simply swallows that 
potential UOE and prints it is ignoring it.  The method is essentially only 
there to support niche cases of providers that also have non-JMS clients that 
require a specific 'native' correlation encoding. I think I historically saw it 
referenced for interop with the 'non-jms' IBM MQ clients for example, as they 
encoded things in a certain structure with certain hex encodings etc that need 
to be matched.




Issue Time Tracking
---

Worklog Id: (was: 907539)
Time Spent: 1h 10m  (was: 1h)

> Support correlation ID compatibility between JMS clients
> 
>
> Key: ARTEMIS-4657
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4657
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Currently there are some use-cases with both {{String}} and {{byte[]}} values 
> of JMS correlation ID that don't work between Core, OpenWire, and AMQP. We 
> should support as many as possible.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (ARTEMIS-4663) Possible dereference of null in MQTTPublishManager

2024-02-29 Thread Andrey Slepykh (Jira)


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

Andrey Slepykh updated ARTEMIS-4663:

Description: 
Return value of a function 
[readNullableSimpleString|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L377]
 is dereferenced at 
[MQTTPublishManager.java:378|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L378]
 without checking for null, but it is usually checked for this function.

Since the readNullableSimpleString() function can return a null value, it may 
be worth adding a null check before using it on line 378.

The 
[publishToClient|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L371]
 private function can throw exceptions, but they are not handled anywhere in 
the class.

Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author A. Burke.

  was:
Return value of a function 
[readNullableSimpleString|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L377]
 is dereferenced at 
[MQTTPublishManager.java:378|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L378]
 without checking for null, but it is usually checked for this function.

Since the readNullableSimpleString() function can return a null value, it may 
be worth adding a null check before using it on line 378.

The 
[publishToClient|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L371]
 private function can throw exceptions, but they are not handled anywhere in 
the class.

 

Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author A. Burke.


> Possible dereference of null in MQTTPublishManager
> --
>
> Key: ARTEMIS-4663
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4663
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: ActiveMQ-Artemis-Native
>Affects Versions: 2.32.0
>Reporter: Andrey Slepykh
>Priority: Major
>
> Return value of a function 
> [readNullableSimpleString|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L377]
>  is dereferenced at 
> [MQTTPublishManager.java:378|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L378]
>  without checking for null, but it is usually checked for this function.
> Since the readNullableSimpleString() function can return a null value, it may 
> be worth adding a null check before using it on line 378.
> The 
> [publishToClient|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L371]
>  private function can throw exceptions, but they are not handled anywhere in 
> the class.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author A. Burke.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (ARTEMIS-4663) Possible dereference of null in MQTTPublishManager

2024-02-29 Thread Andrey Slepykh (Jira)


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

Andrey Slepykh updated ARTEMIS-4663:

Affects Version/s: 2.32.0

> Possible dereference of null in MQTTPublishManager
> --
>
> Key: ARTEMIS-4663
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4663
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.32.0
>Reporter: Andrey Slepykh
>Priority: Major
>
> Return value of a function 
> [readNullableSimpleString|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L377]
>  is dereferenced at 
> [MQTTPublishManager.java:378|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L378]
>  without checking for null, but it is usually checked for this function.
> Since the readNullableSimpleString() function can return a null value, it may 
> be worth adding a null check before using it on line 378.
> The 
> [publishToClient|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L371]
>  private function can throw exceptions, but they are not handled anywhere in 
> the class.
>  
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author A. Burke.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (ARTEMIS-4663) Possible dereference of null in MQTTPublishManager

2024-02-29 Thread Andrey Slepykh (Jira)
Andrey Slepykh created ARTEMIS-4663:
---

 Summary: Possible dereference of null in MQTTPublishManager
 Key: ARTEMIS-4663
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4663
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Andrey Slepykh


Return value of a function 
[readNullableSimpleString|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L377]
 is dereferenced at 
[MQTTPublishManager.java:378|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L378]
 without checking for null, but it is usually checked for this function.

Since the readNullableSimpleString() function can return a null value, it may 
be worth adding a null check before using it on line 378.

The 
[publishToClient|https://github.com/apache/activemq-artemis/blob/fb1b362b473cad51ae5d05a897be02b1fa8461d4/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L371]
 private function can throw exceptions, but they are not handled anywhere in 
the class.

 

Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author A. Burke.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)