date:20240422

[jira] [Work logged] (ARTEMIS-4743) Split lines on CLI Queue stat when the queue names or address names are too large

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 23/Apr/24 05:18
Start Date: 23/Apr/24 05:18
Worklog Time Spent: 10m 
  Work Description: jbertram commented on PR #4905:
URL: 
https://github.com/apache/activemq-artemis/pull/4905#issuecomment-2071427578

   The headings of most columns are being wrapped, e.g.:
   ```
   $ ./artemis queue stat --maxColumnSize=30
   Connection brokerURL = tcp://localhost:61616
   |NAME  |ADDRESS   
|CONSUMER_C|MESSAGE_CO|MESSAGES_A|DELIVERING|MESSAGES_A|SCHEDULED_|ROUTING_TY|
   |  |  |OUNT  
|UNT   |DDED  |_COUNT|CKED  |COUNT |PE|
   |$sys.mqtt.sessions|$sys.mqtt.sessions|0 |0  
   |0 |0 |0 |0 |ANYCAST   |
   |DLQ   |DLQ   |0 |0  
   |0 |0 |0 |0 |ANYCAST   |
   |ExpiryQueue   |ExpiryQueue   |0 |0  
   |0 |0 |0 |0 |ANYCAST   |
   |activemq.management.c9ac407e-f|activemq.management.c9ac407e-f|1 |1  
   |1 |1 |0 |0 |MULTICAST |
   |9a3-48c0-a4c4-c760a01e9170|9a3-48c0-a4c4-c760a01e9170|  |   
   |  |  |  |  |  |
   |activemq.management.e9fe512e-3|activemq.management.e9fe512e-3|1 |0  
   |0 |0 |0 |0 |MULTICAST |
   |77e-415d-ba37-a9cd2e12e0f8|77e-415d-ba37-a9cd2e12e0f8|  |   
   |  |  |  |  |  |
   |activemq.management.ea027bf5-5|activemq.management.ea027bf5-5|1 |1  
   |1 |1 |0 |0 |MULTICAST |
   |a8d-427c-a745-78bf20302274|a8d-427c-a745-78bf20302274|  |   
   |  |  |  |  |  |
   |fo|ba|0 |0  
   |0 |0 |0 |0 |ANYCAST   |
   |00|rr|  |   
   |  |  |  |  |  |
   ```




Issue Time Tracking
---

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

> Split lines on CLI Queue stat when the queue names or address names are too 
> large
> -
>
> Key: ARTEMIS-4743
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4743
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.33.0
>Reporter: Clebert Suconic
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




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

[jira] [Work logged] (ARTEMIS-4742) Decoding PersistedSecuritySetting fails after upgrade

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 23/Apr/24 03:17
Start Date: 23/Apr/24 03:17
Worklog Time Spent: 10m 
  Work Description: jbertram commented on code in PR #4904:
URL: https://github.com/apache/activemq-artemis/pull/4904#discussion_r1575589452


##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/security/PersistedSecuritySettingTest.java:
##
@@ -43,4 +48,31 @@ public void testNPE() {
   persistedSecuritySetting.getViewRoles();
   persistedSecuritySetting.getEditRoles();
}
+
+   @Test
+   public void testUpgradeAfterARTEMIS_4582() {

Review Comment:
   I didn't. The stack-trace on the exception was pretty clear, and since we've 
dealt with this kind of issue before a quick unit test seemed adequate.





Issue Time Tracking
---

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

> Decoding PersistedSecuritySetting fails after upgrade
> -
>
> Key: ARTEMIS-4742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4742
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We have faced problem when upgrading one of ActiveMQ Artemis servers from 
> 2.32.0 to 2.33.0.
> Artemis cannot start and writes an error to the log:
> {noformat}
> 2024-04-18 13:31:44,975 ERROR [org.apache.activemq.artemis.core.server] 
> AMQ224000: Failure in initialisation
> java.lang.IndexOutOfBoundsException: readerIndex(82) + length(1) exceeds 
> writerIndex(82): UnpooledHeapByteBuf(ridx: 82, widx: 82, cap: 82/82)
> at 
> io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1442)
>  ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:730) 
> ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at io.netty.buffer.WrappedByteBuf.readByte(WrappedByteBuf.java:529) 
> ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at 
> org.apache.activemq.artemis.api.core.SimpleString.readNullableSimpleString(SimpleString.java:150)
>  ~[artemis-commons-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:79)
>  ~[artemis-commons-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.persistence.config.PersistedSecuritySetting.decode(PersistedSecuritySetting.java:255)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.newSecurityRecord(AbstractJournalStorageManager.java:2127)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.lambda$loadBindingJournal$5(AbstractJournalStorageManager.java:1640)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList$SparseArray.clear(SparseArrayLinkedList.java:114)
>  ~[artemis-commons-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList.clearSparseArrayList(SparseArrayLinkedList.java:173)
>  ~[artemis-commons-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList.clear(SparseArrayLinkedList.java:227)
>  ~[artemis-commons-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadBindingJournal(AbstractJournalStorageManager.java:1613)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:3856)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3489)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ReplicationPrimaryActivation.run(ReplicationPrimaryActivation.java:145)
>  [artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:738)
>  [artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:628)
>  [artemis-server-2.33.0.jar:2.33.0]
> at 
>

[jira] [Updated] (ARTEMIS-4742) Decoding PersistedSecuritySetting fails after upgrade

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram updated ARTEMIS-4742:

Description: 
We have faced problem when upgrading one of ActiveMQ Artemis servers from 
2.32.0 to 2.33.0.
Artemis cannot start and writes an error to the log:
{noformat}
2024-04-18 13:31:44,975 ERROR [org.apache.activemq.artemis.core.server] 
AMQ224000: Failure in initialisation
java.lang.IndexOutOfBoundsException: readerIndex(82) + length(1) exceeds 
writerIndex(82): UnpooledHeapByteBuf(ridx: 82, widx: 82, cap: 82/82)
at 
io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1442) 
~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:730) 
~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
at io.netty.buffer.WrappedByteBuf.readByte(WrappedByteBuf.java:529) 
~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
at 
org.apache.activemq.artemis.api.core.SimpleString.readNullableSimpleString(SimpleString.java:150)
 ~[artemis-commons-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:79)
 ~[artemis-commons-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.core.persistence.config.PersistedSecuritySetting.decode(PersistedSecuritySetting.java:255)
 ~[artemis-server-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.newSecurityRecord(AbstractJournalStorageManager.java:2127)
 ~[artemis-server-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.lambda$loadBindingJournal$5(AbstractJournalStorageManager.java:1640)
 ~[artemis-server-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList$SparseArray.clear(SparseArrayLinkedList.java:114)
 ~[artemis-commons-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList.clearSparseArrayList(SparseArrayLinkedList.java:173)
 ~[artemis-commons-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList.clear(SparseArrayLinkedList.java:227)
 ~[artemis-commons-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadBindingJournal(AbstractJournalStorageManager.java:1613)
 ~[artemis-server-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:3856)
 ~[artemis-server-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3489)
 ~[artemis-server-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.core.server.impl.ReplicationPrimaryActivation.run(ReplicationPrimaryActivation.java:145)
 [artemis-server-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:738)
 [artemis-server-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:628)
 [artemis-server-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66) 
[artemis-cli-2.33.0.jar:2.33.0]
at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:130) 
[artemis-cli-2.33.0.jar:2.33.0]
at 
org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:221) 
[artemis-cli-2.33.0.jar:2.33.0]
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:167) 
[artemis-cli-2.33.0.jar:2.33.0]
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
~[?:?]
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
 ~[?:?]
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:?]
at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:157) 
[artemis-boot.jar:2.33.0]
at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:64) 
[artemis-boot.jar:2.33.0]{noformat}

> Decoding PersistedSecuritySetting fails after upgrade
> -
>
> Key: ARTEMIS-4742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4742
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have faced problem when upgrading one of

[jira] [Updated] (ARTEMIS-4742) Decoding PersistedSecuritySetting fails after upgrade

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram updated ARTEMIS-4742:

External issue URL: 
https://lists.apache.org/thread/kf4g9t5bh1s2bwkjcot5cq9bjpc9cxc8

> Decoding PersistedSecuritySetting fails after upgrade
> -
>
> Key: ARTEMIS-4742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4742
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have faced problem when upgrading one of ActiveMQ Artemis servers from 
> 2.32.0 to 2.33.0.
> Artemis cannot start and writes an error to the log:
> {noformat}
> 2024-04-18 13:31:44,975 ERROR [org.apache.activemq.artemis.core.server] 
> AMQ224000: Failure in initialisation
> java.lang.IndexOutOfBoundsException: readerIndex(82) + length(1) exceeds 
> writerIndex(82): UnpooledHeapByteBuf(ridx: 82, widx: 82, cap: 82/82)
> at 
> io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1442)
>  ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:730) 
> ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at io.netty.buffer.WrappedByteBuf.readByte(WrappedByteBuf.java:529) 
> ~[netty-buffer-4.1.107.Final.jar:4.1.107.Final]
> at 
> org.apache.activemq.artemis.api.core.SimpleString.readNullableSimpleString(SimpleString.java:150)
>  ~[artemis-commons-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:79)
>  ~[artemis-commons-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.persistence.config.PersistedSecuritySetting.decode(PersistedSecuritySetting.java:255)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.newSecurityRecord(AbstractJournalStorageManager.java:2127)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.lambda$loadBindingJournal$5(AbstractJournalStorageManager.java:1640)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList$SparseArray.clear(SparseArrayLinkedList.java:114)
>  ~[artemis-commons-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList.clearSparseArrayList(SparseArrayLinkedList.java:173)
>  ~[artemis-commons-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.utils.collections.SparseArrayLinkedList.clear(SparseArrayLinkedList.java:227)
>  ~[artemis-commons-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadBindingJournal(AbstractJournalStorageManager.java:1613)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:3856)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3489)
>  ~[artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ReplicationPrimaryActivation.run(ReplicationPrimaryActivation.java:145)
>  [artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:738)
>  [artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:628)
>  [artemis-server-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66) 
> [artemis-cli-2.33.0.jar:2.33.0]
> at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:130) 
> [artemis-cli-2.33.0.jar:2.33.0]
> at 
> org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:221) 
> [artemis-cli-2.33.0.jar:2.33.0]
> at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:167) 
> [artemis-cli-2.33.0.jar:2.33.0]
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method) ~[?:?]
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>  ~[?:?]
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:?]
> at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
> at

[jira] [Work logged] (ARTEMIS-4742) Decoding PersistedSecuritySetting fails after upgrade

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 23/Apr/24 03:00
Start Date: 23/Apr/24 03:00
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on code in PR #4904:
URL: https://github.com/apache/activemq-artemis/pull/4904#discussion_r1575580898


##
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/security/PersistedSecuritySettingTest.java:
##
@@ -43,4 +48,31 @@ public void testNPE() {
   persistedSecuritySetting.getViewRoles();
   persistedSecuritySetting.getEditRoles();
}
+
+   @Test
+   public void testUpgradeAfterARTEMIS_4582() {

Review Comment:
   did you think about writing a compatibility test, perhaps using the 
functionality?





Issue Time Tracking
---

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

> Decoding PersistedSecuritySetting fails after upgrade
> -
>
> Key: ARTEMIS-4742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4742
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




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

[jira] [Commented] (ARTEMIS-4743) Split lines on CLI Queue stat when the queue names or address names are too large

2024-04-22 Thread Clebert Suconic (Jira)



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

Clebert Suconic commented on ARTEMIS-4743:
--

before you could configure the max-size of the QueueStat. with this enhancement 
the queue stat will split it in multiple lines.

> Split lines on CLI Queue stat when the queue names or address names are too 
> large
> -
>
> Key: ARTEMIS-4743
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4743
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.33.0
>Reporter: Clebert Suconic
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




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

[jira] [Work logged] (ARTEMIS-4743) Split lines on CLI Queue stat when the queue names or address names are too large

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 22/Apr/24 23:17
Start Date: 22/Apr/24 23:17
Worklog Time Spent: 10m 
  Work Description: clebertsuconic opened a new pull request, #4905:
URL: https://github.com/apache/activemq-artemis/pull/4905

   (no comment)




Issue Time Tracking
---

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

> Split lines on CLI Queue stat when the queue names or address names are too 
> large
> -
>
> Key: ARTEMIS-4743
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4743
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.33.0
>Reporter: Clebert Suconic
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




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

[jira] [Created] (ARTEMIS-4743) Split lines on CLI Queue stat when the queue names or address names are too large

2024-04-22 Thread Clebert Suconic (Jira)

Clebert Suconic created ARTEMIS-4743:


 Summary: Split lines on CLI Queue stat when the queue names or 
address names are too large
 Key: ARTEMIS-4743
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4743
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Affects Versions: 2.33.0
Reporter: Clebert Suconic






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

[jira] [Work logged] (ARTEMIS-4742) Decoding PersistedSecuritySetting fails after upgrade

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 22/Apr/24 22:45
Start Date: 22/Apr/24 22:45
Worklog Time Spent: 10m 
  Work Description: jbertram opened a new pull request, #4904:
URL: https://github.com/apache/activemq-artemis/pull/4904

   (no comment)




Issue Time Tracking
---

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

> Decoding PersistedSecuritySetting fails after upgrade
> -
>
> Key: ARTEMIS-4742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4742
> 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.20.10#820010)

[jira] [Commented] (ARTEMIS-4182) fill client-id for cluster connections

2024-04-22 Thread Erwin Dondorp (Jira)



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

Erwin Dondorp commented on ARTEMIS-4182:


> I was asking for a screenshot of where, "the field 'Client ID' is filled in 
> with the remote hostname when using broker-connection/amqp-connection."

I was wrong and I cannot reproduce that.
The broker-connection/amqp-connection always uses the remote node-id as the 
client-id.
Here is a screenshot for such connection:
!screenshot-2.png!

> I think the best we could do would be to use the node ID which is 
> automatically generated when the broker is created and uniquely identifies 
> the broker from all others

The node-ID is an internal value that requires some lookup to be done to find 
the more well-known name.
But, agreed, it is consistent with the way broker-connection/amqp-connection 
works and already a nice improvement.

> or use the {{name}} of the node set in {{broker.xml}}

that would be even more useful.

> fill client-id for cluster connections
> --
>
> Key: ARTEMIS-4182
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4182
> Project: ActiveMQ Artemis
>  Issue Type: Wish
>  Components: Broker
>Affects Versions: 2.28.0
>Reporter: Erwin Dondorp
>Priority: Major
> Attachments: image-2023-02-25-13-27-08-542.png, screenshot-2.png
>
>
> when running Artemis in a cluster, the brokers have connections between them.
> these are easily identifiable in the list of connections because the "Users" 
> field is filled in with the username that was specified in setting 
> `cluster-user`.
> but it is unclear where each connection goes to.
> !image-2023-02-25-13-27-08-542.png!
>  
> additional information:
> the field "Client ID" is filled in with the remote hostname when using 
> broker-connection/amqp-connection.
> wish:
> (also) fill in field ClientID of the cluster connections.
> e.g. with the broker-name or from a new parameter `cluster-clientid`



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

[jira] [Created] (ARTEMIS-4742) Decoding PersistedSecuritySetting fails after upgrade

2024-04-22 Thread Justin Bertram (Jira)

Justin Bertram created ARTEMIS-4742:
---

 Summary: Decoding PersistedSecuritySetting fails after upgrade
 Key: ARTEMIS-4742
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4742
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Reporter: Justin Bertram
Assignee: Justin Bertram






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

[jira] [Updated] (ARTEMIS-4182) fill client-id for cluster connections

2024-04-22 Thread Erwin Dondorp (Jira)



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

Erwin Dondorp updated ARTEMIS-4182:
---
Attachment: screenshot-2.png

> fill client-id for cluster connections
> --
>
> Key: ARTEMIS-4182
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4182
> Project: ActiveMQ Artemis
>  Issue Type: Wish
>  Components: Broker
>Affects Versions: 2.28.0
>Reporter: Erwin Dondorp
>Priority: Major
> Attachments: image-2023-02-25-13-27-08-542.png, screenshot-2.png
>
>
> when running Artemis in a cluster, the brokers have connections between them.
> these are easily identifiable in the list of connections because the "Users" 
> field is filled in with the username that was specified in setting 
> `cluster-user`.
> but it is unclear where each connection goes to.
> !image-2023-02-25-13-27-08-542.png!
>  
> additional information:
> the field "Client ID" is filled in with the remote hostname when using 
> broker-connection/amqp-connection.
> wish:
> (also) fill in field ClientID of the cluster connections.
> e.g. with the broker-name or from a new parameter `cluster-clientid`



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

[jira] [Updated] (ARTEMIS-4182) fill client-id for cluster connections

2024-04-22 Thread Erwin Dondorp (Jira)



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

Erwin Dondorp updated ARTEMIS-4182:
---
Attachment: (was: screenshot-1.png)

> fill client-id for cluster connections
> --
>
> Key: ARTEMIS-4182
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4182
> Project: ActiveMQ Artemis
>  Issue Type: Wish
>  Components: Broker
>Affects Versions: 2.28.0
>Reporter: Erwin Dondorp
>Priority: Major
> Attachments: image-2023-02-25-13-27-08-542.png, screenshot-2.png
>
>
> when running Artemis in a cluster, the brokers have connections between them.
> these are easily identifiable in the list of connections because the "Users" 
> field is filled in with the username that was specified in setting 
> `cluster-user`.
> but it is unclear where each connection goes to.
> !image-2023-02-25-13-27-08-542.png!
>  
> additional information:
> the field "Client ID" is filled in with the remote hostname when using 
> broker-connection/amqp-connection.
> wish:
> (also) fill in field ClientID of the cluster connections.
> e.g. with the broker-name or from a new parameter `cluster-clientid`



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

[jira] [Updated] (ARTEMIS-4182) fill client-id for cluster connections

2024-04-22 Thread Erwin Dondorp (Jira)



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

Erwin Dondorp updated ARTEMIS-4182:
---
Attachment: screenshot-1.png

> fill client-id for cluster connections
> --
>
> Key: ARTEMIS-4182
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4182
> Project: ActiveMQ Artemis
>  Issue Type: Wish
>  Components: Broker
>Affects Versions: 2.28.0
>Reporter: Erwin Dondorp
>Priority: Major
> Attachments: image-2023-02-25-13-27-08-542.png, screenshot-1.png
>
>
> when running Artemis in a cluster, the brokers have connections between them.
> these are easily identifiable in the list of connections because the "Users" 
> field is filled in with the username that was specified in setting 
> `cluster-user`.
> but it is unclear where each connection goes to.
> !image-2023-02-25-13-27-08-542.png!
>  
> additional information:
> the field "Client ID" is filled in with the remote hostname when using 
> broker-connection/amqp-connection.
> wish:
> (also) fill in field ClientID of the cluster connections.
> e.g. with the broker-name or from a new parameter `cluster-clientid`



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

[jira] [Comment Edited] (ARTEMIS-4182) fill client-id for cluster connections

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram edited comment on ARTEMIS-4182 at 4/22/24 8:44 PM:
--

bq. The screenshot is already in the description. The image shows that 
cluster-connections do not fill the column ClientID

I was asking for a screenshot of where, "the field 'Client ID' is filled in 
with the remote hostname when using broker-connection/amqp-connection."


Regarding your use-case...

I don't think that using the hostname of the machine will be a robust solution 
because a single host may have many different brokers running simultaneously. I 
think the best we could do would be to use the node ID which is automatically 
generated when the broker is created and uniquely identifies the broker from 
all others *or* use the {{name}} of the node set in {{broker.xml}} if that is 
set instead. Would that work?


was (Author: jbertram):
bq. The screenshot is already in the description. The image shows that 
cluster-connections do not fill the column ClientID

I was asking for a screenshot of where, "the field 'Client ID' is filled in 
with the remote hostname when using broker-connection/amqp-connection."


Regarding your use-case...

I don't think that using the hostname of the machine will be a robust solution 
because a single host may have many different brokers running simultaneously. I 
think the best we could do would be to use the node ID which is automatically 
generated when the broker is created an unique identifies the broker from all 
others *or* use the {{name}} of the node set in {{broker.xml}} if that is set 
instead. Would that work?

> fill client-id for cluster connections
> --
>
> Key: ARTEMIS-4182
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4182
> Project: ActiveMQ Artemis
>  Issue Type: Wish
>  Components: Broker
>Affects Versions: 2.28.0
>Reporter: Erwin Dondorp
>Priority: Major
> Attachments: image-2023-02-25-13-27-08-542.png
>
>
> when running Artemis in a cluster, the brokers have connections between them.
> these are easily identifiable in the list of connections because the "Users" 
> field is filled in with the username that was specified in setting 
> `cluster-user`.
> but it is unclear where each connection goes to.
> !image-2023-02-25-13-27-08-542.png!
>  
> additional information:
> the field "Client ID" is filled in with the remote hostname when using 
> broker-connection/amqp-connection.
> wish:
> (also) fill in field ClientID of the cluster connections.
> e.g. with the broker-name or from a new parameter `cluster-clientid`



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

[jira] [Commented] (ARTEMIS-4182) fill client-id for cluster connections

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram commented on ARTEMIS-4182:
-

bq. The screenshot is already in the description. The image shows that 
cluster-connections do not fill the column ClientID

I was asking for a screenshot of where, "the field 'Client ID' is filled in 
with the remote hostname when using broker-connection/amqp-connection."


Regarding your use-case...

I don't think that using the hostname of the machine will be a robust solution 
because a single host may have many different brokers running simultaneously. I 
think the best we could do would be to use the node ID which is automatically 
generated when the broker is created an unique identifies the broker from all 
others *or* use the {{name}} of the node set in {{broker.xml}} if that is set 
instead. Would that work?

> fill client-id for cluster connections
> --
>
> Key: ARTEMIS-4182
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4182
> Project: ActiveMQ Artemis
>  Issue Type: Wish
>  Components: Broker
>Affects Versions: 2.28.0
>Reporter: Erwin Dondorp
>Priority: Major
> Attachments: image-2023-02-25-13-27-08-542.png
>
>
> when running Artemis in a cluster, the brokers have connections between them.
> these are easily identifiable in the list of connections because the "Users" 
> field is filled in with the username that was specified in setting 
> `cluster-user`.
> but it is unclear where each connection goes to.
> !image-2023-02-25-13-27-08-542.png!
>  
> additional information:
> the field "Client ID" is filled in with the remote hostname when using 
> broker-connection/amqp-connection.
> wish:
> (also) fill in field ClientID of the cluster connections.
> e.g. with the broker-name or from a new parameter `cluster-clientid`



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

[jira] [Resolved] (ARTEMIS-4738) OVERRIDING EQUALS NOT SYMMETRIC in ActiveMQQueue.java

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram resolved ARTEMIS-4738.
-
Resolution: Invalid

As far as I can tell the use of {{instanceof}} here is perfectly valid. You can 
find the same kind of implementation in the {{String}} class shipped by OpenJDK.

> OVERRIDING EQUALS NOT SYMMETRIC in ActiveMQQueue.java
> -
>
> Key: ARTEMIS-4738
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4738
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Priority: Major
>
> The equals method is overridden in the ActiveMQQueue class and this method 
> uses the instanceof operator to check the type of the object. However, this 
> does not take into account the symmetry of the equals method. The equals 
> method must be symmetric, that is, if a.equals(b) returns true, then 
> b.equals(a) must return true. 
> In this case, if the object "o" is not an instance of the ActiveMQQueue 
> class, the equals method immediately returns false([line 
> 83|https://github.com/apache/activemq-artemis/blob/main/artemis-jms-client/src/main/java/org/apache/activemq/artemis/jms/client/ActiveMQQueue.java]),
>  without giving the opportunity to check, on the contrary, whether the 
> current object is an instance of the object "o". Therefore, the equals method 
> in this case does not satisfy the symmetry requirement and can lead to 
> incorrect results when comparing objects.
>  
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.



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

[jira] [Updated] (ARTEMIS-4741) Use specific assertion methods

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram updated ARTEMIS-4741:

Summary: Use specific assertion methods  (was: Use targeted assertion 
methods)

> Use specific assertion methods
> --
>
> Key: ARTEMIS-4741
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4741
> 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.20.10#820010)

[jira] [Work logged] (ARTEMIS-4741) Use targeted assertion methods

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 22/Apr/24 20:17
Start Date: 22/Apr/24 20:17
Worklog Time Spent: 10m 
  Work Description: jbertram opened a new pull request, #4902:
URL: https://github.com/apache/activemq-artemis/pull/4902

   (no comment)




Issue Time Tracking
---

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

> Use targeted assertion methods
> --
>
> Key: ARTEMIS-4741
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4741
> 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.20.10#820010)

[jira] [Created] (ARTEMIS-4741) Use targeted assertion methods

2024-04-22 Thread Justin Bertram (Jira)

Justin Bertram created ARTEMIS-4741:
---

 Summary: Use targeted assertion methods
 Key: ARTEMIS-4741
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4741
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Reporter: Justin Bertram
Assignee: Justin Bertram






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

[jira] [Commented] (ARTEMIS-4735) BOXED PRIMITIVE FOR PARSING in ActiveMQConnectionMetaData.java

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram commented on ARTEMIS-4735:
-

There is unnecessary boxing in many places across the code-base so I opened 
ARTEMIS-4740 to deal with them all rather than just this individual one.

> BOXED PRIMITIVE FOR PARSING in ActiveMQConnectionMetaData.java
> --
>
> Key: ARTEMIS-4735
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4735
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Assignee: Justin Bertram
>Priority: Minor
>
> [On line 
> 48|https://github.com/apache/activemq-artemis/blob/main/artemis-jms-client/src/main/java/org/apache/activemq/artemis/jms/client/ActiveMQConnectionMetaData.java](JMS_MAJOR_VERSION
>  = 
> Integer.valueOf(versionProps.getProperty("activemq.version.implementation.majorVersion",
>  "2")), a truly boxed primitive is created from a string simply to extract 
> the value of the unboxed primitive. This approach is inefficient and can lead 
> to code redundancy and loss of performance.
> A more efficient approach would be to immediately convert strings to 
> primitive values without creating boxed primitives. For example, use the 
> Integer.parseInt() method to directly convert a string to an int without 
> creating an Integer object.
>  
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.



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

[jira] [Resolved] (ARTEMIS-4735) BOXED PRIMITIVE FOR PARSING in ActiveMQConnectionMetaData.java

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram resolved ARTEMIS-4735.
-
  Assignee: Justin Bertram
Resolution: Done

> BOXED PRIMITIVE FOR PARSING in ActiveMQConnectionMetaData.java
> --
>
> Key: ARTEMIS-4735
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4735
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Assignee: Justin Bertram
>Priority: Minor
>
> [On line 
> 48|https://github.com/apache/activemq-artemis/blob/main/artemis-jms-client/src/main/java/org/apache/activemq/artemis/jms/client/ActiveMQConnectionMetaData.java](JMS_MAJOR_VERSION
>  = 
> Integer.valueOf(versionProps.getProperty("activemq.version.implementation.majorVersion",
>  "2")), a truly boxed primitive is created from a string simply to extract 
> the value of the unboxed primitive. This approach is inefficient and can lead 
> to code redundancy and loss of performance.
> A more efficient approach would be to immediately convert strings to 
> primitive values without creating boxed primitives. For example, use the 
> Integer.parseInt() method to directly convert a string to an int without 
> creating an Integer object.
>  
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.



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

[jira] [Work logged] (ARTEMIS-4740) Reduce unnecessary boxing

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 22/Apr/24 19:44
Start Date: 22/Apr/24 19:44
Worklog Time Spent: 10m 
  Work Description: jbertram opened a new pull request, #4901:
URL: https://github.com/apache/activemq-artemis/pull/4901

   (no comment)




Issue Time Tracking
---

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

> Reduce unnecessary boxing
> -
>
> Key: ARTEMIS-4740
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4740
> 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.20.10#820010)

[jira] [Created] (ARTEMIS-4740) Reduce unnecessary boxing

2024-04-22 Thread Justin Bertram (Jira)

Justin Bertram created ARTEMIS-4740:
---

 Summary: Reduce unnecessary boxing
 Key: ARTEMIS-4740
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4740
 Project: ActiveMQ Artemis
  Issue Type: Improvement
Reporter: Justin Bertram
Assignee: Justin Bertram






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

[jira] [Work logged] (ARTEMIS-4734) Null dereferencing in ReplicationManager.java

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 22/Apr/24 18:42
Start Date: 22/Apr/24 18:42
Worklog Time Spent: 10m 
  Work Description: jbertram opened a new pull request, #4900:
URL: https://github.com/apache/activemq-artemis/pull/4900

   (no comment)




Issue Time Tracking
---

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

> Null dereferencing in ReplicationManager.java
> -
>
> Key: ARTEMIS-4734
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4734
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{repliToken}} can be 0.
> In 
> {{org.apache.activemq.artemis.core.replication.ReplicationManager#sendReplicatePacket(org.apache.activemq.artemis.core.protocol.core.Packet,
>  boolean, org.apache.activemq.artemis.utils.ReusableLatch)}} the 
> {{repliToken}} is initialized with the value returned by ([line 
> 464|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/replication/ReplicationManager.java])
>  {{OperationContextImpl.getContext(ioExecutorFactory)}}, i.e.:
> {code:java}
> final OperationContext repliToken = 
> OperationContextImpl.getContext(ioExecutorFactory);{code}
> Inside this method, a call is made to 
> {{OperationContextImpl.threadLocalContext.get()}}([line 
> 61|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/OperationContextImpl.java]),
>  which returns the value from the thread that was set earlier. If no value 
> was set in the stream, then token will be {{null}}.
> {code:java}
> OperationContext token = OperationContextImpl.threadLocalContext.get();{code}
> If {{ioExecutorFactory}} is {{null}} and there is no value set in the thread, 
> then the {{repliToken}} will remain {{null}} because the backing 
> {{getContext()}} method also returns {{null}} in this case.
>  So {{repliToken}} can be 0 if {{ioExecutorFactory}} is {{null}} and there is 
> no value set in the thread.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.
>  
>  



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

[jira] [Assigned] (ARTEMIS-4734) Null dereferencing in ReplicationManager.java

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram reassigned ARTEMIS-4734:
---

Assignee: Justin Bertram

> Null dereferencing in ReplicationManager.java
> -
>
> Key: ARTEMIS-4734
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4734
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Assignee: Justin Bertram
>Priority: Major
>
> {{repliToken}} can be 0.
> In 
> {{org.apache.activemq.artemis.core.replication.ReplicationManager#sendReplicatePacket(org.apache.activemq.artemis.core.protocol.core.Packet,
>  boolean, org.apache.activemq.artemis.utils.ReusableLatch)}} the 
> {{repliToken}} is initialized with the value returned by ([line 
> 464|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/replication/ReplicationManager.java])
>  {{OperationContextImpl.getContext(ioExecutorFactory)}}, i.e.:
> {code:java}
> final OperationContext repliToken = 
> OperationContextImpl.getContext(ioExecutorFactory);{code}
> Inside this method, a call is made to 
> {{OperationContextImpl.threadLocalContext.get()}}([line 
> 61|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/OperationContextImpl.java]),
>  which returns the value from the thread that was set earlier. If no value 
> was set in the stream, then token will be {{null}}.
> {code:java}
> OperationContext token = OperationContextImpl.threadLocalContext.get();{code}
> If {{ioExecutorFactory}} is {{null}} and there is no value set in the thread, 
> then the {{repliToken}} will remain {{null}} because the backing 
> {{getContext()}} method also returns {{null}} in this case.
>  So {{repliToken}} can be 0 if {{ioExecutorFactory}} is {{null}} and there is 
> no value set in the thread.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.
>  
>  



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

[jira] [Updated] (ARTEMIS-4734) Null dereferencing in ReplicationManager.java

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram updated ARTEMIS-4734:

Description: 
{{repliToken}} can be 0.

In 
{{org.apache.activemq.artemis.core.replication.ReplicationManager#sendReplicatePacket(org.apache.activemq.artemis.core.protocol.core.Packet,
 boolean, org.apache.activemq.artemis.utils.ReusableLatch)}} the {{repliToken}} 
is initialized with the value returned by ([line 
464|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/replication/ReplicationManager.java])
 {{OperationContextImpl.getContext(ioExecutorFactory)}}, i.e.:
{code:java}
final OperationContext repliToken = 
OperationContextImpl.getContext(ioExecutorFactory);{code}
Inside this method, a call is made to 
{{OperationContextImpl.threadLocalContext.get()}}([line 
61|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/OperationContextImpl.java]),
 which returns the value from the thread that was set earlier. If no value was 
set in the stream, then token will be {{null}}.
{code:java}
OperationContext token = OperationContextImpl.threadLocalContext.get();{code}
If {{ioExecutorFactory}} is {{null}} and there is no value set in the thread, 
then the {{repliToken}} will remain {{null}} because the backing 
{{getContext()}} method also returns {{null}} in this case.

 So {{repliToken}} can be 0 if {{ioExecutorFactory}} is {{null}} and there is 
no value set in the thread.

Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author Alexey Galkin.

 

 

  was:
repliToken can be 0.

In this code, the repliToken is initialized with the value returned by the 
method ([line 
464|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/replication/ReplicationManager.java])
 OperationContextImpl.getContext(ioExecutorFactory)

final OperationContext repliToken = 
OperationContextImpl.getContext(ioExecutorFactory);

Inside this method, a call is made to the 
OperationContextImpl.threadLocalContext.get()([line 
61|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/OperationContextImpl.java])
 method, which returns the value from the thread that was set earlier. If no 
value was set in the stream, then token will be null.

OperationContext token = OperationContextImpl.threadLocalContext.get();


If ioExecutorFactory is null and there is no value set in the thread, then the 
repliToken will remain null because the backing getContext() method also 
returns null in this case.

 So repliToken can be 0 if ioExecutorFactory is null and there is no value set 
in the thread.

Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author Alexey Galkin.

 

 


> Null dereferencing in ReplicationManager.java
> -
>
> Key: ARTEMIS-4734
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4734
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Priority: Major
>
> {{repliToken}} can be 0.
> In 
> {{org.apache.activemq.artemis.core.replication.ReplicationManager#sendReplicatePacket(org.apache.activemq.artemis.core.protocol.core.Packet,
>  boolean, org.apache.activemq.artemis.utils.ReusableLatch)}} the 
> {{repliToken}} is initialized with the value returned by ([line 
> 464|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/replication/ReplicationManager.java])
>  {{OperationContextImpl.getContext(ioExecutorFactory)}}, i.e.:
> {code:java}
> final OperationContext repliToken = 
> OperationContextImpl.getContext(ioExecutorFactory);{code}
> Inside this method, a call is made to 
> {{OperationContextImpl.threadLocalContext.get()}}([line 
> 61|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/OperationContextImpl.java]),
>  which returns the value from the thread that was set earlier. If no value 
> was set in the stream, then token will be {{null}}.
> {code:java}
> OperationContext token = OperationContextImpl.threadLocalContext.get();{code}
> If {{ioExecutorFactory}} is {{null}} and there is no value set in the thread, 
> then the {{repliToken}} will remain {{null}} because the backing 
> {{getContext()}} method also returns {{null}} in this case.
>  So {{repliToken}} can be 0 if {{ioExecutorFactory}} is {{null}} and there is 
> no value set in the thread.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.
>  
>  



--
This message was sent by Atlassian Jira

[jira] [Commented] (ARTEMIS-4734) Null dereferencing in ReplicationManager.java

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram commented on ARTEMIS-4734:
-

bq. repliToken can be 0.

This doesn't make sense. Do you mean "{{repliToken}} can be {{null}}"?

> Null dereferencing in ReplicationManager.java
> -
>
> Key: ARTEMIS-4734
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4734
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Priority: Major
>
> repliToken can be 0.
> In this code, the repliToken is initialized with the value returned by the 
> method ([line 
> 464|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/replication/ReplicationManager.java])
>  OperationContextImpl.getContext(ioExecutorFactory)
> final OperationContext repliToken = 
> OperationContextImpl.getContext(ioExecutorFactory);
> Inside this method, a call is made to the 
> OperationContextImpl.threadLocalContext.get()([line 
> 61|https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/OperationContextImpl.java])
>  method, which returns the value from the thread that was set earlier. If no 
> value was set in the stream, then token will be null.
> OperationContext token = OperationContextImpl.threadLocalContext.get();
> If ioExecutorFactory is null and there is no value set in the thread, then 
> the repliToken will remain null because the backing getContext() method also 
> returns null in this case.
>  So repliToken can be 0 if ioExecutorFactory is null and there is no value 
> set in the thread.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.
>  
>  



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

[jira] [Commented] (ARTEMIS-4733) Mirror Infinite loops (mirror infinite Reflection) from Internal Queues

2024-04-22 Thread ASF subversion and git services (Jira)



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

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

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

ARTEMIS-4733 Fixing test as it is now correctly ignoring MQTT internal queue


> Mirror Infinite loops (mirror infinite Reflection) from Internal Queues
> ---
>
> Key: ARTEMIS-4733
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4733
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.33.0
>Reporter: Clebert Suconic
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I am seeing Mirroring causing infinite reflections on createAddresses
> I couldn't make the test I wrote to fail before ARTEMIS-4498



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

[jira] [Resolved] (ARTEMIS-4736) DOESNT OVERRIDE EQUALS in ConnectionFactoryProperties.java

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram resolved ARTEMIS-4736.
-
Resolution: Invalid

> DOESNT OVERRIDE EQUALS in ConnectionFactoryProperties.java
> --
>
> Key: ARTEMIS-4736
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4736
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Priority: Major
>
> The class overrides the equals method, but does not implement its logic. 
> Instead, it compares objects by their classes using the getClass() method (
> if (getClass() != obj.getClass()) [line 
> 748|https://github.com/apache/activemq-artemis/blob/main/artemis-ra/src/main/java/org/apache/activemq/artemis/ra/ConnectionFactoryProperties.java]),
>  which can lead to incorrect object comparisons. For the equals method to 
> work correctly, you need to override its logic so that it compares objects by 
> their fields or other criteria, and not just by their classes.
>  
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.



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

[jira] [Commented] (ARTEMIS-4736) DOESNT OVERRIDE EQUALS in ConnectionFactoryProperties.java

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram commented on ARTEMIS-4736:
-

bq. ...it compares objects by their classes using the getClass() method...

The comparison using {{getClass()}} doesn't prove equality. It simply proves 
inequality. In other words, if a {{ConnectionFactoryProperties}} instance is 
compared to a {{String}} instance then this comparison would fail (correctly). 
However, if a {{ConnectionFactoryProperties}} instance is compared to another 
{{ConnectionFactoryProperties}} instance then the comparison would succeed and 
the method would *continue executing* rather than just returning {{true}} as is 
implied in your description.

bq. For the equals method to work correctly, you need to override its logic so 
that it compares objects by their fields or other criteria, and not just by 
their classes.

That's exactly what the {{equals}} implementation of 
{{ConnectionFactoryProperties}} does.

> DOESNT OVERRIDE EQUALS in ConnectionFactoryProperties.java
> --
>
> Key: ARTEMIS-4736
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4736
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Priority: Major
>
> The class overrides the equals method, but does not implement its logic. 
> Instead, it compares objects by their classes using the getClass() method (
> if (getClass() != obj.getClass()) [line 
> 748|https://github.com/apache/activemq-artemis/blob/main/artemis-ra/src/main/java/org/apache/activemq/artemis/ra/ConnectionFactoryProperties.java]),
>  which can lead to incorrect object comparisons. For the equals method to 
> work correctly, you need to override its logic so that it compares objects by 
> their fields or other criteria, and not just by their classes.
>  
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.



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

[jira] [Work logged] (ARTEMIS-4305) Zero persistence does not work in kubernetes

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 22/Apr/24 16:58
Start Date: 22/Apr/24 16:58
Worklog Time Spent: 10m 
  Work Description: iiliev2 opened a new pull request, #4899:
URL: https://github.com/apache/activemq-artemis/pull/4899

   In a cluster deployed in kubernetes, when a node is destroyed it terminates 
the process and shuts down the network before the process has a chance to close 
connections. Then a new node might be brought up, reusing the old node’s ip. If 
this happens before the connection ttl, from artemis’ point of view, it looks 
like as if the connection came back. Yet it is actually not the same, the peer 
has a new node id, etc. This messes things up with the cluster, the old message 
flow record is invalid.
   
   This also solves another similar issue - if a node goes down and a new one 
comes in with a new nodeUUID and the same IP before the cluster connections in 
the others timeout, it would cause them to get stuck and list both the old and 
the new nodes in their topologies.
   
   The changes are grouped in tightly related incremental commits to make it 
easier to understand what is changed:
   
   1. `Ping` packets include `nodeUUID`
   2. Acceptors and connectors carry `TransportConfiguration`
   3. `RemotingConnectionImpl#doBufferReceived` tracks for ping nodeUUID 
mismatch with the target to flag it as `unhealthy`;  `ClientSessionFactoryImpl` 
destroys unhealthy connections(in addition to not receiving any data on time)




Issue Time Tracking
---

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

> Zero persistence does not work in kubernetes
> 
>
> Key: ARTEMIS-4305
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4305
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In a cluster deployed in kubernetes, when a node is destroyed it terminates 
> the process and shuts down the network before the process has a chance to 
> close connections. Then a new node might be brought up, reusing the old 
> node’s ip. If this happens before the connection ttl, from artemis’ point of 
> view, it looks like as if the connection came back. Yet it is actually not 
> the same, the peer has a new node id, etc. This messes things up with the 
> cluster, the old message flow record is invalid.
> One way to fix it could be if the {{Ping}} messages which are typically used 
> to detect dead connections could use some sort of connection id to match that 
> the other side is really the one which it is supposed to be.



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

[jira] [Comment Edited] (ARTEMIS-4739) HANDLE LEAK in OpenWireMessageConverter.java

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram edited comment on ARTEMIS-4739 at 4/22/24 4:05 PM:
--

If {{messageCompressed}} is {{true}} then an {{InflaterInputStream}} instance 
is created which *wraps* the previously created {{ByteArrayInputStream}}. Then 
{{DataInputStream}} *wraps* the {{InflaterInputStream}} so that when {{close}} 
is invoked on the {{DataInputStream}} then it is invoked in turn on the 
{{InflaterInputStream}} and then on the {{ByteArrayInputStream}} which means 
*there is no leak*.

It's also worth noting that the {{ByteArrayInputStream}} implementation of 
{{close}} is empty so even if {{ByteArrayInputStream.close}} wasn't invoked it 
wouldn't be a big deal.


was (Author: jbertram):
If {{messageCompressed}} is {{true}} then an {{InflaterInputStream}} instance 
is created with *wraps* the previously created {{ByteArrayInputStream}}. Then 
{{DataInputStream}} *wraps* the {{InflaterInputStream}} so that when {{close}} 
is invoked on the {{DataInputStream}} then it is invoked in turn on the 
{{InflaterInputStream}} and then on the {{ByteArrayInputStream}} which means 
*there is no leak*.

It's also worth noting that the {{ByteArrayInputStream}} implementation of 
{{close}} is empty so even if {{ByteArrayInputStream.close}} wasn't invoked it 
wouldn't be a big deal.

> HANDLE LEAK in OpenWireMessageConverter.java
> 
>
> Key: ARTEMIS-4739
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4739
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Priority: Major
>
> The handle tis, which is an object of type InflaterInputStream([line 233 
> |https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]),
>  is created in the code and used to read data from contents([line 
> 231|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]).
>  However, if the messageCompressed condition is true, then an 
> InflaterInputStream object will be created based on tis, and tis will be 
> overwritten with a new InflaterInputStream object. The problem occurs on 
> [line 
> 237|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]
>  because only the DataInputStream tdataIn is closed, but tis is not closed 
> explicitly. This may result in resource leakage and unavailability of 
> resources associated with the InflaterInputStream.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.



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

[jira] [Commented] (ARTEMIS-4739) HANDLE LEAK in OpenWireMessageConverter.java

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram commented on ARTEMIS-4739:
-

If {{messageCompressed}} is {{true}} then an {{InflaterInputStream}} instance 
is created with *wraps* the previously created {{ByteArrayInputStream}}. Then 
{{DataInputStream}} *wraps* the {{InflaterInputStream}} so that when {{close}} 
is invoked on the {{DataInputStream}} then it is invoked in turn on the 
{{InflaterInputStream}} and then on the {{ByteArrayInputStream}} which means 
*there is no leak*.

It's also worth noting that the {{ByteArrayInputStream}} implementation of 
{{close}} is empty so even if {{ByteArrayInputStream.close}} wasn't invoked it 
wouldn't be a big deal.

> HANDLE LEAK in OpenWireMessageConverter.java
> 
>
> Key: ARTEMIS-4739
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4739
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Priority: Major
>
> The handle tis, which is an object of type InflaterInputStream([line 233 
> |https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]),
>  is created in the code and used to read data from contents([line 
> 231|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]).
>  However, if the messageCompressed condition is true, then an 
> InflaterInputStream object will be created based on tis, and tis will be 
> overwritten with a new InflaterInputStream object. The problem occurs on 
> [line 
> 237|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]
>  because only the DataInputStream tdataIn is closed, but tis is not closed 
> explicitly. This may result in resource leakage and unavailability of 
> resources associated with the InflaterInputStream.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.



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

[jira] [Resolved] (ARTEMIS-4739) HANDLE LEAK in OpenWireMessageConverter.java

2024-04-22 Thread Justin Bertram (Jira)



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

Justin Bertram resolved ARTEMIS-4739.
-
Resolution: Invalid

> HANDLE LEAK in OpenWireMessageConverter.java
> 
>
> Key: ARTEMIS-4739
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4739
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Priority: Major
>
> The handle tis, which is an object of type InflaterInputStream([line 233 
> |https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]),
>  is created in the code and used to read data from contents([line 
> 231|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]).
>  However, if the messageCompressed condition is true, then an 
> InflaterInputStream object will be created based on tis, and tis will be 
> overwritten with a new InflaterInputStream object. The problem occurs on 
> [line 
> 237|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]
>  because only the DataInputStream tdataIn is closed, but tis is not closed 
> explicitly. This may result in resource leakage and unavailability of 
> resources associated with the InflaterInputStream.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.



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

[jira] [Resolved] (ARTEMIS-4709) Add a plugin to provide periodic expiry of connections on a per acceptor basis

2024-04-22 Thread Gary Tully (Jira)



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

Gary Tully resolved ARTEMIS-4709.
-
Resolution: Fixed

> Add a plugin to provide periodic expiry of connections on a per acceptor basis
> --
>
> Key: ARTEMIS-4709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4709
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 2.33.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.34.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> When credential rotation needs to be enforced, active connections need to be 
> terminated on some timeline to ensure credentials are reevaluated. There are 
> management apis that can be used but these require some intervention.
> In addition to enforce some SLA around duration of connections, having an 
> easy way to limit connections to a given maximum period can be helpful.
> A plugin that will be applied on an per acceptor basis, that can be used to 
> disconnect connections that have lived for some period can provide a nice 
> building block for these use cases.



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

[jira] [Commented] (ARTEMIS-4709) Add a plugin to provide periodic expiry of connections on a per acceptor basis

2024-04-22 Thread ASF subversion and git services (Jira)



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

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

Commit 20f345dbe18de05aabd80c1601113d2781a1c4a8 in activemq-artemis's branch 
refs/heads/main from Gary Tully
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=20f345dbe1 ]

ARTEMIS-4709 plugin to enforce connection periodic expiry per acceptor


> Add a plugin to provide periodic expiry of connections on a per acceptor basis
> --
>
> Key: ARTEMIS-4709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4709
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 2.33.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.34.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> When credential rotation needs to be enforced, active connections need to be 
> terminated on some timeline to ensure credentials are reevaluated. There are 
> management apis that can be used but these require some intervention.
> In addition to enforce some SLA around duration of connections, having an 
> easy way to limit connections to a given maximum period can be helpful.
> A plugin that will be applied on an per acceptor basis, that can be used to 
> disconnect connections that have lived for some period can provide a nice 
> building block for these use cases.



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

[jira] [Work logged] (ARTEMIS-4709) Add a plugin to provide periodic expiry of connections on a per acceptor basis

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 22/Apr/24 15:19
Start Date: 22/Apr/24 15:19
Worklog Time Spent: 10m 
  Work Description: jbertram merged PR #4871:
URL: https://github.com/apache/activemq-artemis/pull/4871




Issue Time Tracking
---

Worklog Id: (was: 915847)
Time Spent: 2h 10m  (was: 2h)

> Add a plugin to provide periodic expiry of connections on a per acceptor basis
> --
>
> Key: ARTEMIS-4709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4709
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 2.33.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.34.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> When credential rotation needs to be enforced, active connections need to be 
> terminated on some timeline to ensure credentials are reevaluated. There are 
> management apis that can be used but these require some intervention.
> In addition to enforce some SLA around duration of connections, having an 
> easy way to limit connections to a given maximum period can be helpful.
> A plugin that will be applied on an per acceptor basis, that can be used to 
> disconnect connections that have lived for some period can provide a nice 
> building block for these use cases.



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

[jira] [Resolved] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher

2024-04-22 Thread Christopher L. Shannon (Jira)



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

Christopher L. Shannon resolved AMQ-9481.
-
Resolution: Fixed

> Concurrent access error attempting to consume messages via REST API in 5.18.2 
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
>  Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I am attempting to download a file from a queue via PowerShell. This can be 
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri 
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer; 
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times 
> out after a short period if there are no files on the queue. When I run the 
> same script against 5.18.2 or higher, I get the following error the first 
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> +           ~~~
>     + CategoryInfo          : InvalidOperation: 
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
>    eption
>     + FullyQualifiedErrorId : 
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException: 
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException: 
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is 
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
>         at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
>         at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
>         at org.eclipse.jetty.server.Server.handle(Server.java:516)
>         at 
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
>         at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
>         at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
>         at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
>         at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
>         at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
>         at 
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>         at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
>         at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
>         at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> Caused by: javax.servlet.ServletException: javax.servlet.ServletException: 
> Concurrent access to consumer is not
>

[jira] [Commented] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher

2024-04-22 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on AMQ-9481:
--

Commit 827ad1012b934ca4fff749a5da1a9c1e070a0ee1 in activemq's branch 
refs/heads/activemq-5.18.x from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=827ad1012 ]

AMQ-9481 - Correctly complete async servlet request on timeout

This fixes AsyncServletRequest to correctly call context.dispatch() when
the async request times out so that the consumer can be re-used.

(cherry picked from commit 72befc14fbb69c24bdec0c7d4a1002da8874380d)


> Concurrent access error attempting to consume messages via REST API in 5.18.2 
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
>  Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I am attempting to download a file from a queue via PowerShell. This can be 
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri 
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer; 
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times 
> out after a short period if there are no files on the queue. When I run the 
> same script against 5.18.2 or higher, I get the following error the first 
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> +           ~~~
>     + CategoryInfo          : InvalidOperation: 
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
>    eption
>     + FullyQualifiedErrorId : 
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException: 
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException: 
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is 
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
>         at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
>         at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
>         at org.eclipse.jetty.server.Server.handle(Server.java:516)
>         at 
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
>         at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
>         at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
>         at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
>         at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
>         at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
>         at 
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>

[jira] [Commented] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher

2024-04-22 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on AMQ-9481:
--

Commit 6e6caf7c6060efadc1ba524147e71d9720fcd935 in activemq's branch 
refs/heads/main from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=6e6caf7c6 ]

Merge pull request #1206 from apache/AMQ-9841

AMQ-9481 - Correctly complete async servlet request on timeout

> Concurrent access error attempting to consume messages via REST API in 5.18.2 
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
>  Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I am attempting to download a file from a queue via PowerShell. This can be 
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri 
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer; 
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times 
> out after a short period if there are no files on the queue. When I run the 
> same script against 5.18.2 or higher, I get the following error the first 
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> +           ~~~
>     + CategoryInfo          : InvalidOperation: 
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
>    eption
>     + FullyQualifiedErrorId : 
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException: 
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException: 
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is 
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
>         at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
>         at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
>         at org.eclipse.jetty.server.Server.handle(Server.java:516)
>         at 
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
>         at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
>         at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
>         at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
>         at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
>         at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
>         at 
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>         at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
>         at 
>

[jira] [Commented] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher

2024-04-22 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on AMQ-9481:
--

Commit 72befc14fbb69c24bdec0c7d4a1002da8874380d in activemq's branch 
refs/heads/main from Christopher L. Shannon
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=72befc14f ]

AMQ-9481 - Correctly complete async servlet request on timeout

This fixes AsyncServletRequest to correctly call context.dispatch() when
the async request times out so that the consumer can be re-used.


> Concurrent access error attempting to consume messages via REST API in 5.18.2 
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
>  Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I am attempting to download a file from a queue via PowerShell. This can be 
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri 
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer; 
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times 
> out after a short period if there are no files on the queue. When I run the 
> same script against 5.18.2 or higher, I get the following error the first 
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> +           ~~~
>     + CategoryInfo          : InvalidOperation: 
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
>    eption
>     + FullyQualifiedErrorId : 
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException: 
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException: 
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is 
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
>         at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
>         at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
>         at org.eclipse.jetty.server.Server.handle(Server.java:516)
>         at 
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
>         at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
>         at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
>         at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
>         at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
>         at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
>         at 
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>         at 
>

[jira] [Work logged] (AMQ-9481) Concurrent access error attempting to consume messages via REST API in 5.18.2 or higher

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 22/Apr/24 15:01
Start Date: 22/Apr/24 15:01
Worklog Time Spent: 10m 
  Work Description: cshannon merged PR #1206:
URL: https://github.com/apache/activemq/pull/1206




Issue Time Tracking
---

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

> Concurrent access error attempting to consume messages via REST API in 5.18.2 
> or higher
> ---
>
> Key: AMQ-9481
> URL: https://issues.apache.org/jira/browse/AMQ-9481
> Project: ActiveMQ Classic
>  Issue Type: Bug
>Affects Versions: 5.18.2, 5.18.3, 5.18.4
>Reporter: Andrew Smith
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.18.5, 6.1.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I am attempting to download a file from a queue via PowerShell. This can be 
> done with the following 4 lines:
> {code:java}
> $user="admin"
> $pass="admin" | ConvertTo-SecureString -AsPlainText -Force
> $cred = New-Object Management.Automation.PSCredential($user,$pass)
> $status = Invoke-WebRequest -Uri 
> "http://localhost:8161/api/message/TestQueue?type=queue=Importer; 
> -Credential $cred -ContentType "application/base64"{code}
> When I do this using 5.18.1, it works and either downloads a file or times 
> out after a short period if there are no files on the queue. When I run the 
> same script against 5.18.2 or higher, I get the following error the first 
> time I try to download a file after starting the broker:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 AsyncContext timeout
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:AsyncContext timeout
> SERVLET:MessageServlet
> At line:1 char:11
> + $status = Invoke-WebRequest -Uri "http://localhost:8161/api/message/T ...
> +           ~~~
>     + CategoryInfo          : InvalidOperation: 
> (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
>    eption
>     + FullyQualifiedErrorId : 
> WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand{noformat}
> Then every time I try after that I get the following:
> {noformat}
> Invoke-WebRequest : HTTP ERROR 500 javax.servlet.ServletException: 
> javax.servlet.ServletException:
> javax.servlet.ServletException: Concurrent access to consumer is not supported
> URI:/api/message/TestQueue
> STATUS:500
> MESSAGE:javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> SERVLET:MessageServlet
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent
> access to consumer is not supported
> CAUSED BY:javax.servlet.ServletException: javax.servlet.ServletException: 
> Concurrent access to consumer is not
> supported
> CAUSED BY:javax.servlet.ServletException: Concurrent access to consumer is 
> not supported
> Caused by:
> javax.servlet.ServletException: javax.servlet.ServletException: 
> javax.servlet.ServletException: Concurrent access to
> consumer is not supported
>         at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:162)
>         at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
>         at org.eclipse.jetty.server.Server.handle(Server.java:516)
>         at 
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)
>         at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
>         at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
>         at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)
>         at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
>         at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
>         at 
> org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)
>         at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>         at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)
>

[jira] [Commented] (ARTEMIS-4582) add view and edit permissions to extend security-settings rbac for management operations

2024-04-22 Thread ASF subversion and git services (Jira)



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

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

Commit a4d1f7084ddf2cafd339e4a236466e220039c8be in activemq-artemis's branch 
refs/heads/main from Gary Tully
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=a4d1f7084d ]

ARTEMIS-4582 - fix typo in smoke test comment


> add view and edit permissions to extend security-settings rbac for management 
> operations
> 
>
> 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
> Fix For: 2.33.0
>
>  Time Spent: 4h 40m
>  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)
> edit 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-4680) Upgrade the console to use HawtIO 4

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 22/Apr/24 13:03
Start Date: 22/Apr/24 13:03
Worklog Time Spent: 10m 
  Work Description: andytaylor commented on code in PR #3:
URL: 
https://github.com/apache/activemq-artemis-console-plugin/pull/3#discussion_r1574724547


##
README.md:
##
@@ -1 +1,61 @@
-# activemq-artemis-console-plugin
+# Apache ActiveMQ Artemis Console Plugin
+
+
+The [Apache ActiveMQ Artemis](https://activemq.apache.org/components/artemis/) 
Console Plugin is written using [Hawtio v4](https://github.com/hawtio/hawtio).
+The plugin is written in TypeScript. Since a Hawtio plugin is based on React 
and [Webpack Module Federation](https://module-federation.github.io/),
+this project uses Yarn v3 and [CRACO](https://craco.js.org/) as the build 
tools.
+
+The WAR file created by this project is consumed by ActiveMQ Artemis but can 
be developed and run standalone.
+
+
+### Build
+
+The following command first builds the `activemq-artemis-console-plugin` 
frontend project and then compiles and packages 
+the main Java project together.
+
+```console
+mvn clean install
+```
+
+Building the frontend project 'artemis-console-extension' can take time, so if 
you build it once and make no changes on the project afterwards, you 
+can speed up the whole build by skipping the frontend part next time.
+
+```console
+mvn install -Dskip.yarn
+```
+
+### Test run
+
+You can quickly run and test the console by using `jetty-maven-plugin` 
configured in `pom.xml`. It launches an embedded 
+Jetty server and deploys the plugin WAR application. From the 
'artemis-console-war' directory run:
+
+```console
+mvn jetty:run -Dskip.yarn
+```
+
+You can access the Artemis console with the sample plugin at: 

+
+## Faster plugin development
+
+You could run `mvn install` or `mvn jetty:run` every time to incrementally 
develop the `activemq-artemis-console` 
+frontend project while checking its behaviour in the browser. But this is not 
suitable for running the fast development feedback cycle.

Review Comment:
   Ive fixed that as well





Issue Time Tracking
---

Worklog Id: (was: 915816)
Time Spent: 6h 40m  (was: 6.5h)

> Upgrade the console to use HawtIO 4
> ---
>
> Key: ARTEMIS-4680
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4680
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
>  Time Spent: 6h 40m
>  Remaining Estimate: 0h
>
> The current console is based upon HawtIO 1 which in turn is built on 
> Bootstrap. Bootstrap is old and no longer actively being maintained.
>  
> This improvement is to migrate the current console to use HawtIO 4 which i 
> based on Typescript, react and Patternfly.
>  
> A WIP can be found 
> [here|https://github.com/andytaylor/activemq-artemis/tree/artemis-console-ng]



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

[jira] [Updated] (ARTEMIS-4739) HANDLE LEAK in OpenWireMessageConverter.java

2024-04-22 Thread Galkin Alexey (Jira)



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

Galkin Alexey updated ARTEMIS-4739:
---
Description: 
The handle tis, which is an object of type InflaterInputStream([line 233 
|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]),
 is created in the code and used to read data from contents([line 
231|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]).
 However, if the messageCompressed condition is true, then an 
InflaterInputStream object will be created based on tis, and tis will be 
overwritten with a new InflaterInputStream object. The problem occurs on [line 
237|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]
 because only the DataInputStream tdataIn is closed, but tis is not closed 
explicitly. This may result in resource leakage and unavailability of resources 
associated with the InflaterInputStream.

Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author Alexey Galkin.

  was:The handle tis, which is an object of type InflaterInputStream([line 233 
| 
https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]),
 is created in the code and used to read data from contents([line 
231|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]).
 However, if the messageCompressed condition is true, then an 
InflaterInputStream object will be created based on tis, and tis will be 
overwritten with a new InflaterInputStream object. The problem occurs on [line 
237|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]
 because only the DataInputStream tdataIn is closed, but tis is not closed 
explicitly. This may result in resource leakage and unavailability of resources 
associated with the InflaterInputStream.


> HANDLE LEAK in OpenWireMessageConverter.java
> 
>
> Key: ARTEMIS-4739
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4739
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Priority: Major
>
> The handle tis, which is an object of type InflaterInputStream([line 233 
> |https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]),
>  is created in the code and used to read data from contents([line 
> 231|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]).
>  However, if the messageCompressed condition is true, then an 
> InflaterInputStream object will be created based on tis, and tis will be 
> overwritten with a new InflaterInputStream object. The problem occurs on 
> [line 
> 237|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]
>  because only the DataInputStream tdataIn is closed, but tis is not closed 
> explicitly. This may result in resource leakage and unavailability of 
> resources associated with the InflaterInputStream.
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.



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

[jira] [Created] (ARTEMIS-4739) HANDLE LEAK in OpenWireMessageConverter.java

2024-04-22 Thread Galkin Alexey (Jira)

Galkin Alexey created ARTEMIS-4739:
--

 Summary: HANDLE LEAK in OpenWireMessageConverter.java
 Key: ARTEMIS-4739
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4739
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Galkin Alexey


The handle tis, which is an object of type InflaterInputStream([line 233 | 
https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]),
 is created in the code and used to read data from contents([line 
231|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]).
 However, if the messageCompressed condition is true, then an 
InflaterInputStream object will be created based on tis, and tis will be 
overwritten with a new InflaterInputStream object. The problem occurs on [line 
237|https://github.com/apache/activemq-artemis/blob/main/artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/OpenWireMessageConverter.java]
 because only the DataInputStream tdataIn is closed, but tis is not closed 
explicitly. This may result in resource leakage and unavailability of resources 
associated with the InflaterInputStream.



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

[jira] [Created] (ARTEMIS-4738) OVERRIDING EQUALS NOT SYMMETRIC in ActiveMQQueue.java

2024-04-22 Thread Galkin Alexey (Jira)

Galkin Alexey created ARTEMIS-4738:
--

 Summary: OVERRIDING EQUALS NOT SYMMETRIC in ActiveMQQueue.java
 Key: ARTEMIS-4738
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4738
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Galkin Alexey


The equals method is overridden in the ActiveMQQueue class and this method uses 
the instanceof operator to check the type of the object. However, this does not 
take into account the symmetry of the equals method. The equals method must be 
symmetric, that is, if a.equals(b) returns true, then b.equals(a) must return 
true. 

In this case, if the object "o" is not an instance of the ActiveMQQueue class, 
the equals method immediately returns false([line 
83|https://github.com/apache/activemq-artemis/blob/main/artemis-jms-client/src/main/java/org/apache/activemq/artemis/jms/client/ActiveMQQueue.java]),
 without giving the opportunity to check, on the contrary, whether the current 
object is an instance of the object "o". Therefore, the equals method in this 
case does not satisfy the symmetry requirement and can lead to incorrect 
results when comparing objects.

 

Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author Alexey Galkin.



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

[jira] [Closed] (ARTEMIS-4737) DOESNT OVERRIDE EQUALS in ConnectionFactoryProperties.java

2024-04-22 Thread Robbie Gemmell (Jira)



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

Robbie Gemmell closed ARTEMIS-4737.
---
Resolution: Duplicate

> DOESNT OVERRIDE EQUALS in ConnectionFactoryProperties.java
> --
>
> Key: ARTEMIS-4737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4737
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Galkin Alexey
>Priority: Major
>
> The class overrides the equals method, but does not implement its logic.
> Instead, it compares objects by their classes using the getClass() method (
> if (getClass() != obj.getClass()) [line 
> 748|https://github.com/apache/activemq-artemis/blob/main/artemis-ra/src/main/java/org/apache/activemq/artemis/ra/ConnectionFactoryProperties.java]),
>  which can lead to incorrect object comparisons. For the equals method to 
> work correctly, you need to override its logic so that it compares objects by 
> their fields or other criteria, and not just by their classes.
>  
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author Alexey Galkin.



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

[jira] [Work logged] (ARTEMIS-4680) Upgrade the console to use HawtIO 4

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 22/Apr/24 11:15
Start Date: 22/Apr/24 11:15
Worklog Time Spent: 10m 
  Work Description: gemmellr commented on code in PR #3:
URL: 
https://github.com/apache/activemq-artemis-console-plugin/pull/3#discussion_r1574581049


##
README.md:
##
@@ -1 +1,61 @@
-# activemq-artemis-console-plugin
+# Apache ActiveMQ Artemis Console Plugin
+
+
+The [Apache ActiveMQ Artemis](https://activemq.apache.org/components/artemis/) 
Console Plugin is written using [Hawtio v4](https://github.com/hawtio/hawtio).
+The plugin is written in TypeScript. Since a Hawtio plugin is based on React 
and [Webpack Module Federation](https://module-federation.github.io/),
+this project uses Yarn v3 and [CRACO](https://craco.js.org/) as the build 
tools.
+
+The WAR file created by this project is consumed by ActiveMQ Artemis but can 
be developed and run standalone.
+
+
+### Build
+
+The following command first builds the `activemq-artemis-console-plugin` 
frontend project and then compiles and packages 
+the main Java project together.
+
+```console
+mvn clean install
+```
+
+Building the frontend project 'artemis-console-extension' can take time, so if 
you build it once and make no changes on the project afterwards, you 
+can speed up the whole build by skipping the frontend part next time.
+
+```console
+mvn install -Dskip.yarn
+```
+
+### Test run
+
+You can quickly run and test the console by using `jetty-maven-plugin` 
configured in `pom.xml`. It launches an embedded 
+Jetty server and deploys the plugin WAR application. From the 
'artemis-console-war' directory run:
+
+```console
+mvn jetty:run -Dskip.yarn
+```
+
+You can access the Artemis console with the sample plugin at: 

+
+## Faster plugin development
+
+You could run `mvn install` or `mvn jetty:run` every time to incrementally 
develop the `activemq-artemis-console` 
+frontend project while checking its behaviour in the browser. But this is not 
suitable for running the fast development feedback cycle.

Review Comment:
   and the other bit? `activemq-artemis-console frontend project` vs earlier 
`frontend project artemis-console-extension`





Issue Time Tracking
---

Worklog Id: (was: 915786)
Time Spent: 6.5h  (was: 6h 20m)

> Upgrade the console to use HawtIO 4
> ---
>
> Key: ARTEMIS-4680
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4680
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
>  Time Spent: 6.5h
>  Remaining Estimate: 0h
>
> The current console is based upon HawtIO 1 which in turn is built on 
> Bootstrap. Bootstrap is old and no longer actively being maintained.
>  
> This improvement is to migrate the current console to use HawtIO 4 which i 
> based on Typescript, react and Patternfly.
>  
> A WIP can be found 
> [here|https://github.com/andytaylor/activemq-artemis/tree/artemis-console-ng]



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

[jira] [Work logged] (ARTEMIS-4680) Upgrade the console to use HawtIO 4

2024-04-22 Thread ASF GitHub Bot (Jira)



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

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

Author: ASF GitHub Bot
Created on: 22/Apr/24 11:10
Start Date: 22/Apr/24 11:10
Worklog Time Spent: 10m 
  Work Description: andytaylor commented on code in PR #3:
URL: 
https://github.com/apache/activemq-artemis-console-plugin/pull/3#discussion_r1574575303


##
README.md:
##
@@ -1 +1,61 @@
-# activemq-artemis-console-plugin
+# Apache ActiveMQ Artemis Console Plugin
+
+
+The [Apache ActiveMQ Artemis](https://activemq.apache.org/components/artemis/) 
Console Plugin is written using [Hawtio v4](https://github.com/hawtio/hawtio).
+The plugin is written in TypeScript. Since a Hawtio plugin is based on React 
and [Webpack Module Federation](https://module-federation.github.io/),
+this project uses Yarn v3 and [CRACO](https://craco.js.org/) as the build 
tools.
+
+The WAR file created by this project is consumed by ActiveMQ Artemis but can 
be developed and run standalone.
+
+
+### Build
+
+The following command first builds the `activemq-artemis-console-plugin` 
frontend project and then compiles and packages 
+the main Java project together.
+
+```console
+mvn clean install
+```
+
+Building the frontend project 'artemis-console-extension' can take time, so if 
you build it once and make no changes on the project afterwards, you 
+can speed up the whole build by skipping the frontend part next time.
+
+```console
+mvn install -Dskip.yarn
+```
+
+### Test run
+
+You can quickly run and test the console by using `jetty-maven-plugin` 
configured in `pom.xml`. It launches an embedded 
+Jetty server and deploys the plugin WAR application. From the 
'artemis-console-war' directory run:
+
+```console
+mvn jetty:run -Dskip.yarn
+```
+
+You can access the Artemis console with the sample plugin at: 

+
+## Faster plugin development
+
+You could run `mvn install` or `mvn jetty:run` every time to incrementally 
develop the `activemq-artemis-console` 
+frontend project while checking its behaviour in the browser. But this is not 
suitable for running the fast development feedback cycle.

Review Comment:
   it is still correct





Issue Time Tracking
---

Worklog Id: (was: 915785)
Time Spent: 6h 20m  (was: 6h 10m)

> Upgrade the console to use HawtIO 4
> ---
>
> Key: ARTEMIS-4680
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4680
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
>  Time Spent: 6h 20m
>  Remaining Estimate: 0h
>
> The current console is based upon HawtIO 1 which in turn is built on 
> Bootstrap. Bootstrap is old and no longer actively being maintained.
>  
> This improvement is to migrate the current console to use HawtIO 4 which i 
> based on Typescript, react and Patternfly.
>  
> A WIP can be found 
> [here|https://github.com/andytaylor/activemq-artemis/tree/artemis-console-ng]



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

51 matches

Mail list logo