[jira] [Commented] (ARTEMIS-3585) Broken link in tests.md
[ https://issues.apache.org/jira/browse/ARTEMIS-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445551#comment-17445551 ] Nabwegamo Brendah commented on ARTEMIS-3585: Hello I have created a PR on this [https://github.com/apache/activemq-artemis/pull/3860] cc [@clebertsuconic|https://github.com/clebertsuconic] [@brusdev|https://github.com/brusdev] [@jbertram|https://github.com/jbertram] Thank you. > Broken link in tests.md > --- > > Key: ARTEMIS-3585 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3585 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Nabwegamo Brendah >Priority: Minor > Labels: easyfix > > In the [tests.md > |https://github.com/apache/activemq-artemis/blob/main/docs/hacking-guide/en/tests.md]file > under the Writing Web Tests section, the link to the ConsoleTest.java is > broken -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARTEMIS-3585) Broken link in tests.md
Nabwegamo Brendah created ARTEMIS-3585: -- Summary: Broken link in tests.md Key: ARTEMIS-3585 URL: https://issues.apache.org/jira/browse/ARTEMIS-3585 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Nabwegamo Brendah In the [tests.md |https://github.com/apache/activemq-artemis/blob/main/docs/hacking-guide/en/tests.md]file under the Writing Web Tests section, the link to the ConsoleTest.java is broken -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3546) ClassNotFoundException: javax.json.JsonValue when creating an ActiveMQConnectionFactory using artemis-jakarta-client-all
[
https://issues.apache.org/jira/browse/ARTEMIS-3546?focusedWorklogId=682977=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682977
]
ASF GitHub Bot logged work on ARTEMIS-3546:
---
Author: ASF GitHub Bot
Created on: 17/Nov/21 22:40
Start Date: 17/Nov/21 22:40
Worklog Time Spent: 10m
Work Description: clebertsuconic edited a comment on pull request #3846:
URL: https://github.com/apache/activemq-artemis/pull/3846#issuecomment-972177555
@jbonofre / @gtully the only thing missing here now is the feature failure.
At the moment the module is commented out on the main pom so just I could
run some tests.. but if you enable it, you will get failures:
```
[ERROR] Feature resolution failed for [artemis-openwire/2.20.0.SNAPSHOT]
[ERROR] Message: Unable to resolve root: missing requirement [root]
osgi.identity; osgi.identity=artemis-openwire; type=karaf.feature;
version=2.20.0.SNAPSHOT;
filter:="(&(osgi.identity=artemis-openwire)(type=karaf.feature)(version>=2.20.0.SNAPSHOT))"
[caused by: Unable to resolve artemis-openwire/2.20.0.SNAPSHOT: missing
requirement [artemis-openwire/2.20.0.SNAPSHOT] osgi.identity;
osgi.identity=org.apache.activemq.artemis-openwire-protocol; type=osgi.bundle;
version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]"; resolution:=mandatory [caused by:
Unable to resolve
org.apache.activemq.artemis-openwire-protocol/2.20.0.SNAPSHOT: missing
requirement [org.apache.activemq.artemis-openwire-protocol/2.20.0.SNAPSHOT]
osgi.wiring.package;
filter:="(osgi.wiring.package=org.apache.activemq.artemis.api.core.client)"
[caused by: Unable to resolve
org.apache.activemq.artemis-server-osgi/2.20.0.SNAPSHOT: missing requirement
[org.apache.activemq.artemis-server-osgi/2.20.0.SNAPSHOT] osgi.wiring.package;
filter:="(osgi.wiring.package=org.glassfish.json)"]]]
[ERROR] Repositories: {
[ERROR]
file:/Users/clebertsuconic/work/apache/activemq-artemis/artemis-features/target/classes/features.xml
[ERROR] mvn:org.apache.aries.jpa/jpa-features/2.7.3/xml/features
[ERROR] mvn:org.apache.karaf.features/enterprise/4.3.3/xml/features
```
I don't have a pointer to even where to start looking and how to debug this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 682977)
Time Spent: 4.5h (was: 4h 20m)
> ClassNotFoundException: javax.json.JsonValue when creating an
> ActiveMQConnectionFactory using artemis-jakarta-client-all
>
>
> Key: ARTEMIS-3546
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3546
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.19.0
>Reporter: Andy Wilkinson
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> As expected, {{artemis-jakarta-client-all}} contains the various
> {{jakarta.json.\*}} classes from Jakarta EE 9. However, its bytecode still
> references the {{javax.json.\*}} classes from EE 8. This results in a failure
> at runtime when creating an {{ActiveMQConnectionFactory}}:
> {noformat}
> Exception in thread "main" java.lang.IllegalStateException:
> java.lang.NoClassDefFoundError: javax/json/JsonValue
> at
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.(ActiveMQConnectionFactory.java:225)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.(ActiveMQConnectionFactory.java:218)
> at example.Main.main(Main.java:8)
> Caused by: java.lang.NoClassDefFoundError: javax/json/JsonValue
> at
> org.apache.activemq.artemis.uri.schema.connector.TCPTransportConfigurationSchema.getTransportConfigurations(TCPTransportConfigurationSchema.java:68)
> at
> org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:42)
> at
> org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:33)
> at
> org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:86)
> at
> org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:30)
> at
> org.apache.activemq.artemis.utils.uri.URIFactory.newObject(URIFactory.java:59)
> at
>
[jira] [Work logged] (ARTEMIS-3546) ClassNotFoundException: javax.json.JsonValue when creating an ActiveMQConnectionFactory using artemis-jakarta-client-all
[
https://issues.apache.org/jira/browse/ARTEMIS-3546?focusedWorklogId=682975=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682975
]
ASF GitHub Bot logged work on ARTEMIS-3546:
---
Author: ASF GitHub Bot
Created on: 17/Nov/21 22:39
Start Date: 17/Nov/21 22:39
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on pull request #3846:
URL: https://github.com/apache/activemq-artemis/pull/3846#issuecomment-972177555
@jbonofre / @gtully the only thing missing here now is the feature failure.
At the moment the module is commented out on the main pom so just I could
run some tests.. but if you enable it, you will get failures:
```
[ERROR] Feature resolution failed for [artemis-openwire/2.20.0.SNAPSHOT]
[ERROR] Message: Unable to resolve root: missing requirement [root]
osgi.identity; osgi.identity=artemis-openwire; type=karaf.feature;
version=2.20.0.SNAPSHOT;
filter:="(&(osgi.identity=artemis-openwire)(type=karaf.feature)(version>=2.20.0.SNAPSHOT))"
[caused by: Unable to resolve artemis-openwire/2.20.0.SNAPSHOT: missing
requirement [artemis-openwire/2.20.0.SNAPSHOT] osgi.identity;
osgi.identity=org.apache.activemq.artemis-openwire-protocol; type=osgi.bundle;
version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]"; resolution:=mandatory [caused by:
Unable to resolve
org.apache.activemq.artemis-openwire-protocol/2.20.0.SNAPSHOT: missing
requirement [org.apache.activemq.artemis-openwire-protocol/2.20.0.SNAPSHOT]
osgi.wiring.package;
filter:="(osgi.wiring.package=org.apache.activemq.artemis.api.core.client)"
[caused by: Unable to resolve
org.apache.activemq.artemis-server-osgi/2.20.0.SNAPSHOT: missing requirement
[org.apache.activemq.artemis-server-osgi/2.20.0.SNAPSHOT] osgi.wiring.package;
filter:="(osgi.wiring.package=org.glassfish.json)"]]]
[ERROR] Repositories: {
[ERROR]
file:/Users/clebertsuconic/work/apache/activemq-artemis/artemis-features/target/classes/features.xml
[ERROR] mvn:org.apache.aries.jpa/jpa-features/2.7.3/xml/features
[ERROR] mvn:org.apache.karaf.features/enterprise/4.3.3/xml/features
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 682975)
Time Spent: 4h 20m (was: 4h 10m)
> ClassNotFoundException: javax.json.JsonValue when creating an
> ActiveMQConnectionFactory using artemis-jakarta-client-all
>
>
> Key: ARTEMIS-3546
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3546
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: JMS
>Affects Versions: 2.19.0
>Reporter: Andy Wilkinson
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> As expected, {{artemis-jakarta-client-all}} contains the various
> {{jakarta.json.\*}} classes from Jakarta EE 9. However, its bytecode still
> references the {{javax.json.\*}} classes from EE 8. This results in a failure
> at runtime when creating an {{ActiveMQConnectionFactory}}:
> {noformat}
> Exception in thread "main" java.lang.IllegalStateException:
> java.lang.NoClassDefFoundError: javax/json/JsonValue
> at
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.(ActiveMQConnectionFactory.java:225)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.(ActiveMQConnectionFactory.java:218)
> at example.Main.main(Main.java:8)
> Caused by: java.lang.NoClassDefFoundError: javax/json/JsonValue
> at
> org.apache.activemq.artemis.uri.schema.connector.TCPTransportConfigurationSchema.getTransportConfigurations(TCPTransportConfigurationSchema.java:68)
> at
> org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:42)
> at
> org.apache.activemq.artemis.uri.schema.serverLocator.TCPServerLocatorSchema.internalNewObject(TCPServerLocatorSchema.java:33)
> at
> org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:86)
> at
> org.apache.activemq.artemis.utils.uri.URISchema.newObject(URISchema.java:30)
> at
> org.apache.activemq.artemis.utils.uri.URIFactory.newObject(URIFactory.java:59)
> at
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.newLocator(ServerLocatorImpl.java:333)
> at
>
[jira] [Updated] (ARTEMIS-3584) show multiple representations of the payload on "Browse Queue"
[ https://issues.apache.org/jira/browse/ARTEMIS-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-3584: --- Description: A message payload can be viewed in a few different ways: text, hexadecimal bytes and decimal bytes, or a combination of these. However, when a message payload follows the internal structure of its protocol, it is indistinguishable whether the text that is shown is the actual payload for a text message, or the representation for a structured message. I'm proposing a new visualisation, in which multiple (relevant) representations of the message payload are shown in a tabbed area. Basically the tabs are added to the message description and message payload fields that already exist. Selecting a tab will just replace the content of these 2 fields. The following tabs are proposed: * Text * Hex * Decimal * AMQP * Large * Compressed The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only active when the message has an actual text payload, otherwise it is inactive. The Hex and Decimal tabs are always active, except for large messages. The last 3 tabs (AMQP/Large/Compressed) are only visible when the message-payload is of that type. The AMQP tab shows the simple AMQP data structure in a JSON-like notation, and the Large and Compressed tabs just inform the user that the message is large or compressed. Using 3 separate tabs for this quickly informs the user that the text that is shown is a representation and not the actual text. All relevant representations are generated on the server-side, including the hex and decimal representations that previously were constructed on the gui-side. The construction of representations that are similar between the message protocols is now shared code. this applies to text/hex/binary. The preferences option "Browse Bytes Messages" is now removed. Instead, the system will remember the last representation that was used. otherwise the first active representation is selected. A first look: !screenshot-1.png! TODO: * replace the button-row with a tab-bar; with the current selection highlighted * remember previous selection(s) in LRU order * fix all texts * test, test, test * cleanup, cleanup, cleanup It may take a while before the matching PR is ready... was: A message payload can be viewed in a few different ways: text, hexadecimal bytes and decimal bytes, or a combination of these. However, when a message payload follows the internal structure of its protocol, it is indistinguishable whether the text that is shown is the actual payload for a text message, or the representation for a structured message. I'm proposing a new visualisation, in which multiple (relevant) representations of the message payload are shown in a tabbed area. Basically the tabs are added to the message description and message payload fields that already exist. Selecting a tab will just replace the content of these 2 fields. The following tabs are proposed: * Text * Hex * Decimal * AMQP * Large * Compressed The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only active when the message has an actual text payload, otherwise it is inactive. The Hex and Decimal tabs are always active, except for large messages. The last 3 tabs (AMQP/Large/Compressed) are only visible when the message-payload is of that type. The AMQP tab shows the simple AMQP data structure in a JSON-like notation, and the Large and Compressed tabs just inform the user that the message is large or compressed. Using 3 separate tabs for this quickly informs the user that the text that is shown is a representation and not the actual text. All relevant representations are generated on the server-side, including the hex and decimal representations that previously were constructed on the gui-side. The construction of representations that are similar between the message protocols is now shared code. this applies to text/hex/binary. The preferences option "Browse Bytes Messages" is now removed. Instead, the system will remember the last representation that was used. otherwise the first active representation is selected. A first look: !screenshot-1.png! TODO: * replace the button-row with a tab-bar; with the current selection highlighted * fix all texts * test, test, test * cleanup, cleanup, cleanup It may take a while before the matching PR is ready... > show multiple representations of the payload on "Browse Queue" > -- > > Key: ARTEMIS-3584 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3584 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Erwin Dondorp >Priority: Minor > Attachments: screenshot-1.png > >
[jira] [Work logged] (ARTEMIS-3584) show multiple representations of the payload on "Browse Queue"
[ https://issues.apache.org/jira/browse/ARTEMIS-3584?focusedWorklogId=682896=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682896 ] ASF GitHub Bot logged work on ARTEMIS-3584: --- Author: ASF GitHub Bot Created on: 17/Nov/21 20:16 Start Date: 17/Nov/21 20:16 Worklog Time Spent: 10m Work Description: erwindon opened a new pull request #3859: URL: https://github.com/apache/activemq-artemis/pull/3859 see https://issues.apache.org/jira/browse/ARTEMIS-3584 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 682896) Remaining Estimate: 0h Time Spent: 10m > show multiple representations of the payload on "Browse Queue" > -- > > Key: ARTEMIS-3584 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3584 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Erwin Dondorp >Priority: Minor > Attachments: screenshot-1.png > > Time Spent: 10m > Remaining Estimate: 0h > > A message payload can be viewed in a few different ways: text, hexadecimal > bytes and decimal bytes, or a combination of these. However, when a message > payload follows the internal structure of its protocol, it is > indistinguishable whether the text that is shown is the actual payload for a > text message, or the representation for a structured message. > I'm proposing a new visualisation, in which multiple (relevant) > representations of the message payload are shown in a tabbed area. Basically > the tabs are added to the message description and message payload fields that > already exist. Selecting a tab will just replace the content of these 2 > fields. > The following tabs are proposed: > * Text > * Hex > * Decimal > * AMQP > * Large > * Compressed > The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only > active when the message has an actual text payload, otherwise it is inactive. > The Hex and Decimal tabs are always active, except for large messages. The > last 3 tabs (AMQP/Large/Compressed) are only visible when the message-payload > is of that type. The AMQP tab shows the simple AMQP data structure in a > JSON-like notation, and the Large and Compressed tabs just inform the user > that the message is large or compressed. Using 3 separate tabs for this > quickly informs the user that the text that is shown is a representation and > not the actual text. > All relevant representations are generated on the server-side, including the > hex and decimal representations that previously were constructed on the > gui-side. > The construction of representations that are similar between the message > protocols is now shared code. this applies to text/hex/binary. > The preferences option "Browse Bytes Messages" is now removed. Instead, the > system will remember the last representation that was used. otherwise the > first active representation is selected. > A first look: > !screenshot-1.png! > TODO: > * replace the button-row with a tab-bar; with the current selection > highlighted > * fix all texts > * test, test, test > * cleanup, cleanup, cleanup > It may take a while before the matching PR is ready... -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3584) show multiple representations of the payload on "Browse Queue"
[ https://issues.apache.org/jira/browse/ARTEMIS-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-3584: --- Description: A message payload can be viewed in a few different ways: text, hexadecimal bytes and decimal bytes, or a combination of these. However, when a message payload follows the internal structure of its protocol, it is indistinguishable whether the text that is shown is the actual payload for a text message, or the representation for a structured message. I'm proposing a new visualisation, in which multiple (relevant) representations of the message payload are shown in a tabbed area. Basically the tabs are added to the message description and message payload fields that already exist. Selecting a tab will just replace the content of these 2 fields. The following tabs are proposed: * Text * Hex * Decimal * AMQP * Large * Compressed The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only active when the message has an actual text payload, otherwise it is inactive. The Hex and Decimal tabs are always active, except for large messages. The last 3 tabs (AMQP/Large/Compressed) are only visible when the message-payload is of that type. The AMQP tab shows the simple AMQP data structure in a JSON-like notation, and the Large and Compressed tabs just inform the user that the message is large or compressed. Using 3 separate tabs for this quickly informs the user that the text that is shown is a representation and not the actual text. All relevant representations are generated on the server-side, including the hex and decimal representations that previously were constructed on the gui-side. The construction of representations that are similar between the message protocols is now shared code. this applies to text/hex/binary. The preferences option "Browse Bytes Messages" is now removed. Instead, the system will remember the last representation that was used. otherwise the first active representation is selected. A first look: !screenshot-1.png! TODO: * replace the button-row with a tab-bar; with the current selection highlighted * fix all texts * test, test, test * cleanup, cleanup, cleanup It may take a while before the matching PR is ready... was: A message payload can be viewed in a few different ways: text, hexadecimal bytes and decimal bytes, or a combination of these. However, when a message payload follows the internal structure of its protocol, it is indistinguishable whether the text that is shown is the actual payload for a text message, or the representation for a structured message. I'm proposing a new visualisation, in which multiple (relevant) representations of the message payload are shown in a tabbed area. Basically the tabs are added to the message description and message payload fields that already exist. Selecting a tab will just replace the content of these 2 fields. The following tabs are proposed: * Text * Hex * Decimal * AMQP * Large * Compressed * The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only active when the message has an actual text payload, otherwise it is inactive. The Hex and Decimal tabs are always active, except for large messages. The last 3 tabs (AMQP/Large/Compressed) are only visible when the message-payload is of that type. The AMQP tab shows the simple AMQP data structure in a JSON-like notation, and the Large and Compressed tabs just inform the user that the message is large or compressed. Using 3 separate tabs for this quickly informs the user that the text that is shown is a representation and not the actual text. All relevant representations are generated on the server-side, including the hex and decimal representations that previously were constructed on the gui-side. The construction of representations that are similar between the message protocols is now shared code. this applies to text/hex/binary. The preferences option "Browse Bytes Messages" is now removed. Instead, the system will remember the last representation that was used. otherwise the first active representation is selected. A first look: !screenshot-1.png! > show multiple representations of the payload on "Browse Queue" > -- > > Key: ARTEMIS-3584 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3584 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Erwin Dondorp >Priority: Minor > Attachments: screenshot-1.png > > > A message payload can be viewed in a few different ways: text, hexadecimal > bytes and decimal bytes, or a combination of these. However, when a message > payload follows the internal structure of its protocol, it is > indistinguishable whether the text
[jira] [Updated] (ARTEMIS-3584) show multiple representations of the payload on "Browse Queue"
[ https://issues.apache.org/jira/browse/ARTEMIS-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-3584: --- Description: A message payload can be viewed in a few different ways: text, hexadecimal bytes and decimal bytes, or a combination of these. However, when a message payload follows the internal structure of its protocol, it is indistinguishable whether the text that is shown is the actual payload for a text message, or the representation for a structured message. I'm proposing a new visualisation, in which multiple (relevant) representations of the message payload are shown in a tabbed area. Basically the tabs are added to the message description and message payload fields that already exist. Selecting a tab will just replace the content of these 2 fields. The following tabs are proposed: * Text * Hex * Decimal * AMQP * Large * Compressed * The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only active when the message has an actual text payload, otherwise it is inactive. The Hex and Decimal tabs are always active, except for large messages. The last 3 tabs (AMQP/Large/Compressed) are only visible when the message-payload is of that type. The AMQP tab shows the simple AMQP data structure in a JSON-like notation, and the Large and Compressed tabs just inform the user that the message is large or compressed. Using 3 separate tabs for this quickly informs the user that the text that is shown is a representation and not the actual text. All relevant representations are generated on the server-side, including the hex and decimal representations that previously were constructed on the gui-side. The construction of representations that are similar between the message protocols is now shared code. this applies to text/hex/binary. The preferences option "Browse Bytes Messages" is now removed. Instead, the system will remember the last representation that was used. otherwise the first active representation is selected. A first look: !screenshot-1.png! was: A message payload can be viewed in a few different ways: text, hexadecimal bytes and decimal bytes, or a combination of these. However, when a message payload follows the internal structure of its protocol, it is indistinguishable whether the text that is shown is the actual payload for a text message, or the representation for a structured message. I'm proposing a new visualisation, in which multiple (relevant) representations of the message payload are shown in a tabbed area. Basically the tabs are added to the message description and message payload fields that already exist. Selecting a tab will just replace the content of these 2 fields. The following tabs are proposed: * Text * Hex * Decimal * AMQP * Large * Compressed The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only active when the message has an actual text payload, otherwise it is inactive. The Hex and Decimal tabs are always active, except for large messages. The last 3 tabs (AMQP/Large/Compressed) are only visible when the message-payload is of that type. The AMQP tab shows the simple AMQP data structure in a JSON-like notation, and the Large and Compressed tabs just inform the user that the message is large or compressed. Using 3 separate tabs for this quickly informs the user that the text that is shown is a representation and not the actual text. All relevant representations are generated on the server-side, including the hex and decimal representations that previously were constructed on the gui-side. The construction of representations that are similar between the message protocols is now shared code. this applies to text/hex/binary. The preferences option "Browse Bytes Messages" is now removed. Instead, the system will remember the last representation that was used. otherwise the first active representation is selected. > show multiple representations of the payload on "Browse Queue" > -- > > Key: ARTEMIS-3584 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3584 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Erwin Dondorp >Priority: Minor > Attachments: screenshot-1.png > > > A message payload can be viewed in a few different ways: text, hexadecimal > bytes and decimal bytes, or a combination of these. However, when a message > payload follows the internal structure of its protocol, it is > indistinguishable whether the text that is shown is the actual payload for a > text message, or the representation for a structured message. > I'm proposing a new visualisation, in which multiple (relevant) > representations of the message payload are shown in a tabbed area.
[jira] [Updated] (ARTEMIS-3584) show multiple representations of the payload on "Browse Queue"
[ https://issues.apache.org/jira/browse/ARTEMIS-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erwin Dondorp updated ARTEMIS-3584: --- Attachment: screenshot-1.png > show multiple representations of the payload on "Browse Queue" > -- > > Key: ARTEMIS-3584 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3584 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Erwin Dondorp >Priority: Minor > Attachments: screenshot-1.png > > > A message payload can be viewed in a few different ways: text, hexadecimal > bytes and decimal bytes, or a combination of these. However, when a message > payload follows the internal structure of its protocol, it is > indistinguishable whether the text that is shown is the actual payload for a > text message, or the representation for a structured message. > I'm proposing a new visualisation, in which multiple (relevant) > representations of the message payload are shown in a tabbed area. Basically > the tabs are added to the message description and message payload fields that > already exist. Selecting a tab will just replace the content of these 2 > fields. > The following tabs are proposed: > * Text > * Hex > * Decimal > * AMQP > * Large > * Compressed > The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only > active when the message has an actual text payload, otherwise it is inactive. > The Hex and Decimal tabs are always active, except for large messages. The > last 3 tabs (AMQP/Large/Compressed) are only visible when the message-payload > is of that type. The AMQP tab shows the simple AMQP data structure in a > JSON-like notation, and the Large and Compressed tabs just inform the user > that the message is large or compressed. Using 3 separate tabs for this > quickly informs the user that the text that is shown is a representation and > not the actual text. > All relevant representations are generated on the server-side, including the > hex and decimal representations that previously were constructed on the > gui-side. > The construction of representations that are similar between the message > protocols is now shared code. this applies to text/hex/binary. > The preferences option "Browse Bytes Messages" is now removed. Instead, the > system will remember the last representation that was used. otherwise the > first active representation is selected. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARTEMIS-3584) show multiple representations of the payload on "Browse Queue"
Erwin Dondorp created ARTEMIS-3584: -- Summary: show multiple representations of the payload on "Browse Queue" Key: ARTEMIS-3584 URL: https://issues.apache.org/jira/browse/ARTEMIS-3584 Project: ActiveMQ Artemis Issue Type: Improvement Components: Web Console Affects Versions: 2.19.0 Reporter: Erwin Dondorp A message payload can be viewed in a few different ways: text, hexadecimal bytes and decimal bytes, or a combination of these. However, when a message payload follows the internal structure of its protocol, it is indistinguishable whether the text that is shown is the actual payload for a text message, or the representation for a structured message. I'm proposing a new visualisation, in which multiple (relevant) representations of the message payload are shown in a tabbed area. Basically the tabs are added to the message description and message payload fields that already exist. Selecting a tab will just replace the content of these 2 fields. The following tabs are proposed: * Text * Hex * Decimal * AMQP * Large * Compressed The first 3 (Text/Hex/Decimal) are always visible. The "Text" tab is only active when the message has an actual text payload, otherwise it is inactive. The Hex and Decimal tabs are always active, except for large messages. The last 3 tabs (AMQP/Large/Compressed) are only visible when the message-payload is of that type. The AMQP tab shows the simple AMQP data structure in a JSON-like notation, and the Large and Compressed tabs just inform the user that the message is large or compressed. Using 3 separate tabs for this quickly informs the user that the text that is shown is a representation and not the actual text. All relevant representations are generated on the server-side, including the hex and decimal representations that previously were constructed on the gui-side. The construction of representations that are similar between the message protocols is now shared code. this applies to text/hex/binary. The preferences option "Browse Bytes Messages" is now removed. Instead, the system will remember the last representation that was used. otherwise the first active representation is selected. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3557) ARTEMIS-1925 fix does not handle redistribution to "old" consumers
[ https://issues.apache.org/jira/browse/ARTEMIS-3557?focusedWorklogId=682853=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682853 ] ASF GitHub Bot logged work on ARTEMIS-3557: --- Author: ASF GitHub Bot Created on: 17/Nov/21 18:39 Start Date: 17/Nov/21 18:39 Worklog Time Spent: 10m Work Description: AntonRoskvist opened a new pull request #3858: URL: https://github.com/apache/activemq-artemis/pull/3858 …ast consumers -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 682853) Time Spent: 40m (was: 0.5h) > ARTEMIS-1925 fix does not handle redistribution to "old" consumers > -- > > Key: ARTEMIS-3557 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3557 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > OFF_WITH_REDISTRIBUTION does not handle this scenario: > If a destination and consumer exist on one node in a cluster and a producer > shows up on another node messages will not get redistributed until the old > consumer disconnects and reconnects. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3557) ARTEMIS-1925 fix does not handle redistribution to "old" consumers
[ https://issues.apache.org/jira/browse/ARTEMIS-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Roskvist updated ARTEMIS-3557: Description: OFF_WITH_REDISTRIBUTION does not handle this scenario: If a destination and consumer exist on one node in a cluster and a producer shows up on another node messages will not get redistributed until the old consumer disconnects and reconnects. was: OFF_WITH_REDISTRIBUTION does not handle two scenarios: 1. non durable Multicast where the subscriber is on a separate node from the publisher. Messages gets dropped. 2. If a destination and consumer exist on one node in a cluster and a producer shows up on another node messages will not get redistributed until the old consumer disconnects and reconnects. > ARTEMIS-1925 fix does not handle redistribution to "old" consumers > -- > > Key: ARTEMIS-3557 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3557 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > OFF_WITH_REDISTRIBUTION does not handle this scenario: > If a destination and consumer exist on one node in a cluster and a producer > shows up on another node messages will not get redistributed until the old > consumer disconnects and reconnects. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3557) ARTEMIS-1925 fix does not handle redistribution to "old" consumers
[ https://issues.apache.org/jira/browse/ARTEMIS-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Roskvist updated ARTEMIS-3557: Summary: ARTEMIS-1925 fix does not handle redistribution to "old" consumers (was: ARTEMIS-1925 fix does not handle Multicast in cluster and redistribution to "old" consumers) > ARTEMIS-1925 fix does not handle redistribution to "old" consumers > -- > > Key: ARTEMIS-3557 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3557 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > OFF_WITH_REDISTRIBUTION does not handle two scenarios: > 1. non durable Multicast where the subscriber is on a separate node from the > publisher. Messages gets dropped. > 2. If a destination and consumer exist on one node in a cluster and a > producer shows up on another node messages will not get redistributed until > the old consumer disconnects and reconnects. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-2563) Create redistributor for remote broker even if local binding is missing
[ https://issues.apache.org/jira/browse/ARTEMIS-2563?focusedWorklogId=682850=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682850 ] ASF GitHub Bot logged work on ARTEMIS-2563: --- Author: ASF GitHub Bot Created on: 17/Nov/21 18:37 Start Date: 17/Nov/21 18:37 Worklog Time Spent: 10m Work Description: AntonRoskvist closed pull request #2978: URL: https://github.com/apache/activemq-artemis/pull/2978 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 682850) Time Spent: 1h 50m (was: 1h 40m) > Create redistributor for remote broker even if local binding is missing > --- > > Key: ARTEMIS-2563 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2563 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.10.1 >Reporter: Anton Roskvist >Priority: Minor > Time Spent: 1h 50m > Remaining Estimate: 0h > > I have a use case in which I rely on message redistribution on some low > volume queues. The setup is like this: > There is a cluster of all active Artemis brokers, where low volume clients > connect to one broker on random to read or publish messages. > > The issue I am having is when a consumer connects first, followed by a > producer connecting to another broker. In this scenario redistribution is not > triggered because the broker with the connected producer did not have a local > binding to the address the consumer created on the remote broker. > If I disconnect and reconnect the consumer, the redistributor gets > established and messages gets forwarded between the brokers. This workaround > is not great in my case, as the clients are managed by other teams and are > created sort of ad-hoc. > > I would like some option to create redistributors or addresses based on > activity on a remote, clustered broker. I have seen that a notification is > received on all cluster members when a consumer creates an address on just > one broker, but I guess that currently these notifications are discarded if > the broker does not have a local binding for that address. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3557) ARTEMIS-1925 fix does not handle Multicast in cluster and redistribution to "old" consumers
[ https://issues.apache.org/jira/browse/ARTEMIS-3557?focusedWorklogId=682849=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682849 ] ASF GitHub Bot logged work on ARTEMIS-3557: --- Author: ASF GitHub Bot Created on: 17/Nov/21 18:37 Start Date: 17/Nov/21 18:37 Worklog Time Spent: 10m Work Description: AntonRoskvist closed pull request #3842: URL: https://github.com/apache/activemq-artemis/pull/3842 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 682849) Time Spent: 0.5h (was: 20m) > ARTEMIS-1925 fix does not handle Multicast in cluster and redistribution to > "old" consumers > --- > > Key: ARTEMIS-3557 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3557 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > OFF_WITH_REDISTRIBUTION does not handle two scenarios: > 1. non durable Multicast where the subscriber is on a separate node from the > publisher. Messages gets dropped. > 2. If a destination and consumer exist on one node in a cluster and a > producer shows up on another node messages will not get redistributed until > the old consumer disconnects and reconnects. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445426#comment-17445426
]
Anders Wallgren commented on ARTEMIS-3583:
--
(y)
> Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause
> spurious AMQ224013 warnings to be emitted.
> -
>
> Key: ARTEMIS-3583
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3583
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.18.0
> Environment: Large-core machines running embedded ActiveMQ broker.
>Reporter: Anders Wallgren
>Priority: Major
>
> A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
> appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
> that can cause the Runnable "done" parameter to never be invoked. This
> manifests itself as spurious "AMQ224013: failed to expire messages for queue"
> messages.
> The problem is this section of code and the non-atomic test-and-set on the
> expiryScanner.scannerRunning AtomicInteger:
> {code:java}
> if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
> if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "and-set"
> expiryScanner.doneCallback = done;
> }
> getExecutor().execute(expiryScanner);
> } else {
> // expire is already happening on this queue, move on!
> if (done != null) {
> done.run();
> }
> {code}
> Consider the following sequence of events and see if you agree with my
> analysis:
> # Two threads, t1 and t2
> # t1 runs PostOfficeImpl.ExpiryReaper which calls
> QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration
> is "done". It waits 10 seconds for the latch to drop. If the latch doesn't
> drop within the timeout it issues a AMQ224013 warning.
> # t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which
> in turn calls QueueImpl.expireReferences(null)
> # t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they
> both enter that branch. <--- This is where things start to go wrong, as only
> one of the two threads will successfully set expiryScanner.done; if the
> thread that "loses" is the one that supplies a non-null "done" parameter then
> that Runnable will never be invoked.
> # t2 successfully increments expiryScanner.scannerRunning to 1 and sets
> expiryScanner.doneCallback = null (since it passed null as the "done"
> parameter) and then continues to run expiryScanner.
> # t1 doesn't increment expiryScanner.scannerRunning and at this point the
> "done" argument is lost and will never be invoked, guaranteeing the AMQ224013
> warning. t1 then also runs the expiryScanner (which has already been
> submitted once by t2)
> Because of the non-atomic test-and-set, the callback is not guaranteed to be
> invoked and, also, more than one expiry run will execute simultaneously (this
> seems to be undesirable based on why this change was made in the first place).
> Should the code not be something like this (I'm not 100% familiar with the
> semantics of scannerRunning being > 1, so this may not be the correct
> solution):
>
> {code:java}
> if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) {
> <--- test-and-set
> expiryScanner.doneCallback = done;
> getExecutor().execute(expiryScanner);
> } else {
> // expire is already happening on this queue, move on!
> if (done != null) {
> done.run();
> }
> {code}
>
> This guarantees that only one thread can enter the section that sets
> expiryScanner.doneCallback and submits expiryScanner for execution; all other
> threads will immediately have their Runnable invoked.
> We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
> testing on very large instances (64 CPUs and up) that are very busy.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445425#comment-17445425
]
Clebert Suconic commented on ARTEMIS-3583:
--
your fix is good, but I don't think the warnings will happen because of this
issue.
As far as I know the scheduler always happen from the same thread?
I will bring your change on this.. and I will investigate what else is going on.
> Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause
> spurious AMQ224013 warnings to be emitted.
> -
>
> Key: ARTEMIS-3583
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3583
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.18.0
> Environment: Large-core machines running embedded ActiveMQ broker.
>Reporter: Anders Wallgren
>Priority: Major
>
> A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
> appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
> that can cause the Runnable "done" parameter to never be invoked. This
> manifests itself as spurious "AMQ224013: failed to expire messages for queue"
> messages.
> The problem is this section of code and the non-atomic test-and-set on the
> expiryScanner.scannerRunning AtomicInteger:
> {code:java}
> if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
> if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "and-set"
> expiryScanner.doneCallback = done;
> }
> getExecutor().execute(expiryScanner);
> } else {
> // expire is already happening on this queue, move on!
> if (done != null) {
> done.run();
> }
> {code}
> Consider the following sequence of events and see if you agree with my
> analysis:
> # Two threads, t1 and t2
> # t1 runs PostOfficeImpl.ExpiryReaper which calls
> QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration
> is "done". It waits 10 seconds for the latch to drop. If the latch doesn't
> drop within the timeout it issues a AMQ224013 warning.
> # t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which
> in turn calls QueueImpl.expireReferences(null)
> # t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they
> both enter that branch. <--- This is where things start to go wrong, as only
> one of the two threads will successfully set expiryScanner.done; if the
> thread that "loses" is the one that supplies a non-null "done" parameter then
> that Runnable will never be invoked.
> # t2 successfully increments expiryScanner.scannerRunning to 1 and sets
> expiryScanner.doneCallback = null (since it passed null as the "done"
> parameter) and then continues to run expiryScanner.
> # t1 doesn't increment expiryScanner.scannerRunning and at this point the
> "done" argument is lost and will never be invoked, guaranteeing the AMQ224013
> warning. t1 then also runs the expiryScanner (which has already been
> submitted once by t2)
> Because of the non-atomic test-and-set, the callback is not guaranteed to be
> invoked and, also, more than one expiry run will execute simultaneously (this
> seems to be undesirable based on why this change was made in the first place).
> Should the code not be something like this (I'm not 100% familiar with the
> semantics of scannerRunning being > 1, so this may not be the correct
> solution):
>
> {code:java}
> if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) {
> <--- test-and-set
> expiryScanner.doneCallback = done;
> getExecutor().execute(expiryScanner);
> } else {
> // expire is already happening on this queue, move on!
> if (done != null) {
> done.run();
> }
> {code}
>
> This guarantees that only one thread can enter the section that sets
> expiryScanner.doneCallback and submits expiryScanner for execution; all other
> threads will immediately have their Runnable invoked.
> We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
> testing on very large instances (64 CPUs and up) that are very busy.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3581) Allow setMaxSizeBytes(0) to indicate an address that will always page
[
https://issues.apache.org/jira/browse/ARTEMIS-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-3581:
Description:
Currently for force paging on an address, for a DLQ for example, you would set
{{max-size-bytes}} to some small number, e.g.:
{code:xml}
PAGE
1{code}
However, the broker will complain with:
{noformat}
2021-11-15 16:21:51,606 ERROR [org.apache.activemq.artemis.core.server]
AMQ224000: Failure in initialisation: java.lang.IllegalStateException:
java.lang.IllegalStateException: pageSize for address DLQ.mytest >= maxSize.
Normally pageSize should be significantly smaller than maxSize, ms: 1 ps
1024{noformat}
You could go ahead and downsize the {{page-size-bytes}} as well, but you don't
want to cripple de-page or page-in and use a reasonable value and some memory!
{code:xml}
PAGE
256
128{code}
It _should_ be sufficient to just set:
{code:xml}
PAGE
0{code}
was:
Currently for force paging on an address, for a DLQ for example, you would set
PAGE
1
MaxSizeBytes to some small number but the broker will complain with:
2021-11-15 16:21:51,606 ERROR [org.apache.activemq.artemis.core.server]
AMQ224000: Failure in initialisation: java.lang.IllegalStateException:
java.lang.IllegalStateException: pageSize for address DLQ.mytest >= maxSize.
Normally pageSize should be significantly smaller than maxSize, ms: 1 ps 1024
You go ahead and downsize the page-size-bytes but don't want to cripple de-page
or page-in and use a reasonable value and some memory!
PAGE
256
128
It should be sufficient to set:
PAGE
0
> Allow setMaxSizeBytes(0) to indicate an address that will always page
> -
>
> Key: ARTEMIS-3581
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3581
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration
>Affects Versions: 2.19.0
>Reporter: Gary Tully
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently for force paging on an address, for a DLQ for example, you would
> set {{max-size-bytes}} to some small number, e.g.:
> {code:xml}
>PAGE
>1{code}
> However, the broker will complain with:
> {noformat}
> 2021-11-15 16:21:51,606 ERROR [org.apache.activemq.artemis.core.server]
> AMQ224000: Failure in initialisation: java.lang.IllegalStateException:
> java.lang.IllegalStateException: pageSize for address DLQ.mytest >= maxSize.
> Normally pageSize should be significantly smaller than maxSize, ms: 1 ps
> 1024{noformat}
> You could go ahead and downsize the {{page-size-bytes}} as well, but you
> don't want to cripple de-page or page-in and use a reasonable value and some
> memory!
> {code:xml}
>PAGE
>256
>128{code}
> It _should_ be sufficient to just set:
> {code:xml}
>PAGE
>0{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3581) Allow setMaxSizeBytes(0) to indicate an address that will always page
[ https://issues.apache.org/jira/browse/ARTEMIS-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-3581: Summary: Allow setMaxSizeBytes(0) to indicate an address that will always page (was: Aallow setMaxSizeBytes(0) to indicate an address that will always page) > Allow setMaxSizeBytes(0) to indicate an address that will always page > - > > Key: ARTEMIS-3581 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3581 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration >Affects Versions: 2.19.0 >Reporter: Gary Tully >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently for force paging on an address, for a DLQ for example, you would set > PAGE > 1 > MaxSizeBytes to some small number but the broker will complain with: > 2021-11-15 16:21:51,606 ERROR [org.apache.activemq.artemis.core.server] > AMQ224000: Failure in initialisation: java.lang.IllegalStateException: > java.lang.IllegalStateException: pageSize for address DLQ.mytest >= maxSize. > Normally pageSize should be significantly smaller than maxSize, ms: 1 ps 1024 > You go ahead and downsize the page-size-bytes but don't want to cripple > de-page or page-in and use a reasonable value and some memory! > PAGE > 256 > 128 > It should be sufficient to set: >PAGE >0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3522) Implement performance tools to evaluate throughput and Response Under Load performance of Artemis
[ https://issues.apache.org/jira/browse/ARTEMIS-3522?focusedWorklogId=682798=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682798 ] ASF GitHub Bot logged work on ARTEMIS-3522: --- Author: ASF GitHub Bot Created on: 17/Nov/21 17:23 Start Date: 17/Nov/21 17:23 Worklog Time Spent: 10m Work Description: gtully commented on pull request #3857: URL: https://github.com/apache/activemq-artemis/pull/3857#issuecomment-971793729 I think just with a little user guide this has great value already. nice. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 682798) Time Spent: 0.5h (was: 20m) > Implement performance tools to evaluate throughput and Response Under Load > performance of Artemis > - > > Key: ARTEMIS-3522 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3522 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker, JMS >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > There are many performance benchmarks around eg [SoftwareMill > MqPerf|https://softwaremill.com/mqperf/] that could be used to test > performance of Artemis in specific scenario, but none is both simple and easy > to be composed with ad-hoc env setup scripts to perform a wide range of > different performance tests against the broker. > This JIRA aim to provide CLI commands that could be used as building blocks > to perform: > * all-out throughput tests > * responsiveness under load tests (with no [coordinated > omission|http://highscalability.com/blog/2015/10/5/your-load-generator-is-probably-lying-to-you-take-the-red-pi.html]) > ie fixed throughput (per producer) load > * scalability tests > The effort of this JIRA should produce CLI commands similar to [Apache Pulsar > Perf|https://pulsar.apache.org/docs/en/performance-pulsar-perf/] that could > be composed to create complete performance benchmark pipelines (eg using > [qDup|https://github.com/Hyperfoil/qDup] and > [Horreum|https://github.com/Hyperfoil/Horreum] on a CI/CD) or used as-it-is > by users to quickly check performance of the broker. > Requirements: > * support AMQP and Core protocol > * cross JVMs with microseconds time measurement granularity > * support parsable output format > * suitable to perform scale tests > The last requirement can be achieved both by using MessageListeners and async > producers available on [JMS > 2|https://javaee.github.io/jms-spec/pages/JMS20FinalRelease] although both > [qpid JMS|https://github.com/apache/qpid-jms] and Artemis Core protocols > blocks the producer caller thread ie the former on > [jmsConnection::send|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsConnection.java#L773], > awaiting Netty threads to unblock it on > [AmqpFixedProducer::doSend|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpFixedProducer.java#L169], > while the latter on > [ClientProducerImpl::sendRegularMessage|https://github.com/apache/activemq-artemis/blob/e364961c8f035613f3ce4e3bdb3430a17efb0ffd/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientProducerImpl.java#L284-L294]. > This seems odd because [JMS 2's > CompletionListener|https://docs.oracle.com/javaee/7/api/javax/jms/CompletionListener.html] > should save any previous send operation to ever block and the user should > take care (despite being tedious and error-prone) to track the amount of > in-flight messages and limit it accordly (ie [Reactive Messaging's > Emitter|https://smallrye.io/smallrye-reactive-messaging/smallrye-reactive-messaging/2/emitter/emitter.html#emitter-overflow] > abstract it with its overflow policies to save blocking the caller thread). > If JMS 2 both impl cannot be turned into non-blocking then there're just 2 > options: > # using the blocking variant: it means that scalability tests requires using > machines with high core numbers > # using [Reactive > Messaging|https://github.com/eclipse/microprofile-reactive-messaging], but > losing the ability to use local transactions (and maybe other JMS features) > With the first option the number of producers threads can easily be much
[jira] [Work logged] (ARTEMIS-3581) Aallow setMaxSizeBytes(0) to indicate an address that will always page
[ https://issues.apache.org/jira/browse/ARTEMIS-3581?focusedWorklogId=682792=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682792 ] ASF GitHub Bot logged work on ARTEMIS-3581: --- Author: ASF GitHub Bot Created on: 17/Nov/21 17:20 Start Date: 17/Nov/21 17:20 Worklog Time Spent: 10m Work Description: gtully commented on pull request #3856: URL: https://github.com/apache/activemq-artemis/pull/3856#issuecomment-971791969 full test looks good, nothing seems to mind that that illegal state relating to page-size < max-size-bytes has gone! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 682792) Time Spent: 20m (was: 10m) > Aallow setMaxSizeBytes(0) to indicate an address that will always page > -- > > Key: ARTEMIS-3581 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3581 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker, Configuration >Affects Versions: 2.19.0 >Reporter: Gary Tully >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently for force paging on an address, for a DLQ for example, you would set > PAGE > 1 > MaxSizeBytes to some small number but the broker will complain with: > 2021-11-15 16:21:51,606 ERROR [org.apache.activemq.artemis.core.server] > AMQ224000: Failure in initialisation: java.lang.IllegalStateException: > java.lang.IllegalStateException: pageSize for address DLQ.mytest >= maxSize. > Normally pageSize should be significantly smaller than maxSize, ms: 1 ps 1024 > You go ahead and downsize the page-size-bytes but don't want to cripple > de-page or page-in and use a reasonable value and some memory! > PAGE > 256 > 128 > It should be sufficient to set: >PAGE >0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable "done" parameter to never be invoked. This
manifests itself as spurious "AMQ224013: failed to expire messages for queue"
messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "and-set"
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch. <--- This is where things start to go wrong, as only one of
the two threads will successfully set expiryScanner.done; if the thread that
"loses" is the one that supplies a non-null "done" parameter then that Runnable
will never be invoked.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this (I'm not 100% familiar with the
semantics of scannerRunning being > 1, so this may not be the correct solution):
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) { <---
test-and-set
expiryScanner.doneCallback = done;
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable "done" parameter to never be invoked. This
manifests itself as spurious "AMQ224013: failed to expire messages for queue"
messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "and-set"
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment
[jira] [Commented] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445373#comment-17445373
]
Anders Wallgren commented on ARTEMIS-3583:
--
[~clebert.suco...@jboss.com] can you confirm my analysis above, or am I missing
something here?
> Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause
> spurious AMQ224013 warnings to be emitted.
> -
>
> Key: ARTEMIS-3583
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3583
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.18.0
> Environment: Large-core machines running embedded ActiveMQ broker.
>Reporter: Anders Wallgren
>Priority: Major
>
> A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
> appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
> that can cause the Runnable "done" parameter to never be invoked. This
> manifests itself as spurious "AMQ224013: failed to expire messages for queue"
> messages.
> The problem is this section of code and the non-atomic test-and-set on the
> expiryScanner.scannerRunning AtomicInteger:
> {code:java}
> if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
> if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "and-set"
> expiryScanner.doneCallback = done;
> }
> getExecutor().execute(expiryScanner);
> } else {
> // expire is already happening on this queue, move on!
> if (done != null) {
> done.run();
> }
> {code}
> Consider the following sequence of events and see if you agree with my
> analysis:
> # Two threads, t1 and t2
> # t1 runs PostOfficeImpl.ExpiryReaper which calls
> QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration
> is "done". It waits 10 seconds for the latch to drop. If the latch doesn't
> drop within the timeout it issues a AMQ224013 warning.
> # t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which
> in turn calls QueueImpl.expireReferences(null)
> # t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they
> both enter that branch.
> # t2 successfully increments expiryScanner.scannerRunning to 1 and sets
> expiryScanner.doneCallback = null (since it passed null as the "done"
> parameter) and then continues to run expiryScanner.
> # t1 doesn't increment expiryScanner.scannerRunning and at this point the
> "done" argument is lost and will never be invoked, guaranteeing the AMQ224013
> warning. t1 then also runs the expiryScanner (which has already been
> submitted once by t2)
> Because of the non-atomic test-and-set, the callback is not guaranteed to be
> invoked and, also, more than one expiry run will execute simultaneously (this
> seems to be undesirable based on why this change was made in the first place).
> Should the code not be something like this (I'm not 100% familiar with the
> semantics of scannerRunning being > 1, so this may not be the correct
> solution):
>
> {code:java}
> if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) {
> <--- test-and-set
> expiryScanner.doneCallback = done;
> getExecutor().execute(expiryScanner);
> } else {
> // expire is already happening on this queue, move on!
> if (done != null) {
> done.run();
> }
> {code}
>
> This guarantees that only one thread can enter the section that sets
> expiryScanner.doneCallback and submits expiryScanner for execution; all other
> threads will immediately have their Runnable invoked.
> We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
> testing on very large instances (64 CPUs and up) that are very busy.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3569) Broker balancer based on authenticated user role assignment
[
https://issues.apache.org/jira/browse/ARTEMIS-3569?focusedWorklogId=682773=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682773
]
ASF GitHub Bot logged work on ARTEMIS-3569:
---
Author: ASF GitHub Bot
Created on: 17/Nov/21 17:02
Start Date: 17/Nov/21 17:02
Worklog Time Spent: 10m
Work Description: gtully commented on pull request #3849:
URL: https://github.com/apache/activemq-artemis/pull/3849#issuecomment-971775838
@brusdev thanks for your feedback. I have removed the duplication of
validateUser and removed RejectedResult in favour of a result with a status
enum. It does look better. Thanks again.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 682773)
Time Spent: 1h 20m (was: 1h 10m)
> Broker balancer based on authenticated user role assignment
> ---
>
> Key: ARTEMIS-3569
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3569
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: balancer
>Affects Versions: 2.19.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> following up on ARTEMIS-3365 for the local target path.
> add support for ROLE_NAME as a targetKey.
> Matching one of the Roles of an authenticated principal associated with a
> connection, accept or reject the connection based on some partition policy
> based on the role.
> Using the existing regular expression based filter, it is possible to ensure
> a sub set of roles are associated with a given broker.
> The symmeteric-simple-example that uses the client id key type can be
> extended to support partitioning on role assignment, the configuration, to
> use role names that begin with "PARTITION_" and match "PARTITION_FOO" to
> this broker, would be of the form:
> {code:java}
>
> ROLE_NAME
> ^PARTITION_*
> ^PARTITION_FOO.*
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable "done" parameter to never be invoked. This
manifests itself as spurious "AMQ224013: failed to expire messages for queue"
messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "and-set"
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this (I'm not 100% familiar with the
semantics of scannerRunning being > 1, so this may not be the correct solution):
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) { <---
test-and-set
expiryScanner.doneCallback = done;
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable "done" parameter to never be invoked. This
manifests itself as spurious "AMQ224013: failed to expire messages for queue"
messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "test-and-set"
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable "done" parameter to never be invoked. This
manifests itself as spurious "AMQ224013: failed to expire messages for queue"
messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "test-and-set"
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this (I'm not 100% familiar with the
semantics of scannerRunning being > 1, so this may not be the correct solution):
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) { <---
test-and-set
expiryScanner.doneCallback = done;
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable "done" parameter to never be invoked. This
manifests itself as spurious "AMQ224013: failed to expire messages for queue"
messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "test-and-set"
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable "done" parameter to never be invoked. This
manifests itself as spurious "AMQ224013: failed to expire messages for queue"
messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "test-and-set"
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) { <---
test-and-set
expiryScanner.doneCallback = done;
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable "done" parameter to never be invoked. This
manifests itself as spurious "AMQ224013: failed to expire messages for queue"
messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "and set"
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable "done" parameter to never be invoked. This
manifests itself as spurious "AMQ224013: failed to expire messages for queue"
messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "and set"
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) { <---
test-and-set
expiryScanner.doneCallback = done;
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "and set"
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {
if (expiryScanner.scannerRunning.incrementAndGet() == 1) {
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) {
expiryScanner.doneCallback = done;
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {
if (expiryScanner.scannerRunning.incrementAndGet() == 1) {
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this:
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test"
if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "and set"
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) { <---
test-and-set
expiryScanner.doneCallback = done;
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{code:java}
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {
if (expiryScanner.scannerRunning.incrementAndGet() == 1) {
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
{code}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {
if (expiryScanner.scannerRunning.incrementAndGet() == 1) {
expiryScanner.doneCallback = done;
}
getExecutor().execute(expiryScanner);
} else {
// expire is already happening on this queue, move on!
if (done != null) {
done.run();
}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this:
{{if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) {}}
{{ expiryScanner.doneCallback = done;}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{{}}}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{{if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {}}
{{ if (expiryScanner.scannerRunning.incrementAndGet() == 1) {}}
{{ expiryScanner.doneCallback = done;}}
{{ }}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{{}}}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{{if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {}}
{{ if (expiryScanner.scannerRunning.incrementAndGet() == 1) {}}
{{ expiryScanner.doneCallback = done;}}
{{ }}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{{}}}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this:
{{if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) {}}
{{ expiryScanner.doneCallback = done;}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{{}}}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{{if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {}}
{{ if (expiryScanner.scannerRunning.incrementAndGet() == 1) {}}
{{ expiryScanner.doneCallback = done;}}
{{ }}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{{}}}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{{if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {}}
{{ if (expiryScanner.scannerRunning.incrementAndGet() == 1) {}}
{{ expiryScanner.doneCallback = done;}}
{\\{ }}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{{} done.run();{}}}{\{ }
}}
{{}}}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this:
{{if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) {}}
{{ expiryScanner.doneCallback = done;}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{{}}}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{{if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {}}
{{ if (expiryScanner.scannerRunning.incrementAndGet() == 1) {}}
{{ expiryScanner.doneCallback = done;}}
{\{ }}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{\{ }}}
{{}}}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{{if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {}}
{{ if (expiryScanner.scannerRunning.incrementAndGet() == 1) {}}
{{ expiryScanner.doneCallback = done;}}
{{ }}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{{}}}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this:
{{if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) {}}
{{ expiryScanner.doneCallback = done;}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{{}}}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{{if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {}}
{{ if (expiryScanner.scannerRunning.incrementAndGet() == 1) {}}
{{ expiryScanner.doneCallback = done;}}
{\\{ }}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{{} done.run();{}}}{\{ }
}}
{{}}}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based
[jira] [Updated] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[
https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Wallgren updated ARTEMIS-3583:
-
Description:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked. This manifests itself as
spurious "AMQ224013: failed to expire messages for queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{{if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {}}
{{ if (expiryScanner.scannerRunning.incrementAndGet() == 1) {}}
{{ expiryScanner.doneCallback = done;}}
{\{ }}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{\{ }}}
{{}}}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this:
{{if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) {}}
{{ expiryScanner.doneCallback = done;}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{\{ }}}
{{}}}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
was:
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked..
This manifests itself as spurious "AMQ224013: failed to expire messages for
queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{{if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {}}
{{ if (expiryScanner.scannerRunning.incrementAndGet() == 1) {}}
{{ expiryScanner.doneCallback = done;}}
{{ }}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{{ }}}
{{}}}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be
[jira] [Created] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
Anders Wallgren created ARTEMIS-3583:
Summary: Race condition in
QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013
warnings to be emitted.
Key: ARTEMIS-3583
URL: https://issues.apache.org/jira/browse/ARTEMIS-3583
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.18.0
Environment: Large-core machines running embedded ActiveMQ broker.
Reporter: Anders Wallgren
A recent change - [https://github.com/apache/activemq-artemis/pull/3654] -
appears to introduce a race condition in QueueImpl#expireReferences(Runnable)
that can cause the Runnable to never be invoked..
This manifests itself as spurious "AMQ224013: failed to expire messages for
queue" messages.
The problem is this section of code and the non-atomic test-and-set on the
expiryScanner.scannerRunning AtomicInteger:
{{if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) {}}
{{ if (expiryScanner.scannerRunning.incrementAndGet() == 1) {}}
{{ expiryScanner.doneCallback = done;}}
{{ }}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{{ }}}
{{}}}
Consider the following sequence of events and see if you agree with my analysis:
# Two threads, t1 and t2
# t1 runs PostOfficeImpl.ExpiryReaper which calls
QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration is
"done". It waits 10 seconds for the latch to drop. If the latch doesn't drop
within the timeout it issues a AMQ224013 warning.
# t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which in
turn calls QueueImpl.expireReferences(null)
# t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they both
enter that branch.
# t2 successfully increments expiryScanner.scannerRunning to 1 and sets
expiryScanner.doneCallback = null (since it passed null as the "done"
parameter) and then continues to run expiryScanner.
# t1 doesn't increment expiryScanner.scannerRunning and at this point the
"done" argument is lost and will never be invoked, guaranteeing the AMQ224013
warning. t1 then also runs the expiryScanner (which has already been submitted
once by t2)
Because of the non-atomic test-and-set, the callback is not guaranteed to be
invoked and, also, more than one expiry run will execute simultaneously (this
seems to be undesirable based on why this change was made in the first place).
Should the code not be something like this:
{{if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0, 1)) {}}
{{ expiryScanner.doneCallback = done;}}
{{ getExecutor().execute(expiryScanner);}}
{{} else {}}
{{ // expire is already happening on this queue, move on!}}
{{ if (done != null) {}}
{{ done.run();}}
{{ }}}
{{}}}
This guarantees that only one thread can enter the section that sets
expiryScanner.doneCallback and submits expiryScanner for execution; all other
threads will immediately have their Runnable invoked.
We have seen these AMQ224013 warnings while trying to upgrade to 2.18.0 while
testing on very large instances (64 CPUs and up) that are very busy.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (AMQ-8413) Support different username and password for remote broker
Matt Pavlovich created AMQ-8413: --- Summary: Support different username and password for remote broker Key: AMQ-8413 URL: https://issues.apache.org/jira/browse/AMQ-8413 Project: ActiveMQ Issue Type: New Feature Reporter: Matt Pavlovich Currently, the same username and password is used for network connectors. Proposal: - add remoteUserName - add remotePassword if(remoteUserName != null) .. use remote username and password when creating the bridge, otherwise fallback to existing behavior -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work started] (ARTEMIS-3522) Implement performance tools to evaluate throughput and Response Under Load performance of Artemis
[ https://issues.apache.org/jira/browse/ARTEMIS-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTEMIS-3522 started by Francesco Nigro. > Implement performance tools to evaluate throughput and Response Under Load > performance of Artemis > - > > Key: ARTEMIS-3522 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3522 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker, JMS >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > There are many performance benchmarks around eg [SoftwareMill > MqPerf|https://softwaremill.com/mqperf/] that could be used to test > performance of Artemis in specific scenario, but none is both simple and easy > to be composed with ad-hoc env setup scripts to perform a wide range of > different performance tests against the broker. > This JIRA aim to provide CLI commands that could be used as building blocks > to perform: > * all-out throughput tests > * responsiveness under load tests (with no [coordinated > omission|http://highscalability.com/blog/2015/10/5/your-load-generator-is-probably-lying-to-you-take-the-red-pi.html]) > ie fixed throughput (per producer) load > * scalability tests > The effort of this JIRA should produce CLI commands similar to [Apache Pulsar > Perf|https://pulsar.apache.org/docs/en/performance-pulsar-perf/] that could > be composed to create complete performance benchmark pipelines (eg using > [qDup|https://github.com/Hyperfoil/qDup] and > [Horreum|https://github.com/Hyperfoil/Horreum] on a CI/CD) or used as-it-is > by users to quickly check performance of the broker. > Requirements: > * support AMQP and Core protocol > * cross JVMs with microseconds time measurement granularity > * support parsable output format > * suitable to perform scale tests > The last requirement can be achieved both by using MessageListeners and async > producers available on [JMS > 2|https://javaee.github.io/jms-spec/pages/JMS20FinalRelease] although both > [qpid JMS|https://github.com/apache/qpid-jms] and Artemis Core protocols > blocks the producer caller thread ie the former on > [jmsConnection::send|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsConnection.java#L773], > awaiting Netty threads to unblock it on > [AmqpFixedProducer::doSend|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpFixedProducer.java#L169], > while the latter on > [ClientProducerImpl::sendRegularMessage|https://github.com/apache/activemq-artemis/blob/e364961c8f035613f3ce4e3bdb3430a17efb0ffd/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientProducerImpl.java#L284-L294]. > This seems odd because [JMS 2's > CompletionListener|https://docs.oracle.com/javaee/7/api/javax/jms/CompletionListener.html] > should save any previous send operation to ever block and the user should > take care (despite being tedious and error-prone) to track the amount of > in-flight messages and limit it accordly (ie [Reactive Messaging's > Emitter|https://smallrye.io/smallrye-reactive-messaging/smallrye-reactive-messaging/2/emitter/emitter.html#emitter-overflow] > abstract it with its overflow policies to save blocking the caller thread). > If JMS 2 both impl cannot be turned into non-blocking then there're just 2 > options: > # using the blocking variant: it means that scalability tests requires using > machines with high core numbers > # using [Reactive > Messaging|https://github.com/eclipse/microprofile-reactive-messaging], but > losing the ability to use local transactions (and maybe other JMS features) > With the first option the number of producers threads can easily be much more > then the available cores, causing the load generator to benchmark OS (or the > runtime) ability to context switch threads instead of the broker. That's why > a non-blocking approach should be preferred. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3522) Implement performance tools to evaluate throughput and Response Under Load performance of Artemis
[ https://issues.apache.org/jira/browse/ARTEMIS-3522?focusedWorklogId=682684=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682684 ] ASF GitHub Bot logged work on ARTEMIS-3522: --- Author: ASF GitHub Bot Created on: 17/Nov/21 15:17 Start Date: 17/Nov/21 15:17 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3857: URL: https://github.com/apache/activemq-artemis/pull/3857#issuecomment-971680458 I still need to clean-up code, improve reporting, add histogram depedencies, expose wall-clock SPI providers (to support microseconds latencies across processes/machines, using JNI/JNA) + add a user guide It's already possible to play with it (by manually adding hdr histogram dep) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 682684) Time Spent: 20m (was: 10m) > Implement performance tools to evaluate throughput and Response Under Load > performance of Artemis > - > > Key: ARTEMIS-3522 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3522 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker, JMS >Reporter: nigrofranz >Assignee: nigrofranz >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > There are many performance benchmarks around eg [SoftwareMill > MqPerf|https://softwaremill.com/mqperf/] that could be used to test > performance of Artemis in specific scenario, but none is both simple and easy > to be composed with ad-hoc env setup scripts to perform a wide range of > different performance tests against the broker. > This JIRA aim to provide CLI commands that could be used as building blocks > to perform: > * all-out throughput tests > * responsiveness under load tests (with no [coordinated > omission|http://highscalability.com/blog/2015/10/5/your-load-generator-is-probably-lying-to-you-take-the-red-pi.html]) > ie fixed throughput (per producer) load > * scalability tests > The effort of this JIRA should produce CLI commands similar to [Apache Pulsar > Perf|https://pulsar.apache.org/docs/en/performance-pulsar-perf/] that could > be composed to create complete performance benchmark pipelines (eg using > [qDup|https://github.com/Hyperfoil/qDup] and > [Horreum|https://github.com/Hyperfoil/Horreum] on a CI/CD) or used as-it-is > by users to quickly check performance of the broker. > Requirements: > * support AMQP and Core protocol > * cross JVMs with microseconds time measurement granularity > * support parsable output format > * suitable to perform scale tests > The last requirement can be achieved both by using MessageListeners and async > producers available on [JMS > 2|https://javaee.github.io/jms-spec/pages/JMS20FinalRelease] although both > [qpid JMS|https://github.com/apache/qpid-jms] and Artemis Core protocols > blocks the producer caller thread ie the former on > [jmsConnection::send|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsConnection.java#L773], > awaiting Netty threads to unblock it on > [AmqpFixedProducer::doSend|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpFixedProducer.java#L169], > while the latter on > [ClientProducerImpl::sendRegularMessage|https://github.com/apache/activemq-artemis/blob/e364961c8f035613f3ce4e3bdb3430a17efb0ffd/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientProducerImpl.java#L284-L294]. > This seems odd because [JMS 2's > CompletionListener|https://docs.oracle.com/javaee/7/api/javax/jms/CompletionListener.html] > should save any previous send operation to ever block and the user should > take care (despite being tedious and error-prone) to track the amount of > in-flight messages and limit it accordly (ie [Reactive Messaging's > Emitter|https://smallrye.io/smallrye-reactive-messaging/smallrye-reactive-messaging/2/emitter/emitter.html#emitter-overflow] > abstract it with its overflow policies to save blocking the caller thread). > If JMS 2 both impl cannot be turned into non-blocking then there're just 2 > options: > # using the blocking variant: it means that scalability tests requires using > machines with high core numbers > # using [Reactive >
[jira] [Work logged] (ARTEMIS-3522) Implement performance tools to evaluate throughput and Response Under Load performance of Artemis
[ https://issues.apache.org/jira/browse/ARTEMIS-3522?focusedWorklogId=682677=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682677 ] ASF GitHub Bot logged work on ARTEMIS-3522: --- Author: ASF GitHub Bot Created on: 17/Nov/21 15:14 Start Date: 17/Nov/21 15:14 Worklog Time Spent: 10m Work Description: franz1981 opened a new pull request #3857: URL: https://github.com/apache/activemq-artemis/pull/3857 https://issues.apache.org/jira/browse/ARTEMIS-3522 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 682677) Remaining Estimate: 0h Time Spent: 10m > Implement performance tools to evaluate throughput and Response Under Load > performance of Artemis > - > > Key: ARTEMIS-3522 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3522 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker, JMS >Reporter: nigrofranz >Assignee: nigrofranz >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There are many performance benchmarks around eg [SoftwareMill > MqPerf|https://softwaremill.com/mqperf/] that could be used to test > performance of Artemis in specific scenario, but none is both simple and easy > to be composed with ad-hoc env setup scripts to perform a wide range of > different performance tests against the broker. > This JIRA aim to provide CLI commands that could be used as building blocks > to perform: > * all-out throughput tests > * responsiveness under load tests (with no [coordinated > omission|http://highscalability.com/blog/2015/10/5/your-load-generator-is-probably-lying-to-you-take-the-red-pi.html]) > ie fixed throughput (per producer) load > * scalability tests > The effort of this JIRA should produce CLI commands similar to [Apache Pulsar > Perf|https://pulsar.apache.org/docs/en/performance-pulsar-perf/] that could > be composed to create complete performance benchmark pipelines (eg using > [qDup|https://github.com/Hyperfoil/qDup] and > [Horreum|https://github.com/Hyperfoil/Horreum] on a CI/CD) or used as-it-is > by users to quickly check performance of the broker. > Requirements: > * support AMQP and Core protocol > * cross JVMs with microseconds time measurement granularity > * support parsable output format > * suitable to perform scale tests > The last requirement can be achieved both by using MessageListeners and async > producers available on [JMS > 2|https://javaee.github.io/jms-spec/pages/JMS20FinalRelease] although both > [qpid JMS|https://github.com/apache/qpid-jms] and Artemis Core protocols > blocks the producer caller thread ie the former on > [jmsConnection::send|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsConnection.java#L773], > awaiting Netty threads to unblock it on > [AmqpFixedProducer::doSend|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpFixedProducer.java#L169], > while the latter on > [ClientProducerImpl::sendRegularMessage|https://github.com/apache/activemq-artemis/blob/e364961c8f035613f3ce4e3bdb3430a17efb0ffd/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientProducerImpl.java#L284-L294]. > This seems odd because [JMS 2's > CompletionListener|https://docs.oracle.com/javaee/7/api/javax/jms/CompletionListener.html] > should save any previous send operation to ever block and the user should > take care (despite being tedious and error-prone) to track the amount of > in-flight messages and limit it accordly (ie [Reactive Messaging's > Emitter|https://smallrye.io/smallrye-reactive-messaging/smallrye-reactive-messaging/2/emitter/emitter.html#emitter-overflow] > abstract it with its overflow policies to save blocking the caller thread). > If JMS 2 both impl cannot be turned into non-blocking then there're just 2 > options: > # using the blocking variant: it means that scalability tests requires using > machines with high core numbers > # using [Reactive > Messaging|https://github.com/eclipse/microprofile-reactive-messaging], but > losing the ability to use local transactions (and maybe other JMS features) > With the first option the number of producers threads can easily be much more > then the
[jira] [Commented] (ARTEMIS-3574) Allow multiple bindings for embedded webserver
[ https://issues.apache.org/jira/browse/ARTEMIS-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445278#comment-17445278 ] Marlon Müller commented on ARTEMIS-3574: [~brusdev] Thanks for the clarification. I didn't thought about those scenarios as our artemis instances are only reachable within a private network. But I agree with you that there are use cases in which a reverse proxy is clearly the better choice. Maybe it would be a good idea to state the intended use case of the embedded webserver more clearly in the documentation. At the moment it says: "However, it can also host other web applications like the REST interface or even Spring-based web applications (e.g. using Camel).". This could lead to the assumption to also run non-broker related applications on this server. > Allow multiple bindings for embedded webserver > -- > > Key: ARTEMIS-3574 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3574 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Marlon Müller >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > At the moment it is only possible to configure one binding for the embedded > jetty webserver to listen on. It would be great to have the possibility to > configure multiple bindings for different war-files in order to serve those > files on different ports and allow the usage of http and https at the same > time. > My current problem is the usage of the prometheus metrics plugin. In our > setup it is not possible to call the "/metrics" endpoint with SSL enabled. > Therefore I would like to define a second binding without SSL enabled for > this plugin. Disabling SSL completely is not an option as other endpoints > like the jolokia-api and the web-console require some user authentication > which should be protected. > The idea is to move all binding related configuration parameters of the > "web" element and the configured "apps" in "bootstrap.xml" to a new element > called "binding" and put a list of those "binding" elements inside the "web" > element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3574) Allow multiple bindings for embedded webserver
[ https://issues.apache.org/jira/browse/ARTEMIS-3574?focusedWorklogId=682662=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682662 ] ASF GitHub Bot logged work on ARTEMIS-3574: --- Author: ASF GitHub Bot Created on: 17/Nov/21 14:41 Start Date: 17/Nov/21 14:41 Worklog Time Spent: 10m Work Description: MM53 commented on pull request #3853: URL: https://github.com/apache/activemq-artemis/pull/3853#issuecomment-971645721 I updated my changes to work properly with the old style configuration and added some tests to verify both formats. I also resolved the checkstyle violations. Hope everything is fine now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 682662) Time Spent: 1h (was: 50m) > Allow multiple bindings for embedded webserver > -- > > Key: ARTEMIS-3574 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3574 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Marlon Müller >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > At the moment it is only possible to configure one binding for the embedded > jetty webserver to listen on. It would be great to have the possibility to > configure multiple bindings for different war-files in order to serve those > files on different ports and allow the usage of http and https at the same > time. > My current problem is the usage of the prometheus metrics plugin. In our > setup it is not possible to call the "/metrics" endpoint with SSL enabled. > Therefore I would like to define a second binding without SSL enabled for > this plugin. Disabling SSL completely is not an option as other endpoints > like the jolokia-api and the web-console require some user authentication > which should be protected. > The idea is to move all binding related configuration parameters of the > "web" element and the configured "apps" in "bootstrap.xml" to a new element > called "binding" and put a list of those "binding" elements inside the "web" > element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3569) Broker balancer based on authenticated user role assignment
[
https://issues.apache.org/jira/browse/ARTEMIS-3569?focusedWorklogId=682603=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682603
]
ASF GitHub Bot logged work on ARTEMIS-3569:
---
Author: ASF GitHub Bot
Created on: 17/Nov/21 13:18
Start Date: 17/Nov/21 13:18
Worklog Time Spent: 10m
Work Description: gtully commented on a change in pull request #3849:
URL: https://github.com/apache/activemq-artemis/pull/3849#discussion_r751231705
##
File path: pom.xml
##
@@ -206,7 +206,7 @@
-Dorg.apache.commons.logging.Log=org.apache.activemq.artemis.logs.JBossLoggingApacheLoggerBridge
-Dorg.apache.activemq.artemis.utils.RetryRule.retry=${retryTests}
-Dbrokerconfig.maxDiskUsage=100
-Dorg.apache.activemq.artemis.core.remoting.impl.netty.TransportConstants.DEFAULT_QUIET_PERIOD=0
-Dorg.apache.activemq.artemis.core.remoting.impl.netty.TransportConstants.DEFAULT_SHUTDOWN_TIMEOUT=0
-Djava.util.logging.manager=org.jboss.logmanager.LogManager
-Dlogging.configuration="file:${activemq.basedir}/tests/config/${logging.config}"
-
-Djava.library.path="${activemq.basedir}/target/bin/lib/linux-x86_64:${activemq.basedir}/target/bin/lib/linux-i686"
-Djgroups.bind_addr=localhost
-Dorg.apache.activemq.artemis.api.core.UDPBroadcastEndpointFactory.localBindAddress=localhost
+
-Djava.library.path="${activemq.basedir}/target/bin/lib/linux-x86_64:${activemq.basedir}/target/bin/lib/linux-i686"
-Djgroups.bind_addr=localhost
-Dorg.apache.activemq.artemis.api.core.UDPBroadcastEndpointFactory.localBindAddress=0.0.0.0
Review comment:
Something has changed since a rebase, possibly jgroups. I now need to
unset that system property to have the clustered/discovery tests run!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 682603)
Time Spent: 1h 10m (was: 1h)
> Broker balancer based on authenticated user role assignment
> ---
>
> Key: ARTEMIS-3569
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3569
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: balancer
>Affects Versions: 2.19.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> following up on ARTEMIS-3365 for the local target path.
> add support for ROLE_NAME as a targetKey.
> Matching one of the Roles of an authenticated principal associated with a
> connection, accept or reject the connection based on some partition policy
> based on the role.
> Using the existing regular expression based filter, it is possible to ensure
> a sub set of roles are associated with a given broker.
> The symmeteric-simple-example that uses the client id key type can be
> extended to support partitioning on role assignment, the configuration, to
> use role names that begin with "PARTITION_" and match "PARTITION_FOO" to
> this broker, would be of the form:
> {code:java}
>
> ROLE_NAME
> ^PARTITION_*
> ^PARTITION_FOO.*
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3569) Broker balancer based on authenticated user role assignment
[
https://issues.apache.org/jira/browse/ARTEMIS-3569?focusedWorklogId=682601=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682601
]
ASF GitHub Bot logged work on ARTEMIS-3569:
---
Author: ASF GitHub Bot
Created on: 17/Nov/21 13:17
Start Date: 17/Nov/21 13:17
Worklog Time Spent: 10m
Work Description: gtully commented on a change in pull request #3849:
URL: https://github.com/apache/activemq-artemis/pull/3849#discussion_r751230489
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/ActiveMQPacketHandler.java
##
@@ -175,6 +171,11 @@ private void handleCreateSession(final
CreateSessionMessage request) {
activeMQPrincipal = connection.getDefaultActiveMQPrincipal();
}
+ if (connection.getTransportConnection().getRedirectTo() != null) {
+server.validateUser(activeMQPrincipal == null ?
request.getUsername() : activeMQPrincipal.getUserName(), activeMQPrincipal ==
null ? request.getPassword() : activeMQPrincipal.getPassword(), connection,
protocolManager.getSecurityDomain());
Review comment:
that makes sense, create session is called in a few places, but
preceding those with validate user is probably fine.
I think there is a body of work to deal with the sasl subject and probably
replace a validatedUser string with a subject at some stage... but that is for
another day.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 682601)
Time Spent: 1h (was: 50m)
> Broker balancer based on authenticated user role assignment
> ---
>
> Key: ARTEMIS-3569
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3569
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: balancer
>Affects Versions: 2.19.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> following up on ARTEMIS-3365 for the local target path.
> add support for ROLE_NAME as a targetKey.
> Matching one of the Roles of an authenticated principal associated with a
> connection, accept or reject the connection based on some partition policy
> based on the role.
> Using the existing regular expression based filter, it is possible to ensure
> a sub set of roles are associated with a given broker.
> The symmeteric-simple-example that uses the client id key type can be
> extended to support partitioning on role assignment, the configuration, to
> use role names that begin with "PARTITION_" and match "PARTITION_FOO" to
> this broker, would be of the form:
> {code:java}
>
> ROLE_NAME
> ^PARTITION_*
> ^PARTITION_FOO.*
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3573) Support PropertiesLoginModule custom password codecs
[
https://issues.apache.org/jira/browse/ARTEMIS-3573?focusedWorklogId=682574=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682574
]
ASF GitHub Bot logged work on ARTEMIS-3573:
---
Author: ASF GitHub Bot
Created on: 17/Nov/21 12:30
Start Date: 17/Nov/21 12:30
Worklog Time Spent: 10m
Work Description: gemmellr commented on a change in pull request #3851:
URL: https://github.com/apache/activemq-artemis/pull/3851#discussion_r751194210
##
File path:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/SecureHashProcessor.java
##
@@ -33,6 +33,6 @@ public String hash(String plainText) throws Exception {
//storedValue must take form of ENC(...)
public boolean compare(char[] inputValue, String storedValue) {
String storedHash = storedValue.substring(4, storedValue.length() - 1);
- return codec.verify(inputValue, storedHash);
+ return codec.compare(inputValue, storedHash);
Review comment:
Ahhh. I've missed that the verify method isnt new, its an existing
method defined in DefaultSensitiveStringCodec that you just implemented in
another bit of DefaultSensitiveStringCodec. But added the essentially same
compare method to the SensitiveDataCodec interface.
My main thought is still why have both, and why does the private
CodecAlgorithm class need to exist within DefaultSensitiveStringCodec at all,
just to define methods that are basically already defined on the
SensitiveDataCodec interface.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 682574)
Time Spent: 2h 10m (was: 2h)
> Support PropertiesLoginModule custom password codecs
>
>
> Key: ARTEMIS-3573
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3573
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> The `PropertiesLoginModule` login module supports only the
> `DefaultSensitiveStringCodec` codec to verify the user passwords.
> Add a property to set a custom password codec, i.e.
> org.apache.activemq.jaas.properties.password.codec="org.apache.activemq.artemis.tests.integration.security.MD5SensitiveDataCodec"
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3573) Support PropertiesLoginModule custom password codecs
[
https://issues.apache.org/jira/browse/ARTEMIS-3573?focusedWorklogId=682566=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682566
]
ASF GitHub Bot logged work on ARTEMIS-3573:
---
Author: ASF GitHub Bot
Created on: 17/Nov/21 12:26
Start Date: 17/Nov/21 12:26
Worklog Time Spent: 10m
Work Description: gemmellr commented on a change in pull request #3851:
URL: https://github.com/apache/activemq-artemis/pull/3851#discussion_r751191216
##
File path:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/DefaultSensitiveStringCodec.java
##
@@ -188,6 +208,16 @@ public String encode(String secret) throws Exception {
BigInteger n = new BigInteger(encoding);
return n.toString(16);
}
+
+ @Override
+ public boolean verify(char[] inputValue, String storedValue) {
+ try {
+return Objects.equals(storedValue,
encode(String.valueOf(inputValue)));
Review comment:
The methods here seems somewhat all over the place.
The class implements SensitiveDataCodec, meaning it has to return
String (i.e T) for encode and decode methods, but is only taking Object args
which it then blindly assumes are actually String and casts to that unchecked.
The new compare method also takes Object args and then for some odd reason
requires one of them to be String or char[], but only String in the other. It
converts the first to char[] if it wasnt, so it can call this verify method
which has fixed char[] and String type args. Which then turns the char[]
_[back]_ into a String so it can call encode with a String to get another
String to further compare to the given String.
Why allow different types in the various different methods? Why is one
methods args fixed type and the others floating Object, that are then assumed
or enforced to be a specific types (meaning the broker has to be calling it
with those types), and yet always ending up as String ultimately. Almost
nothing is using the generic T type to pick up the String generic from the
class definition but that appears to be the only type that is used in the
broker so nothing else will actually work.
Actually, why add both new verify and compare methods when they do
essentially the same thing overall? Verify is probably a better name overall
since compare doesnt as much imply the fact one arg has to be manipulated to
equal the other (and the not-present javadoc doesnt say what the method
actually does at all)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 682566)
Time Spent: 1h 50m (was: 1h 40m)
> Support PropertiesLoginModule custom password codecs
>
>
> Key: ARTEMIS-3573
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3573
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The `PropertiesLoginModule` login module supports only the
> `DefaultSensitiveStringCodec` codec to verify the user passwords.
> Add a property to set a custom password codec, i.e.
> org.apache.activemq.jaas.properties.password.codec="org.apache.activemq.artemis.tests.integration.security.MD5SensitiveDataCodec"
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3573) Support PropertiesLoginModule custom password codecs
[
https://issues.apache.org/jira/browse/ARTEMIS-3573?focusedWorklogId=682567=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-682567
]
ASF GitHub Bot logged work on ARTEMIS-3573:
---
Author: ASF GitHub Bot
Created on: 17/Nov/21 12:26
Start Date: 17/Nov/21 12:26
Worklog Time Spent: 10m
Work Description: gemmellr commented on a change in pull request #3851:
URL: https://github.com/apache/activemq-artemis/pull/3851#discussion_r751191562
##
File path:
artemis-commons/src/test/java/org/apache/activemq/artemis/utils/DefaultSensitiveStringCodecTest.java
##
@@ -39,20 +40,33 @@ public void testDefaultAlgorithm() throws Exception {
@Test
public void testOnewayAlgorithm() throws Exception {
- DefaultSensitiveStringCodec codec = new DefaultSensitiveStringCodec();
- Map params = new HashMap<>();
- params.put(DefaultSensitiveStringCodec.ALGORITHM,
DefaultSensitiveStringCodec.ONE_WAY);
- codec.init(params);
+ testAlgorithm(DefaultSensitiveStringCodec.ONE_WAY);
+ }
+
+ @Test
+ public void testTwowayAlgorithm() throws Exception {
+ testAlgorithm(DefaultSensitiveStringCodec.TWO_WAY);
+ }
+
+ private void testAlgorithm(String algorithm) throws Exception {
+ DefaultSensitiveStringCodec codec =
getDefaultSensitiveStringCodec(algorithm);
String plainText = "some_password";
String maskedText = codec.encode(plainText);
log.debug("encoded value: " + maskedText);
- //one way can't decode
- try {
- codec.decode(maskedText);
- fail("one way algorithm can't decode");
- } catch (IllegalArgumentException expected) {
+ if (algorithm.equals(DefaultSensitiveStringCodec.ONE_WAY)) {
+ //one way can't decode
+ try {
+codec.decode(maskedText);
+fail("one way algorithm can't decode");
+ } catch (IllegalArgumentException expected) {
Review comment:
UnsupportedOperation or IllegalState would seem a far better fit, but if
this is existing behaviour I guess perhaps retaining it might be the way to go.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 682567)
Time Spent: 2h (was: 1h 50m)
> Support PropertiesLoginModule custom password codecs
>
>
> Key: ARTEMIS-3573
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3573
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> The `PropertiesLoginModule` login module supports only the
> `DefaultSensitiveStringCodec` codec to verify the user passwords.
> Add a property to set a custom password codec, i.e.
> org.apache.activemq.jaas.properties.password.codec="org.apache.activemq.artemis.tests.integration.security.MD5SensitiveDataCodec"
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Deleted] (AMQNET-739) How to purchase adderall online without prescription | using credit card in USA
[
https://issues.apache.org/jira/browse/AMQNET-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon deleted AMQNET-739:
--
> How to purchase adderall online without prescription | using credit card in
> USA
>
>
> Key: AMQNET-739
> URL: https://issues.apache.org/jira/browse/AMQNET-739
> Project: ActiveMQ .Net
> Issue Type: Bug
> Environment: Adderall on line purchase, ,buy Adderall without a
> prescription overnight shipping, ,Adderall non prescription fedex overnight
> free, ,where to buy Adderall no prescription no fees, ,Adderall without rx
> saturday delivery, ,online doctor consultation for Adderall ,Adderall no rx
> cod ,Adderall cod delivery ,cod shipped Adderall ,Adderall no rx,cheap
> Adderall overnight delivery
>Reporter: wayright meds
>Priority: Major
> Labels: sse
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> {*}{*}[Adderall|https://wayrightmeds.com/product-category/buy-adderall-online/]
> is a prescription medication made up of two drugs: amphetamine and
> dextroamphetamine. It is a stimulant, which is a type of medication.
>
> Adderall is most commonly used to treat attention deficit hyperactivity
> disorder (ADHD). It is also used in the treatment of narcolepsy.
>
> Adderall is available in two forms: oral tablet and extended-release oral
> capsule. You can {*}{*}[buy Adderall online using credit cards in
> USA|https://wayrightmeds.com/product-category/buy-adderall-online/] from our
> website.
> *[Buy adderall online,Buy adderall without prescription,Buy adderall
> overnight,Order adderall by credit card,Buy adderall No Rx,Adderall fedex
> delivery,Adderall overnight COD no
> prescription|https://wayrightmeds.com/product-category/buy-adderall-online/]*
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Deleted] (AMQCLI-52) Hẹn Hò 12h - Nơi kết bạn hẹn hò uy tín nhất Việt Nam
[ https://issues.apache.org/jira/browse/AMQCLI-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon deleted AMQCLI-52: - > Hẹn Hò 12h - Nơi kết bạn hẹn hò uy tín nhất Việt Nam > > > Key: AMQCLI-52 > URL: https://issues.apache.org/jira/browse/AMQCLI-52 > Project: ActiveMQ CLI Tools > Issue Type: Test >Reporter: Hẹn Hò 12h >Priority: Critical > > Welcome to https://henho12h.com. Website Hẹn Hò 12h là nơi giao lưu Tìm bạn > trai ✅, Tìm bạn gái ✅, tìm bạn les✅, tìm máy bay bà già uy tín✅, có số điện > thoại, zalo và hình thật 100%. Hãy nhanh tay đăng ký thành viên Hẹn Hò 12h để > tìm kiếm hạnh phúc của mình nhé! > Thông tin liên hệ: > Địa chỉ: 128 Nguyễn Thị Minh Khai, Phường 6, Quận 3, Thành phố Hồ Chí Minh > 7, Việt Nam > Email: [henho...@gmail.com|mailto:henho...@gmail.com] > Website: [https://henho12h.com|https://henho12h.com/] > [https://henho12h.com/may-bay-ba-gia/] > [https://henho12h.com/tim-ban-gai/] > [https://henho12h.com/tim-ban-trai/] > [https://henho12h.com/tim-ban-tinh/] > [https://henho12h.com/tim-ban-les/] > Tags: henho12h, hẹn hò online, hẹn hò bốn phương, hẹn hò app, hẹn hò an toàn, > tìm bạn trai, tìm bạn gái, tìm máy bay bà già, tìm bạn tình, tìm bạn les, tìm > bạn tâm sự, tìm bạn bốn phương, tim bạn đời, tìm bạn kín đáo > Hashtag: #henho12h #henhoonline #henhobonphuong #henhoapp #henhoantoan > #timbantrai #timbangai #timmaybaybagia #timbantinh #timbanles #timbantamsu > #timbanbonphuong #timbandoi #timbankindao -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (ARTEMIS-3575) Wrong address size estimation on broker restart
[ https://issues.apache.org/jira/browse/ARTEMIS-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-3575. - Fix Version/s: 2.20.0 Resolution: Fixed > Wrong address size estimation on broker restart > --- > > Key: ARTEMIS-3575 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3575 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Gary Tully >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Steps to reproduce: > Using the GUI in the console: > * Create a new multicast address named "mytest" > * Select the address and create a durable multicast queue named "mytest" > * Use the artemis CLI to produce messages. For example like this: > artemis producer --user admin --password admin --url tcp://localhost:61616 > --destination topic://mytest --message-count 1000 --message-size 40960 > --threads 4 > Note the reported address memory used in the console: in the example above it > is 160.26MB > * restart the broker > * the reported address memory is now below 1 MB > The error seems due to the paging store owner that's not correctly set on the > message while loading it, preventing its memory estimation to be accounted > into the address size. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3580) Possibility to view (truncated) body content for large messages in web console
[ https://issues.apache.org/jira/browse/ARTEMIS-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Magnus Johansson updated ARTEMIS-3580: -- Summary: Possibility to view (truncated) body content for large messages in web console (was: Possibility to view (trunctaed) body content for large messages in web console) > Possibility to view (truncated) body content for large messages in web console > -- > > Key: ARTEMIS-3580 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3580 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Magnus Johansson >Priority: Major > > For us it would be greatly beneficial if we could view at least the first > part of a "large message" truncated according to the setting > management-message-attribute-size-limit introduced in 2.18.0. > > If a message ends up in the error (dlq) queue. It is sometimes good to be > able to look at the content from the web console. > > For a message labelled as large, it seems like the lower layers set the body > to the string "large message" and the setting > management-message-attribute-size-limit doesn't apply. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
