[jira] [Work logged] (AMQ-7340) Scheduled messages performance degrade
[ https://issues.apache.org/jira/browse/AMQ-7340?focusedWorklogId=711707=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711707 ] ASF GitHub Bot logged work on AMQ-7340: --- Author: ASF GitHub Bot Created on: 19/Jan/22 22:19 Start Date: 19/Jan/22 22:19 Worklog Time Spent: 10m Work Description: lucastetreault commented on pull request #728: URL: https://github.com/apache/activemq/pull/728#issuecomment-1016924723 Thanks JB! -- 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: 711707) Time Spent: 50m (was: 40m) > Scheduled messages performance degrade > -- > > Key: AMQ-7340 > URL: https://issues.apache.org/jira/browse/AMQ-7340 > Project: ActiveMQ > Issue Type: Bug > Environment: ActiveMQ broker has been started in a docker container, > with (most likely) sufficient allocation of resources. >Reporter: Daynews >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 5.17.0, 5.16.4 > > Attachments: ScheduleActiveMQ.zip > > Time Spent: 50m > Remaining Estimate: 0h > > I have sent lot of scheduled messages with 10ms delay between each to see if > the broker can cope with high load of scheduled messages. Sending delayed > messages to the queue works fine, however I get a problem when those messages > need to be put to the main queue when next schedule time is reached. The rate > of putting scheduled messages to the main queue drops drastically at around > 1500-3000 messages. I tried to search for a potential cause why this happen, > but was not able to indicate anything. Even restarting the broker or cleaning > the main queue, the rate of putting scheduled messages stays at ~0.5s leaving > many scheduled messages behind. > Does anyone know a potential cause for his problem? Is this performance > bottleneck or insufficient resources or badly configured RabitMQ (I've used > default settings). > Thanks for the support. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (AMQ-8316) Remove deprecated BrokerService methods
[ https://issues.apache.org/jira/browse/AMQ-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated AMQ-8316: -- Fix Version/s: 5.17.0 5.16.4 > Remove deprecated BrokerService methods > > > Key: AMQ-8316 > URL: https://issues.apache.org/jira/browse/AMQ-8316 > Project: ActiveMQ > Issue Type: Sub-task >Reporter: Matt Pavlovich >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.17.0, 5.16.4 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Legacy BrokerService methods are unused and should be removed > Methods targeted for removal: > isWaitForSlave() -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (AMQ-8316) Remove deprecated BrokerService methods
[ https://issues.apache.org/jira/browse/AMQ-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated AMQ-8316: -- Fix Version/s: (was: 5.16.4) > Remove deprecated BrokerService methods > > > Key: AMQ-8316 > URL: https://issues.apache.org/jira/browse/AMQ-8316 > Project: ActiveMQ > Issue Type: Sub-task >Reporter: Matt Pavlovich >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.17.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Legacy BrokerService methods are unused and should be removed > Methods targeted for removal: > isWaitForSlave() -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (AMQ-8316) Remove deprecated BrokerService methods
[ https://issues.apache.org/jira/browse/AMQ-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned AMQ-8316: - Assignee: Jean-Baptiste Onofré (was: Matt Pavlovich) > Remove deprecated BrokerService methods > > > Key: AMQ-8316 > URL: https://issues.apache.org/jira/browse/AMQ-8316 > Project: ActiveMQ > Issue Type: Sub-task >Reporter: Matt Pavlovich >Assignee: Jean-Baptiste Onofré >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Legacy BrokerService methods are unused and should be removed > Methods targeted for removal: > isWaitForSlave() -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (AMQ-8317) Add a Broker config parameter to flip between deprecated terminology
[
https://issues.apache.org/jira/browse/AMQ-8317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated AMQ-8317:
--
Fix Version/s: 5.17.0
5.16.4
> Add a Broker config parameter to flip between deprecated terminology
>
>
> Key: AMQ-8317
> URL: https://issues.apache.org/jira/browse/AMQ-8317
> Project: ActiveMQ
> Issue Type: Sub-task
> Components: Broker
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.4
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In BrokerService:
> # create field 'useDeprecatedTopologyTerminology'
> # For 5.17.0 default to 'true'
> # Update the logging statement to wrap deprecated and targeted-for-remove
> code with an if block using this field.
> {noformat}
> if(isUseDeprecatedTopologyTerminology()) {
> LOG.warn("Master Failed - starting all connectors");
> } else {
> LOG.warn("Active Failed - starting all connectors");
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (AMQ-8317) Add a Broker config parameter to flip between deprecated terminology
[
https://issues.apache.org/jira/browse/AMQ-8317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré reassigned AMQ-8317:
-
Assignee: Jean-Baptiste Onofré (was: Matt Pavlovich)
> Add a Broker config parameter to flip between deprecated terminology
>
>
> Key: AMQ-8317
> URL: https://issues.apache.org/jira/browse/AMQ-8317
> Project: ActiveMQ
> Issue Type: Sub-task
> Components: Broker
>Reporter: Matt Pavlovich
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In BrokerService:
> # create field 'useDeprecatedTopologyTerminology'
> # For 5.17.0 default to 'true'
> # Update the logging statement to wrap deprecated and targeted-for-remove
> code with an if block using this field.
> {noformat}
> if(isUseDeprecatedTopologyTerminology()) {
> LOG.warn("Master Failed - starting all connectors");
> } else {
> LOG.warn("Active Failed - starting all connectors");
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (AMQ-7340) Scheduled messages performance degrade
[ https://issues.apache.org/jira/browse/AMQ-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-7340. --- Resolution: Fixed > Scheduled messages performance degrade > -- > > Key: AMQ-7340 > URL: https://issues.apache.org/jira/browse/AMQ-7340 > Project: ActiveMQ > Issue Type: Bug > Environment: ActiveMQ broker has been started in a docker container, > with (most likely) sufficient allocation of resources. >Reporter: Daynews >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 5.17.0, 5.16.4 > > Attachments: ScheduleActiveMQ.zip > > Time Spent: 40m > Remaining Estimate: 0h > > I have sent lot of scheduled messages with 10ms delay between each to see if > the broker can cope with high load of scheduled messages. Sending delayed > messages to the queue works fine, however I get a problem when those messages > need to be put to the main queue when next schedule time is reached. The rate > of putting scheduled messages to the main queue drops drastically at around > 1500-3000 messages. I tried to search for a potential cause why this happen, > but was not able to indicate anything. Even restarting the broker or cleaning > the main queue, the rate of putting scheduled messages stays at ~0.5s leaving > many scheduled messages behind. > Does anyone know a potential cause for his problem? Is this performance > bottleneck or insufficient resources or badly configured RabitMQ (I've used > default settings). > Thanks for the support. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (AMQ-7340) Scheduled messages performance degrade
[ https://issues.apache.org/jira/browse/AMQ-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478858#comment-17478858 ] ASF subversion and git services commented on AMQ-7340: -- Commit 70e0b3babf07d708064365c400d37cea8a2bfd4b in activemq's branch refs/heads/main from Jean-Baptiste Onofré [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=70e0b3b ] Merge pull request #728 from lucastetreault/scheduler-performance [AMQ-7340] Improve scheduled message performance > Scheduled messages performance degrade > -- > > Key: AMQ-7340 > URL: https://issues.apache.org/jira/browse/AMQ-7340 > Project: ActiveMQ > Issue Type: Bug > Environment: ActiveMQ broker has been started in a docker container, > with (most likely) sufficient allocation of resources. >Reporter: Daynews >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 5.17.0, 5.16.4 > > Attachments: ScheduleActiveMQ.zip > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have sent lot of scheduled messages with 10ms delay between each to see if > the broker can cope with high load of scheduled messages. Sending delayed > messages to the queue works fine, however I get a problem when those messages > need to be put to the main queue when next schedule time is reached. The rate > of putting scheduled messages to the main queue drops drastically at around > 1500-3000 messages. I tried to search for a potential cause why this happen, > but was not able to indicate anything. Even restarting the broker or cleaning > the main queue, the rate of putting scheduled messages stays at ~0.5s leaving > many scheduled messages behind. > Does anyone know a potential cause for his problem? Is this performance > bottleneck or insufficient resources or badly configured RabitMQ (I've used > default settings). > Thanks for the support. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (AMQ-7340) Scheduled messages performance degrade
[ https://issues.apache.org/jira/browse/AMQ-7340?focusedWorklogId=711531=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711531 ] ASF GitHub Bot logged work on AMQ-7340: --- Author: ASF GitHub Bot Created on: 19/Jan/22 18:01 Start Date: 19/Jan/22 18:01 Worklog Time Spent: 10m Work Description: jbonofre merged pull request #728: URL: https://github.com/apache/activemq/pull/728 -- 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: 711531) Time Spent: 40m (was: 0.5h) > Scheduled messages performance degrade > -- > > Key: AMQ-7340 > URL: https://issues.apache.org/jira/browse/AMQ-7340 > Project: ActiveMQ > Issue Type: Bug > Environment: ActiveMQ broker has been started in a docker container, > with (most likely) sufficient allocation of resources. >Reporter: Daynews >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 5.17.0, 5.16.4 > > Attachments: ScheduleActiveMQ.zip > > Time Spent: 40m > Remaining Estimate: 0h > > I have sent lot of scheduled messages with 10ms delay between each to see if > the broker can cope with high load of scheduled messages. Sending delayed > messages to the queue works fine, however I get a problem when those messages > need to be put to the main queue when next schedule time is reached. The rate > of putting scheduled messages to the main queue drops drastically at around > 1500-3000 messages. I tried to search for a potential cause why this happen, > but was not able to indicate anything. Even restarting the broker or cleaning > the main queue, the rate of putting scheduled messages stays at ~0.5s leaving > many scheduled messages behind. > Does anyone know a potential cause for his problem? Is this performance > bottleneck or insufficient resources or badly configured RabitMQ (I've used > default settings). > Thanks for the support. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (AMQ-8409) Unexpected \\r instead of \r in header property in incoming messages
[
https://issues.apache.org/jira/browse/AMQ-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré resolved AMQ-8409.
---
Resolution: Fixed
> Unexpected \\r instead of \r in header property in incoming messages
>
>
> Key: AMQ-8409
> URL: https://issues.apache.org/jira/browse/AMQ-8409
> Project: ActiveMQ
> Issue Type: Improvement
> Components: STOMP
> Environment: Broker: ActiveMQ 5.16.3
> OS: Windows 10
> Client: own implementation
>Reporter: Michael Justin
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.4
>
> Attachments: AMQ-8409.patch, image-2021-11-07-12-04-34-856.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> I tested the Stomp acceptor handling of escape sequences as specified in the
> 1.2 protocol documentation.
> With ActiveMQ Artemis 2.19.0, all escape sequences are received according to
> the 1.2 specification:
> !image-2021-11-07-12-04-34-856.png|width=456,height=105!
> [https://stomp.github.io/stomp-specification-1.2.html#Value_Encoding]
>
> With ActiveMQ "Classic" however, there is a difference: when the escape
> sequence *\r* is used in SEND frame header values, it will be received as
> *r* in incoming MESSAGE frames.
> h2. Test with Artemis 2.19.0
> The first example uses the Artemis broker. A message with four special
> escaped characters (backslash, colon, newline and carriage return) is sent to
> the broker and then received with identical values.
> As you can see in the example, the header property {{*keyr*}} in the outgoing
> {{SEND}} frame has the value *value\r* and is received as *value\r* in the
> incoming {{MESSAGE}} frame.
> Unescaped, this is "value" + carriage return
>
> {noformat}
> CONNECTED
> version:1.2
> session:be014f64
> server:ActiveMQ-Artemis/2.19.0 ActiveMQ Artemis Messaging Engine
>
> SEND
> destination:queue/TStomp12TestCase.TestEscapes.Q
> keyb:value\\
> keyc:value\c
> keyn:value\n
> keyr:value\r
> content-type:text/plain
>
> Send:Bytes:112
> SUBSCRIBE
> destination:queue/TStomp12TestCase.TestEscapes.Q
> ack:auto
> id:{13084522-1FEF-4B8A-802A-4656A77784EA}
>
> MESSAGE
> subscription:{13084522-1FEF-4B8A-802A-4656A77784EA}
> message-id:10737418259
> destination:queue/TStomp12TestCase.TestEscapes.Q
> expires:0
> redelivered:false
> priority:4
> persistent:false
> timestamp:1636280945342
> content-type:text/plain
> keyn:value\n
> keyc:value\c
> keyb:value\\
> keyr:value\r
> {noformat}
>
> h2. Test with ActiveMQ 5.16.3
> As you can see in the example, the header property {{*keyr*}} in the outgoing
> {{SEND}} frame has the value *value\r* (as in the first test) but is received
> as *valuer* in the incoming {{MESSAGE}} frame. Unescaped, this is
> not "value" + carriage return, but "value\r".
> {noformat}
> CONNECTED
> server:ActiveMQ/5.16.3
> heart-beat:0,0
> session:ID:DESKTOP-3LKMPLS-49926-1636281770555-3:4
> version:1.2
> SEND
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> keyb:value\\
> keyc:value\c
> keyn:value\n
> keyr:value\r
> content-type:text/plain
> SUBSCRIBE
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> ack:auto
> id:{7316E53E-E7C3-43DC-B2EF-75BCFC09D899}
> MESSAGE
> keyr:value\\r
> expires:0
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> subscription:{7316E53E-E7C3-43DC-B2EF-75BCFC09D899}
> priority:4
> keyb:value\\
> keyc:value\c
> message-id:ID\cDESKTOP-3LKMPLS-49926-1636281770555-3\c4\c-1\c1\c1
> content-type:text/plain
> keyn:value\n
> timestamp:1636281794663
> {noformat}
>
>
> So it seems that ActiveMQ Classic performs either an incorrect unescaping on
> the incoming message, or an incorrect escaping on the outgoing message.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (AMQ-8409) Unexpected \\r instead of \r in header property in incoming messages
[
https://issues.apache.org/jira/browse/AMQ-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478840#comment-17478840
]
ASF subversion and git services commented on AMQ-8409:
--
Commit 31a07c11aae8f96172d6aadba221cb0de6634098 in activemq's branch
refs/heads/activemq-5.16.x from Anthony F
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=31a07c1 ]
[AMQ-8409] Fixed Unexpected \\r instead of \r in header property in incoming
messages
(cherry picked from commit d9450cdd74aed1471388058e28c2b777db419e68)
> Unexpected \\r instead of \r in header property in incoming messages
>
>
> Key: AMQ-8409
> URL: https://issues.apache.org/jira/browse/AMQ-8409
> Project: ActiveMQ
> Issue Type: Improvement
> Components: STOMP
> Environment: Broker: ActiveMQ 5.16.3
> OS: Windows 10
> Client: own implementation
>Reporter: Michael Justin
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.4
>
> Attachments: AMQ-8409.patch, image-2021-11-07-12-04-34-856.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> I tested the Stomp acceptor handling of escape sequences as specified in the
> 1.2 protocol documentation.
> With ActiveMQ Artemis 2.19.0, all escape sequences are received according to
> the 1.2 specification:
> !image-2021-11-07-12-04-34-856.png|width=456,height=105!
> [https://stomp.github.io/stomp-specification-1.2.html#Value_Encoding]
>
> With ActiveMQ "Classic" however, there is a difference: when the escape
> sequence *\r* is used in SEND frame header values, it will be received as
> *r* in incoming MESSAGE frames.
> h2. Test with Artemis 2.19.0
> The first example uses the Artemis broker. A message with four special
> escaped characters (backslash, colon, newline and carriage return) is sent to
> the broker and then received with identical values.
> As you can see in the example, the header property {{*keyr*}} in the outgoing
> {{SEND}} frame has the value *value\r* and is received as *value\r* in the
> incoming {{MESSAGE}} frame.
> Unescaped, this is "value" + carriage return
>
> {noformat}
> CONNECTED
> version:1.2
> session:be014f64
> server:ActiveMQ-Artemis/2.19.0 ActiveMQ Artemis Messaging Engine
>
> SEND
> destination:queue/TStomp12TestCase.TestEscapes.Q
> keyb:value\\
> keyc:value\c
> keyn:value\n
> keyr:value\r
> content-type:text/plain
>
> Send:Bytes:112
> SUBSCRIBE
> destination:queue/TStomp12TestCase.TestEscapes.Q
> ack:auto
> id:{13084522-1FEF-4B8A-802A-4656A77784EA}
>
> MESSAGE
> subscription:{13084522-1FEF-4B8A-802A-4656A77784EA}
> message-id:10737418259
> destination:queue/TStomp12TestCase.TestEscapes.Q
> expires:0
> redelivered:false
> priority:4
> persistent:false
> timestamp:1636280945342
> content-type:text/plain
> keyn:value\n
> keyc:value\c
> keyb:value\\
> keyr:value\r
> {noformat}
>
> h2. Test with ActiveMQ 5.16.3
> As you can see in the example, the header property {{*keyr*}} in the outgoing
> {{SEND}} frame has the value *value\r* (as in the first test) but is received
> as *valuer* in the incoming {{MESSAGE}} frame. Unescaped, this is
> not "value" + carriage return, but "value\r".
> {noformat}
> CONNECTED
> server:ActiveMQ/5.16.3
> heart-beat:0,0
> session:ID:DESKTOP-3LKMPLS-49926-1636281770555-3:4
> version:1.2
> SEND
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> keyb:value\\
> keyc:value\c
> keyn:value\n
> keyr:value\r
> content-type:text/plain
> SUBSCRIBE
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> ack:auto
> id:{7316E53E-E7C3-43DC-B2EF-75BCFC09D899}
> MESSAGE
> keyr:value\\r
> expires:0
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> subscription:{7316E53E-E7C3-43DC-B2EF-75BCFC09D899}
> priority:4
> keyb:value\\
> keyc:value\c
> message-id:ID\cDESKTOP-3LKMPLS-49926-1636281770555-3\c4\c-1\c1\c1
> content-type:text/plain
> keyn:value\n
> timestamp:1636281794663
> {noformat}
>
>
> So it seems that ActiveMQ Classic performs either an incorrect unescaping on
> the incoming message, or an incorrect escaping on the outgoing message.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (AMQ-8409) Unexpected \\r instead of \r in header property in incoming messages
[
https://issues.apache.org/jira/browse/AMQ-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478839#comment-17478839
]
ASF subversion and git services commented on AMQ-8409:
--
Commit d9450cdd74aed1471388058e28c2b777db419e68 in activemq's branch
refs/heads/main from Anthony F
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=d9450cd ]
[AMQ-8409] Fixed Unexpected \\r instead of \r in header property in incoming
messages
> Unexpected \\r instead of \r in header property in incoming messages
>
>
> Key: AMQ-8409
> URL: https://issues.apache.org/jira/browse/AMQ-8409
> Project: ActiveMQ
> Issue Type: Improvement
> Components: STOMP
> Environment: Broker: ActiveMQ 5.16.3
> OS: Windows 10
> Client: own implementation
>Reporter: Michael Justin
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.4
>
> Attachments: AMQ-8409.patch, image-2021-11-07-12-04-34-856.png
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> I tested the Stomp acceptor handling of escape sequences as specified in the
> 1.2 protocol documentation.
> With ActiveMQ Artemis 2.19.0, all escape sequences are received according to
> the 1.2 specification:
> !image-2021-11-07-12-04-34-856.png|width=456,height=105!
> [https://stomp.github.io/stomp-specification-1.2.html#Value_Encoding]
>
> With ActiveMQ "Classic" however, there is a difference: when the escape
> sequence *\r* is used in SEND frame header values, it will be received as
> *r* in incoming MESSAGE frames.
> h2. Test with Artemis 2.19.0
> The first example uses the Artemis broker. A message with four special
> escaped characters (backslash, colon, newline and carriage return) is sent to
> the broker and then received with identical values.
> As you can see in the example, the header property {{*keyr*}} in the outgoing
> {{SEND}} frame has the value *value\r* and is received as *value\r* in the
> incoming {{MESSAGE}} frame.
> Unescaped, this is "value" + carriage return
>
> {noformat}
> CONNECTED
> version:1.2
> session:be014f64
> server:ActiveMQ-Artemis/2.19.0 ActiveMQ Artemis Messaging Engine
>
> SEND
> destination:queue/TStomp12TestCase.TestEscapes.Q
> keyb:value\\
> keyc:value\c
> keyn:value\n
> keyr:value\r
> content-type:text/plain
>
> Send:Bytes:112
> SUBSCRIBE
> destination:queue/TStomp12TestCase.TestEscapes.Q
> ack:auto
> id:{13084522-1FEF-4B8A-802A-4656A77784EA}
>
> MESSAGE
> subscription:{13084522-1FEF-4B8A-802A-4656A77784EA}
> message-id:10737418259
> destination:queue/TStomp12TestCase.TestEscapes.Q
> expires:0
> redelivered:false
> priority:4
> persistent:false
> timestamp:1636280945342
> content-type:text/plain
> keyn:value\n
> keyc:value\c
> keyb:value\\
> keyr:value\r
> {noformat}
>
> h2. Test with ActiveMQ 5.16.3
> As you can see in the example, the header property {{*keyr*}} in the outgoing
> {{SEND}} frame has the value *value\r* (as in the first test) but is received
> as *valuer* in the incoming {{MESSAGE}} frame. Unescaped, this is
> not "value" + carriage return, but "value\r".
> {noformat}
> CONNECTED
> server:ActiveMQ/5.16.3
> heart-beat:0,0
> session:ID:DESKTOP-3LKMPLS-49926-1636281770555-3:4
> version:1.2
> SEND
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> keyb:value\\
> keyc:value\c
> keyn:value\n
> keyr:value\r
> content-type:text/plain
> SUBSCRIBE
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> ack:auto
> id:{7316E53E-E7C3-43DC-B2EF-75BCFC09D899}
> MESSAGE
> keyr:value\\r
> expires:0
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> subscription:{7316E53E-E7C3-43DC-B2EF-75BCFC09D899}
> priority:4
> keyb:value\\
> keyc:value\c
> message-id:ID\cDESKTOP-3LKMPLS-49926-1636281770555-3\c4\c-1\c1\c1
> content-type:text/plain
> keyn:value\n
> timestamp:1636281794663
> {noformat}
>
>
> So it seems that ActiveMQ Classic performs either an incorrect unescaping on
> the incoming message, or an incorrect escaping on the outgoing message.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (AMQ-8409) Unexpected \\r instead of \r in header property in incoming messages
[
https://issues.apache.org/jira/browse/AMQ-8409?focusedWorklogId=711518=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711518
]
ASF GitHub Bot logged work on AMQ-8409:
---
Author: ASF GitHub Bot
Created on: 19/Jan/22 17:29
Start Date: 19/Jan/22 17:29
Worklog Time Spent: 10m
Work Description: asfgit closed pull request #736:
URL: https://github.com/apache/activemq/pull/736
--
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: 711518)
Time Spent: 2h 20m (was: 2h 10m)
> Unexpected \\r instead of \r in header property in incoming messages
>
>
> Key: AMQ-8409
> URL: https://issues.apache.org/jira/browse/AMQ-8409
> Project: ActiveMQ
> Issue Type: Improvement
> Components: STOMP
> Environment: Broker: ActiveMQ 5.16.3
> OS: Windows 10
> Client: own implementation
>Reporter: Michael Justin
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.17.0, 5.16.4
>
> Attachments: AMQ-8409.patch, image-2021-11-07-12-04-34-856.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> I tested the Stomp acceptor handling of escape sequences as specified in the
> 1.2 protocol documentation.
> With ActiveMQ Artemis 2.19.0, all escape sequences are received according to
> the 1.2 specification:
> !image-2021-11-07-12-04-34-856.png|width=456,height=105!
> [https://stomp.github.io/stomp-specification-1.2.html#Value_Encoding]
>
> With ActiveMQ "Classic" however, there is a difference: when the escape
> sequence *\r* is used in SEND frame header values, it will be received as
> *r* in incoming MESSAGE frames.
> h2. Test with Artemis 2.19.0
> The first example uses the Artemis broker. A message with four special
> escaped characters (backslash, colon, newline and carriage return) is sent to
> the broker and then received with identical values.
> As you can see in the example, the header property {{*keyr*}} in the outgoing
> {{SEND}} frame has the value *value\r* and is received as *value\r* in the
> incoming {{MESSAGE}} frame.
> Unescaped, this is "value" + carriage return
>
> {noformat}
> CONNECTED
> version:1.2
> session:be014f64
> server:ActiveMQ-Artemis/2.19.0 ActiveMQ Artemis Messaging Engine
>
> SEND
> destination:queue/TStomp12TestCase.TestEscapes.Q
> keyb:value\\
> keyc:value\c
> keyn:value\n
> keyr:value\r
> content-type:text/plain
>
> Send:Bytes:112
> SUBSCRIBE
> destination:queue/TStomp12TestCase.TestEscapes.Q
> ack:auto
> id:{13084522-1FEF-4B8A-802A-4656A77784EA}
>
> MESSAGE
> subscription:{13084522-1FEF-4B8A-802A-4656A77784EA}
> message-id:10737418259
> destination:queue/TStomp12TestCase.TestEscapes.Q
> expires:0
> redelivered:false
> priority:4
> persistent:false
> timestamp:1636280945342
> content-type:text/plain
> keyn:value\n
> keyc:value\c
> keyb:value\\
> keyr:value\r
> {noformat}
>
> h2. Test with ActiveMQ 5.16.3
> As you can see in the example, the header property {{*keyr*}} in the outgoing
> {{SEND}} frame has the value *value\r* (as in the first test) but is received
> as *valuer* in the incoming {{MESSAGE}} frame. Unescaped, this is
> not "value" + carriage return, but "value\r".
> {noformat}
> CONNECTED
> server:ActiveMQ/5.16.3
> heart-beat:0,0
> session:ID:DESKTOP-3LKMPLS-49926-1636281770555-3:4
> version:1.2
> SEND
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> keyb:value\\
> keyc:value\c
> keyn:value\n
> keyr:value\r
> content-type:text/plain
> SUBSCRIBE
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> ack:auto
> id:{7316E53E-E7C3-43DC-B2EF-75BCFC09D899}
> MESSAGE
> keyr:value\\r
> expires:0
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> subscription:{7316E53E-E7C3-43DC-B2EF-75BCFC09D899}
> priority:4
> keyb:value\\
> keyc:value\c
> message-id:ID\cDESKTOP-3LKMPLS-49926-1636281770555-3\c4\c-1\c1\c1
> content-type:text/plain
> keyn:value\n
> timestamp:1636281794663
> {noformat}
>
>
> So it seems that ActiveMQ Classic performs either an incorrect unescaping on
> the incoming message, or an incorrect escaping on the outgoing message.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3638) Support MQTT 5
[ https://issues.apache.org/jira/browse/ARTEMIS-3638?focusedWorklogId=711498=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711498 ] ASF GitHub Bot logged work on ARTEMIS-3638: --- Author: ASF GitHub Bot Created on: 19/Jan/22 16:53 Start Date: 19/Jan/22 16:53 Worklog Time Spent: 10m Work Description: jbertram commented on pull request #3907: URL: https://github.com/apache/activemq-artemis/pull/3907#issuecomment-1016664063 @gtully, I'll take a look. No worries! -- 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: 711498) Time Spent: 0.5h (was: 20m) > Support MQTT 5 > -- > > Key: ARTEMIS-3638 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3638 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (AMQ-5388) User Role Granted Full Privileges in jetty.xml
[ https://issues.apache.org/jira/browse/AMQ-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved AMQ-5388. --- Resolution: Fixed > User Role Granted Full Privileges in jetty.xml > -- > > Key: AMQ-5388 > URL: https://issues.apache.org/jira/browse/AMQ-5388 > Project: ActiveMQ > Issue Type: Bug > Components: Web Console >Affects Versions: 5.9.0 > Environment: Any >Reporter: Justin Reock >Assignee: Jean-Baptiste Onofré >Priority: Minor > Labels: jetty, security, web-console > Fix For: 5.17.0, 5.15.16, 5.16.4 > > > The default ConstraintMapping for the "user" role grants privileges to > /admin/*, which supersedes the *.action constraint that is supposed to be > granted only to the admin role. > The current pathspec for the user role reads: > > By granting access to /admin/*, that in turn grants access to all of the > *.action URLs, essentially nullifying the attempt to restrict *.action URLs > to only the admin role. > To repeat, just log in as the default "user/user" account to the web console > and add or delete destinations. > Workaround is to change the pathSpec to: > > Which allows access to the console but disallows access to the *.action URLs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (AMQ-5388) User Role Granted Full Privileges in jetty.xml
[ https://issues.apache.org/jira/browse/AMQ-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated AMQ-5388: -- Fix Version/s: 5.15.16 > User Role Granted Full Privileges in jetty.xml > -- > > Key: AMQ-5388 > URL: https://issues.apache.org/jira/browse/AMQ-5388 > Project: ActiveMQ > Issue Type: Bug > Components: Web Console >Affects Versions: 5.9.0 > Environment: Any >Reporter: Justin Reock >Assignee: Jean-Baptiste Onofré >Priority: Minor > Labels: jetty, security, web-console > Fix For: 5.17.0, 5.15.16, 5.16.4 > > > The default ConstraintMapping for the "user" role grants privileges to > /admin/*, which supersedes the *.action constraint that is supposed to be > granted only to the admin role. > The current pathspec for the user role reads: > > By granting access to /admin/*, that in turn grants access to all of the > *.action URLs, essentially nullifying the attempt to restrict *.action URLs > to only the admin role. > To repeat, just log in as the default "user/user" account to the web console > and add or delete destinations. > Workaround is to change the pathSpec to: > > Which allows access to the console but disallows access to the *.action URLs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (AMQ-5388) User Role Granted Full Privileges in jetty.xml
[ https://issues.apache.org/jira/browse/AMQ-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478812#comment-17478812 ] ASF subversion and git services commented on AMQ-5388: -- Commit 5af38bc2e5fffcb39a83a3436b2979b084d58395 in activemq's branch refs/heads/activemq-5.15.x from Vilius Šumskas [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=5af38bc ] https://issues.apache.org/jira/browse/AMQ-5388 Fix user permissions in web console (cherry picked from commit c67ada04c77e9379ef25ac62d5ea1fcf20cf8b8f) > User Role Granted Full Privileges in jetty.xml > -- > > Key: AMQ-5388 > URL: https://issues.apache.org/jira/browse/AMQ-5388 > Project: ActiveMQ > Issue Type: Bug > Components: Web Console >Affects Versions: 5.9.0 > Environment: Any >Reporter: Justin Reock >Assignee: Jean-Baptiste Onofré >Priority: Minor > Labels: jetty, security, web-console > Fix For: 5.17.0, 5.16.4 > > > The default ConstraintMapping for the "user" role grants privileges to > /admin/*, which supersedes the *.action constraint that is supposed to be > granted only to the admin role. > The current pathspec for the user role reads: > > By granting access to /admin/*, that in turn grants access to all of the > *.action URLs, essentially nullifying the attempt to restrict *.action URLs > to only the admin role. > To repeat, just log in as the default "user/user" account to the web console > and add or delete destinations. > Workaround is to change the pathSpec to: > > Which allows access to the console but disallows access to the *.action URLs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (AMQ-5388) User Role Granted Full Privileges in jetty.xml
[ https://issues.apache.org/jira/browse/AMQ-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478811#comment-17478811 ] ASF subversion and git services commented on AMQ-5388: -- Commit ffc2aad6e3e9fe79943503f57eec3dda7e5af807 in activemq's branch refs/heads/activemq-5.16.x from Vilius Šumskas [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=ffc2aad ] https://issues.apache.org/jira/browse/AMQ-5388 Fix user permissions in web console (cherry picked from commit c67ada04c77e9379ef25ac62d5ea1fcf20cf8b8f) > User Role Granted Full Privileges in jetty.xml > -- > > Key: AMQ-5388 > URL: https://issues.apache.org/jira/browse/AMQ-5388 > Project: ActiveMQ > Issue Type: Bug > Components: Web Console >Affects Versions: 5.9.0 > Environment: Any >Reporter: Justin Reock >Assignee: Jean-Baptiste Onofré >Priority: Minor > Labels: jetty, security, web-console > Fix For: 5.17.0, 5.16.4 > > > The default ConstraintMapping for the "user" role grants privileges to > /admin/*, which supersedes the *.action constraint that is supposed to be > granted only to the admin role. > The current pathspec for the user role reads: > > By granting access to /admin/*, that in turn grants access to all of the > *.action URLs, essentially nullifying the attempt to restrict *.action URLs > to only the admin role. > To repeat, just log in as the default "user/user" account to the web console > and add or delete destinations. > Workaround is to change the pathSpec to: > > Which allows access to the console but disallows access to the *.action URLs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (AMQ-5388) User Role Granted Full Privileges in jetty.xml
[ https://issues.apache.org/jira/browse/AMQ-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478810#comment-17478810 ] ASF subversion and git services commented on AMQ-5388: -- Commit c67ada04c77e9379ef25ac62d5ea1fcf20cf8b8f in activemq's branch refs/heads/main from Vilius Šumskas [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=c67ada0 ] https://issues.apache.org/jira/browse/AMQ-5388 Fix user permissions in web console > User Role Granted Full Privileges in jetty.xml > -- > > Key: AMQ-5388 > URL: https://issues.apache.org/jira/browse/AMQ-5388 > Project: ActiveMQ > Issue Type: Bug > Components: Web Console >Affects Versions: 5.9.0 > Environment: Any >Reporter: Justin Reock >Assignee: Jean-Baptiste Onofré >Priority: Minor > Labels: jetty, security, web-console > Fix For: 5.17.0, 5.16.4 > > > The default ConstraintMapping for the "user" role grants privileges to > /admin/*, which supersedes the *.action constraint that is supposed to be > granted only to the admin role. > The current pathspec for the user role reads: > > By granting access to /admin/*, that in turn grants access to all of the > *.action URLs, essentially nullifying the attempt to restrict *.action URLs > to only the admin role. > To repeat, just log in as the default "user/user" account to the web console > and add or delete destinations. > Workaround is to change the pathSpec to: > > Which allows access to the console but disallows access to the *.action URLs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3638) Support MQTT 5
[ https://issues.apache.org/jira/browse/ARTEMIS-3638?focusedWorklogId=711490=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711490 ] ASF GitHub Bot logged work on ARTEMIS-3638: --- Author: ASF GitHub Bot Created on: 19/Jan/22 16:44 Start Date: 19/Jan/22 16:44 Worklog Time Spent: 10m Work Description: gtully commented on pull request #3907: URL: https://github.com/apache/activemq-artemis/pull/3907#issuecomment-1016656322 @jbertram looking to resolve the merge conflict via the gh ui, seems not to have the desired effect. sorry! Maybe you do a rebase and resolve against main and force push from your local branch and whack my merge from main. I won't attempt that again any time soon :-) -- 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: 711490) Time Spent: 20m (was: 10m) > Support MQTT 5 > -- > > Key: ARTEMIS-3638 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3638 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- 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=711477=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711477
]
ASF GitHub Bot logged work on ARTEMIS-3573:
---
Author: ASF GitHub Bot
Created on: 19/Jan/22 16:28
Start Date: 19/Jan/22 16:28
Worklog Time Spent: 10m
Work Description: brusdev commented on a change in pull request #3851:
URL: https://github.com/apache/activemq-artemis/pull/3851#discussion_r787927355
##
File path:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/LazyHashProcessor.java
##
@@ -0,0 +1,63 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.activemq.artemis.utils;
+
+public abstract class LazyHashProcessor implements HashProcessor {
+ private volatile HashProcessor hashProcessor;
+ private volatile RuntimeException supplierException;
+
+ public HashProcessor getHashProcessor() {
+ if (supplierException != null) {
+ throw supplierException;
+ }
+
+ if (hashProcessor == null) {
+ synchronized (this) {
+if (supplierException != null) {
+ throw supplierException;
+}
+
+if (hashProcessor == null) {
+ try {
+ hashProcessor = createHashProcessor();
+ } catch (RuntimeException e) {
+ supplierException = e;
+ throw supplierException;
+ } catch (Exception e) {
+ supplierException = new RuntimeException(e);
+ throw supplierException;
+ }
+}
+ }
+ }
+
+ return hashProcessor;
+ }
Review comment:
@franz1981 @gemmellr thanks I replaced the getHashProcessor with the
MemoizingSupplier.
--
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: 711477)
Time Spent: 5h 10m (was: 5h)
> 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: 5h 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] [Assigned] (AMQ-5388) User Role Granted Full Privileges in jetty.xml
[ https://issues.apache.org/jira/browse/AMQ-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned AMQ-5388: - Assignee: Jean-Baptiste Onofré (was: Matt Pavlovich) > User Role Granted Full Privileges in jetty.xml > -- > > Key: AMQ-5388 > URL: https://issues.apache.org/jira/browse/AMQ-5388 > Project: ActiveMQ > Issue Type: Bug > Components: Web Console >Affects Versions: 5.9.0 > Environment: Any >Reporter: Justin Reock >Assignee: Jean-Baptiste Onofré >Priority: Minor > Labels: jetty, security, web-console > Fix For: 5.17.0, 5.16.4 > > > The default ConstraintMapping for the "user" role grants privileges to > /admin/*, which supersedes the *.action constraint that is supposed to be > granted only to the admin role. > The current pathspec for the user role reads: > > By granting access to /admin/*, that in turn grants access to all of the > *.action URLs, essentially nullifying the attempt to restrict *.action URLs > to only the admin role. > To repeat, just log in as the default "user/user" account to the web console > and add or delete destinations. > Workaround is to change the pathSpec to: > > Which allows access to the console but disallows access to the *.action URLs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (AMQ-8451) Message URL Host is incorrect
[ https://issues.apache.org/jira/browse/AMQ-8451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated AMQ-8451: -- Fix Version/s: 5.17.0 5.16.4 > Message URL Host is incorrect > - > > Key: AMQ-8451 > URL: https://issues.apache.org/jira/browse/AMQ-8451 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.16.2 >Reporter: Varun Ramachandran >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.17.0, 5.16.4 > > > After I upgraded the Active MQ client version from 5.15.12 to 5.16.2 in our > pom.xml, I encounter the below exception for Blob Messages. I tried upgrading > to 5.16.3 and find the same problem > *Exception* > _java.io.IOException: The message URL host is incorrect_ > _at > org.apache.activemq.blob.DefaultBlobDownloadStrategy.getInputStream(DefaultBlobDownloadStrategy.java:51)_ > _at > org.apache.activemq.blob.BlobDownloader.getInputStream(BlobDownloader.java:38)_ > _at > org.apache.activemq.command.ActiveMQBlobMessage.getInputStream(ActiveMQBlobMessage.java:132)_ > > The URL host of our message is same for both the versions, however it just > gives an exception for the 5.16.2 version. > http://blob-service:8080/blob/ID > ID Masked > Thanks in advance! > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3622) MQTT can deadlock on client connection / disconnection
[
https://issues.apache.org/jira/browse/ARTEMIS-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478786#comment-17478786
]
Marcelo Takeshi Fukushima commented on ARTEMIS-3622:
I think I've found the problem but unfortunately I cannot write a consistently
failing test case. Basically it goes like this:
Thread-1 starts connection, which creates a new MQTTSession with a default
MQTTSessionState but stalls or starves (either way, pauses for a bit)
The failure-detector-thread kicks in and thinks that the connection created by
1 has failed* so initiates MQTTConnectionManager.disconnect. In it, it
synchronizes over the MQTTSessionState of that MQTTConnection but that is still
the MQTTSessionState.DEFAULT instance (clientId == null). It them proceedes to
clean up and enters MQTTSession.stop, a synchronized method. This thread now
holds both the MQTTSessionState.DEFAULT and MQTTSession monitors but before it
proceedes further, it gets swapped out.
Thread-1 'resumes' and, in the MQTTConnectionManager.connect, gets either a
brand new MQTTSessionState or an existing one from the MQTTProtocolManager. It
them synchronizes over this new MQTTSessionState and updates the MQTTSession
with the 'correct' MQTTSessionState. Finally, it proceedes to start the session
by calling MQTTSession.start, which is synchronized but cannot proceed since
the failure-detector-thread still holds the monitor for the MQTTSession and
thread-1 is now blocked holding the monitor for the MQTTSessionState that is
inside the MQTTSession.
The failure-detector-thread tries to resume the MQTTSession.stop, eventually
calling MQTTSession.clear, a synchronized method. But this MQTTSession is not
the same as the one that it held the monitor to, so it blocks waiting for
Thread-1 and we get our deadlock.
* - this is the part that I'm unsure about. I'm not sure why the failure
detector kicks in for a freshly created connection. Either way, I think the
deadlock is a bug.
Now, I can see some ways this can be fixed:
1 - mark all mutator methods on MQTTSession as synchronized. That would, in
theory, protect against thread-1 swapping the MQTTSessionState while the
failure detector holds the session. This looks weird to me, but not weirder
than the current version just because you can mutate the MQTTSession in weird
ways if it is shared by multiple threads (each mutator method can advance at
its own pace and they may be inconsistent).
2 - mark MQTTConnectionManager.connect and disconnect as synchronized. This
will effectively make connection and disconnection exclusive. This looks better
to me, but I don't know the implications - it may create more deadlocks down
the road.
3 - only create the MQTTSession after the 'correct' MQTTSessionState has been
created / retrieved and maybe mark the field as final for good measure. This is
the most disruptive change (will change a large number of classes) but it looks
to me the most 'correct' (but again, I'm not familiar with the code so this is
just my guess).
I can provide a pull request for 1 and 2 and I can give a shot at 3 if you all
think it would be better.
Thanks a bunch
takeshi
> MQTT can deadlock on client connection / disconnection
> --
>
> Key: ARTEMIS-3622
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3622
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: MQTT
>Affects Versions: 2.19.0
> Environment: Using the latest java 17 and artemis 2.19 but looking at
> the code, it should affect 2.20 as well.
>Reporter: Marcelo Takeshi Fukushima
>Priority: Major
>
> It seems that the {{MQTTProtocolHandler}} and {{MQTTConnectionManager}} are
> on a racing condition and can deadlock themselves on misbehaving clients. I'm
> including the relevant stack trace (ignore thread 11 that is just waiting for
> the lock).
> Looking at the relevant code, it seems that the clean-up thread (88 on the
> {{{}MQTTFailureListener{}}}) starts cleaning up the session state and then
> the session, but when {{MQTTSession.stop}} calls
> {{{}MQTTSessionState.clear{}}}, the session state is no longer the same (a
> racy connection has replaced the session state with a brand new under the
> same client-id).
> I think the methods connect and disconnect on the {{MQTTConnectionManager}}
> could be marked as synchronized as a whole, to prevent racy connects /
> disconnects (but since I don't know all the ins and outs of the code, you
> guys might have a better fix).
> {noformat}
> Found one Java-level deadlock:
> =
> "Thread-11
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@640f11a1)":
> waiting to lock monitor 0x7f6d003368c0 (object 0x00045f29f240, a
>
[jira] [Resolved] (ARTEMIS-3525) Empty Auto created queues should be removed right away
[ https://issues.apache.org/jira/browse/ARTEMIS-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-3525. - Resolution: Fixed > Empty Auto created queues should be removed right away > -- > > Key: ARTEMIS-3525 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3525 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > this is a borderline between a bug and an improvement. > The broker should check for empty auto-created queues upon restart. Empty > auto-created queues should be removed right away. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] (ARTEMIS-3525) Empty Auto created queues should be removed right away
[ https://issues.apache.org/jira/browse/ARTEMIS-3525 ] Gary Tully deleted comment on ARTEMIS-3525: - was (Author: gemmellr): I dont have permissions to remove the comment, so just noting: the above mentioned commit 11a0c000475d2769d9c91df36c56b25a407fda2 to 2.19.x was dropped from the branch and so has not been backported as it seems to suggest. > Empty Auto created queues should be removed right away > -- > > Key: ARTEMIS-3525 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3525 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > this is a borderline between a bug and an improvement. > The broker should check for empty auto-created queues upon restart. Empty > auto-created queues should be removed right away. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] (ARTEMIS-3525) Empty Auto created queues should be removed right away
[ https://issues.apache.org/jira/browse/ARTEMIS-3525 ] Gary Tully deleted comment on ARTEMIS-3525: - was (Author: jira-bot): Commit c11a0c000475d2769d9c91df36c56b25a407fda2 in activemq-artemis's branch refs/heads/2.19.x from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c11a0c0 ] ARTEMIS-3525 Empty Auto Created queues should be removed on restart (cherry picked from commit 2383aa0125320713b9a753668b203a878c24b2e0) > Empty Auto created queues should be removed right away > -- > > Key: ARTEMIS-3525 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3525 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > this is a borderline between a bug and an improvement. > The broker should check for empty auto-created queues upon restart. Empty > auto-created queues should be removed right away. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (ARTEMIS-3525) Empty Auto created queues should be removed right away
[ https://issues.apache.org/jira/browse/ARTEMIS-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully reopened ARTEMIS-3525: - > Empty Auto created queues should be removed right away > -- > > Key: ARTEMIS-3525 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3525 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > this is a borderline between a bug and an improvement. > The broker should check for empty auto-created queues upon restart. Empty > auto-created queues should be removed right away. -- 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=711420=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711420
]
ASF GitHub Bot logged work on ARTEMIS-3573:
---
Author: ASF GitHub Bot
Created on: 19/Jan/22 14:43
Start Date: 19/Jan/22 14:43
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_r787801385
##
File path:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/LazyHashProcessor.java
##
@@ -0,0 +1,63 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.activemq.artemis.utils;
+
+public abstract class LazyHashProcessor implements HashProcessor {
+ private volatile HashProcessor hashProcessor;
+ private volatile RuntimeException supplierException;
+
+ public HashProcessor getHashProcessor() {
+ if (supplierException != null) {
+ throw supplierException;
+ }
+
+ if (hashProcessor == null) {
+ synchronized (this) {
+if (supplierException != null) {
+ throw supplierException;
+}
+
+if (hashProcessor == null) {
+ try {
+ hashProcessor = createHashProcessor();
+ } catch (RuntimeException e) {
+ supplierException = e;
+ throw supplierException;
+ } catch (Exception e) {
+ supplierException = new RuntimeException(e);
+ throw supplierException;
+ }
+}
+ }
+ }
+
+ return hashProcessor;
+ }
Review comment:
```suggestion
public abstract class LazyHashProcessor implements HashProcessor {
private volatile HashProcessor hashProcessor;
private RuntimeException supplierException;
public HashProcessor getHashProcessor() {
HashProcessor hp = hashProcessor;
if (hp == null) {
synchronized (this) {
if (supplierException != null) {
throw supplierException;
}
hp = hashProcessor;
if (hp == null) {
try {
hashProcessor = hp = createHashProcessor();
} catch (RuntimeException e) {
supplierException = e;
throw supplierException;
} catch (Exception e) {
supplierException = new RuntimeException(e);
throw supplierException;
}
}
}
}
return hp;
}
```
I think the initial if (supplierException != null) bit can just be removed,
and that field doesnt then need to be volatile as its then only used under
synchronization. The exception will only be non-null if hashProcessor is still
null, and whole the idea is to typically not expect it to be null, so it seems
unnecessary to pre-check the exception every time through. It can just rely on
the check at the start of the synchronized block.
I think it should also use the local variable to copy hashProcessor to as
typically expected in these cases.
Something like the suggestion (didnt check it compiles).
--
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: 711420)
Time Spent: 5h (was: 4h 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
>
[jira] [Work logged] (AMQ-8274) Pass sortColumnId and sortOrder to console via url parameters
[ https://issues.apache.org/jira/browse/AMQ-8274?focusedWorklogId=711419=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711419 ] ASF GitHub Bot logged work on AMQ-8274: --- Author: ASF GitHub Bot Created on: 19/Jan/22 14:41 Start Date: 19/Jan/22 14:41 Worklog Time Spent: 10m Work Description: mattrpav commented on pull request #655: URL: https://github.com/apache/activemq/pull/655#issuecomment-1016532008 I’m working on tasks to get into 5.16.4. This is one. Should be within the next week. Thanks! -- 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: 711419) Time Spent: 1h (was: 50m) > Pass sortColumnId and sortOrder to console via url parameters > - > > Key: AMQ-8274 > URL: https://issues.apache.org/jira/browse/AMQ-8274 > Project: ActiveMQ > Issue Type: New Feature > Components: Web Console >Reporter: Max >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 5.17.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Pass sortColumnId and sortOrder to console via url parameters. > This is convenient for visual monitoring of dequeued message counts over time. > > Current web console always sorts by name and there is no way to pass > preferred sort order. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (ARTEMIS-3627) Allow properties to configure 'new' broker attributes and load from a file
[ https://issues.apache.org/jira/browse/ARTEMIS-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-3627. - Resolution: Fixed > Allow properties to configure 'new' broker attributes and load from a file > -- > > Key: ARTEMIS-3627 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3627 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.20.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.21.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Following up on ARTEMIS-851, where simple set attributes can be overridden > via system properties. This enhancement will allow properties to be loaded > from broker.properties and allow additions to lists and maps. > The additions to the collections require some naming convention. Many of the > elements already support a name attribute and this can be used to locate and > or create new entries. > The idea is that a plain broker can be augmented with the presence of a > properties file to add a new acceptor called "tcp" using properties of the > form: > acceptorConfigurations.tcp.params.host=localhost > acceptorConfigurations.tcp.params.port=61616 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3627) Allow properties to configure 'new' broker attributes and load from a file
[ https://issues.apache.org/jira/browse/ARTEMIS-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478721#comment-17478721 ] ASF subversion and git services commented on ARTEMIS-3627: -- Commit 10d93d9c92f1b0f276c88a8b782152af596cd7da in activemq-artemis's branch refs/heads/main from gtully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=10d93d9 ] ARTEMIS-3627 - support broker.properties for augmenting or supplying additional configuration via nested properties of the internal configuratinimpl bean - elements with a name attribute can be configured in collections, the type inferred by the add singular fluent api > Allow properties to configure 'new' broker attributes and load from a file > -- > > Key: ARTEMIS-3627 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3627 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.20.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.21.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Following up on ARTEMIS-851, where simple set attributes can be overridden > via system properties. This enhancement will allow properties to be loaded > from broker.properties and allow additions to lists and maps. > The additions to the collections require some naming convention. Many of the > elements already support a name attribute and this can be used to locate and > or create new entries. > The idea is that a plain broker can be augmented with the presence of a > properties file to add a new acceptor called "tcp" using properties of the > form: > acceptorConfigurations.tcp.params.host=localhost > acceptorConfigurations.tcp.params.port=61616 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3627) Allow properties to configure 'new' broker attributes and load from a file
[ https://issues.apache.org/jira/browse/ARTEMIS-3627?focusedWorklogId=711417=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711417 ] ASF GitHub Bot logged work on ARTEMIS-3627: --- Author: ASF GitHub Bot Created on: 19/Jan/22 14:39 Start Date: 19/Jan/22 14:39 Worklog Time Spent: 10m Work Description: gtully merged pull request #3904: URL: https://github.com/apache/activemq-artemis/pull/3904 -- 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: 711417) Time Spent: 2h 10m (was: 2h) > Allow properties to configure 'new' broker attributes and load from a file > -- > > Key: ARTEMIS-3627 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3627 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.20.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.21.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Following up on ARTEMIS-851, where simple set attributes can be overridden > via system properties. This enhancement will allow properties to be loaded > from broker.properties and allow additions to lists and maps. > The additions to the collections require some naming convention. Many of the > elements already support a name attribute and this can be used to locate and > or create new entries. > The idea is that a plain broker can be augmented with the presence of a > properties file to add a new acceptor called "tcp" using properties of the > form: > acceptorConfigurations.tcp.params.host=localhost > acceptorConfigurations.tcp.params.port=61616 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (AMQ-8274) Pass sortColumnId and sortOrder to console via url parameters
[ https://issues.apache.org/jira/browse/AMQ-8274?focusedWorklogId=711398=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711398 ] ASF GitHub Bot logged work on AMQ-8274: --- Author: ASF GitHub Bot Created on: 19/Jan/22 14:00 Start Date: 19/Jan/22 14:00 Worklog Time Spent: 10m Work Description: maxfortun commented on pull request #655: URL: https://github.com/apache/activemq/pull/655#issuecomment-1016492262 How do I get this PR merged in? -- 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: 711398) Time Spent: 50m (was: 40m) > Pass sortColumnId and sortOrder to console via url parameters > - > > Key: AMQ-8274 > URL: https://issues.apache.org/jira/browse/AMQ-8274 > Project: ActiveMQ > Issue Type: New Feature > Components: Web Console >Reporter: Max >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 5.17.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Pass sortColumnId and sortOrder to console via url parameters. > This is convenient for visual monitoring of dequeued message counts over time. > > Current web console always sorts by name and there is no way to pass > preferred sort order. -- 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=711384=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711384
]
ASF GitHub Bot logged work on ARTEMIS-3573:
---
Author: ASF GitHub Bot
Created on: 19/Jan/22 13:43
Start Date: 19/Jan/22 13:43
Worklog Time Spent: 10m
Work Description: brusdev commented on a change in pull request #3851:
URL: https://github.com/apache/activemq-artemis/pull/3851#discussion_r787756420
##
File path:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/LazyHashProcessor.java
##
@@ -0,0 +1,63 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.activemq.artemis.utils;
+
+public abstract class LazyHashProcessor implements HashProcessor {
+ private HashProcessor hashProcessor;
+ private RuntimeException supplierException;
+
+ public HashProcessor getHashProcessor() {
+ if (supplierException != null) {
+ throw supplierException;
+ }
+
+ if (hashProcessor == null) {
+ synchronized (this) {
+if (supplierException != null) {
+ throw supplierException;
+}
+
+if (hashProcessor == null) {
+ try {
+ hashProcessor = createHashProcessor();
+ } catch (RuntimeException e) {
+ supplierException = e;
+ throw supplierException;
+ } catch (Exception e) {
+ supplierException = new RuntimeException(e);
+ throw supplierException;
+ }
+}
+ }
+ }
Review comment:
fixed
--
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: 711384)
Time Spent: 4h 50m (was: 4h 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: 4h 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=711373=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711373
]
ASF GitHub Bot logged work on ARTEMIS-3573:
---
Author: ASF GitHub Bot
Created on: 19/Jan/22 13:04
Start Date: 19/Jan/22 13:04
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_r787723700
##
File path:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/LazyHashProcessor.java
##
@@ -0,0 +1,63 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.activemq.artemis.utils;
+
+public abstract class LazyHashProcessor implements HashProcessor {
+ private HashProcessor hashProcessor;
+ private RuntimeException supplierException;
+
+ public HashProcessor getHashProcessor() {
+ if (supplierException != null) {
+ throw supplierException;
+ }
+
+ if (hashProcessor == null) {
+ synchronized (this) {
+if (supplierException != null) {
+ throw supplierException;
+}
+
+if (hashProcessor == null) {
+ try {
+ hashProcessor = createHashProcessor();
+ } catch (RuntimeException e) {
+ supplierException = e;
+ throw supplierException;
+ } catch (Exception e) {
+ supplierException = new RuntimeException(e);
+ throw supplierException;
+ }
+}
+ }
+ }
Review comment:
This will still be non-thread-safe because the hashProcessor field isnt
volatile (prior to the synchronized addition the other one would have needed to
be also).
https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java
--
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: 711373)
Time Spent: 4h 40m (was: 4.5h)
> 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: 4h 40m
> 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] [Commented] (ARTEMIS-3260) Already consumed messages are redelivered after server restart (possible Journal corruption)
[
https://issues.apache.org/jira/browse/ARTEMIS-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478651#comment-17478651
]
Alexander Andreevich Revkov commented on ARTEMIS-3260:
--
Maybe it is link with ARTEMIS-3312 ?
> Already consumed messages are redelivered after server restart (possible
> Journal corruption)
>
>
> Key: ARTEMIS-3260
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3260
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.17.0
> Environment: Embedded Apache Artemis 2.17.0
> Windows Server 2016 Standard (10.0.14393)
> Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
>Reporter: Christian Danner
>Priority: Blocker
> Attachments: ExampleClient.java, PagingStoreImpl.java,
> QueueImpl.java, activemq_artemis.log, broker.xml, broker.zip,
> restart_log_1_no_recovery-2021-04-22_08.46.52.log,
> restart_log_2_recovery-2021-04-22_08.48.49.log
>
>
> After upgrading from Artemis 2.15.0 to 2.17.0 we are experiencing situations
> (non-deterministic but quite regular) where the embedded Apache Artemis
> instance re-delivers messages to a client again after a server restart.
> Those messages were already processed successfully before restart and the web
> console shows a message count of 0 prior to restarting the process.
> It is also important to note once those stuck messages (which seemingly
> appear from out of nowhere) have been reprocessed newly added messages are
> processed just fine - so what we are seeing is the following:
> # At some point in time messages A,B,C were routed to Queue Q and
> successfully consumed
> # Q is empty (web console)
> # perform broker restart
> # client consumes A,B,C from Q again
> # Q is empty (web console)
> # another client sends X,Y,Z to Q
> # client consumes X,Y,Z
> # Q is empty (web console)
> # perform broker restart
> # client consumes A,B,C from Q again!
> This happens again and again on each boker restart up to a point where the
> broker finally manages to recover from this situation by detecting an invalid
> (negative) address size as indicated by the following log output:
> {quote}2021-04-22 21:04:51.897 WARN
> org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.addSize(PagingStoreImpl.java:753)
> [Thread-1
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@26bb92e2)]
> {quote}
> {quote}[ARTEMIS] AMQ14: Destination incoming.message has an inconsistent
> and negative address size=-3,379.
> {quote}
> {quote}2021-04-22 21:04:51.897 WARN
> org.apache.activemq.artemis.core.paging.impl.PagingStoreImpl.addSize(PagingStoreImpl.java:753)
> [Thread-1
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@26bb92e2)]
> {quote}
> {quote}[ARTEMIS] AMQ14: Destination incoming.message has an inconsistent
> and negative address size=-3,451.
> {quote}
>
> The full log file of such a situation (where the broker managed to recover)
> is attached together with the broker.xml file that we use as a template to
> configure the embedded instance programmatically.
> The broker runs embedded with the client which consumes messages via AMQP
> using the Apache QPID library (JMS2.0 - v0.57.0) - there is only a single
> Thread ever consuming from a queue and we use transactions to explicitly
> commit or rollback received messages with prefetch disabled
> (jms.prefetchPolicy.all=0)
> Further investigation / debugging has shown that when messages are
> redelivered the above log outputs concerning the negative address size are
> absent and the reason is that the value returned by
> messageReference.getMessageMemoryEstimate() is different for the exact same
> message in line 1022 of class
> org.apache.activemq.artemis.core.server.impl.QueueImpl.
> This difference stems from a different value being calculated in
> AMQPStandardMessage class (getMemoryEstimate()) and the difference is equal
> to the value returned by
> unmarshalledApplicationPropertiesMemoryEstimateFromData() so I assume that
> the applicationProperties are sometimes not being considered (I still have to
> verify this).
> I can also provide the complete broker journal for such a situation which we
> currently use for debugging if this helps to analyze the issue (approx. ~25MB
> of files, compressed ~100kB)
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3627) Allow properties to configure 'new' broker attributes and load from a file
[ https://issues.apache.org/jira/browse/ARTEMIS-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-3627: Description: Following up on ARTEMIS-851, where simple set attributes can be overridden via system properties. This enhancement will allow properties to be loaded from broker.properties and allow additions to lists and maps. The additions to the collections require some naming convention. Many of the elements already support a name attribute and this can be used to locate and or create new entries. The idea is that a plain broker can be augmented with the presence of a properties file to add a new acceptor called "tcp" using properties of the form: acceptorConfigurations.tcp.params.host=localhost acceptorConfigurations.tcp.params.port=61616 was: Following up on ARTEMIS-851, where simple set attributes can be overridden via system properties. This enhancement will allow properties to be loaded from broker.properties and allow additions to lists and maps. The additions to the collections require some naming convention. Many of the elements already support a name attribute and this can be used to locate and or create new entries. The idea is that a plain broker can be augmented with the presence of a properties file to add a new acceptor called "tcp" using properties of the form: acceptorConfigurations.tcp.params.HOST=localhost acceptorConfigurations.tcp.params.PORT=61616 > Allow properties to configure 'new' broker attributes and load from a file > -- > > Key: ARTEMIS-3627 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3627 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.20.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.21.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Following up on ARTEMIS-851, where simple set attributes can be overridden > via system properties. This enhancement will allow properties to be loaded > from broker.properties and allow additions to lists and maps. > The additions to the collections require some naming convention. Many of the > elements already support a name attribute and this can be used to locate and > or create new entries. > The idea is that a plain broker can be augmented with the presence of a > properties file to add a new acceptor called "tcp" using properties of the > form: > acceptorConfigurations.tcp.params.host=localhost > acceptorConfigurations.tcp.params.port=61616 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3627) Allow properties to configure 'new' broker attributes and load from a file
[ https://issues.apache.org/jira/browse/ARTEMIS-3627?focusedWorklogId=711303=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711303 ] ASF GitHub Bot logged work on ARTEMIS-3627: --- Author: ASF GitHub Bot Created on: 19/Jan/22 11:20 Start Date: 19/Jan/22 11:20 Worklog Time Spent: 10m Work Description: gtully commented on pull request #3904: URL: https://github.com/apache/activemq-artemis/pull/3904#issuecomment-1016358585 made it such that the mapped collection(key) can retrieve an existing entry, but still won't auto create. collection.key will auto create. -- 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: 711303) Time Spent: 2h (was: 1h 50m) > Allow properties to configure 'new' broker attributes and load from a file > -- > > Key: ARTEMIS-3627 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3627 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.20.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.21.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Following up on ARTEMIS-851, where simple set attributes can be overridden > via system properties. This enhancement will allow properties to be loaded > from broker.properties and allow additions to lists and maps. > The additions to the collections require some naming convention. Many of the > elements already support a name attribute and this can be used to locate and > or create new entries. > The idea is that a plain broker can be augmented with the presence of a > properties file to add a new acceptor called "tcp" using properties of the > form: > acceptorConfigurations.tcp.params.HOST=localhost > acceptorConfigurations.tcp.params.PORT=61616 -- 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=711258=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711258
]
ASF GitHub Bot logged work on ARTEMIS-3573:
---
Author: ASF GitHub Bot
Created on: 19/Jan/22 10:28
Start Date: 19/Jan/22 10:28
Worklog Time Spent: 10m
Work Description: brusdev commented on a change in pull request #3851:
URL: https://github.com/apache/activemq-artemis/pull/3851#discussion_r787597367
##
File path:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/LazyHashProcessor.java
##
@@ -0,0 +1,55 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.activemq.artemis.utils;
+
+public abstract class LazyHashProcessor implements HashProcessor {
+ private HashProcessor hashProcessor;
+ private RuntimeException supplierException;
+
+ public HashProcessor getHashProcessor() {
+ if (supplierException != null) {
+ throw supplierException;
+ }
+
+ if (hashProcessor == null) {
+ try {
+hashProcessor = createHashProcessor();
+ } catch (RuntimeException e) {
+supplierException = e;
+throw supplierException;
+ } catch (Exception e) {
+supplierException = new RuntimeException(e);
+throw supplierException;
+ }
+ }
+
+ return hashProcessor;
+ }
Review comment:
fixed
--
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: 711258)
Time Spent: 4.5h (was: 4h 20m)
> 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: 4.5h
> 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] [Commented] (ARTEMIS-3649) OpenWire consumers with zero prefetch get stuck
[ https://issues.apache.org/jira/browse/ARTEMIS-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478528#comment-17478528 ] ASF subversion and git services commented on ARTEMIS-3649: -- Commit 9c01f9b983976ea38bacfca98fbdebe2b7fef035 in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=9c01f9b ] ARTEMIS-3649 Fix zero prefetch OpenWire consumers > OpenWire consumers with zero prefetch get stuck > --- > > Key: ARTEMIS-3649 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3649 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Execute org.apache.activemq.ZeroPrefetchConsumerTest to reproduce the issue. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3649) OpenWire consumers with zero prefetch get stuck
[ https://issues.apache.org/jira/browse/ARTEMIS-3649?focusedWorklogId=711242=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711242 ] ASF GitHub Bot logged work on ARTEMIS-3649: --- Author: ASF GitHub Bot Created on: 19/Jan/22 10:14 Start Date: 19/Jan/22 10:14 Worklog Time Spent: 10m Work Description: gtully merged pull request #3918: URL: https://github.com/apache/activemq-artemis/pull/3918 -- 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: 711242) Time Spent: 20m (was: 10m) > OpenWire consumers with zero prefetch get stuck > --- > > Key: ARTEMIS-3649 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3649 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Execute org.apache.activemq.ZeroPrefetchConsumerTest to reproduce the issue. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3649) OpenWire consumers with zero prefetch get stuck
[
https://issues.apache.org/jira/browse/ARTEMIS-3649?focusedWorklogId=711239=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711239
]
ASF GitHub Bot logged work on ARTEMIS-3649:
---
Author: ASF GitHub Bot
Created on: 19/Jan/22 10:10
Start Date: 19/Jan/22 10:10
Worklog Time Spent: 10m
Work Description: gtully commented on a change in pull request #3918:
URL: https://github.com/apache/activemq-artemis/pull/3918#discussion_r787577622
##
File path:
artemis-protocols/artemis-openwire-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/openwire/amq/AMQConsumer.java
##
@@ -232,11 +232,24 @@ public ConsumerId getId() {
return info.getConsumerId();
}
- public void acquireCredit(int n) {
+ public void acquireCredit(int n, boolean delivered) {
if (messagePullHandler.get() != null) {
//don't acquire any credits when the pull handler controls it!!
return;
}
+
+ if (delivered) {
+ deliveredAcksCreditExtension += n;
+ } else if (deliveredAcksCreditExtension > 0) {
Review comment:
that is better, now the normal deliveredAcksCreditExtension == 0 branch
is clear
--
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: 711239)
Remaining Estimate: 0h
Time Spent: 10m
> OpenWire consumers with zero prefetch get stuck
> ---
>
> Key: ARTEMIS-3649
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3649
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Execute org.apache.activemq.ZeroPrefetchConsumerTest to reproduce the issue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (AMQ-7426) Upgrade to log4j2
[ https://issues.apache.org/jira/browse/AMQ-7426?focusedWorklogId=711162=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-711162 ] ASF GitHub Bot logged work on AMQ-7426: --- Author: ASF GitHub Bot Created on: 19/Jan/22 08:17 Start Date: 19/Jan/22 08:17 Worklog Time Spent: 10m Work Description: jbonofre commented on pull request #662: URL: https://github.com/apache/activemq/pull/662#issuecomment-1016188305 Runtime/assembly works fine. Now I have to fix some tests which are using log4j (logger/appender). -- 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: 711162) Time Spent: 4h 20m (was: 4h 10m) > Upgrade to log4j2 > - > > Key: AMQ-7426 > URL: https://issues.apache.org/jira/browse/AMQ-7426 > Project: ActiveMQ > Issue Type: Task > Components: Broker >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.17.0 > > Time Spent: 4h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
