[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[ https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668098=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668098 ] ASF GitHub Bot logged work on ARTEMIS-3523: --- Author: ASF GitHub Bot Created on: 21/Oct/21 05:30 Start Date: 21/Oct/21 05:30 Worklog Time Spent: 10m Work Description: nbrendah edited a comment on pull request #3801: URL: https://github.com/apache/activemq-artemis/pull/3801#issuecomment-948269393 @clebertsuconic I honestly cant thank you enough, but i appreciate the time you have invested in this. I have added more changes. I hope its fine now. Have a good night. > `mvn -Pdev install -Derrorprone` This is a good command because it even checks style guide conventions. I received a build success locally. Let me wait for that on upstream -- 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: 668098) Time Spent: 3h 50m (was: 3h 40m) > Expose replay through AddressControl > > > Key: ARTEMIS-3523 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3523 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > Time Spent: 3h 50m > Remaining Estimate: 0h > > Currently there is a method replay on ActiveMQServer with the following > signature: > replay(address, .) > it should be a lot easier for our users to implement a method replay on the > ActiveMQServerControl > such method should just call server.replay(this.address, .) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[ https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668097=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668097 ] ASF GitHub Bot logged work on ARTEMIS-3523: --- Author: ASF GitHub Bot Created on: 21/Oct/21 05:26 Start Date: 21/Oct/21 05:26 Worklog Time Spent: 10m Work Description: nbrendah commented on pull request #3801: URL: https://github.com/apache/activemq-artemis/pull/3801#issuecomment-948269393 @clebertsuconic I honestly cant thank you enough, but i appreciate the time you have invested in this. I have added more changes. I hope its fine now. Have a good night. -- 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: 668097) Time Spent: 3h 40m (was: 3.5h) > Expose replay through AddressControl > > > Key: ARTEMIS-3523 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3523 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently there is a method replay on ActiveMQServer with the following > signature: > replay(address, .) > it should be a lot easier for our users to implement a method replay on the > ActiveMQServerControl > such method should just call server.replay(this.address, .) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[ https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668086=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668086 ] ASF GitHub Bot logged work on ARTEMIS-3523: --- Author: ASF GitHub Bot Created on: 21/Oct/21 04:12 Start Date: 21/Oct/21 04:12 Worklog Time Spent: 10m Work Description: clebertsuconic edited a comment on pull request #3801: URL: https://github.com/apache/activemq-artemis/pull/3801#issuecomment-948241083 also, next time you mvn build, use the -Pdev profile at least once.. it takes some extra time, but it will run the check style.. etc... the -Derrorprone may also help with the PR checks to make sure it passes it. ``` mvn -Pdev install -Derrorprone ``` One thing I do all the time to not run tests: ``` mvn -Pdev install -DskipTests=true -Derrorprone ``` I actually have an alias on my OS to those scripts... -- 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: 668086) Time Spent: 3.5h (was: 3h 20m) > Expose replay through AddressControl > > > Key: ARTEMIS-3523 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3523 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > Time Spent: 3.5h > Remaining Estimate: 0h > > Currently there is a method replay on ActiveMQServer with the following > signature: > replay(address, .) > it should be a lot easier for our users to implement a method replay on the > ActiveMQServerControl > such method should just call server.replay(this.address, .) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[ https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668085=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668085 ] ASF GitHub Bot logged work on ARTEMIS-3523: --- Author: ASF GitHub Bot Created on: 21/Oct/21 04:12 Start Date: 21/Oct/21 04:12 Worklog Time Spent: 10m Work Description: clebertsuconic edited a comment on pull request #3801: URL: https://github.com/apache/activemq-artemis/pull/3801#issuecomment-948241083 also, next time you mvn build, use the -Pdev profile at least once.. it takes some extra time, but it will run the check style.. etc... the -Derrorprone may also help with the PR checks to make sure it passes it. ``` mvn -Pdev install -Derrorprone ``` One thing I do all the time: ``` mvn -Pdev install -DskipTests=true -Derrorprone ``` I actually have an alias on my OS to those scripts... -- 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: 668085) Time Spent: 3h 20m (was: 3h 10m) > Expose replay through AddressControl > > > Key: ARTEMIS-3523 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3523 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > Time Spent: 3h 20m > Remaining Estimate: 0h > > Currently there is a method replay on ActiveMQServer with the following > signature: > replay(address, .) > it should be a lot easier for our users to implement a method replay on the > ActiveMQServerControl > such method should just call server.replay(this.address, .) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[ https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668082=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668082 ] ASF GitHub Bot logged work on ARTEMIS-3523: --- Author: ASF GitHub Bot Created on: 21/Oct/21 04:11 Start Date: 21/Oct/21 04:11 Worklog Time Spent: 10m Work Description: clebertsuconic commented on a change in pull request #3801: URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r733303390 ## File path: artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/AddressControl.java ## @@ -230,4 +230,15 @@ String sendMessage(@Parameter(name = "headers", desc = "The headers to add to th @Operation(desc = "Purges the queues bound to this address. Returns the total number of messages purged.", impact = MBeanOperationInfo.ACTION) long purge() throws Exception; + @Operation(desc = "Makes the broker to read messages from the retention folder matching the address and filter.", impact = MBeanOperationInfo.ACTION) + void replay(@Parameter(name = "address", desc = "Name of the address to replay") String address, Review comment: the address should not be a parameter on the AddressControl... That's the purpose, you understand? you delegate the replay from AddressControl calling ActiveMQServer that way you pass in (target, filter) on the AddressControl, and the implementation will call Server.replay(this.address, target, filter); This would make it simpler, because you are usually browsing messages at the address level on the console. it would make it simpler for users. -- 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: 668082) Time Spent: 3h (was: 2h 50m) > Expose replay through AddressControl > > > Key: ARTEMIS-3523 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3523 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > Time Spent: 3h > Remaining Estimate: 0h > > Currently there is a method replay on ActiveMQServer with the following > signature: > replay(address, .) > it should be a lot easier for our users to implement a method replay on the > ActiveMQServerControl > such method should just call server.replay(this.address, .) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[
https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668084=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668084
]
ASF GitHub Bot logged work on ARTEMIS-3523:
---
Author: ASF GitHub Bot
Created on: 21/Oct/21 04:11
Start Date: 21/Oct/21 04:11
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on a change in pull request
#3801:
URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r733303476
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/AddressControlImpl.java
##
@@ -574,6 +576,22 @@ public long purge() throws Exception {
return totalMsgs;
}
+ @Override
+ public void replay(String address, String target, String filter) throws
Exception {
Review comment:
remove "String address" from here (as I mentioned on the interface
declaration)
--
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: 668084)
Time Spent: 3h 10m (was: 3h)
> Expose replay through AddressControl
>
>
> Key: ARTEMIS-3523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3523
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Clebert Suconic
>Priority: Major
> Labels: easy
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Currently there is a method replay on ActiveMQServer with the following
> signature:
> replay(address, .)
> it should be a lot easier for our users to implement a method replay on the
> ActiveMQServerControl
> such method should just call server.replay(this.address, .)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[ https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668081=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668081 ] ASF GitHub Bot logged work on ARTEMIS-3523: --- Author: ASF GitHub Bot Created on: 21/Oct/21 04:10 Start Date: 21/Oct/21 04:10 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #3801: URL: https://github.com/apache/activemq-artemis/pull/3801#issuecomment-948241083 also, next time you mvn build, use the -Pdev profile at least once.. it takes some extra time, but it will run the check style.. etc... the -Derrorprone may also help with the PR checks to make sure it passes it. ``` mvn -Pdev install -Derrorprone ``` -- 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: 668081) Time Spent: 2h 50m (was: 2h 40m) > Expose replay through AddressControl > > > Key: ARTEMIS-3523 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3523 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently there is a method replay on ActiveMQServer with the following > signature: > replay(address, .) > it should be a lot easier for our users to implement a method replay on the > ActiveMQServerControl > such method should just call server.replay(this.address, .) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[ https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668080=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668080 ] ASF GitHub Bot logged work on ARTEMIS-3523: --- Author: ASF GitHub Bot Created on: 21/Oct/21 04:09 Start Date: 21/Oct/21 04:09 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #3801: URL: https://github.com/apache/activemq-artemis/pull/3801#issuecomment-948240642 @nbrendah Nice job... you're getting there...It's midnight here and I made sure I came to look, because it looked almost good already... a few minor adjustments and it will be ready to merge.. not bad! pretty much you have to remove the address parameter from the address control (the address control knows the address name already, that's the point), which will be delegated to the server's with the this.addressName from the address controller (I don't remember the actual variable name, but it will be there somehow). -- 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: 668080) Time Spent: 2h 40m (was: 2.5h) > Expose replay through AddressControl > > > Key: ARTEMIS-3523 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3523 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently there is a method replay on ActiveMQServer with the following > signature: > replay(address, .) > it should be a lot easier for our users to implement a method replay on the > ActiveMQServerControl > such method should just call server.replay(this.address, .) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[
https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668079=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668079
]
ASF GitHub Bot logged work on ARTEMIS-3523:
---
Author: ASF GitHub Bot
Created on: 21/Oct/21 04:06
Start Date: 21/Oct/21 04:06
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on a change in pull request
#3801:
URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r733303561
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/AddressControlImpl.java
##
@@ -574,6 +576,22 @@ public long purge() throws Exception {
return totalMsgs;
}
+ @Override
+ public void replay(String address, String target, String filter) throws
Exception {
+ server.replay(null, null, address, target, filter);
Review comment:
and here you pass in the address name that will be part of the
AddressControlImpl already.
--
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: 668079)
Time Spent: 2.5h (was: 2h 20m)
> Expose replay through AddressControl
>
>
> Key: ARTEMIS-3523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3523
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Clebert Suconic
>Priority: Major
> Labels: easy
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Currently there is a method replay on ActiveMQServer with the following
> signature:
> replay(address, .)
> it should be a lot easier for our users to implement a method replay on the
> ActiveMQServerControl
> such method should just call server.replay(this.address, .)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[
https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668078=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668078
]
ASF GitHub Bot logged work on ARTEMIS-3523:
---
Author: ASF GitHub Bot
Created on: 21/Oct/21 04:05
Start Date: 21/Oct/21 04:05
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on a change in pull request
#3801:
URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r733303476
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/AddressControlImpl.java
##
@@ -574,6 +576,22 @@ public long purge() throws Exception {
return totalMsgs;
}
+ @Override
+ public void replay(String address, String target, String filter) throws
Exception {
Review comment:
remove String.address from here
--
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: 668078)
Time Spent: 2h 20m (was: 2h 10m)
> Expose replay through AddressControl
>
>
> Key: ARTEMIS-3523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3523
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Clebert Suconic
>Priority: Major
> Labels: easy
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Currently there is a method replay on ActiveMQServer with the following
> signature:
> replay(address, .)
> it should be a lot easier for our users to implement a method replay on the
> ActiveMQServerControl
> such method should just call server.replay(this.address, .)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[ https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668077=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668077 ] ASF GitHub Bot logged work on ARTEMIS-3523: --- Author: ASF GitHub Bot Created on: 21/Oct/21 04:05 Start Date: 21/Oct/21 04:05 Worklog Time Spent: 10m Work Description: clebertsuconic commented on a change in pull request #3801: URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r733303390 ## File path: artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/AddressControl.java ## @@ -230,4 +230,15 @@ String sendMessage(@Parameter(name = "headers", desc = "The headers to add to th @Operation(desc = "Purges the queues bound to this address. Returns the total number of messages purged.", impact = MBeanOperationInfo.ACTION) long purge() throws Exception; + @Operation(desc = "Makes the broker to read messages from the retention folder matching the address and filter.", impact = MBeanOperationInfo.ACTION) + void replay(@Parameter(name = "address", desc = "Name of the address to replay") String address, Review comment: the address should not be a parameter on the AddressControl... That's the purpose, you understand? you delegate the replay from AddressControl calling ActiveMQServerControl that way you pass in (target, filter) on the AddressControl, and the implementation will call Server.replay(this.address, target, filter); This would make it simpler, because you are usually browsing messages at the address level on the console. it would make it simpler for users. -- 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: 668077) Time Spent: 2h 10m (was: 2h) > Expose replay through AddressControl > > > Key: ARTEMIS-3523 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3523 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently there is a method replay on ActiveMQServer with the following > signature: > replay(address, .) > it should be a lot easier for our users to implement a method replay on the > ActiveMQServerControl > such method should just call server.replay(this.address, .) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[ https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668074=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668074 ] ASF GitHub Bot logged work on ARTEMIS-3523: --- Author: ASF GitHub Bot Created on: 21/Oct/21 03:56 Start Date: 21/Oct/21 03:56 Worklog Time Spent: 10m Work Description: nbrendah edited a comment on pull request #3801: URL: https://github.com/apache/activemq-artemis/pull/3801#issuecomment-948234857 Thank you @clebertsuconic for taking time to look at this. I have updated the PR to match the suggestions and comments above. If you get some free time, i request for a review. Thanks for the good work -- 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: 668074) Time Spent: 2h (was: 1h 50m) > Expose replay through AddressControl > > > Key: ARTEMIS-3523 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3523 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > Time Spent: 2h > Remaining Estimate: 0h > > Currently there is a method replay on ActiveMQServer with the following > signature: > replay(address, .) > it should be a lot easier for our users to implement a method replay on the > ActiveMQServerControl > such method should just call server.replay(this.address, .) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[ https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668073=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668073 ] ASF GitHub Bot logged work on ARTEMIS-3523: --- Author: ASF GitHub Bot Created on: 21/Oct/21 03:54 Start Date: 21/Oct/21 03:54 Worklog Time Spent: 10m Work Description: nbrendah commented on pull request #3801: URL: https://github.com/apache/activemq-artemis/pull/3801#issuecomment-948234857 Thank you @clebertsuconic for taking time to look at this. I have added updated the PR to match the suggestions and comments above. If you get some free time, i request for a review. Thanks for the good work -- 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: 668073) Time Spent: 1h 50m (was: 1h 40m) > Expose replay through AddressControl > > > Key: ARTEMIS-3523 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3523 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently there is a method replay on ActiveMQServer with the following > signature: > replay(address, .) > it should be a lot easier for our users to implement a method replay on the > ActiveMQServerControl > such method should just call server.replay(this.address, .) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[
https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668066=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668066
]
ASF GitHub Bot logged work on ARTEMIS-3523:
---
Author: ASF GitHub Bot
Created on: 21/Oct/21 02:37
Start Date: 21/Oct/21 02:37
Worklog Time Spent: 10m
Work Description: nbrendah commented on a change in pull request #3801:
URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r733273289
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/AddressControlImpl.java
##
@@ -574,6 +574,11 @@ public long purge() throws Exception {
return totalMsgs;
}
+ @Override
+ public void replay() throws Exception {
Review comment:
Thanks @clebertsuconic
> I think you the signature should be the same one on ServerControl minus
the address...
`server.replay(null, null, this.getAddress(), null, null);`
In my thinking, referencing the `this is trivial.` This is what i mean,
```
public void replay(String address, String target, String filter) throws
Exception {
server.replay(null, null, this.address, target, filter);
}
```
Or i should just ignore the `this`, for now?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 668066)
Time Spent: 1h 40m (was: 1.5h)
> Expose replay through AddressControl
>
>
> Key: ARTEMIS-3523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3523
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Clebert Suconic
>Priority: Major
> Labels: easy
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Currently there is a method replay on ActiveMQServer with the following
> signature:
> replay(address, .)
> it should be a lot easier for our users to implement a method replay on the
> ActiveMQServerControl
> such method should just call server.replay(this.address, .)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[
https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668065=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668065
]
ASF GitHub Bot logged work on ARTEMIS-3523:
---
Author: ASF GitHub Bot
Created on: 21/Oct/21 02:36
Start Date: 21/Oct/21 02:36
Worklog Time Spent: 10m
Work Description: nbrendah commented on a change in pull request #3801:
URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r733275756
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/ActiveMQServerControlImpl.java
##
@@ -4443,7 +4443,7 @@ public void reloadConfigurationFile() throws Exception {
@Override
public void replay(String address, String target, String filter) throws
Exception {
- server.replay(null, null, address, target, filter);
+ server.replay(null, null, this.getAddressInfo(address), target, filter);
Review comment:
@clebertsuconic This is pretty clear now. Thank you so much.
--
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: 668065)
Time Spent: 1.5h (was: 1h 20m)
> Expose replay through AddressControl
>
>
> Key: ARTEMIS-3523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3523
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Clebert Suconic
>Priority: Major
> Labels: easy
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently there is a method replay on ActiveMQServer with the following
> signature:
> replay(address, .)
> it should be a lot easier for our users to implement a method replay on the
> ActiveMQServerControl
> such method should just call server.replay(this.address, .)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[
https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668063=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668063
]
ASF GitHub Bot logged work on ARTEMIS-3523:
---
Author: ASF GitHub Bot
Created on: 21/Oct/21 02:29
Start Date: 21/Oct/21 02:29
Worklog Time Spent: 10m
Work Description: nbrendah commented on a change in pull request #3801:
URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r733273289
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/AddressControlImpl.java
##
@@ -574,6 +574,11 @@ public long purge() throws Exception {
return totalMsgs;
}
+ @Override
+ public void replay() throws Exception {
Review comment:
Thanks @clebertsuconic
> I think you the signature should be the same one on ServerControl minus
the address...
`server.replay(null, null, this.getAddress(), null, null);`
In my thinking, referencing the `this is trivial.` This is what i mean,
```
public void replay(String address, String target, String filter) throws
Exception {
server.replay(null, null, this.address, target, filter);
}
```
Or i should just ignore the `this`, for now?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 668063)
Time Spent: 1h 20m (was: 1h 10m)
> Expose replay through AddressControl
>
>
> Key: ARTEMIS-3523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3523
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Clebert Suconic
>Priority: Major
> Labels: easy
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Currently there is a method replay on ActiveMQServer with the following
> signature:
> replay(address, .)
> it should be a lot easier for our users to implement a method replay on the
> ActiveMQServerControl
> such method should just call server.replay(this.address, .)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[
https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668061=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668061
]
ASF GitHub Bot logged work on ARTEMIS-3523:
---
Author: ASF GitHub Bot
Created on: 21/Oct/21 02:23
Start Date: 21/Oct/21 02:23
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on a change in pull request
#3801:
URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r733271478
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/ActiveMQServerControlImpl.java
##
@@ -4443,7 +4443,7 @@ public void reloadConfigurationFile() throws Exception {
@Override
public void replay(String address, String target, String filter) throws
Exception {
- server.replay(null, null, address, target, filter);
+ server.replay(null, null, this.getAddressInfo(address), target, filter);
Review comment:
Notice, I'm suggesting you add two methods into ActiveMQAddressControl..
one with the date, one without the date, just list the ActiveMQServerControl..
but those are just there as overloads.
let me know what you think and how you progress on this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 668061)
Time Spent: 1h 10m (was: 1h)
> Expose replay through AddressControl
>
>
> Key: ARTEMIS-3523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3523
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Clebert Suconic
>Priority: Major
> Labels: easy
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently there is a method replay on ActiveMQServer with the following
> signature:
> replay(address, .)
> it should be a lot easier for our users to implement a method replay on the
> ActiveMQServerControl
> such method should just call server.replay(this.address, .)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[
https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668060=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668060
]
ASF GitHub Bot logged work on ARTEMIS-3523:
---
Author: ASF GitHub Bot
Created on: 21/Oct/21 02:21
Start Date: 21/Oct/21 02:21
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on a change in pull request
#3801:
URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r733271090
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/ActiveMQServerControlImpl.java
##
@@ -4443,7 +4443,7 @@ public void reloadConfigurationFile() throws Exception {
@Override
public void replay(String address, String target, String filter) throws
Exception {
- server.replay(null, null, address, target, filter);
+ server.replay(null, null, this.getAddressInfo(address), target, filter);
Review comment:
@nbrendah the test should be something fairly simple...
Get the ActiveMQServerControlTest::testReplayWithoutDate and
testReplaWithDate
copy those into ActiveMQAddressControlTest, and call the new methods that
you will add:
Add 2 methods to AcctiveMQAddressControl:
```
@Operation(desc = "Makes the broker to read messages from the retention
folder matching the address and filter.", impact = MBeanOperationInfo.ACTION)
void replay(
@Parameter(name = "target", desc = "Where the replay data
should be sent") String target,
@Parameter(name = "filter", desc = "Filter to apply on
message selection. Null means everything matching the address") String filter)
throws Exception;
@Operation(desc = "Makes the broker to read messages from the retention
folder matching the address and filter.", impact = MBeanOperationInfo.ACTION)
void replay(@Parameter(name = "startScanDate", desc = "Start date where
we will start scanning for journals to replay. Format MMDDHHMMSS") String
startScan,
@Parameter(name = "endScanDate", desc = "Finish date where we
will stop scannning for journals to replay. Format MMDDHHMMSS") String
endScan,
@Parameter(name = "target", desc = "Where the replay data
should be sent") String target,
@Parameter(name = "filter", desc = "Filter to apply on
message selection. Null means everything matching the address") String filter)
throws Exception;
```
notice I only removed the address, as that will be delegated through the
this.addressName
With the two copied & pasted tests from ActiveMQServerControl into
ActiveMQAddressControlTest (select a random address for the test), you should
be able to finish the task.
--
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: 668060)
Time Spent: 1h (was: 50m)
> Expose replay through AddressControl
>
>
> Key: ARTEMIS-3523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3523
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Clebert Suconic
>Priority: Major
> Labels: easy
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently there is a method replay on ActiveMQServer with the following
> signature:
> replay(address, .)
> it should be a lot easier for our users to implement a method replay on the
> ActiveMQServerControl
> such method should just call server.replay(this.address, .)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[
https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=668056=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-668056
]
ASF GitHub Bot logged work on ARTEMIS-3523:
---
Author: ASF GitHub Bot
Created on: 21/Oct/21 01:45
Start Date: 21/Oct/21 01:45
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on a change in pull request
#3801:
URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r733259828
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/AddressControlImpl.java
##
@@ -574,6 +574,11 @@ public long purge() throws Exception {
return totalMsgs;
}
+ @Override
+ public void replay() throws Exception {
Review comment:
I think you the signature should be the same one on ServerControl minus
the address...
other than that you're spot on on the change.
--
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: 668056)
Time Spent: 50m (was: 40m)
> Expose replay through AddressControl
>
>
> Key: ARTEMIS-3523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3523
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Clebert Suconic
>Priority: Major
> Labels: easy
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently there is a method replay on ActiveMQServer with the following
> signature:
> replay(address, .)
> it should be a lot easier for our users to implement a method replay on the
> ActiveMQServerControl
> such method should just call server.replay(this.address, .)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3524) Review Documentation
[ https://issues.apache.org/jira/browse/ARTEMIS-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17432103#comment-17432103 ] Nabwegamo Brendah commented on ARTEMIS-3524: Thank you [~brusdev] and [~clebertsuconic] I have opened up a PR https://github.com/apache/activemq-website/pull/66 I am looking forward to your suggestions. > Review Documentation > > > Key: ARTEMIS-3524 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3524 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Labels: easy > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3085) Support registering IOCriticalErrorListener on the broker
[ https://issues.apache.org/jira/browse/ARTEMIS-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431304#comment-17431304 ] Somdatta commented on ARTEMIS-3085: --- [~clebertsuconic] After going through the code what I understood is, this is what has to be done- it needs it to add a criticalErrorListener to the ActiveMQServer interface, so a critical error could be called from somewhere else? cc [~ehsavoie] > Support registering IOCriticalErrorListener on the broker > - > > Key: ARTEMIS-3085 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3085 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.16.0 >Reporter: Emmanuel Hugonnet >Priority: Major > Labels: easy > > There is no way to register a IOCriticalErrorListener on the broker to > customize the behaviour on critical IO errors -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3085) Support registering IOCriticalErrorListener on the broker
[ https://issues.apache.org/jira/browse/ARTEMIS-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431279#comment-17431279 ] Somdatta commented on ARTEMIS-3085: --- I am looking into this issue. > Support registering IOCriticalErrorListener on the broker > - > > Key: ARTEMIS-3085 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3085 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.16.0 >Reporter: Emmanuel Hugonnet >Priority: Major > Labels: easy > > There is no way to register a IOCriticalErrorListener on the broker to > customize the behaviour on critical IO errors -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[
https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431276#comment-17431276
]
Rico Neubauer commented on ARTEMIS-3433:
Thanks [~gtully], this looks good to me and fixes the issue on shut-down.
> AMQ224068 on stop due to No OpenSSLContextFactory registered
>
>
> Key: ARTEMIS-3433
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3433
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
>Reporter: Rico Neubauer
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ARTEMIS-3117 introduced code in 2.18.0 to invoke
> _OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();_
> during stop of _RemotingServiceImpl_. See below for whole stacktrace.
> This throws a NullPointerException for us running inside Karaf on stop due to
> the OpenSSLContextFactory being null at that point in time.
>
> ARTEMIS-2791 was somewhat similar to this.
> Requesting to not fail on the OpenSSLContextFactory being null during stop.
> {code:java}
> {code:java}
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> ERROR org.apache.activemq.artemis.core.server FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068:
> Unable to stop component:
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
> null at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
> ~[?:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380)
> ~[osgi.core-7.0.0.jar:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?]
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:?] at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?] at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165)
> ~[?:?] at
>
[jira] [Assigned] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[
https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully reassigned ARTEMIS-3433:
---
Assignee: Gary Tully
> AMQ224068 on stop due to No OpenSSLContextFactory registered
>
>
> Key: ARTEMIS-3433
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3433
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
>Reporter: Rico Neubauer
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ARTEMIS-3117 introduced code in 2.18.0 to invoke
> _OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();_
> during stop of _RemotingServiceImpl_. See below for whole stacktrace.
> This throws a NullPointerException for us running inside Karaf on stop due to
> the OpenSSLContextFactory being null at that point in time.
>
> ARTEMIS-2791 was somewhat similar to this.
> Requesting to not fail on the OpenSSLContextFactory being null during stop.
> {code:java}
> {code:java}
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> ERROR org.apache.activemq.artemis.core.server FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068:
> Unable to stop component:
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
> null at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
> ~[?:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380)
> ~[osgi.core-7.0.0.jar:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?]
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:?] at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?] at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853)
> ~[?:?] at
>
[jira] [Updated] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[
https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated ARTEMIS-3433:
Fix Version/s: (was: 2.19.0)
> AMQ224068 on stop due to No OpenSSLContextFactory registered
>
>
> Key: ARTEMIS-3433
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3433
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
>Reporter: Rico Neubauer
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ARTEMIS-3117 introduced code in 2.18.0 to invoke
> _OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();_
> during stop of _RemotingServiceImpl_. See below for whole stacktrace.
> This throws a NullPointerException for us running inside Karaf on stop due to
> the OpenSSLContextFactory being null at that point in time.
>
> ARTEMIS-2791 was somewhat similar to this.
> Requesting to not fail on the OpenSSLContextFactory being null during stop.
> {code:java}
> {code:java}
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> ERROR org.apache.activemq.artemis.core.server FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068:
> Unable to stop component:
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
> null at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
> ~[?:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380)
> ~[osgi.core-7.0.0.jar:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?]
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:?] at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?] at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853)
> ~[?:?] at
>
[jira] [Commented] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[
https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431262#comment-17431262
]
Gary Tully commented on ARTEMIS-3433:
-
[~riconeubauer] would you be in a position to verify a PR?
[https://github.com/apache/activemq-artemis/pull/3806]
the throw on initialisation is gone, and the null checks are now only on the
start/initialisation path, such that the null check on shutdown now kicks in
just fine.
> AMQ224068 on stop due to No OpenSSLContextFactory registered
>
>
> Key: ARTEMIS-3433
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3433
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
>Reporter: Rico Neubauer
>Priority: Major
> Fix For: 2.19.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ARTEMIS-3117 introduced code in 2.18.0 to invoke
> _OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();_
> during stop of _RemotingServiceImpl_. See below for whole stacktrace.
> This throws a NullPointerException for us running inside Karaf on stop due to
> the OpenSSLContextFactory being null at that point in time.
>
> ARTEMIS-2791 was somewhat similar to this.
> Requesting to not fail on the OpenSSLContextFactory being null during stop.
> {code:java}
> {code:java}
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> ERROR org.apache.activemq.artemis.core.server FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068:
> Unable to stop component:
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
> null at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
> ~[?:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380)
> ~[osgi.core-7.0.0.jar:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?]
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:?] at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?] at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308)
> ~[?:?] at
> org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421)
>
[jira] [Work logged] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[
https://issues.apache.org/jira/browse/ARTEMIS-3433?focusedWorklogId=66=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-66
]
ASF GitHub Bot logged work on ARTEMIS-3433:
---
Author: ASF GitHub Bot
Created on: 20/Oct/21 14:01
Start Date: 20/Oct/21 14:01
Worklog Time Spent: 10m
Work Description: gtully opened a new pull request #3806:
URL: https://github.com/apache/activemq-artemis/pull/3806
…aths
--
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: 66)
Time Spent: 40m (was: 0.5h)
> AMQ224068 on stop due to No OpenSSLContextFactory registered
>
>
> Key: ARTEMIS-3433
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3433
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.18.0
>Reporter: Rico Neubauer
>Priority: Major
> Fix For: 2.19.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> ARTEMIS-3117 introduced code in 2.18.0 to invoke
> _OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();_
> during stop of _RemotingServiceImpl_. See below for whole stacktrace.
> This throws a NullPointerException for us running inside Karaf on stop due to
> the OpenSSLContextFactory being null at that point in time.
>
> ARTEMIS-2791 was somewhat similar to this.
> Requesting to not fail on the OpenSSLContextFactory being null during stop.
> {code:java}
> {code:java}
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> INFO org.apache.activemq.artemis.osgi FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002:
> Required protocol OPENWIRE was removed for broker local. Stopping broker.
> ERROR org.apache.activemq.artemis.core.server FelixStartLevel
> [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068:
> Unable to stop component:
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError:
> null at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
> ~[?:?] at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94)
> ~[?:?] at
> org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38)
> ~[?:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)
> ~[osgi.core-7.0.0.jar:?] at
> org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380)
> ~[osgi.core-7.0.0.jar:?] at
> org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?]
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:?] at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?] at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244)
> ~[?:?] at
> org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
> ~[?:?] at
>
[jira] [Resolved] (ARTEMIS-3030) Journal lock evaluation fails when NFS is temporarily disconnected
[
https://issues.apache.org/jira/browse/ARTEMIS-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Nigro resolved ARTEMIS-3030.
--
Resolution: Information Provided
> Journal lock evaluation fails when NFS is temporarily disconnected
> --
>
> Key: ARTEMIS-3030
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3030
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
>Reporter: Apache Dev
>Assignee: Francesco Nigro
>Priority: Blocker
>
> Same scenario of ARTEMIS-2421.
> If network between Live Broker (B1) and NFS Server is disconnected (for
> example rejecting its TCP packets with iptables), after the lock lease
> timeout this happens:
> * Backup server (B2) becomes Live
> * When NFS connectivity of B1 is restored, B1 remains Live
> So both broker are live.
> Issue seems caused by \{{java.nio.channels.FileLock#isValid}} used in
> \{{org.apache.activemq.artemis.core.server.impl.FileLockNodeManager#isLiveLockLost}},
> because it is always returning true, even if in the meanwhile the lock was
> lost and taken by B2.
> Do you suggest to use specific mount options for NFS?
> Or the lock evaluation should be replaced with a more reliable mechanism? We
> notice that \{{FileLock#isValid}} is returning a cached value (true), even
> when NFS connectivity is down, so it would be better to use a validation
> mechanism that forces querying the NFS server.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3030) Journal lock evaluation fails when NFS is temporarily disconnected
[
https://issues.apache.org/jira/browse/ARTEMIS-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431222#comment-17431222
]
Francesco Nigro commented on ARTEMIS-3030:
--
Closing as explained on
https://issues.apache.org/jira/browse/ARTEMIS-3030?focusedCommentId=17418751=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17418751
> Journal lock evaluation fails when NFS is temporarily disconnected
> --
>
> Key: ARTEMIS-3030
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3030
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
>Reporter: Apache Dev
>Priority: Blocker
>
> Same scenario of ARTEMIS-2421.
> If network between Live Broker (B1) and NFS Server is disconnected (for
> example rejecting its TCP packets with iptables), after the lock lease
> timeout this happens:
> * Backup server (B2) becomes Live
> * When NFS connectivity of B1 is restored, B1 remains Live
> So both broker are live.
> Issue seems caused by \{{java.nio.channels.FileLock#isValid}} used in
> \{{org.apache.activemq.artemis.core.server.impl.FileLockNodeManager#isLiveLockLost}},
> because it is always returning true, even if in the meanwhile the lock was
> lost and taken by B2.
> Do you suggest to use specific mount options for NFS?
> Or the lock evaluation should be replaced with a more reliable mechanism? We
> notice that \{{FileLock#isValid}} is returning a cached value (true), even
> when NFS connectivity is down, so it would be better to use a validation
> mechanism that forces querying the NFS server.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (ARTEMIS-3030) Journal lock evaluation fails when NFS is temporarily disconnected
[
https://issues.apache.org/jira/browse/ARTEMIS-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Nigro reassigned ARTEMIS-3030:
Assignee: Francesco Nigro
> Journal lock evaluation fails when NFS is temporarily disconnected
> --
>
> Key: ARTEMIS-3030
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3030
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
>Reporter: Apache Dev
>Assignee: Francesco Nigro
>Priority: Blocker
>
> Same scenario of ARTEMIS-2421.
> If network between Live Broker (B1) and NFS Server is disconnected (for
> example rejecting its TCP packets with iptables), after the lock lease
> timeout this happens:
> * Backup server (B2) becomes Live
> * When NFS connectivity of B1 is restored, B1 remains Live
> So both broker are live.
> Issue seems caused by \{{java.nio.channels.FileLock#isValid}} used in
> \{{org.apache.activemq.artemis.core.server.impl.FileLockNodeManager#isLiveLockLost}},
> because it is always returning true, even if in the meanwhile the lock was
> lost and taken by B2.
> Do you suggest to use specific mount options for NFS?
> Or the lock evaluation should be replaced with a more reliable mechanism? We
> notice that \{{FileLock#isValid}} is returning a cached value (true), even
> when NFS connectivity is down, so it would be better to use a validation
> mechanism that forces querying the NFS server.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2916) Two servers becoming Live using JDBC Shared Store
[
https://issues.apache.org/jira/browse/ARTEMIS-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431219#comment-17431219
]
Francesco Nigro commented on ARTEMIS-2916:
--
Closing as explained on
https://issues.apache.org/jira/browse/ARTEMIS-2916?focusedCommentId=17204773=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17204773
and further addressed on https://issues.apache.org/jira/browse/ARTEMIS-2926
> Two servers becoming Live using JDBC Shared Store
> -
>
> Key: ARTEMIS-2916
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2916
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.13.0
>Reporter: Apache Dev
>Assignee: Francesco Nigro
>Priority: Critical
> Attachments: logs.zip
>
>
> We have similar scenario described in ARTEMIS-2421 but using:
> * Artemis 2.13.0
> * JDBC Shared Store
> * 1 Master currently down
> * 3 Slave
> ** 1 Live
> ** 2 Backup
> All 3 slaves are configured with:
> {code:xml}
>
>
>
> false
> true
>
>
>
> {code}
>
> After 2 days of activities, with a single slave working as live we got
> suddenly one slave server becoming live too while the other live server was
> still working. No warnings/errors available. Just backup server started
> creating configured addresses, queues and starting connectors, then it logged
> "AMQ221010: Backup Server is now live".
> The third slave broker started in the meanwhile to log continuously:
> {noformat}
> AMQ212034: There are more than one servers on the network broadcasting the
> same node id. You will see this message exactly once (per node) if a node is
> restarted, in which case it can be safely ignored. But if it is logged
> continuously it means you really do have more than one node on the same
> network active concurrently with the same node id. This could occur if you
> have a backup node active at the same time as its live node. nodeID=...
> {noformat}
> Final scenario was:
> * 1 Master down
> * 3 Slave
> ** 2 Live
> ** 1 Backup
> I see that ARTEMIS-2421 was fixed only in the filesystem use-case. Should it
> be fixed for JDBC too?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-2916) Two servers becoming Live using JDBC Shared Store
[
https://issues.apache.org/jira/browse/ARTEMIS-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Nigro resolved ARTEMIS-2916.
--
Resolution: Information Provided
> Two servers becoming Live using JDBC Shared Store
> -
>
> Key: ARTEMIS-2916
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2916
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.13.0
>Reporter: Apache Dev
>Assignee: Francesco Nigro
>Priority: Critical
> Attachments: logs.zip
>
>
> We have similar scenario described in ARTEMIS-2421 but using:
> * Artemis 2.13.0
> * JDBC Shared Store
> * 1 Master currently down
> * 3 Slave
> ** 1 Live
> ** 2 Backup
> All 3 slaves are configured with:
> {code:xml}
>
>
>
> false
> true
>
>
>
> {code}
>
> After 2 days of activities, with a single slave working as live we got
> suddenly one slave server becoming live too while the other live server was
> still working. No warnings/errors available. Just backup server started
> creating configured addresses, queues and starting connectors, then it logged
> "AMQ221010: Backup Server is now live".
> The third slave broker started in the meanwhile to log continuously:
> {noformat}
> AMQ212034: There are more than one servers on the network broadcasting the
> same node id. You will see this message exactly once (per node) if a node is
> restarted, in which case it can be safely ignored. But if it is logged
> continuously it means you really do have more than one node on the same
> network active concurrently with the same node id. This could occur if you
> have a backup node active at the same time as its live node. nodeID=...
> {noformat}
> Final scenario was:
> * 1 Master down
> * 3 Slave
> ** 2 Live
> ** 1 Backup
> I see that ARTEMIS-2421 was fixed only in the filesystem use-case. Should it
> be fixed for JDBC too?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (ARTEMIS-2916) Two servers becoming Live using JDBC Shared Store
[
https://issues.apache.org/jira/browse/ARTEMIS-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Nigro reassigned ARTEMIS-2916:
Assignee: Francesco Nigro
> Two servers becoming Live using JDBC Shared Store
> -
>
> Key: ARTEMIS-2916
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2916
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.13.0
>Reporter: Apache Dev
>Assignee: Francesco Nigro
>Priority: Critical
> Attachments: logs.zip
>
>
> We have similar scenario described in ARTEMIS-2421 but using:
> * Artemis 2.13.0
> * JDBC Shared Store
> * 1 Master currently down
> * 3 Slave
> ** 1 Live
> ** 2 Backup
> All 3 slaves are configured with:
> {code:xml}
>
>
>
> false
> true
>
>
>
> {code}
>
> After 2 days of activities, with a single slave working as live we got
> suddenly one slave server becoming live too while the other live server was
> still working. No warnings/errors available. Just backup server started
> creating configured addresses, queues and starting connectors, then it logged
> "AMQ221010: Backup Server is now live".
> The third slave broker started in the meanwhile to log continuously:
> {noformat}
> AMQ212034: There are more than one servers on the network broadcasting the
> same node id. You will see this message exactly once (per node) if a node is
> restarted, in which case it can be safely ignored. But if it is logged
> continuously it means you really do have more than one node on the same
> network active concurrently with the same node id. This could occur if you
> have a backup node active at the same time as its live node. nodeID=...
> {noformat}
> Final scenario was:
> * 1 Master down
> * 3 Slave
> ** 2 Live
> ** 1 Backup
> I see that ARTEMIS-2421 was fixed only in the filesystem use-case. Should it
> be fixed for JDBC too?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (ARTEMIS-3536) version 2.19.0 released but not "Affects Version/s"
[ https://issues.apache.org/jira/browse/ARTEMIS-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully closed ARTEMIS-3536. --- Resolution: Fixed > version 2.19.0 released but not "Affects Version/s" > --- > > Key: ARTEMIS-3536 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3536 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: arne anka >Priority: Major > > As per > [https://activemq.apache.org/components/artemis/documentation/latest/versions.html] > and the download page, 2.19.0 has been released officially. > Yet, it is not vaialbale as version in the > Affects Version/s > dropdown above. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3141) limit the amount of data returned from jmx/queue control listMessages
[ https://issues.apache.org/jira/browse/ARTEMIS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431126#comment-17431126 ] Gary Tully commented on ARTEMIS-3141: - It is typically the body that is large and needs to be truncated, the body, properties etc are all ``attributes`` of the message. I think if users want to use the webconsole as a messaging browser and see the whole message, they need to configure the broker or the addresses to allow that. In typical. usage, there is just way too much data to be moving between the broker and browser/UI for the defaults to be anything other than restrictive/conservative. But even so, a message could be stored as a LargeMessage on the broker and it won't be visible in the console representation. I don't see an easy answer to "get a single full message by ID as " when the message is stored as a Large Message. > limit the amount of data returned from jmx/queue control listMessages > - > > Key: ARTEMIS-3141 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3141 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JMX >Affects Versions: 2.17.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The list methods of queue control that are exposed via jmx seem to be > unbounded. > 1) they list all messages > 2) they display the full body > To protect both the broker and the browser/UI/client it would make sense to > limit both the number of messages and the size of the data that is returned. > Imaging 500k messages pending messages with a body of 10k... and 400k are > paged to disk. It would be crazy to try and list those. > I need to do some more tests to verify the extent a broker will do to support > the current api. I note that the browse functionality can be paged and with > out a page defaults to 200 messages. That is sensible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3141) limit the amount of data returned from jmx/queue control listMessages
[ https://issues.apache.org/jira/browse/ARTEMIS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431093#comment-17431093 ] arne anka commented on ARTEMIS-3141: Maybe I misunderstand the rationale of this feature, but what but understand is, that the _attributes_ may grow to large and cause issues. Since the message body is treated as an attribute, it's affected. So, my idea was not to add the body as attribute at all, but to "get a single full message by ID" whenever so requested. Did I get that completely wrong? > limit the amount of data returned from jmx/queue control listMessages > - > > Key: ARTEMIS-3141 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3141 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JMX >Affects Versions: 2.17.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The list methods of queue control that are exposed via jmx seem to be > unbounded. > 1) they list all messages > 2) they display the full body > To protect both the broker and the browser/UI/client it would make sense to > limit both the number of messages and the size of the data that is returned. > Imaging 500k messages pending messages with a body of 10k... and 400k are > paged to disk. It would be crazy to try and list those. > I need to do some more tests to verify the extent a broker will do to support > the current api. I note that the browse functionality can be paged and with > out a page defaults to 200 messages. That is sensible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3533) Have federation configuration respect extra url parameters from the connector-ref
[ https://issues.apache.org/jira/browse/ARTEMIS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved ARTEMIS-3533. - Resolution: Fixed > Have federation configuration respect extra url parameters from the > connector-ref > - > > Key: ARTEMIS-3533 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3533 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.18.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > a connector ref with a url of the form: > "tcp://localhost:61616?ackBatchSize=100=-1" > should be capable of configuring the ServerLocator used by a federation > client. > These are ignored by the transport connector but are captured as > extraParameters in the internal configuration. > It is simply a case of applying them. currently they are ignored! > This is better than duplicating additional serverLocator configuration in > federation configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3308) Federated queue will not move large messages
[
https://issues.apache.org/jira/browse/ARTEMIS-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431084#comment-17431084
]
Gary Tully commented on ARTEMIS-3308:
-
note from the doc:
If Federation has to process large messages, the default ackBatchSize and
consumerWindowSize for the consumer will need to be changed
to limit the number of in-flight messages and to enable large message flow.
These options can be supplied as parameters on the referenced connector URI,
for example:
{code}tcp://:?ackBatchSize=100=-1{code}
> Federated queue will not move large messages
>
>
> Key: ARTEMIS-3308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3308
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Federation
>Affects Versions: 2.17.0
> Environment: Windows 10 Pro (jdk 1.8 oracle last) artemis 2.17.0
>Reporter: Alexander Andreevich Revkov
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hello. I'am create two artemis broker:
> artemis01:
> {code:java}
> artemis create --max-hops=1 artemis01{code}
> artemis02:
> {code:java}
> artemis create --max-hops=1 --port-offset=10 artemis02{code}
> user: artemis
> password: artemis
>
> In artemis01/etc/broker.xml i add:
>
> {code:java}
>
>tcp://localhost:61626
>
>
>
>
>
> artemis02-connector
>
>
>
> include-federated="false">
>
>
>
> {code}
> then run both brokers.
> I send large message to artemis02:
> {code:java}
> artemis producer --url tcp://localhost:61626 --text-size 800
> --destination TEST.FEDERATED --message-count 1 --user artemis --password
> artemis{code}
> And then try get it from artemis01:
> {code:java}
> artemis consumer --url tcp://localhost:61616 --destination TEST.FEDERATED
> --message-count 1 --user artemis --password artemis{code}
> But i can't received message. Consumer stuck it loop. And artemis01 write in
> logs many NPE:
> {code:java}
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,001 DEBUG
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ843017:
> onMessageRouteError message: ClientLargeMessageImpl[messageID=1518976,
> durable=true,
> address=TEST.FEDERATED::TEST.FEDERATED,userID=50cb6a04-b8bd-11eb-85ab-00155d7523cb,properties=TypedProperties[__AMQ_CID=50bf3501-b8bd-11eb-85ab-00155d7523cb,_AMQ_ROUTING_TYPE=1,count=0,_AMQ_LARGE_SIZE=16014077,ThreadSent=Producer
> ActiveMQQueue[TEST.FEDERATED], thread=0]], with context:
> RoutingContextImpl(Address=null, routingType=null, PreviousAddress=null
> previousRoute:null, reusable=false, version=0)
> ..
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,002 INFO
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ841018: error
> routing message with ID: 1518976, exception: java.lang.NullPointerException
> {code}
>
> I see some source code and find what NPE occurs in CoreMessage.java class at
> 717 line because buffer is NULL:
> {code:java}
> buffer.setIndex(0, 0);{code}
> Not large messages works fine. Please fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ARTEMIS-3308) Federated queue will not move large messages
[
https://issues.apache.org/jira/browse/ARTEMIS-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved ARTEMIS-3308.
-
Fix Version/s: 2.20.0
Resolution: Fixed
> Federated queue will not move large messages
>
>
> Key: ARTEMIS-3308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3308
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Federation
>Affects Versions: 2.17.0
> Environment: Windows 10 Pro (jdk 1.8 oracle last) artemis 2.17.0
>Reporter: Alexander Andreevich Revkov
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hello. I'am create two artemis broker:
> artemis01:
> {code:java}
> artemis create --max-hops=1 artemis01{code}
> artemis02:
> {code:java}
> artemis create --max-hops=1 --port-offset=10 artemis02{code}
> user: artemis
> password: artemis
>
> In artemis01/etc/broker.xml i add:
>
> {code:java}
>
>tcp://localhost:61626
>
>
>
>
>
> artemis02-connector
>
>
>
> include-federated="false">
>
>
>
> {code}
> then run both brokers.
> I send large message to artemis02:
> {code:java}
> artemis producer --url tcp://localhost:61626 --text-size 800
> --destination TEST.FEDERATED --message-count 1 --user artemis --password
> artemis{code}
> And then try get it from artemis01:
> {code:java}
> artemis consumer --url tcp://localhost:61616 --destination TEST.FEDERATED
> --message-count 1 --user artemis --password artemis{code}
> But i can't received message. Consumer stuck it loop. And artemis01 write in
> logs many NPE:
> {code:java}
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,001 DEBUG
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ843017:
> onMessageRouteError message: ClientLargeMessageImpl[messageID=1518976,
> durable=true,
> address=TEST.FEDERATED::TEST.FEDERATED,userID=50cb6a04-b8bd-11eb-85ab-00155d7523cb,properties=TypedProperties[__AMQ_CID=50bf3501-b8bd-11eb-85ab-00155d7523cb,_AMQ_ROUTING_TYPE=1,count=0,_AMQ_LARGE_SIZE=16014077,ThreadSent=Producer
> ActiveMQQueue[TEST.FEDERATED], thread=0]], with context:
> RoutingContextImpl(Address=null, routingType=null, PreviousAddress=null
> previousRoute:null, reusable=false, version=0)
> ..
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,002 INFO
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ841018: error
> routing message with ID: 1518976, exception: java.lang.NullPointerException
> {code}
>
> I see some source code and find what NPE occurs in CoreMessage.java class at
> 717 line because buffer is NULL:
> {code:java}
> buffer.setIndex(0, 0);{code}
> Not large messages works fine. Please fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3141) limit the amount of data returned from jmx/queue control listMessages
[ https://issues.apache.org/jira/browse/ARTEMIS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431082#comment-17431082 ] Gary Tully commented on ARTEMIS-3141: - I don't think so, the point is to protect the broker and the UI. Message data gets very big very quickly. For DLQ addresses use the -1, you will need to provide a test case for the -1 case not working. see: https://github.com/apache/activemq-artemis/blob/main/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/management/QueueControlTest.java#L502 for an example, if the limit is flipped to -1 that test fails as expected. it may be the XML content on your message is being modified/transformed by the UI? > limit the amount of data returned from jmx/queue control listMessages > - > > Key: ARTEMIS-3141 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3141 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JMX >Affects Versions: 2.17.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The list methods of queue control that are exposed via jmx seem to be > unbounded. > 1) they list all messages > 2) they display the full body > To protect both the broker and the browser/UI/client it would make sense to > limit both the number of messages and the size of the data that is returned. > Imaging 500k messages pending messages with a body of 10k... and 400k are > paged to disk. It would be crazy to try and list those. > I need to do some more tests to verify the extent a broker will do to support > the current api. I note that the browse functionality can be paged and with > out a page defaults to 200 messages. That is sensible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3533) Have federation configuration respect extra url parameters from the connector-ref
[ https://issues.apache.org/jira/browse/ARTEMIS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431075#comment-17431075 ] ASF subversion and git services commented on ARTEMIS-3533: -- Commit 1ef059db2b9feb1cdedccb29c77c548c8613212e in activemq-artemis's branch refs/heads/main from gtully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=1ef059d ] ARTEMIS-3533, ARTEMIS-3308 - doc extra params and large messages for federation > Have federation configuration respect extra url parameters from the > connector-ref > - > > Key: ARTEMIS-3533 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3533 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.18.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > a connector ref with a url of the form: > "tcp://localhost:61616?ackBatchSize=100=-1" > should be capable of configuring the ServerLocator used by a federation > client. > These are ignored by the transport connector but are captured as > extraParameters in the internal configuration. > It is simply a case of applying them. currently they are ignored! > This is better than duplicating additional serverLocator configuration in > federation configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3308) Federated queue will not move large messages
[
https://issues.apache.org/jira/browse/ARTEMIS-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431076#comment-17431076
]
ASF subversion and git services commented on ARTEMIS-3308:
--
Commit 1ef059db2b9feb1cdedccb29c77c548c8613212e in activemq-artemis's branch
refs/heads/main from gtully
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=1ef059d ]
ARTEMIS-3533, ARTEMIS-3308 - doc extra params and large messages for federation
> Federated queue will not move large messages
>
>
> Key: ARTEMIS-3308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3308
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Federation
>Affects Versions: 2.17.0
> Environment: Windows 10 Pro (jdk 1.8 oracle last) artemis 2.17.0
>Reporter: Alexander Andreevich Revkov
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hello. I'am create two artemis broker:
> artemis01:
> {code:java}
> artemis create --max-hops=1 artemis01{code}
> artemis02:
> {code:java}
> artemis create --max-hops=1 --port-offset=10 artemis02{code}
> user: artemis
> password: artemis
>
> In artemis01/etc/broker.xml i add:
>
> {code:java}
>
>tcp://localhost:61626
>
>
>
>
>
> artemis02-connector
>
>
>
> include-federated="false">
>
>
>
> {code}
> then run both brokers.
> I send large message to artemis02:
> {code:java}
> artemis producer --url tcp://localhost:61626 --text-size 800
> --destination TEST.FEDERATED --message-count 1 --user artemis --password
> artemis{code}
> And then try get it from artemis01:
> {code:java}
> artemis consumer --url tcp://localhost:61616 --destination TEST.FEDERATED
> --message-count 1 --user artemis --password artemis{code}
> But i can't received message. Consumer stuck it loop. And artemis01 write in
> logs many NPE:
> {code:java}
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,001 DEBUG
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ843017:
> onMessageRouteError message: ClientLargeMessageImpl[messageID=1518976,
> durable=true,
> address=TEST.FEDERATED::TEST.FEDERATED,userID=50cb6a04-b8bd-11eb-85ab-00155d7523cb,properties=TypedProperties[__AMQ_CID=50bf3501-b8bd-11eb-85ab-00155d7523cb,_AMQ_ROUTING_TYPE=1,count=0,_AMQ_LARGE_SIZE=16014077,ThreadSent=Producer
> ActiveMQQueue[TEST.FEDERATED], thread=0]], with context:
> RoutingContextImpl(Address=null, routingType=null, PreviousAddress=null
> previousRoute:null, reusable=false, version=0)
> ..
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,002 INFO
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ841018: error
> routing message with ID: 1518976, exception: java.lang.NullPointerException
> {code}
>
> I see some source code and find what NPE occurs in CoreMessage.java class at
> 717 line because buffer is NULL:
> {code:java}
> buffer.setIndex(0, 0);{code}
> Not large messages works fine. Please fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3535) management-message-attribute-size-limit = -1 does not unlimit
[
https://issues.apache.org/jira/browse/ARTEMIS-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431074#comment-17431074
]
arne anka commented on ARTEMIS-3535:
I have an already existing installation where it happens.
Seems, there's an untested dependency to another setting?
Given that the feature was introduced w/o any doumentation, it's near to
impossible to figure out what that might be.
> management-message-attribute-size-limit = -1 does not unlimit
> -
>
> Key: ARTEMIS-3535
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3535
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
> Environment: A' Artems 2.19.0
>Reporter: arne anka
>Priority: Major
>
> With the new option messages are truncated.
> [https://activemq.apache.org/components/artemis/documentation/latest/versions.html]
> states for 2.18.0 that this may be overriden by using
> -1
> as value. But that doesn't work.
> {{broker.xml}}
> {code:xml}
>
> ...
>
> -1
>
> {code}
> Text shown is empty.
> Changing -1 to eg 1024 text appears partially.
> Seems -1 does not work as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-3535) management-message-attribute-size-limit = -1 does not unlimit
[
https://issues.apache.org/jira/browse/ARTEMIS-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431070#comment-17431070
]
Domenico Francesco Bruscino edited comment on ARTEMIS-3535 at 10/20/21, 8:59 AM:
-
I'm not able to reproduce this issue executing the following steps:
1) create a broker instance `./bin/artemis create broker --user admin
--password admin --require-login`
2) set management-message-attribute-size-limit to -1 `sed -i
's//-1<\/management-message-attribute-size-limit>/g'
./broker/etc/broker.xml`
3) run the broker instance `./broker/bin/artemis run`
4) send a text message with 2000 characters `./broker/bin/artemis producer
--destination queue://TEST.QUEUE --user admin --password admin --protocol core
--message-count 1 --text-size 2000`
Could you add further details to reproduce this issue?
was (Author: brusdev):
I'm not able to reproduce this issue executing the following steps:
1) create a broker instance `./bin/artemis create broker --user admin
--password admin --require-login`
2) set management-message-attribute-size-limit to -1 `sed -i
's//-1<\/management-message-attribute-size-limit>/g'
./broker/etc/broker.xml`
3) run the broker instance `./broker/bin/artemis run`
4) send a text message with 2000 characters `./broker/bin/artemis producer
--destination queue://TEST.QUEUE --user admin --password admin --protocol core
--message-count 1 --text-size 2000`
> management-message-attribute-size-limit = -1 does not unlimit
> -
>
> Key: ARTEMIS-3535
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3535
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
> Environment: A' Artems 2.19.0
>Reporter: arne anka
>Priority: Major
>
> With the new option messages are truncated.
> [https://activemq.apache.org/components/artemis/documentation/latest/versions.html]
> states for 2.18.0 that this may be overriden by using
> -1
> as value. But that doesn't work.
> {{broker.xml}}
> {code:xml}
>
> ...
>
> -1
>
> {code}
> Text shown is empty.
> Changing -1 to eg 1024 text appears partially.
> Seems -1 does not work as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3535) management-message-attribute-size-limit = -1 does not unlimit
[
https://issues.apache.org/jira/browse/ARTEMIS-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431070#comment-17431070
]
Domenico Francesco Bruscino commented on ARTEMIS-3535:
--
I'm not able to reproduce this issue executing the following steps:
1) create a broker instance `./bin/artemis create broker --user admin
--password admin --require-login`
2) set management-message-attribute-size-limit to -1 `sed -i
's//-1<\/management-message-attribute-size-limit>/g'
./broker/etc/broker.xml`
3) run the broker instance `./broker/bin/artemis run`
4) send a text message with 2000 characters `./broker/bin/artemis producer
--destination queue://TEST.QUEUE --user admin --password admin --protocol core
--message-count 1 --text-size 2000`
> management-message-attribute-size-limit = -1 does not unlimit
> -
>
> Key: ARTEMIS-3535
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3535
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
> Environment: A' Artems 2.19.0
>Reporter: arne anka
>Priority: Major
>
> With the new option messages are truncated.
> [https://activemq.apache.org/components/artemis/documentation/latest/versions.html]
> states for 2.18.0 that this may be overriden by using
> -1
> as value. But that doesn't work.
> {{broker.xml}}
> {code:xml}
>
> ...
>
> -1
>
> {code}
> Text shown is empty.
> Changing -1 to eg 1024 text appears partially.
> Seems -1 does not work as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3536) version 2.19.0 released but not "Affects Version/s"
[ https://issues.apache.org/jira/browse/ARTEMIS-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431065#comment-17431065 ] Robbie Gemmell commented on ARTEMIS-3536: - It is available in the dropdown, it just isnt marked 'released' yet so it is lower down the list until it is. > version 2.19.0 released but not "Affects Version/s" > --- > > Key: ARTEMIS-3536 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3536 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: arne anka >Priority: Major > > As per > [https://activemq.apache.org/components/artemis/documentation/latest/versions.html] > and the download page, 2.19.0 has been released officially. > Yet, it is not vaialbale as version in the > Affects Version/s > dropdown above. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3533) Have federation configuration respect extra url parameters from the connector-ref
[ https://issues.apache.org/jira/browse/ARTEMIS-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431062#comment-17431062 ] ASF subversion and git services commented on ARTEMIS-3533: -- Commit 3259791bbb54e6241246618bb8f097370976cc34 in activemq-artemis's branch refs/heads/main from gtully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3259791 ] ARTEMIS-3533 - respect extra url parameters from federation connector-ref > Have federation configuration respect extra url parameters from the > connector-ref > - > > Key: ARTEMIS-3533 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3533 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.18.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > > a connector ref with a url of the form: > "tcp://localhost:61616?ackBatchSize=100=-1" > should be capable of configuring the ServerLocator used by a federation > client. > These are ignored by the transport connector but are captured as > extraParameters in the internal configuration. > It is simply a case of applying them. currently they are ignored! > This is better than duplicating additional serverLocator configuration in > federation configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3533) Have federation configuration respect extra url parameters from the connector-ref
[ https://issues.apache.org/jira/browse/ARTEMIS-3533?focusedWorklogId=667545=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-667545 ] ASF GitHub Bot logged work on ARTEMIS-3533: --- Author: ASF GitHub Bot Created on: 20/Oct/21 08:44 Start Date: 20/Oct/21 08:44 Worklog Time Spent: 10m Work Description: gtully merged pull request #3803: URL: https://github.com/apache/activemq-artemis/pull/3803 -- 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: 667545) Time Spent: 20m (was: 10m) > Have federation configuration respect extra url parameters from the > connector-ref > - > > Key: ARTEMIS-3533 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3533 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Federation >Affects Versions: 2.18.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.20.0 > > Time Spent: 20m > Remaining Estimate: 0h > > a connector ref with a url of the form: > "tcp://localhost:61616?ackBatchSize=100=-1" > should be capable of configuring the ServerLocator used by a federation > client. > These are ignored by the transport connector but are captured as > extraParameters in the internal configuration. > It is simply a case of applying them. currently they are ignored! > This is better than duplicating additional serverLocator configuration in > federation configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3308) Federated queue will not move large messages
[
https://issues.apache.org/jira/browse/ARTEMIS-3308?focusedWorklogId=667541=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-667541
]
ASF GitHub Bot logged work on ARTEMIS-3308:
---
Author: ASF GitHub Bot
Created on: 20/Oct/21 08:43
Start Date: 20/Oct/21 08:43
Worklog Time Spent: 10m
Work Description: gtully commented on pull request #3802:
URL: https://github.com/apache/activemq-artemis/pull/3802#issuecomment-947454614
the bridge does handle large messages, but the consumer is local and the
producer is remote, so the large message is present for the producers.
with federation, the consumer is remote, so the core client needs to deal
with the large message chunks, prepare a server large message and then route.
good thinking though :-)
--
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: 667541)
Time Spent: 40m (was: 0.5h)
> Federated queue will not move large messages
>
>
> Key: ARTEMIS-3308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3308
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Federation
>Affects Versions: 2.17.0
> Environment: Windows 10 Pro (jdk 1.8 oracle last) artemis 2.17.0
>Reporter: Alexander Andreevich Revkov
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Hello. I'am create two artemis broker:
> artemis01:
> {code:java}
> artemis create --max-hops=1 artemis01{code}
> artemis02:
> {code:java}
> artemis create --max-hops=1 --port-offset=10 artemis02{code}
> user: artemis
> password: artemis
>
> In artemis01/etc/broker.xml i add:
>
> {code:java}
>
>tcp://localhost:61626
>
>
>
>
>
> artemis02-connector
>
>
>
> include-federated="false">
>
>
>
> {code}
> then run both brokers.
> I send large message to artemis02:
> {code:java}
> artemis producer --url tcp://localhost:61626 --text-size 800
> --destination TEST.FEDERATED --message-count 1 --user artemis --password
> artemis{code}
> And then try get it from artemis01:
> {code:java}
> artemis consumer --url tcp://localhost:61616 --destination TEST.FEDERATED
> --message-count 1 --user artemis --password artemis{code}
> But i can't received message. Consumer stuck it loop. And artemis01 write in
> logs many NPE:
> {code:java}
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,001 DEBUG
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ843017:
> onMessageRouteError message: ClientLargeMessageImpl[messageID=1518976,
> durable=true,
> address=TEST.FEDERATED::TEST.FEDERATED,userID=50cb6a04-b8bd-11eb-85ab-00155d7523cb,properties=TypedProperties[__AMQ_CID=50bf3501-b8bd-11eb-85ab-00155d7523cb,_AMQ_ROUTING_TYPE=1,count=0,_AMQ_LARGE_SIZE=16014077,ThreadSent=Producer
> ActiveMQQueue[TEST.FEDERATED], thread=0]], with context:
> RoutingContextImpl(Address=null, routingType=null, PreviousAddress=null
> previousRoute:null, reusable=false, version=0)
> ..
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,002 INFO
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ841018: error
> routing message with ID: 1518976, exception: java.lang.NullPointerException
> {code}
>
> I see some source code and find what NPE occurs in CoreMessage.java class at
> 717 line because buffer is NULL:
> {code:java}
> buffer.setIndex(0, 0);{code}
> Not large messages works fine. Please fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3308) Federated queue will not move large messages
[
https://issues.apache.org/jira/browse/ARTEMIS-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431060#comment-17431060
]
ASF subversion and git services commented on ARTEMIS-3308:
--
Commit cf85d35355a4c9965a1916066bfdde821c8a84bb in activemq-artemis's branch
refs/heads/main from gtully
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=cf85d35 ]
ARTEMIS-3308 - support federation of large messages
> Federated queue will not move large messages
>
>
> Key: ARTEMIS-3308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3308
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Federation
>Affects Versions: 2.17.0
> Environment: Windows 10 Pro (jdk 1.8 oracle last) artemis 2.17.0
>Reporter: Alexander Andreevich Revkov
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Hello. I'am create two artemis broker:
> artemis01:
> {code:java}
> artemis create --max-hops=1 artemis01{code}
> artemis02:
> {code:java}
> artemis create --max-hops=1 --port-offset=10 artemis02{code}
> user: artemis
> password: artemis
>
> In artemis01/etc/broker.xml i add:
>
> {code:java}
>
>tcp://localhost:61626
>
>
>
>
>
> artemis02-connector
>
>
>
> include-federated="false">
>
>
>
> {code}
> then run both brokers.
> I send large message to artemis02:
> {code:java}
> artemis producer --url tcp://localhost:61626 --text-size 800
> --destination TEST.FEDERATED --message-count 1 --user artemis --password
> artemis{code}
> And then try get it from artemis01:
> {code:java}
> artemis consumer --url tcp://localhost:61616 --destination TEST.FEDERATED
> --message-count 1 --user artemis --password artemis{code}
> But i can't received message. Consumer stuck it loop. And artemis01 write in
> logs many NPE:
> {code:java}
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,001 DEBUG
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ843017:
> onMessageRouteError message: ClientLargeMessageImpl[messageID=1518976,
> durable=true,
> address=TEST.FEDERATED::TEST.FEDERATED,userID=50cb6a04-b8bd-11eb-85ab-00155d7523cb,properties=TypedProperties[__AMQ_CID=50bf3501-b8bd-11eb-85ab-00155d7523cb,_AMQ_ROUTING_TYPE=1,count=0,_AMQ_LARGE_SIZE=16014077,ThreadSent=Producer
> ActiveMQQueue[TEST.FEDERATED], thread=0]], with context:
> RoutingContextImpl(Address=null, routingType=null, PreviousAddress=null
> previousRoute:null, reusable=false, version=0)
> ..
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,002 INFO
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ841018: error
> routing message with ID: 1518976, exception: java.lang.NullPointerException
> {code}
>
> I see some source code and find what NPE occurs in CoreMessage.java class at
> 717 line because buffer is NULL:
> {code:java}
> buffer.setIndex(0, 0);{code}
> Not large messages works fine. Please fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3308) Federated queue will not move large messages
[
https://issues.apache.org/jira/browse/ARTEMIS-3308?focusedWorklogId=667542=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-667542
]
ASF GitHub Bot logged work on ARTEMIS-3308:
---
Author: ASF GitHub Bot
Created on: 20/Oct/21 08:43
Start Date: 20/Oct/21 08:43
Worklog Time Spent: 10m
Work Description: gtully merged pull request #3802:
URL: https://github.com/apache/activemq-artemis/pull/3802
--
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: 667542)
Time Spent: 50m (was: 40m)
> Federated queue will not move large messages
>
>
> Key: ARTEMIS-3308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3308
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Federation
>Affects Versions: 2.17.0
> Environment: Windows 10 Pro (jdk 1.8 oracle last) artemis 2.17.0
>Reporter: Alexander Andreevich Revkov
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hello. I'am create two artemis broker:
> artemis01:
> {code:java}
> artemis create --max-hops=1 artemis01{code}
> artemis02:
> {code:java}
> artemis create --max-hops=1 --port-offset=10 artemis02{code}
> user: artemis
> password: artemis
>
> In artemis01/etc/broker.xml i add:
>
> {code:java}
>
>tcp://localhost:61626
>
>
>
>
>
> artemis02-connector
>
>
>
> include-federated="false">
>
>
>
> {code}
> then run both brokers.
> I send large message to artemis02:
> {code:java}
> artemis producer --url tcp://localhost:61626 --text-size 800
> --destination TEST.FEDERATED --message-count 1 --user artemis --password
> artemis{code}
> And then try get it from artemis01:
> {code:java}
> artemis consumer --url tcp://localhost:61616 --destination TEST.FEDERATED
> --message-count 1 --user artemis --password artemis{code}
> But i can't received message. Consumer stuck it loop. And artemis01 write in
> logs many NPE:
> {code:java}
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,001 DEBUG
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ843017:
> onMessageRouteError message: ClientLargeMessageImpl[messageID=1518976,
> durable=true,
> address=TEST.FEDERATED::TEST.FEDERATED,userID=50cb6a04-b8bd-11eb-85ab-00155d7523cb,properties=TypedProperties[__AMQ_CID=50bf3501-b8bd-11eb-85ab-00155d7523cb,_AMQ_ROUTING_TYPE=1,count=0,_AMQ_LARGE_SIZE=16014077,ThreadSent=Producer
> ActiveMQQueue[TEST.FEDERATED], thread=0]], with context:
> RoutingContextImpl(Address=null, routingType=null, PreviousAddress=null
> previousRoute:null, reusable=false, version=0)
> ..
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,002 INFO
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ841018: error
> routing message with ID: 1518976, exception: java.lang.NullPointerException
> {code}
>
> I see some source code and find what NPE occurs in CoreMessage.java class at
> 717 line because buffer is NULL:
> {code:java}
> buffer.setIndex(0, 0);{code}
> Not large messages works fine. Please fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3523) Expose replay through AddressControl
[
https://issues.apache.org/jira/browse/ARTEMIS-3523?focusedWorklogId=667513=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-667513
]
ASF GitHub Bot logged work on ARTEMIS-3523:
---
Author: ASF GitHub Bot
Created on: 20/Oct/21 08:17
Start Date: 20/Oct/21 08:17
Worklog Time Spent: 10m
Work Description: nbrendah commented on a change in pull request #3801:
URL: https://github.com/apache/activemq-artemis/pull/3801#discussion_r732523600
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/management/impl/ActiveMQServerControlImpl.java
##
@@ -4443,7 +4443,7 @@ public void reloadConfigurationFile() throws Exception {
@Override
public void replay(String address, String target, String filter) throws
Exception {
- server.replay(null, null, address, target, filter);
+ server.replay(null, null, this.getAddressInfo(address), target, filter);
Review comment:
Hello @clebertsuconic
Thank you so much for making this more clear. All existing tests are
passing but i am out of opinions on how to create tests match this logic.
Thank you so much.
--
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: 667513)
Time Spent: 40m (was: 0.5h)
> Expose replay through AddressControl
>
>
> Key: ARTEMIS-3523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3523
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Clebert Suconic
>Priority: Major
> Labels: easy
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently there is a method replay on ActiveMQServer with the following
> signature:
> replay(address, .)
> it should be a lot easier for our users to implement a method replay on the
> ActiveMQServerControl
> such method should just call server.replay(this.address, .)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-3536) version 2.19.0 released but not "Affects Version/s"
arne anka created ARTEMIS-3536: -- Summary: version 2.19.0 released but not "Affects Version/s" Key: ARTEMIS-3536 URL: https://issues.apache.org/jira/browse/ARTEMIS-3536 Project: ActiveMQ Artemis Issue Type: Bug Reporter: arne anka As per [https://activemq.apache.org/components/artemis/documentation/latest/versions.html] and the download page, 2.19.0 has been released officially. Yet, it is not vaialbale as version in the Affects Version/s dropdown above. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3535) management-message-attribute-size-limit = -1 does not unlimit
arne anka created ARTEMIS-3535:
--
Summary: management-message-attribute-size-limit = -1 does not
unlimit
Key: ARTEMIS-3535
URL: https://issues.apache.org/jira/browse/ARTEMIS-3535
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Web Console
Environment: A' Artems 2.19.0
Reporter: arne anka
With the new option messages are truncated.
[https://activemq.apache.org/components/artemis/documentation/latest/versions.html]
states for 2.18.0 that this may be overriden by using
-1
as value. But that doesn't work.
{{broker.xml}}
{code:xml}
...
-1
{code}
Text shown is empty.
Changing -1 to eg 1024 text appears partially.
Seems -1 does not work as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3141) limit the amount of data returned from jmx/queue control listMessages
[ https://issues.apache.org/jira/browse/ARTEMIS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431035#comment-17431035 ] arne anka commented on ARTEMIS-3141: [~jbertram] [~gtully] Shouldn't the message body in Managment Console -> Browse Queue -> Show the not be provided by different means instead of a truncated attribute? I rather often need to check messages in a DLQ, but with the new truncation, the messages are always too short (and -1 does not work, see above). If populating with too large a property is an issue in several places, the message body as attribute seems to be a misfit, doesn't it? > limit the amount of data returned from jmx/queue control listMessages > - > > Key: ARTEMIS-3141 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3141 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JMX >Affects Versions: 2.17.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.18.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The list methods of queue control that are exposed via jmx seem to be > unbounded. > 1) they list all messages > 2) they display the full body > To protect both the broker and the browser/UI/client it would make sense to > limit both the number of messages and the size of the data that is returned. > Imaging 500k messages pending messages with a body of 10k... and 400k are > paged to disk. It would be crazy to try and list those. > I need to do some more tests to verify the extent a broker will do to support > the current api. I note that the browse functionality can be paged and with > out a page defaults to 200 messages. That is sensible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3531) adding documentation for management-message-attribute-size-limit
[ https://issues.apache.org/jira/browse/ARTEMIS-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431033#comment-17431033 ] arne anka commented on ARTEMIS-3531: [~erwindon] So? My comment explicitly addressed that – and added emphasis to it's priority mismatch. Documentation _must not_ be a separate issue and at low priority at that. > adding documentation for management-message-attribute-size-limit > > > Key: ARTEMIS-3531 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3531 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.18.0, 2.19.0 >Reporter: Erwin Dondorp >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > The documentation pages do not mention configuration parameter > `management-message-attribute-size-limit`. This parameter is used to control > which part (size) of the messages can be browsed. it was introduced in 2.18.0 > to solve out-of-memory problems. > PR will be supplied... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3308) Federated queue will not move large messages
[
https://issues.apache.org/jira/browse/ARTEMIS-3308?focusedWorklogId=667469=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-667469
]
ASF GitHub Bot logged work on ARTEMIS-3308:
---
Author: ASF GitHub Bot
Created on: 20/Oct/21 06:58
Start Date: 20/Oct/21 06:58
Worklog Time Spent: 10m
Work Description: michaelandrepearce commented on pull request #3802:
URL: https://github.com/apache/activemq-artemis/pull/3802#issuecomment-947382929
As that code was based a bit from bridge code, does that mean bridge does
not support large msg? Or has that already been handled?
--
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: 667469)
Time Spent: 0.5h (was: 20m)
> Federated queue will not move large messages
>
>
> Key: ARTEMIS-3308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3308
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, Federation
>Affects Versions: 2.17.0
> Environment: Windows 10 Pro (jdk 1.8 oracle last) artemis 2.17.0
>Reporter: Alexander Andreevich Revkov
>Assignee: Gary Tully
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hello. I'am create two artemis broker:
> artemis01:
> {code:java}
> artemis create --max-hops=1 artemis01{code}
> artemis02:
> {code:java}
> artemis create --max-hops=1 --port-offset=10 artemis02{code}
> user: artemis
> password: artemis
>
> In artemis01/etc/broker.xml i add:
>
> {code:java}
>
>tcp://localhost:61626
>
>
>
>
>
> artemis02-connector
>
>
>
> include-federated="false">
>
>
>
> {code}
> then run both brokers.
> I send large message to artemis02:
> {code:java}
> artemis producer --url tcp://localhost:61626 --text-size 800
> --destination TEST.FEDERATED --message-count 1 --user artemis --password
> artemis{code}
> And then try get it from artemis01:
> {code:java}
> artemis consumer --url tcp://localhost:61616 --destination TEST.FEDERATED
> --message-count 1 --user artemis --password artemis{code}
> But i can't received message. Consumer stuck it loop. And artemis01 write in
> logs many NPE:
> {code:java}
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,001 DEBUG
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ843017:
> onMessageRouteError message: ClientLargeMessageImpl[messageID=1518976,
> durable=true,
> address=TEST.FEDERATED::TEST.FEDERATED,userID=50cb6a04-b8bd-11eb-85ab-00155d7523cb,properties=TypedProperties[__AMQ_CID=50bf3501-b8bd-11eb-85ab-00155d7523cb,_AMQ_ROUTING_TYPE=1,count=0,_AMQ_LARGE_SIZE=16014077,ThreadSent=Producer
> ActiveMQQueue[TEST.FEDERATED], thread=0]], with context:
> RoutingContextImpl(Address=null, routingType=null, PreviousAddress=null
> previousRoute:null, reusable=false, version=0)
> ..
> * durable queues TEST.FEDERATED:
> - queueID=30 address:TEST.FEDERATED name:TEST.FEDERATED filter:null
> * non durable for TEST.FEDERATED:
> ..
> , direct: true, rejectDuplicates: true
> 2021-05-19 19:27:18,002 INFO
> [org.apache.activemq.artemis.core.server.plugin.impl] AMQ841018: error
> routing message with ID: 1518976, exception: java.lang.NullPointerException
> {code}
>
> I see some source code and find what NPE occurs in CoreMessage.java class at
> 717 line because buffer is NULL:
> {code:java}
> buffer.setIndex(0, 0);{code}
> Not large messages works fine. Please fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
