[jira] [Work logged] (ARTEMIS-2523) Deprecate the parameter failoverOnInitialConnection

2019-10-19 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 19/Oct/19 23:55
Start Date: 19/Oct/19 23:55
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on issue #2866: ARTEMIS-2523 
Deprecate the parameter failoverOnInitialConnection
URL: https://github.com/apache/activemq-artemis/pull/2866#issuecomment-544206991
 
 
   LGTM however there's a real test failure shown on the PR check. We can merge 
this after fixed.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Deprecate the parameter failoverOnInitialConnection
> ---
>
> Key: ARTEMIS-2523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2523
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The parameter failoverOnInitialConnection wouldn't seem to be used and I can't
> understand the sense of this parameter because the failover will not occur
> if the client fails to make an initial connection to the live server
> ([https://activemq.apache.org/components/artemis/documentation/latest/ha.html#failing-over-on-the-initial-connection]).
>  So I think the parameter could be deprecated from the API.
> The topic is discussed at 
> [https://activemq.markmail.org/thread/ryf32vhjrwc4e7yf]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7249) Upgrade to Camel 2.24.1 and Jetty 9.4.19

2019-10-19 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 19/Oct/19 13:37
Start Date: 19/Oct/19 13:37
Worklog Time Spent: 10m 
  Work Description: jbonofre commented on issue #388: [AMQ-7249] Upgrade to 
Scala 2.13.0
URL: https://github.com/apache/activemq/pull/388#issuecomment-544144586
 
 
   Note: scala is only used in leveldb which is now deprecated. I don't 
consider this one as a blocker as we should remove leveldb from the codebase.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Upgrade to Camel 2.24.1 and Jetty 9.4.19
> 
>
> Key: AMQ-7249
> URL: https://issues.apache.org/jira/browse/AMQ-7249
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-camel
>Affects Versions: 5.15.9
>Reporter: Harish Kumar
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
>  Labels: Apache, camel-core
> Fix For: 5.16.0, 5.15.10
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Latest version of ActiveMQ(5.15.9) which has dependent jars has Security 
> Vulnerabilities.
> *Below are the jars with Security Vulnerabilities.*
>  
> *1) camel-core-2.19.5.jar :* To be updated to latest 
> version(camel-core-2.24.1.jar or above).
> *Reference* : CVE-2019-0188 
> *Path :* org.apache.activemq-5.15.9_1/lib/camel/camel-core-2.19.5.jar
>  
> *2) apache-jsp-9.2.25.v20180606.jar:* To be updated to latest version 
> (apache-jsp-9.4.19.v20190610.jar) 
> *Reference:* CVE-2018-8014 , CVE-2018-8034, CVE-2019-10241, 
> CVE-2019-10247,CVE-2017-6056
>  
> *Path:* org.apache.activemq-5.15.9_1/lib/web/apache-jsp-8.0.33.jar
>         : org.apache.activemq-5.15.9_1/lib/web/apache-jsp-9.2.25.v20180606.jar
>  
> 3) *scala-library-2.11.0.jar:* To be updated to 2.13.0 version. ActiveMQ 
> library has dependency with scala-library.jar
> *Path:* org.apache.activemq-5.15.9_1/lib/optional/scala-library-2.11.0.jar
> *Reference:*  [https://nvd.nist.gov/vuln/detail/CVE-2017-15288]
> Need to upgrade the above jars to the the recommended version or provide an 
> alternative way to replace the existing jar version with the updated versions.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2523) Deprecate the parameter failoverOnInitialConnection

2019-10-19 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 19/Oct/19 09:40
Start Date: 19/Oct/19 09:40
Worklog Time Spent: 10m 
  Work Description: brusdev commented on pull request #2866: ARTEMIS-2523 
Deprecate the parameter failoverOnInitialConnection
URL: https://github.com/apache/activemq-artemis/pull/2866
 
 
   The parameter failoverOnInitialConnection wouldn't seem to be used and
   makes no sense any more, because the connectors are retried in a loop.
   So someone can just add the backup in the initial connection.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Deprecate the parameter failoverOnInitialConnection
> ---
>
> Key: ARTEMIS-2523
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2523
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The parameter failoverOnInitialConnection wouldn't seem to be used and I can't
> understand the sense of this parameter because the failover will not occur
> if the client fails to make an initial connection to the live server
> ([https://activemq.apache.org/components/artemis/documentation/latest/ha.html#failing-over-on-the-initial-connection]).
>  So I think the parameter could be deprecated from the API.
> The topic is discussed at 
> [https://activemq.markmail.org/thread/ryf32vhjrwc4e7yf]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.

2019-10-18 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 18/Oct/19 18:49
Start Date: 18/Oct/19 18:49
Worklog Time Spent: 10m 
  Work Description: jbonofre commented on issue #326: AMQ-7118: fix issue 
with the unchanged acknowledgement map.
URL: https://github.com/apache/activemq/pull/326#issuecomment-543885060
 
 
   It has been already applied.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> KahaDB store limit can be exceeded with durable subscribers.
> 
>
> Key: AMQ-7118
> URL: https://issues.apache.org/jira/browse/AMQ-7118
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB
>Affects Versions: 5.16.0, 5.15.8
> Environment: JDK 8
>Reporter: Jamie Mark Goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.8
>
> Attachments: kahaCommands.jpg
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> KahaDB store limit can be exceeded with durable subscribers.
> AMQ with store limit set, we can observe that the usage continues to increase 
> AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having 
> exceeded the store limit remains.
> See below output from KahaDB dump in attachments:
> This appears to be caused by checkpointAckMessageFileMap. The log files are 
> not GC'd, and the KAHA_ACK_MESSAGE_FILE_MAP_COMMAND is replicated and the DB 
> log files continue to expand - this can become exponential. Side effect of 
> also not checking storage size in checkpoint update can cause the DB log 
> files to exceed any set limits. The real critical part is the duplicated and 
> leaking Kaha messages which appears to happen with durable subscribers.
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.

2019-10-18 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 18/Oct/19 18:49
Start Date: 18/Oct/19 18:49
Worklog Time Spent: 10m 
  Work Description: jbonofre commented on pull request #326: AMQ-7118: fix 
issue with the unchanged acknowledgement map.
URL: https://github.com/apache/activemq/pull/326
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> KahaDB store limit can be exceeded with durable subscribers.
> 
>
> Key: AMQ-7118
> URL: https://issues.apache.org/jira/browse/AMQ-7118
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB
>Affects Versions: 5.16.0, 5.15.8
> Environment: JDK 8
>Reporter: Jamie Mark Goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.8
>
> Attachments: kahaCommands.jpg
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> KahaDB store limit can be exceeded with durable subscribers.
> AMQ with store limit set, we can observe that the usage continues to increase 
> AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having 
> exceeded the store limit remains.
> See below output from KahaDB dump in attachments:
> This appears to be caused by checkpointAckMessageFileMap. The log files are 
> not GC'd, and the KAHA_ACK_MESSAGE_FILE_MAP_COMMAND is replicated and the DB 
> log files continue to expand - this can become exponential. Side effect of 
> also not checking storage size in checkpoint update can cause the DB log 
> files to exceed any set limits. The real critical part is the duplicated and 
> leaking Kaha messages which appears to happen with durable subscribers.
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7055) Small optimization on SequenceSet to prevent iterating through the whole set when a value bigger than the last value is added

2019-10-18 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 18/Oct/19 18:45
Start Date: 18/Oct/19 18:45
Worklog Time Spent: 10m 
  Work Description: jbonofre commented on issue #300: AMQ-7055 - 
Optimization on SequenceSet to prevent iterating through t…
URL: https://github.com/apache/activemq/pull/300#issuecomment-543883392
 
 
   This change has been already applied.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Small optimization on SequenceSet to prevent iterating through the whole set 
> when a value bigger than the last value is added
> -
>
> Key: AMQ-7055
> URL: https://issues.apache.org/jira/browse/AMQ-7055
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Assignee: Gary Tully
>Priority: Minor
> Fix For: 5.16.0, 5.15.7
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When the index file has a huge number of free pages and the broker is 
> starting up (loading the index) we end up in a O(n2) loop.
> This was causing the broker to use 100% cpu and not being able to start up 
> even after a long time (as i remember we had around 3 millions free page in 
> this case)
> [https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/page/PageFile.java#L428]
> https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/util/SequenceSet.java#L118
> I noticed that almost all the free pages was being added to the end of the 
> sequenceSet... So for any free page the broker had to necessity iterate 
> through  all the Set (and after doing that for nothing add . the value to the 
> tail).
> With this small change, the broker started up in less than 5 minutes.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7055) Small optimization on SequenceSet to prevent iterating through the whole set when a value bigger than the last value is added

2019-10-18 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 18/Oct/19 18:45
Start Date: 18/Oct/19 18:45
Worklog Time Spent: 10m 
  Work Description: jbonofre commented on pull request #300: AMQ-7055 - 
Optimization on SequenceSet to prevent iterating through t…
URL: https://github.com/apache/activemq/pull/300
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Small optimization on SequenceSet to prevent iterating through the whole set 
> when a value bigger than the last value is added
> -
>
> Key: AMQ-7055
> URL: https://issues.apache.org/jira/browse/AMQ-7055
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: KahaDB
>Affects Versions: 5.15.6
>Reporter: Alan Protasio
>Assignee: Gary Tully
>Priority: Minor
> Fix For: 5.16.0, 5.15.7
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When the index file has a huge number of free pages and the broker is 
> starting up (loading the index) we end up in a O(n2) loop.
> This was causing the broker to use 100% cpu and not being able to start up 
> even after a long time (as i remember we had around 3 millions free page in 
> this case)
> [https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/page/PageFile.java#L428]
> https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/util/SequenceSet.java#L118
> I noticed that almost all the free pages was being added to the end of the 
> sequenceSet... So for any free page the broker had to necessity iterate 
> through  all the Set (and after doing that for nothing add . the value to the 
> tail).
> With this small change, the broker started up in less than 5 minutes.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7312) virtualSelectorCacheBrokerPlugin fails on "browse" action

2019-10-18 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 18/Oct/19 17:09
Start Date: 18/Oct/19 17:09
Worklog Time Spent: 10m 
  Work Description: jbonofre commented on pull request #395: AMQ-7312 
virtualSelectorCacheBrokerPlugin addConsumer issue
URL: https://github.com/apache/activemq/pull/395
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> virtualSelectorCacheBrokerPlugin fails on "browse" action
> -
>
> Key: AMQ-7312
> URL: https://issues.apache.org/jira/browse/AMQ-7312
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.15.10
>Reporter: Dany LECOQ
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 5.16.0, 5.15.11
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We have a VirtualTopic "VirtualTopic.multi_dest" and 2 consumers :
>  * Consumer.alpha.VirtualTopic.multi_dest
>  * Consumer.beta.VirtualTopic.multi_dest
> Message producer send messages on that vTopic with various "tenant" header 
> value.
> Each consumer use a selector to receive only desired data :
>  * tenant='alpha' for Consumer.alpha.VirtualTopic.multi_dest
>  * tenant='beta' for Consumer.beta.VirtualTopic.multi_dest
> To avoid to get many pending message on each consumer queue, we activated 
> selectorAware="true" in broker settings.
> To avoid to lose message on temporary consumer deconnection, we activated 
> virtualSelectorCacheBrokerPlugin plugin.
> Steps to reproduce bug :
>  * launch message producer and both message consumers alpha and beta
>  * stop alpha consumer
>  * notice on console pending messages on alpha queue increase
>  * if we restart alpha consumer, all pending messages are consumed => ok, 
> only messages matching selector were in queue
>  * restop alpha consumer
>  * go on console and click on "Browse" link for alpha consumer queue
>  * restart alpha consumer => it will consume pending messages matching 
> selector
>  * notice there are other waiting messages that do not match selector, so the 
> consumer queue is fastly full of useless messages => ko
>  * even after broker restart, the alpha consumer queue continues to receive 
> message that do not match selectors => ko
>  
> After code analysis, I notice "Browse" action create a new consumer on queue. 
> In virtualSelectorCacheBrokerPlugin, the addConsumer method update 
> "subSelectorCache" variable with 'TRUE' selector.
>  
> A pull request is submitted to fix that issue 
> ([https://github.com/apache/activemq/pull/395]), could you merge it for the 
> next patch 5.15.11 ?
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7130) bug tracking link is pointing to wrong url

2019-10-18 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 18/Oct/19 17:05
Start Date: 18/Oct/19 17:05
Worklog Time Spent: 10m 
  Work Description: jbonofre commented on pull request #399: AMQ-7130 
Update AMQ doap
URL: https://github.com/apache/activemq/pull/399
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 330655)
Remaining Estimate: 167h 40m  (was: 167h 50m)
Time Spent: 20m  (was: 10m)

> bug tracking link is pointing to wrong url
> --
>
> Key: AMQ-7130
> URL: https://issues.apache.org/jira/browse/AMQ-7130
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 5.15.8
> Environment: MacOS High Sierra, 10.13.6
> Processor: 2.8 GHz Intel Core i7
> Memory: 16 GB 2133 MHz LPDDR3
> Graphics: Intel HD Graphics 630 1536 MB
>  
>  
>Reporter: Shubham Gupta
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
>  Labels: documentation
> Fix For: 5.x
>
>   Original Estimate: 168h
>  Time Spent: 20m
>  Remaining Estimate: 167h 40m
>
> Hello,
> I was browsing through the documentation. I landed up in the page-> 
> [https://projects.apache.org/project.html?activemq|https://projects.apache.org/project.html?activemq.]
> In the Bug-Tracking: [http://issues.apache.org/activemq/browse/AMQ] , URL is 
> wrong, it gives 404 Page Not Found. I think the correct would be 
> [https://issues.apache.org/jira/projects/AMQ] 
> I can take up this task, if someone point to the git location or any other 
> pointers would be good.
> Thanks!
> Regards,
> Shubham Gupta
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7322) Add HTTPOnly flag to the webconsole + REST API Cookies

2019-10-18 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 18/Oct/19 17:03
Start Date: 18/Oct/19 17:03
Worklog Time Spent: 10m 
  Work Description: jbonofre commented on pull request #400: AMQ-7322 - Add 
HTTPOnly flag to the webconsole + REST API Cookies
URL: https://github.com/apache/activemq/pull/400
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Add HTTPOnly flag to the webconsole + REST API Cookies
> --
>
> Key: AMQ-7322
> URL: https://issues.apache.org/jira/browse/AMQ-7322
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: webconsole
>Reporter: Colm O hEigeartaigh
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0, 5.15.11
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We should add the HTTPOnly flag to the webconsole + REST API Cookies



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7322) Add HTTPOnly flag to the webconsole + REST API Cookies

2019-10-18 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 18/Oct/19 16:19
Start Date: 18/Oct/19 16:19
Worklog Time Spent: 10m 
  Work Description: coheigea commented on pull request #400: AMQ-7322 - Add 
HTTPOnly flag to the webconsole + REST API Cookies
URL: https://github.com/apache/activemq/pull/400
 
 
   We should add the HTTPOnly flag to the webconsole + REST API Cookies
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Add HTTPOnly flag to the webconsole + REST API Cookies
> --
>
> Key: AMQ-7322
> URL: https://issues.apache.org/jira/browse/AMQ-7322
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Priority: Major
> Fix For: 5.16.0, 5.15.11
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should add the HTTPOnly flag to the webconsole + REST API Cookies



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7130) bug tracking link is pointing to wrong url

2019-10-18 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 18/Oct/19 09:27
Start Date: 18/Oct/19 09:27
Worklog Time Spent: 10m 
  Work Description: coheigea commented on pull request #399: AMQ-7130 
Update AMQ doap
URL: https://github.com/apache/activemq/pull/399
 
 
   https://issues.apache.org/jira/browse/AMQ-7130 is caused by the fact that 
our doap JIRA link is incorrect. Once this PR is merged then 
https://projects.apache.org/project.html?activemq will need to be updated to 
point to git instead of svn.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 330386)
Remaining Estimate: 167h 50m  (was: 168h)
Time Spent: 10m

> bug tracking link is pointing to wrong url
> --
>
> Key: AMQ-7130
> URL: https://issues.apache.org/jira/browse/AMQ-7130
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 5.15.8
> Environment: MacOS High Sierra, 10.13.6
> Processor: 2.8 GHz Intel Core i7
> Memory: 16 GB 2133 MHz LPDDR3
> Graphics: Intel HD Graphics 630 1536 MB
>  
>  
>Reporter: Shubham Gupta
>Priority: Minor
>  Labels: documentation
> Fix For: 5.x
>
>   Original Estimate: 168h
>  Time Spent: 10m
>  Remaining Estimate: 167h 50m
>
> Hello,
> I was browsing through the documentation. I landed up in the page-> 
> [https://projects.apache.org/project.html?activemq|https://projects.apache.org/project.html?activemq.]
> In the Bug-Tracking: [http://issues.apache.org/activemq/browse/AMQ] , URL is 
> wrong, it gives 404 Page Not Found. I think the correct would be 
> [https://issues.apache.org/jira/projects/AMQ] 
> I can take up this task, if someone point to the git location or any other 
> pointers would be good.
> Thanks!
> Regards,
> Shubham Gupta
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-17 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 17/Oct/19 22:07
Start Date: 17/Oct/19 22:07
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on issue #2850: 
ARTEMIS-2504 implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-543381734
 
 
   No further comments from me atm other bits and bobs can always be added 
later in future prs /version and refined over time. Thanks for this @jbertram 
was prob the last big ticket for artemis to be in feature parity with 
activemq5. 
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 330166)
Time Spent: 7h 40m  (was: 7.5h)

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 7h 40m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-17 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 17/Oct/19 20:31
Start Date: 17/Oct/19 20:31
Worklog Time Spent: 10m 
  Work Description: jbertram commented on issue #2850: ARTEMIS-2504 
implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-543349109
 
 
   I added a simple failover test and pushed. Everything looks OK as far as I 
can tell.
   
   As far as the "destructive testing" you mentioned goes, I've done a bit more 
than what is captured in the tests, but nothing I could categorize as 
industrial grade (e.g. no huge loads on big hardware).
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 330125)
Time Spent: 7.5h  (was: 7h 20m)

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-17 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 17/Oct/19 20:30
Start Date: 17/Oct/19 20:30
Worklog Time Spent: 10m 
  Work Description: jbertram commented on issue #2850: ARTEMIS-2504 
implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-543349109
 
 
   I added a simple failover test and push. Everything looks OK as far as I can 
tell.
   
   As far as the "destructive testing" you mentioned goes, I've done a bit more 
than what is captured in the tests, but nothing I could categorize as 
industrial grade (e.g. no huge loads on big hardware).
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 330124)
Time Spent: 7h 20m  (was: 7h 10m)

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 7h 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2420) Reimplementation of AMQ5 dead letter strategy queuePrefix

2019-10-17 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 17/Oct/19 19:44
Start Date: 17/Oct/19 19:44
Worklog Time Spent: 10m 
  Work Description: rcsilva83 commented on issue #2760: ARTEMIS-2420 Adding 
support for DLA/DLQ prefix for wildcard addresses
URL: https://github.com/apache/activemq-artemis/pull/2760#issuecomment-543332194
 
 
   Please, support suffix on "dead-letter-address-auto-create" element too. We 
prefer "Queue.Name.DLQ" so DLQ queues stay close to the original ones in 
alphabetical order. This is how our current ActiveMQ is configured.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 330090)
Remaining Estimate: 0h  (was: 10m)
Time Spent: 12h  (was: 11h 50m)

> Reimplementation of AMQ5 dead letter strategy queuePrefix
> -
>
> Key: ARTEMIS-2420
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2420
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.9.0
>Reporter: Piotr Klimczak
>Priority: Major
>   Original Estimate: 12h
>  Time Spent: 12h
>  Remaining Estimate: 0h
>
> ActiveMQ Classic supports DLQ prefixes for dynamically created destinations.
> This causes regression when switching from AMQ5 to AMQ Artemis, therefore it 
> should be reimplemented.
> *Detailed requirements*
> *Configuration*
>  # Prefix for dead-letter-address-auto-create is mandatory, while the tag 
> itself is optional - DONE
>  # All attributes for dead-letter-address-auto-create are optional, in which 
> case values will be taken from origin queue  - DONE
>  ** routing type for DLQ
>  ** temporary
>  ** durable can be null
>  # DLA settings can be defined with address-settings with wildcard match - 
> DONE
>  # Should throw error if both DLA and auto-create DLA are defined for same AS 
> - *TODO*
> Example
> {code:xml}
>  
> 
>MULTICAST
>true
>false
> 
>  
>  
>  
>  
> {code}
> Questions:
>  # [michaelpearce-gain|https://github.com/michaelpearce-gain]: What occurs if 
> both dead letter address is set and prefix?
>  # [michaelpearce-gain|https://github.com/michaelpearce-gain]: Is there auto 
> clean up, so the auto created dead letter addresses are removed when the 
> original address is removed, in cases of auto creation.
>  # [michaelpearce-gain|https://github.com/michaelpearce-gain]: Also would it 
> be possible to configure a spefiic queue to goto a specific address, taking 
> precedence over the default prefix when set.
>  ** This is how it should work now- *TODO* test coverage
>  # [michaelpearce-gain|https://github.com/michaelpearce-gain]:I dea around 
> security and address creation restrictions, could that both the address and 
> queue settings are checked both for the new address/queue and the dead 
> letter, before it is created. Thus meaning that either both create (because 
> permission and settings allow) or both wouldnt. Thus avoiding the situation 
> of one being created without the other
>  ** Not sure if I understand above- *TODO* get clarification
> *Message delivery to DLQ*
>  # Delivery to dynamic DLQ only happens for messages failed by a consumer - 
> DONE
>  # Delivery to dynamic addresses should happen using FQQN address, regardless 
> of routing - DONE 
>  # [michaelpearce-gain|https://github.com/michaelpearce-gain]: The same 
> should be made for expiryQueues with all the same rules and logic - DONE
> Questions:
>  # Should dynamic DLQ creation also work for messages delivered to an address 
> with no queues?
> *Security*
>  # TODO Consolidate security requirements from original PR: 
> [https://github.com/apache/activemq-artemis/pull/2747]
>  
> Questions:
>  # [michaelpearce-gain|https://github.com/michaelpearce-gain]: What occurs if 
> queue/address is allowed to be created due security settings, but the user 
> able to do that is unable to create the dead letter address? Do both fail? 
> Does one part succeed but the dla fails? And then what occurs?
>  # [michaelpearce-gain|https://github.com/michaelpearce-gain]: What occurs 
> when security settings come into play? How does it fail if you have ability 
> to create address but not dla? Do both fail?
>  
> Links to all 

[jira] [Work logged] (ARTEMIS-2521) Role-mapping not described in documentation

2019-10-17 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 17/Oct/19 15:04
Start Date: 17/Oct/19 15:04
Worklog Time Spent: 10m 
  Work Description: jbertram commented on issue #2865: ARTEMIS-2521 add 
documentation for role-mapping
URL: https://github.com/apache/activemq-artemis/pull/2865#issuecomment-543218430
 
 
   Thanks for the PR!
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Role-mapping not described in documentation
> ---
>
> Key: ARTEMIS-2521
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2521
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Sascha Dirbach
>Priority: Minor
> Fix For: 2.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The role-mapping as implemented in #ARTEMIS-1116 is not explained in the 
> documentation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2521) Role-mapping not described in documentation

2019-10-17 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 17/Oct/19 15:03
Start Date: 17/Oct/19 15:03
Worklog Time Spent: 10m 
  Work Description: asfgit commented on pull request #2865: ARTEMIS-2521 
add documentation for role-mapping
URL: https://github.com/apache/activemq-artemis/pull/2865
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Role-mapping not described in documentation
> ---
>
> Key: ARTEMIS-2521
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2521
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Sascha Dirbach
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The role-mapping as implemented in #ARTEMIS-1116 is not explained in the 
> documentation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2521) Role-mapping not described in documentation

2019-10-17 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 17/Oct/19 15:03
Start Date: 17/Oct/19 15:03
Worklog Time Spent: 10m 
  Work Description: asfgit commented on pull request #2865: ARTEMIS-2521 
add documentation for role-mapping
URL: https://github.com/apache/activemq-artemis/pull/2865
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Role-mapping not described in documentation
> ---
>
> Key: ARTEMIS-2521
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2521
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Sascha Dirbach
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The role-mapping as implemented in #ARTEMIS-1116 is not explained in the 
> documentation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2426) Allow artemis-native loading Libraries from Bundle

2019-10-17 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 17/Oct/19 13:17
Start Date: 17/Oct/19 13:17
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on pull request #4: 
ARTEMIS-2426 Added Bundle-Native code header
URL: https://github.com/apache/activemq-artemis-native/pull/4
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Allow artemis-native loading Libraries from Bundle
> --
>
> Key: ARTEMIS-2426
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2426
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: ActiveMQ-Artemis-Native
>Affects Versions: native-1.0.0
>Reporter: Rico Neubauer
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: native-1.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> artemis-native currently expects the native libraries to be in the native 
> library path on filesystem. The libraries are shipped in the bundle though 
> already.
> There is header _Bundle-Native_ which can be used to declare the path inside 
> the bundle to look for the libraries. The way they get loaded 
> (System.loadLibrary) already matches to find them.
> See section 3.10 in OSGi spec (4.3).
> Will push a PR, which creates the header for x86 and x86-64, since those are 
> the 2 that are also shipped in the bundle.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2503) Improve wildcards for the roles access match

2019-10-17 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 17/Oct/19 08:25
Start Date: 17/Oct/19 08:25
Worklog Time Spent: 10m 
  Work Description: brusdev commented on pull request #2851: ARTEMIS-2503 
Improve wildcards for the roles access match
URL: https://github.com/apache/activemq-artemis/pull/2851#discussion_r335870325
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/JMXAccessControlList.java
 ##
 @@ -25,12 +25,22 @@
 import java.util.Map;
 import java.util.concurrent.ConcurrentHashMap;
 
+import org.apache.activemq.artemis.core.config.WildcardConfiguration;
+import org.apache.activemq.artemis.core.settings.HierarchicalRepository;
+import 
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository;
+
 public class JMXAccessControlList {
 
private Access defaultAccess = new Access("*");
-   private Map domainAccess = new HashMap<>();
+   private HierarchicalRepository domainAccess;
private ConcurrentHashMap> whitelist = new 
ConcurrentHashMap<>();
 
+   public JMXAccessControlList() {
+  WildcardConfiguration domainAccessWildcardConfiguration = new 
WildcardConfiguration();
 
 Review comment:
   I pushed a commit to simplify the improvement.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 329692)
Time Spent: 3.5h  (was: 3h 20m)

> Improve wildcards for the roles access match
> 
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Please improve wildcard support for the key element in the roles access 
>  element.
> ATM you can NOT apply a restriction across a set of queue instances starting 
> with the same prefix (like below):
> {code:java}
> 
>
>
>...
> {code}
> If queues are created dynamically and only a queue name "prefix" is known in 
> advance; JMX RBAC cannot be used to restrict access in this case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2503) Improve wildcards for the roles access match

2019-10-16 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 16/Oct/19 22:22
Start Date: 16/Oct/19 22:22
Worklog Time Spent: 10m 
  Work Description: jbertram commented on pull request #2851: ARTEMIS-2503 
Improve wildcards for the roles access match
URL: https://github.com/apache/activemq-artemis/pull/2851#discussion_r334624011
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/JMXAccessControlList.java
 ##
 @@ -25,12 +25,22 @@
 import java.util.Map;
 import java.util.concurrent.ConcurrentHashMap;
 
+import org.apache.activemq.artemis.core.config.WildcardConfiguration;
+import org.apache.activemq.artemis.core.settings.HierarchicalRepository;
+import 
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository;
+
 public class JMXAccessControlList {
 
private Access defaultAccess = new Access("*");
-   private Map domainAccess = new HashMap<>();
+   private HierarchicalRepository domainAccess;
private ConcurrentHashMap> whitelist = new 
ConcurrentHashMap<>();
 
+   public JMXAccessControlList() {
+  WildcardConfiguration domainAccessWildcardConfiguration = new 
WildcardConfiguration();
 
 Review comment:
   These use-cases seem pretty different to me. The wildcard configuration in 
broker.xml is for address matching which is hierarchical in nature and 
therefore requires separating "words", matching individual and groups of words, 
etc. The "match" performed for keys defined in management.xml is basically just 
a **prefix**. It's not hierarchical and doesn't even use regular expressions. 
It's *very* simple and IMO it should stay that way. 
   
   > If i need to secure a wildcard of address or queues on broker then no 
doubt i need to secure the same pattern from admin pov to.
   
   I'm not sure there is "no doubt" about that. Use cases for the security of 
actual messaging clients and management users can vary quite a bit. In any 
case, the same kind of matching isn't possible in management.xml as it is in 
broker.xml either before or after this PR. The use-case for this PR is just 
allowing a simple prefixing for the match "key" just like is available for the 
access "method" field. The syntax is the same. It's just allowing it in a new 
field. I don't see any issue with that.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 329457)
Time Spent: 3h 20m  (was: 3h 10m)

> Improve wildcards for the roles access match
> 
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Please improve wildcard support for the key element in the roles access 
>  element.
> ATM you can NOT apply a restriction across a set of queue instances starting 
> with the same prefix (like below):
> {code:java}
> 
>
>
>...
> {code}
> If queues are created dynamically and only a queue name "prefix" is known in 
> advance; JMX RBAC cannot be used to restrict access in this case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2521) Role-mapping not described in documentation

2019-10-16 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 16/Oct/19 16:20
Start Date: 16/Oct/19 16:20
Worklog Time Spent: 10m 
  Work Description: sdirbach commented on pull request #2865: ARTEMIS-2521 
add documentation for role-mapping
URL: https://github.com/apache/activemq-artemis/pull/2865
 
 
   Add documentation for role-mapping implemented in ARTEMIS-1116
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Role-mapping not described in documentation
> ---
>
> Key: ARTEMIS-2521
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2521
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Sascha Dirbach
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The role-mapping as implemented in #ARTEMIS-1116 is not explained in the 
> documentation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-15 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 15/Oct/19 07:37
Start Date: 15/Oct/19 07:37
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on issue #2850: 
ARTEMIS-2504 implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-542081191
 
 
   I mean running this a little more than just an integration test. E.g. 
actually deploying to a real environment and do bits like failover, outage, 
client disconnects, multiple consumers on a shared address underload and then a 
new retro consumer
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 328381)
Time Spent: 7h 10m  (was: 7h)

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 7h 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-15 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 15/Oct/19 07:36
Start Date: 15/Oct/19 07:36
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on issue #2850: 
ARTEMIS-2504 implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-542081191
 
 
   I mean running this a little more than just an integration test. E.g. 
actually deploying to a real environment and do bits like failover, outage, 
client disconnects 
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 328380)
Time Spent: 7h  (was: 6h 50m)

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 7h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 19:59
Start Date: 14/Oct/19 19:59
Worklog Time Spent: 10m 
  Work Description: asfgit commented on pull request #2859: ARTEMIS-2513 
Large message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> In LargeMessageImpl.copy(long) it need to open the underlying file in order 
> to read and copy bytes into the new copied message. However there is a chance 
> that another thread can come in and close the file in the middle, making the 
> copy failed with "channel is null" error.
> This is happening in cases where a large message is sent to a jms topic 
> (multicast address). During delivery it to multiple subscribers, some 
> consumer is doing delivery and closed the underlying file after. Some other 
> consumer is rolling back the messages and eventually move it to DLQ (which 
> will call the above copy method). So there is a chance this bug being hit on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 19:58
Start Date: 14/Oct/19 19:58
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on pull request #2859: 
ARTEMIS-2513 Large message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#discussion_r334639588
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/LargeServerMessageImpl.java
 ##
 @@ -368,52 +368,48 @@ public Message copy(final long newID) {
   try {
  LargeServerMessage newMessage = 
storageManager.createLargeMessage(newID, this);
 
- boolean originallyOpen = file != null && file.isOpen();
+ //clone a SequentialFile to avoid concurrent access
+ ensureFileExists(false);
+ SequentialFile cloneFile = file.cloneFile();
 
- validateFile();
-
- byte[] bufferBytes = new byte[100 * 1024];
-
- ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
+ try {
+byte[] bufferBytes = new byte[100 * 1024];
 
- long oldPosition = file.position();
+ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
 
- if (!file.isOpen()) {
-file.open();
- }
- file.position(0);
-
- for (;;) {
-// The buffer is reused...
-// We need to make sure we clear the limits and the buffer before 
reusing it
-buffer.clear();
-int bytesRead = file.read(buffer);
-
-byte[] bufferToWrite;
-if (bytesRead <= 0) {
-   break;
-} else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
-   // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
-   // otherwise there could be another thread still using the 
buffer on a
-   // replication.
-   bufferToWrite = bufferBytes;
-} else {
-   bufferToWrite = new byte[bytesRead];
-   System.arraycopy(bufferBytes, 0, bufferToWrite, 0, bytesRead);
+if (!cloneFile.isOpen()) {
+   cloneFile.open();
 }
 
-newMessage.addBytes(bufferToWrite);
-
-if (bytesRead < bufferBytes.length) {
-   break;
+cloneFile.position(0);
+
+for (;;) {
+   // The buffer is reused...
+   // We need to make sure we clear the limits and the buffer 
before reusing it
+   buffer.clear();
+   int bytesRead = cloneFile.read(buffer);
+
+   byte[] bufferToWrite;
+   if (bytesRead <= 0) {
+  break;
+   } else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
+  // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
+  // otherwise there could be another thread still using the 
buffer on a
+  // replication.
+  bufferToWrite = bufferBytes;
+   } else {
+  bufferToWrite = new byte[bytesRead];
+  System.arraycopy(bufferBytes, 0, bufferToWrite, 0, 
bytesRead);
+   }
+
+   newMessage.addBytes(bufferToWrite);
+
+   if (bytesRead < bufferBytes.length) {
+  break;
+   }
 }
- }
-
- file.position(oldPosition);
-
- if (!originallyOpen) {
-file.close(false);
-newMessage.getFile().close();
+ } finally {
+cloneFile.close();
  }
 
 Review comment:
   @wy96f  / @gaohoward actually.. I will merge this right away.. as whatever I 
do would clash here.
   
   
   and I will make sure I address how we open and close files.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>  

[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 19:57
Start Date: 14/Oct/19 19:57
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on pull request #2859: 
ARTEMIS-2513 Large message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#discussion_r334639212
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/LargeServerMessageImpl.java
 ##
 @@ -368,52 +368,48 @@ public Message copy(final long newID) {
   try {
  LargeServerMessage newMessage = 
storageManager.createLargeMessage(newID, this);
 
- boolean originallyOpen = file != null && file.isOpen();
+ //clone a SequentialFile to avoid concurrent access
+ ensureFileExists(false);
+ SequentialFile cloneFile = file.cloneFile();
 
- validateFile();
-
- byte[] bufferBytes = new byte[100 * 1024];
-
- ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
+ try {
+byte[] bufferBytes = new byte[100 * 1024];
 
- long oldPosition = file.position();
+ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
 
- if (!file.isOpen()) {
-file.open();
- }
- file.position(0);
-
- for (;;) {
-// The buffer is reused...
-// We need to make sure we clear the limits and the buffer before 
reusing it
-buffer.clear();
-int bytesRead = file.read(buffer);
-
-byte[] bufferToWrite;
-if (bytesRead <= 0) {
-   break;
-} else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
-   // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
-   // otherwise there could be another thread still using the 
buffer on a
-   // replication.
-   bufferToWrite = bufferBytes;
-} else {
-   bufferToWrite = new byte[bytesRead];
-   System.arraycopy(bufferBytes, 0, bufferToWrite, 0, bytesRead);
+if (!cloneFile.isOpen()) {
+   cloneFile.open();
 }
 
-newMessage.addBytes(bufferToWrite);
-
-if (bytesRead < bufferBytes.length) {
-   break;
+cloneFile.position(0);
+
+for (;;) {
+   // The buffer is reused...
+   // We need to make sure we clear the limits and the buffer 
before reusing it
+   buffer.clear();
+   int bytesRead = cloneFile.read(buffer);
+
+   byte[] bufferToWrite;
+   if (bytesRead <= 0) {
+  break;
+   } else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
+  // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
+  // otherwise there could be another thread still using the 
buffer on a
+  // replication.
+  bufferToWrite = bufferBytes;
+   } else {
+  bufferToWrite = new byte[bytesRead];
+  System.arraycopy(bufferBytes, 0, bufferToWrite, 0, 
bytesRead);
+   }
+
+   newMessage.addBytes(bufferToWrite);
+
+   if (bytesRead < bufferBytes.length) {
+  break;
+   }
 }
- }
-
- file.position(oldPosition);
-
- if (!originallyOpen) {
-file.close(false);
-newMessage.getFile().close();
+ } finally {
+cloneFile.close();
  }
 
 Review comment:
   @wy96f I'm doing some work with large messages, and I want to double check 
that as well.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 

[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 19:57
Start Date: 14/Oct/19 19:57
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on issue #2859: ARTEMIS-2513 
Large message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#issuecomment-541887630
 
 
   @gaohoward can I keep this open for 1 or 2 days?
   
   I'm doing some work on large messages and I want to make sure why we have 
that code to close or keep files open.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> In LargeMessageImpl.copy(long) it need to open the underlying file in order 
> to read and copy bytes into the new copied message. However there is a chance 
> that another thread can come in and close the file in the middle, making the 
> copy failed with "channel is null" error.
> This is happening in cases where a large message is sent to a jms topic 
> (multicast address). During delivery it to multiple subscribers, some 
> consumer is doing delivery and closed the underlying file after. Some other 
> consumer is rolling back the messages and eventually move it to DLQ (which 
> will call the above copy method). So there is a chance this bug being hit on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 19:14
Start Date: 14/Oct/19 19:14
Worklog Time Spent: 10m 
  Work Description: jbertram commented on issue #2850: ARTEMIS-2504 
implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-541866699
 
 
   I'm not sure what you mean by "destructive testing." There are a number of 
tests on the PR one of which specifically tests restarting the broker, although 
there aren't any testing failover.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 328068)
Time Spent: 6h 50m  (was: 6h 40m)

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 6h 50m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2503) Improve wildcards for the roles access match

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 19:13
Start Date: 14/Oct/19 19:13
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on pull request #2851: 
ARTEMIS-2503 Improve wildcards for the roles access match
URL: https://github.com/apache/activemq-artemis/pull/2851#discussion_r334625086
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/JMXAccessControlList.java
 ##
 @@ -25,12 +25,22 @@
 import java.util.Map;
 import java.util.concurrent.ConcurrentHashMap;
 
+import org.apache.activemq.artemis.core.config.WildcardConfiguration;
+import org.apache.activemq.artemis.core.settings.HierarchicalRepository;
+import 
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository;
+
 public class JMXAccessControlList {
 
private Access defaultAccess = new Access("*");
-   private Map domainAccess = new HashMap<>();
+   private HierarchicalRepository domainAccess;
private ConcurrentHashMap> whitelist = new 
ConcurrentHashMap<>();
 
+   public JMXAccessControlList() {
+  WildcardConfiguration domainAccessWildcardConfiguration = new 
WildcardConfiguration();
 
 Review comment:
   @michaelandrepearce what do you suggest? merge management and broker.xml?
   
   That's certainly desirable. but I don't think we can do it before a 3.0.
   
   management is on a different domain from queues and addresses. it's about 
object  names.. not queue names.. hence something simpler would certainly apply 
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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 328066)
Time Spent: 3h 10m  (was: 3h)

> Improve wildcards for the roles access match
> 
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> Please improve wildcard support for the key element in the roles access 
>  element.
> ATM you can NOT apply a restriction across a set of queue instances starting 
> with the same prefix (like below):
> {code:java}
> 
>
>
>...
> {code}
> If queues are created dynamically and only a queue name "prefix" is known in 
> advance; JMX RBAC cannot be used to restrict access in this case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2503) Improve wildcards for the roles access match

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 19:10
Start Date: 14/Oct/19 19:10
Worklog Time Spent: 10m 
  Work Description: jbertram commented on pull request #2851: ARTEMIS-2503 
Improve wildcards for the roles access match
URL: https://github.com/apache/activemq-artemis/pull/2851#discussion_r334624011
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/JMXAccessControlList.java
 ##
 @@ -25,12 +25,22 @@
 import java.util.Map;
 import java.util.concurrent.ConcurrentHashMap;
 
+import org.apache.activemq.artemis.core.config.WildcardConfiguration;
+import org.apache.activemq.artemis.core.settings.HierarchicalRepository;
+import 
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository;
+
 public class JMXAccessControlList {
 
private Access defaultAccess = new Access("*");
-   private Map domainAccess = new HashMap<>();
+   private HierarchicalRepository domainAccess;
private ConcurrentHashMap> whitelist = new 
ConcurrentHashMap<>();
 
+   public JMXAccessControlList() {
+  WildcardConfiguration domainAccessWildcardConfiguration = new 
WildcardConfiguration();
 
 Review comment:
   These use-cases seem pretty different to me. The wildcard configuration in 
broker.xml is for address matching which is hierarchical in nature and 
therefore requires separating "words", matching individual and groups of words, 
etc. The "match" performed for keys defined in management.xml is basically just 
a **prefix**. It's not hierarchical and doesn't even use regular expressions. 
It's *very* simple and IMO it should stay that way. 
   
   > If i need to secure a wildcard of address or queues on broker then no 
doubt i need to secure the same pattern from admin pov to.
   
   I'm not sure is "no doubt" about that. Use cases for the security of actual 
messaging clients and management users can vary quite a bit. In any case, the 
same kind of matching isn't possible in management.xml as it is in broker.xml 
either before or after this PR. The use-case for this PR is just allowing a 
simple prefixing for the match "key" just like is available for the access 
"method" field. The syntax is the same. It's just allowing it in a new field. I 
don't see any issue with that.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 328064)
Time Spent: 3h  (was: 2h 50m)

> Improve wildcards for the roles access match
> 
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Please improve wildcard support for the key element in the roles access 
>  element.
> ATM you can NOT apply a restriction across a set of queue instances starting 
> with the same prefix (like below):
> {code:java}
> 
>
>
>...
> {code}
> If queues are created dynamically and only a queue name "prefix" is known in 
> advance; JMX RBAC cannot be used to restrict access in this case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2519) ActiveMQUnexpectedRoutingTypeForAddress uses wrong enum type

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 18:08
Start Date: 14/Oct/19 18:08
Worklog Time Spent: 10m 
  Work Description: asfgit commented on pull request #2864: ARTEMIS-2519: 
Use proper enum type inside ActiveMQUnexpectedRoutingTypeForAddress
URL: https://github.com/apache/activemq-artemis/pull/2864
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> ActiveMQUnexpectedRoutingTypeForAddress uses wrong enum type
> 
>
> Key: ARTEMIS-2519
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2519
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 2.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I was browsing the ActiveMQException types to see what was available to be 
> used for some custom processing I'm doing in a plugin and I noticed that the 
> exception type ActiveMQUnexpectedRoutingTypeForAddress uses the wrong enum 
> type.  It currently is setup to use 
> ActiveMQExceptionType.MAX_CONSUMER_LIMIT_EXCEEDED but this should be 
> ActiveMQExceptionType.UNEXPECTED_ROUTING_TYPE_FOR_ADDRESS.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 17:51
Start Date: 14/Oct/19 17:51
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on issue #2850: 
ARTEMIS-2504 implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-541822492
 
 
   So im getting odd behaviour after restarts and failovers. Trying to work out 
what is going on. Have you done much destructive testing 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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 6h 40m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 17:50
Start Date: 14/Oct/19 17:50
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on issue #2850: 
ARTEMIS-2504 implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-541822492
 
 
   So im getting odd behaviour after restarts. Trying to work out what is going 
on. Have you done much destructive testing 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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 6.5h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2503) Improve wildcards for the roles access match

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 17:48
Start Date: 14/Oct/19 17:48
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on pull request #2851: 
ARTEMIS-2503 Improve wildcards for the roles access match
URL: https://github.com/apache/activemq-artemis/pull/2851#discussion_r334593077
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/JMXAccessControlList.java
 ##
 @@ -25,12 +25,22 @@
 import java.util.Map;
 import java.util.concurrent.ConcurrentHashMap;
 
+import org.apache.activemq.artemis.core.config.WildcardConfiguration;
+import org.apache.activemq.artemis.core.settings.HierarchicalRepository;
+import 
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository;
+
 public class JMXAccessControlList {
 
private Access defaultAccess = new Access("*");
-   private Map domainAccess = new HashMap<>();
+   private HierarchicalRepository domainAccess;
private ConcurrentHashMap> whitelist = new 
ConcurrentHashMap<>();
 
+   public JMXAccessControlList() {
+  WildcardConfiguration domainAccessWildcardConfiguration = new 
WildcardConfiguration();
 
 Review comment:
   So my concern is trying to automate and unify the config the fact already 
slightly snowflaked gives me a massive headache as is. Really don't need 
further differing config. If we want to enchance the wildcards in management i 
feel strongly we need to align it.
   
   E.g. either leave as is, or any new more enhanced stuff needs to be aligned. 
I see no reason to have a differing approaches. If i need to secure a wildcard 
of address or queues on broker then no doubt i need to secure the same pattern 
from admin pov to. Keeping it all aligned just makes it better and simpler to 
operate
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 328015)
Time Spent: 2h 50m  (was: 2h 40m)

> Improve wildcards for the roles access match
> 
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Please improve wildcard support for the key element in the roles access 
>  element.
> ATM you can NOT apply a restriction across a set of queue instances starting 
> with the same prefix (like below):
> {code:java}
> 
>
>
>...
> {code}
> If queues are created dynamically and only a queue name "prefix" is known in 
> advance; JMX RBAC cannot be used to restrict access in this case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2503) Improve wildcards for the roles access match

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 17:47
Start Date: 14/Oct/19 17:47
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on pull request #2851: 
ARTEMIS-2503 Improve wildcards for the roles access match
URL: https://github.com/apache/activemq-artemis/pull/2851#discussion_r334593077
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/JMXAccessControlList.java
 ##
 @@ -25,12 +25,22 @@
 import java.util.Map;
 import java.util.concurrent.ConcurrentHashMap;
 
+import org.apache.activemq.artemis.core.config.WildcardConfiguration;
+import org.apache.activemq.artemis.core.settings.HierarchicalRepository;
+import 
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository;
+
 public class JMXAccessControlList {
 
private Access defaultAccess = new Access("*");
-   private Map domainAccess = new HashMap<>();
+   private HierarchicalRepository domainAccess;
private ConcurrentHashMap> whitelist = new 
ConcurrentHashMap<>();
 
+   public JMXAccessControlList() {
+  WildcardConfiguration domainAccessWildcardConfiguration = new 
WildcardConfiguration();
 
 Review comment:
   So my concern is trying to automate and unify the config the fact already 
slightly snowflaked gives me a massive headache as is. Really don't need 
further differing config. If we want to enchance the wildcards in management i 
feel strongly we need to align it.
   
   E.g. either leave as is, or any new more enhanced stuff needs to be aligned. 
I see no reason to have a differing approaches.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 328012)
Time Spent: 2h 40m  (was: 2.5h)

> Improve wildcards for the roles access match
> 
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> Please improve wildcard support for the key element in the roles access 
>  element.
> ATM you can NOT apply a restriction across a set of queue instances starting 
> with the same prefix (like below):
> {code:java}
> 
>
>
>...
> {code}
> If queues are created dynamically and only a queue name "prefix" is known in 
> advance; JMX RBAC cannot be used to restrict access in this case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2503) Improve wildcards for the roles access match

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 17:46
Start Date: 14/Oct/19 17:46
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on pull request #2851: 
ARTEMIS-2503 Improve wildcards for the roles access match
URL: https://github.com/apache/activemq-artemis/pull/2851#discussion_r334593077
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/JMXAccessControlList.java
 ##
 @@ -25,12 +25,22 @@
 import java.util.Map;
 import java.util.concurrent.ConcurrentHashMap;
 
+import org.apache.activemq.artemis.core.config.WildcardConfiguration;
+import org.apache.activemq.artemis.core.settings.HierarchicalRepository;
+import 
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository;
+
 public class JMXAccessControlList {
 
private Access defaultAccess = new Access("*");
-   private Map domainAccess = new HashMap<>();
+   private HierarchicalRepository domainAccess;
private ConcurrentHashMap> whitelist = new 
ConcurrentHashMap<>();
 
+   public JMXAccessControlList() {
+  WildcardConfiguration domainAccessWildcardConfiguration = new 
WildcardConfiguration();
 
 Review comment:
   So my concern is trying to automate and unify the config the fact already 
slightly snowflaked gives me a massive headache as is. Really don't need 
further differing config. If we want to enchance the wildcards in management i 
feel strongly we need to align it
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 328009)
Time Spent: 2.5h  (was: 2h 20m)

> Improve wildcards for the roles access match
> 
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Please improve wildcard support for the key element in the roles access 
>  element.
> ATM you can NOT apply a restriction across a set of queue instances starting 
> with the same prefix (like below):
> {code:java}
> 
>
>
>...
> {code}
> If queues are created dynamically and only a queue name "prefix" is known in 
> advance; JMX RBAC cannot be used to restrict access in this case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2503) Improve wildcards for the roles access match

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 15:50
Start Date: 14/Oct/19 15:50
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on pull request #2851: 
ARTEMIS-2503 Improve wildcards for the roles access match
URL: https://github.com/apache/activemq-artemis/pull/2851#discussion_r334548567
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/JMXAccessControlList.java
 ##
 @@ -25,12 +25,22 @@
 import java.util.Map;
 import java.util.concurrent.ConcurrentHashMap;
 
+import org.apache.activemq.artemis.core.config.WildcardConfiguration;
+import org.apache.activemq.artemis.core.settings.HierarchicalRepository;
+import 
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository;
+
 public class JMXAccessControlList {
 
private Access defaultAccess = new Access("*");
-   private Map domainAccess = new HashMap<>();
+   private HierarchicalRepository domainAccess;
private ConcurrentHashMap> whitelist = new 
ConcurrentHashMap<>();
 
+   public JMXAccessControlList() {
+  WildcardConfiguration domainAccessWildcardConfiguration = new 
WildcardConfiguration();
 
 Review comment:
   I'm concerned about users abusing the configuration on management, things 
not working later.. and having to answer to user forum's / customer issues... 
etc... 
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Improve wildcards for the roles access match
> 
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Please improve wildcard support for the key element in the roles access 
>  element.
> ATM you can NOT apply a restriction across a set of queue instances starting 
> with the same prefix (like below):
> {code:java}
> 
>
>
>...
> {code}
> If queues are created dynamically and only a queue name "prefix" is known in 
> advance; JMX RBAC cannot be used to restrict access in this case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2503) Improve wildcards for the roles access match

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 15:48
Start Date: 14/Oct/19 15:48
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on pull request #2851: 
ARTEMIS-2503 Improve wildcards for the roles access match
URL: https://github.com/apache/activemq-artemis/pull/2851#discussion_r334547881
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/JMXAccessControlList.java
 ##
 @@ -25,12 +25,22 @@
 import java.util.Map;
 import java.util.concurrent.ConcurrentHashMap;
 
+import org.apache.activemq.artemis.core.config.WildcardConfiguration;
+import org.apache.activemq.artemis.core.settings.HierarchicalRepository;
+import 
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository;
+
 public class JMXAccessControlList {
 
private Access defaultAccess = new Access("*");
-   private Map domainAccess = new HashMap<>();
+   private HierarchicalRepository domainAccess;
private ConcurrentHashMap> whitelist = new 
ConcurrentHashMap<>();
 
+   public JMXAccessControlList() {
+  WildcardConfiguration domainAccessWildcardConfiguration = new 
WildcardConfiguration();
 
 Review comment:
   @michaelandrepearce my personal opinion here: can't we keep this simple.. 
meaning. no configuration of wildcard for management?
   
   I see this can be useful on queues.. etc.. but on management, if we could 
keep it simple??
   
   I mean... management and broker should be kept independent.. I wouldn't load 
something from broker.xml to change semantics on management... 
   
   And if you require the wildcard configuration, then you need testing..and 
more moving parts bound to fail and document...
   
   I would prefer to keep it simpler?
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Improve wildcards for the roles access match
> 
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Please improve wildcard support for the key element in the roles access 
>  element.
> ATM you can NOT apply a restriction across a set of queue instances starting 
> with the same prefix (like below):
> {code:java}
> 
>
>
>...
> {code}
> If queues are created dynamically and only a queue name "prefix" is known in 
> advance; JMX RBAC cannot be used to restrict access in this case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2519) ActiveMQUnexpectedRoutingTypeForAddress uses wrong enum type

2019-10-14 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 14/Oct/19 15:41
Start Date: 14/Oct/19 15:41
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on pull request #2864: 
ARTEMIS-2519: Use proper enum type inside 
ActiveMQUnexpectedRoutingTypeForAddress
URL: https://github.com/apache/activemq-artemis/pull/2864#discussion_r334544613
 
 

 ##
 File path: 
artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/ActiveMQUnexpectedRoutingTypeForAddress.java
 ##
 @@ -22,10 +22,10 @@
 public final class ActiveMQUnexpectedRoutingTypeForAddress extends 
ActiveMQException {
 
public ActiveMQUnexpectedRoutingTypeForAddress() {
-  super(ActiveMQExceptionType.MAX_CONSUMER_LIMIT_EXCEEDED);
 
 Review comment:
   oops
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> ActiveMQUnexpectedRoutingTypeForAddress uses wrong enum type
> 
>
> Key: ARTEMIS-2519
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2519
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 2.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I was browsing the ActiveMQException types to see what was available to be 
> used for some custom processing I'm doing in a plugin and I noticed that the 
> exception type ActiveMQUnexpectedRoutingTypeForAddress uses the wrong enum 
> type.  It currently is setup to use 
> ActiveMQExceptionType.MAX_CONSUMER_LIMIT_EXCEEDED but this should be 
> ActiveMQExceptionType.UNEXPECTED_ROUTING_TYPE_FOR_ADDRESS.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2515) pageIterator.hasNext spends too much time in the case of no messages matched

2019-10-12 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 12/Oct/19 19:36
Start Date: 12/Oct/19 19:36
Worklog Time Spent: 10m 
  Work Description: asfgit commented on pull request #2861: ARTEMIS-2515 
pageIterator.hasNext spends too much time in the case of no messages matched
URL: https://github.com/apache/activemq-artemis/pull/2861
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> pageIterator.hasNext spends too much time in the case of no messages matched
> 
>
> Key: ARTEMIS-2515
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2515
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Wei Yang
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Discussion thread here 
> [http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-pageIterator-hasNext-spends-too-much-time-in-the-case-of-no-messages-matched-td4752397.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7319) Update Jackson to 2.9.10

2019-10-11 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 12/Oct/19 04:46
Start Date: 12/Oct/19 04:46
Worklog Time Spent: 10m 
  Work Description: jbonofre commented on pull request #396: AMQ-7319 - 
Update Jackson to 2.9.10
URL: https://github.com/apache/activemq/pull/396
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Update Jackson to 2.9.10
> 
>
> Key: AMQ-7319
> URL: https://issues.apache.org/jira/browse/AMQ-7319
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker, webconsole
>Reporter: Colm O hEigeartaigh
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 5.16.0, 5.15.11
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We should update Jackson to 2.9.10 due to CVE-2019-17267



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2515) pageIterator.hasNext spends too much time in the case of no messages matched

2019-10-11 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 12/Oct/19 02:05
Start Date: 12/Oct/19 02:05
Worklog Time Spent: 10m 
  Work Description: wy96f commented on issue #2861: ARTEMIS-2515 
pageIterator.hasNext spends too much time in the case of no messages matched
URL: https://github.com/apache/activemq-artemis/pull/2861#issuecomment-541272843
 
 
   @clebertsuconic Changed it, thanks :)
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> pageIterator.hasNext spends too much time in the case of no messages matched
> 
>
> Key: ARTEMIS-2515
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2515
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Wei Yang
>Priority: Major
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Discussion thread here 
> [http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-pageIterator-hasNext-spends-too-much-time-in-the-case-of-no-messages-matched-td4752397.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2519) ActiveMQUnexpectedRoutingTypeForAddress uses wrong enum type

2019-10-11 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 11/Oct/19 17:43
Start Date: 11/Oct/19 17:43
Worklog Time Spent: 10m 
  Work Description: cshannon commented on pull request #2864: ARTEMIS-2519: 
Use proper enum type inside ActiveMQUnexpectedRoutingTy…
URL: https://github.com/apache/activemq-artemis/pull/2864
 
 
   …peForAddress
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> ActiveMQUnexpectedRoutingTypeForAddress uses wrong enum type
> 
>
> Key: ARTEMIS-2519
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2519
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 2.11.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I was browsing the ActiveMQException types to see what was available to be 
> used for some custom processing I'm doing in a plugin and I noticed that the 
> exception type ActiveMQUnexpectedRoutingTypeForAddress uses the wrong enum 
> type.  It currently is setup to use 
> ActiveMQExceptionType.MAX_CONSUMER_LIMIT_EXCEEDED but this should be 
> ActiveMQExceptionType.UNEXPECTED_ROUTING_TYPE_FOR_ADDRESS.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQ-7319) Update Jackson to 2.9.10

2019-10-11 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 11/Oct/19 16:24
Start Date: 11/Oct/19 16:24
Worklog Time Spent: 10m 
  Work Description: coheigea commented on pull request #396: AMQ-7319 - 
Update Jackson to 2.9.10
URL: https://github.com/apache/activemq/pull/396
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Update Jackson to 2.9.10
> 
>
> Key: AMQ-7319
> URL: https://issues.apache.org/jira/browse/AMQ-7319
> Project: ActiveMQ
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Priority: Major
> Fix For: 5.16.0, 5.15.11
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should update Jackson to 2.9.10 due to CVE-2019-17267



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2515) pageIterator.hasNext spends too much time in the case of no messages matched

2019-10-11 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 11/Oct/19 14:04
Start Date: 11/Oct/19 14:04
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on pull request #2861: 
ARTEMIS-2515 pageIterator.hasNext spends too much time in the case of no 
messages matched
URL: https://github.com/apache/activemq-artemis/pull/2861#discussion_r334007680
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
 ##
 @@ -2942,7 +2946,14 @@ private void depage(final boolean scheduleExpiry) {
   this.directDeliver = false;
 
   int depaged = 0;
-  while (timeout > System.currentTimeMillis() && needsDepage() && 
pageIterator.hasNext()) {
+  while (timeout > System.nanoTime() && needsDepage()) {
+ int status = pageIterator.tryNext();
+ if (status == 2) {
+continue;
+ } else if (status == 0) {
+break;
+ }
+
 
 Review comment:
   Same 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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> pageIterator.hasNext spends too much time in the case of no messages matched
> 
>
> Key: ARTEMIS-2515
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2515
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Wei Yang
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Discussion thread here 
> [http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-pageIterator-hasNext-spends-too-much-time-in-the-case-of-no-messages-matched-td4752397.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2515) pageIterator.hasNext spends too much time in the case of no messages matched

2019-10-11 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 11/Oct/19 14:03
Start Date: 11/Oct/19 14:03
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on pull request #2861: 
ARTEMIS-2515 pageIterator.hasNext spends too much time in the case of no 
messages matched
URL: https://github.com/apache/activemq-artemis/pull/2861#discussion_r334007365
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
 ##
 @@ -2680,24 +2684,24 @@ private boolean deliver() {
 
   int handled = 0;
 
-  long timeout = System.currentTimeMillis() + DELIVERY_TIMEOUT;
+  long timeout = System.nanoTime() + 
TimeUnit.MILLISECONDS.toNanos(DELIVERY_TIMEOUT);
   consumers.reset();
   while (true) {
  if (handled == MAX_DELIVERIES_IN_LOOP) {
 // Schedule another one - we do this to prevent a single thread 
getting caught up in this loop for too
 // long
 
-deliverAsync();
+deliverAsync(true);
 
 return false;
  }
 
- if (System.currentTimeMillis() > timeout) {
+ if (System.nanoTime() > timeout) {
 
 Review comment:
   I remember not long ago, we had to change a few nanoTime operations to avoid 
overflow.
   
   I think, based on that the correct would be System.nanoTime() - timeout > 0
   
   There was a previous big commit where we changed a few like this... the 
commit I could find where Franz changed something similar was 
35c3475092576e7b008220f7c39b78e15850d5fd
   
   
   Can you make that change here please?
   
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> pageIterator.hasNext spends too much time in the case of no messages matched
> 
>
> Key: ARTEMIS-2515
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2515
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Wei Yang
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Discussion thread here 
> [http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-pageIterator-hasNext-spends-too-much-time-in-the-case-of-no-messages-matched-td4752397.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2515) pageIterator.hasNext spends too much time in the case of no messages matched

2019-10-11 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 11/Oct/19 08:33
Start Date: 11/Oct/19 08:33
Worklog Time Spent: 10m 
  Work Description: wy96f commented on pull request #2861: ARTEMIS-2515 
pageIterator.hasNext spends too much time in the case of no messages matched
URL: https://github.com/apache/activemq-artemis/pull/2861#discussion_r333883191
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/cursor/impl/PageSubscriptionImpl.java
 ##
 @@ -1323,7 +1328,13 @@ private PagedReference moveNext() {
 PagePositionAndFileOffset lastPosition = position;
 PagePositionAndFileOffset tmpPosition = position;
 
+long timeout = System.currentTimeMillis() + DELIVERY_TIMEOUT;
 
 Review comment:
   Resolved it, thanks :)
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> pageIterator.hasNext spends too much time in the case of no messages matched
> 
>
> Key: ARTEMIS-2515
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2515
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Wei Yang
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Discussion thread here 
> [http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-pageIterator-hasNext-spends-too-much-time-in-the-case-of-no-messages-matched-td4752397.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2517) JMX Server is stopped after a failback

2019-10-10 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 10/Oct/19 18:45
Start Date: 10/Oct/19 18:45
Worklog Time Spent: 10m 
  Work Description: asfgit commented on pull request #2863: ARTEMIS-2517 
JMX will be shutdown after failback
URL: https://github.com/apache/activemq-artemis/pull/2863
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> JMX Server is stopped after a failback
> --
>
> Key: ARTEMIS-2517
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2517
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.10.1
>Reporter: Clebert Suconic
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2517) JMX Server is stopped after a failback

2019-10-10 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 10/Oct/19 15:57
Start Date: 10/Oct/19 15:57
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on pull request #2863: 
ARTEMIS-2517 JMX will be shutdown after failback
URL: https://github.com/apache/activemq-artemis/pull/2863
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> JMX Server is stopped after a failback
> --
>
> Key: ARTEMIS-2517
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2517
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.10.1
>Reporter: Clebert Suconic
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2516) Support system property in xinclude href

2019-10-10 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 10/Oct/19 14:13
Start Date: 10/Oct/19 14:13
Worklog Time Spent: 10m 
  Work Description: jbertram commented on pull request #2862: ARTEMIS-2516 
support sys props in xinclude href
URL: https://github.com/apache/activemq-artemis/pull/2862
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Support system property in xinclude href
> 
>
> Key: ARTEMIS-2516
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2516
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2515) pageIterator.hasNext spends too much time in the case of no messages matched

2019-10-10 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 10/Oct/19 10:01
Start Date: 10/Oct/19 10:01
Worklog Time Spent: 10m 
  Work Description: franz1981 commented on pull request #2861: ARTEMIS-2515 
pageIterator.hasNext spends too much time in the case of no messages matched
URL: https://github.com/apache/activemq-artemis/pull/2861#discussion_r333434047
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/cursor/impl/PageSubscriptionImpl.java
 ##
 @@ -1323,7 +1328,13 @@ private PagedReference moveNext() {
 PagePositionAndFileOffset lastPosition = position;
 PagePositionAndFileOffset tmpPosition = position;
 
+long timeout = System.currentTimeMillis() + DELIVERY_TIMEOUT;
 
 Review comment:
   Use nanoTime here that is not susceptible to NTP updates :)
   Now I can return to my honeymoon :P
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> pageIterator.hasNext spends too much time in the case of no messages matched
> 
>
> Key: ARTEMIS-2515
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2515
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Wei Yang
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Discussion thread here 
> [http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-pageIterator-hasNext-spends-too-much-time-in-the-case-of-no-messages-matched-td4752397.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2515) pageIterator.hasNext spends too much time in the case of no messages matched

2019-10-10 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 10/Oct/19 09:52
Start Date: 10/Oct/19 09:52
Worklog Time Spent: 10m 
  Work Description: wy96f commented on pull request #2861: ARTEMIS-2515 
pageIterator.hasNext spends too much time in the case of no messages matched
URL: https://github.com/apache/activemq-artemis/pull/2861
 
 
   Discussion thread here 
http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-pageIterator-hasNext-spends-too-much-time-in-the-case-of-no-messages-matched-td4752397.html
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> pageIterator.hasNext spends too much time in the case of no messages matched
> 
>
> Key: ARTEMIS-2515
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2515
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Wei Yang
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Discussion thread here 
> [http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-pageIterator-hasNext-spends-too-much-time-in-the-case-of-no-messages-matched-td4752397.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-10 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 10/Oct/19 07:28
Start Date: 10/Oct/19 07:28
Worklog Time Spent: 10m 
  Work Description: gaohoward commented on issue #2859: ARTEMIS-2513 Large 
message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#issuecomment-540432702
 
 
   @clebertsuconic Jenkins has 5 failures, not likely relevant and those failed 
tests are passing on my local. So it's safe 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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> In LargeMessageImpl.copy(long) it need to open the underlying file in order 
> to read and copy bytes into the new copied message. However there is a chance 
> that another thread can come in and close the file in the middle, making the 
> copy failed with "channel is null" error.
> This is happening in cases where a large message is sent to a jms topic 
> (multicast address). During delivery it to multiple subscribers, some 
> consumer is doing delivery and closed the underlying file after. Some other 
> consumer is rolling back the messages and eventually move it to DLQ (which 
> will call the above copy method). So there is a chance this bug being hit on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-10 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 10/Oct/19 07:09
Start Date: 10/Oct/19 07:09
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on issue #2850: 
ARTEMIS-2504 implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-540423943
 
 
   @jbertram im busy this week with some priority bits at work, thus also not 
had time tonrespin the amqp nms release. Im hoping to get time next week to 
look at this again
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 6h 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 10/Oct/19 02:55
Start Date: 10/Oct/19 02:55
Worklog Time Spent: 10m 
  Work Description: gaohoward commented on pull request #2859: ARTEMIS-2513 
Large message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#discussion_r11392
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/LargeServerMessageImpl.java
 ##
 @@ -368,52 +368,48 @@ public Message copy(final long newID) {
   try {
  LargeServerMessage newMessage = 
storageManager.createLargeMessage(newID, this);
 
- boolean originallyOpen = file != null && file.isOpen();
+ //clone a SequentialFile to avoid concurrent access
+ ensureFileExists(false);
+ SequentialFile cloneFile = file.cloneFile();
 
- validateFile();
-
- byte[] bufferBytes = new byte[100 * 1024];
-
- ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
+ try {
+byte[] bufferBytes = new byte[100 * 1024];
 
- long oldPosition = file.position();
+ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
 
- if (!file.isOpen()) {
-file.open();
- }
- file.position(0);
-
- for (;;) {
-// The buffer is reused...
-// We need to make sure we clear the limits and the buffer before 
reusing it
-buffer.clear();
-int bytesRead = file.read(buffer);
-
-byte[] bufferToWrite;
-if (bytesRead <= 0) {
-   break;
-} else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
-   // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
-   // otherwise there could be another thread still using the 
buffer on a
-   // replication.
-   bufferToWrite = bufferBytes;
-} else {
-   bufferToWrite = new byte[bytesRead];
-   System.arraycopy(bufferBytes, 0, bufferToWrite, 0, bytesRead);
+if (!cloneFile.isOpen()) {
+   cloneFile.open();
 }
 
-newMessage.addBytes(bufferToWrite);
-
-if (bytesRead < bufferBytes.length) {
-   break;
+cloneFile.position(0);
+
+for (;;) {
+   // The buffer is reused...
+   // We need to make sure we clear the limits and the buffer 
before reusing it
+   buffer.clear();
+   int bytesRead = cloneFile.read(buffer);
+
+   byte[] bufferToWrite;
+   if (bytesRead <= 0) {
+  break;
+   } else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
+  // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
+  // otherwise there could be another thread still using the 
buffer on a
+  // replication.
+  bufferToWrite = bufferBytes;
+   } else {
+  bufferToWrite = new byte[bytesRead];
+  System.arraycopy(bufferBytes, 0, bufferToWrite, 0, 
bytesRead);
+   }
+
+   newMessage.addBytes(bufferToWrite);
+
+   if (bytesRead < bufferBytes.length) {
+  break;
+   }
 }
- }
-
- file.position(oldPosition);
-
- if (!originallyOpen) {
-file.close(false);
-newMessage.getFile().close();
+ } finally {
+cloneFile.close();
  }
 
 Review comment:
   tbh I don't know either. I just keep the old behavior.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 326085)
Time Spent: 1.5h  (was: 1h 20m)

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 1.5h
> 

[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 10/Oct/19 02:28
Start Date: 10/Oct/19 02:28
Worklog Time Spent: 10m 
  Work Description: wy96f commented on pull request #2859: ARTEMIS-2513 
Large message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#discussion_r06857
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/LargeServerMessageImpl.java
 ##
 @@ -368,52 +368,48 @@ public Message copy(final long newID) {
   try {
  LargeServerMessage newMessage = 
storageManager.createLargeMessage(newID, this);
 
- boolean originallyOpen = file != null && file.isOpen();
+ //clone a SequentialFile to avoid concurrent access
+ ensureFileExists(false);
+ SequentialFile cloneFile = file.cloneFile();
 
- validateFile();
-
- byte[] bufferBytes = new byte[100 * 1024];
-
- ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
+ try {
+byte[] bufferBytes = new byte[100 * 1024];
 
- long oldPosition = file.position();
+ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
 
- if (!file.isOpen()) {
-file.open();
- }
- file.position(0);
-
- for (;;) {
-// The buffer is reused...
-// We need to make sure we clear the limits and the buffer before 
reusing it
-buffer.clear();
-int bytesRead = file.read(buffer);
-
-byte[] bufferToWrite;
-if (bytesRead <= 0) {
-   break;
-} else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
-   // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
-   // otherwise there could be another thread still using the 
buffer on a
-   // replication.
-   bufferToWrite = bufferBytes;
-} else {
-   bufferToWrite = new byte[bytesRead];
-   System.arraycopy(bufferBytes, 0, bufferToWrite, 0, bytesRead);
+if (!cloneFile.isOpen()) {
+   cloneFile.open();
 }
 
-newMessage.addBytes(bufferToWrite);
-
-if (bytesRead < bufferBytes.length) {
-   break;
+cloneFile.position(0);
+
+for (;;) {
+   // The buffer is reused...
+   // We need to make sure we clear the limits and the buffer 
before reusing it
+   buffer.clear();
+   int bytesRead = cloneFile.read(buffer);
+
+   byte[] bufferToWrite;
+   if (bytesRead <= 0) {
+  break;
+   } else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
+  // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
+  // otherwise there could be another thread still using the 
buffer on a
+  // replication.
+  bufferToWrite = bufferBytes;
+   } else {
+  bufferToWrite = new byte[bytesRead];
+  System.arraycopy(bufferBytes, 0, bufferToWrite, 0, 
bytesRead);
+   }
+
+   newMessage.addBytes(bufferToWrite);
+
+   if (bytesRead < bufferBytes.length) {
+  break;
+   }
 }
- }
-
- file.position(oldPosition);
-
- if (!originallyOpen) {
-file.close(false);
-newMessage.getFile().close();
+ } finally {
+cloneFile.close();
  }
 
 Review comment:
   @clebertsuconic @gaohoward I don't understand why we only close file when 
old file is not originally opened? In your case where other consumers open file 
and deliver, the file of new large message might not be closed. This will 
result in file leak and maybe data corrupt if broker crashes, wdyt?
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>   

[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 09/Oct/19 19:13
Start Date: 09/Oct/19 19:13
Worklog Time Spent: 10m 
  Work Description: jbertram commented on issue #2850: ARTEMIS-2504 
implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-540147310
 
 
   @michaelandrepearce, try it now. I eliminated the copy when populating the 
new queue with the old messages.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 6h 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 09/Oct/19 16:11
Start Date: 09/Oct/19 16:11
Worklog Time Spent: 10m 
  Work Description: gaohoward commented on issue #2859: ARTEMIS-2513 Large 
message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#issuecomment-540072662
 
 
   I'll run jenkins again.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> In LargeMessageImpl.copy(long) it need to open the underlying file in order 
> to read and copy bytes into the new copied message. However there is a chance 
> that another thread can come in and close the file in the middle, making the 
> copy failed with "channel is null" error.
> This is happening in cases where a large message is sent to a jms topic 
> (multicast address). During delivery it to multiple subscribers, some 
> consumer is doing delivery and closed the underlying file after. Some other 
> consumer is rolling back the messages and eventually move it to DLQ (which 
> will call the above copy method). So there is a chance this bug being hit on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 09/Oct/19 15:50
Start Date: 09/Oct/19 15:50
Worklog Time Spent: 10m 
  Work Description: gaohoward commented on issue #2859: ARTEMIS-2513 Large 
message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#issuecomment-540063855
 
 
   @clebertsuconic Yes I'm fixing it. Also same issue with hornetq. I'll fix 
that too.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> In LargeMessageImpl.copy(long) it need to open the underlying file in order 
> to read and copy bytes into the new copied message. However there is a chance 
> that another thread can come in and close the file in the middle, making the 
> copy failed with "channel is null" error.
> This is happening in cases where a large message is sent to a jms topic 
> (multicast address). During delivery it to multiple subscribers, some 
> consumer is doing delivery and closed the underlying file after. Some other 
> consumer is rolling back the messages and eventually move it to DLQ (which 
> will call the above copy method). So there is a chance this bug being hit on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 09/Oct/19 15:50
Start Date: 09/Oct/19 15:50
Worklog Time Spent: 10m 
  Work Description: gaohoward commented on pull request #2859: ARTEMIS-2513 
Large message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#discussion_r333093509
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/LargeServerMessageImpl.java
 ##
 @@ -368,52 +368,48 @@ public Message copy(final long newID) {
   try {
  LargeServerMessage newMessage = 
storageManager.createLargeMessage(newID, this);
 
- boolean originallyOpen = file != null && file.isOpen();
+ //clone a SequentialFile to avoid concurrent access
+ ensureFileExists(false);
+ SequentialFile cloneFile = file.cloneFile();
 
- validateFile();
-
- byte[] bufferBytes = new byte[100 * 1024];
-
- ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
+ try {
+byte[] bufferBytes = new byte[100 * 1024];
 
- long oldPosition = file.position();
+ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
 
- if (!file.isOpen()) {
-file.open();
- }
- file.position(0);
-
- for (;;) {
-// The buffer is reused...
-// We need to make sure we clear the limits and the buffer before 
reusing it
-buffer.clear();
-int bytesRead = file.read(buffer);
-
-byte[] bufferToWrite;
-if (bytesRead <= 0) {
-   break;
-} else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
-   // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
-   // otherwise there could be another thread still using the 
buffer on a
-   // replication.
-   bufferToWrite = bufferBytes;
-} else {
-   bufferToWrite = new byte[bytesRead];
-   System.arraycopy(bufferBytes, 0, bufferToWrite, 0, bytesRead);
+if (!cloneFile.isOpen()) {
+   cloneFile.open();
 }
 
-newMessage.addBytes(bufferToWrite);
-
-if (bytesRead < bufferBytes.length) {
-   break;
+cloneFile.position(0);
+
+for (;;) {
+   // The buffer is reused...
+   // We need to make sure we clear the limits and the buffer 
before reusing it
+   buffer.clear();
+   int bytesRead = cloneFile.read(buffer);
+
+   byte[] bufferToWrite;
+   if (bytesRead <= 0) {
+  break;
+   } else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
+  // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
+  // otherwise there could be another thread still using the 
buffer on a
+  // replication.
+  bufferToWrite = bufferBytes;
+   } else {
+  bufferToWrite = new byte[bytesRead];
+  System.arraycopy(bufferBytes, 0, bufferToWrite, 0, 
bytesRead);
+   }
+
+   newMessage.addBytes(bufferToWrite);
+
+   if (bytesRead < bufferBytes.length) {
+  break;
+   }
 }
- }
-
- file.position(oldPosition);
-
- if (!originallyOpen) {
-file.close(false);
-newMessage.getFile().close();
+ } finally {
+cloneFile.close();
  }
 
 Review comment:
   yes it should be closed as original code. That'll cause file leak.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.11.0
>
>  Time 

[jira] [Work logged] (ARTEMIS-2508) Crititical analyser trigger shutdown if removeAllMessages

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 09/Oct/19 15:41
Start Date: 09/Oct/19 15:41
Worklog Time Spent: 10m 
  Work Description: asfgit commented on pull request #2855: ARTEMIS-2508 
Crititical analyser trigger shutdown if removeAllMessages
URL: https://github.com/apache/activemq-artemis/pull/2855
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Crititical analyser trigger shutdown if removeAllMessages
> -
>
> Key: ARTEMIS-2508
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2508
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The crititical analyser trigger the broker shutdown if try to 
> removeAllMessages with a huge queue. 
> {code:java}
> WARN  [org.apache.activemq.artemis.utils.critical.CriticalMeasure] Component 
> org.apache.activemq.artemis.core.server.impl.QueueImpl is expired on path 3
> ERROR [org.apache.activemq.artemis.core.server] AMQ224079: The process for 
> the virtual machine will be killed, as component QueueImpl[name=TEST, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=ba803379-cfa8-11e9-8c2b-0c4de9ce8296], 
> temp=false]@3cf3f5cb is not responsive
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2503) Improve wildcards for the roles access match

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 09/Oct/19 15:22
Start Date: 09/Oct/19 15:22
Worklog Time Spent: 10m 
  Work Description: brusdev commented on pull request #2851: ARTEMIS-2503 
Improve wildcards for the roles access match
URL: https://github.com/apache/activemq-artemis/pull/2851#discussion_r333078297
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/management/JMXAccessControlList.java
 ##
 @@ -25,12 +25,22 @@
 import java.util.Map;
 import java.util.concurrent.ConcurrentHashMap;
 
+import org.apache.activemq.artemis.core.config.WildcardConfiguration;
+import org.apache.activemq.artemis.core.settings.HierarchicalRepository;
+import 
org.apache.activemq.artemis.core.settings.impl.HierarchicalObjectRepository;
+
 public class JMXAccessControlList {
 
private Access defaultAccess = new Access("*");
-   private Map domainAccess = new HashMap<>();
+   private HierarchicalRepository domainAccess;
private ConcurrentHashMap> whitelist = new 
ConcurrentHashMap<>();
 
+   public JMXAccessControlList() {
+  WildcardConfiguration domainAccessWildcardConfiguration = new 
WildcardConfiguration();
 
 Review comment:
   @michaelandrepearce WDYT about the last changes?
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Improve wildcards for the roles access match
> 
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Please improve wildcard support for the key element in the roles access 
>  element.
> ATM you can NOT apply a restriction across a set of queue instances starting 
> with the same prefix (like below):
> {code:java}
> 
>
>
>...
> {code}
> If queues are created dynamically and only a queue name "prefix" is known in 
> advance; JMX RBAC cannot be used to restrict access in this case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 09/Oct/19 15:20
Start Date: 09/Oct/19 15:20
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on issue #2859: ARTEMIS-2513 
Large message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#issuecomment-540050231
 
 
   There are files leaking in your test.
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> In LargeMessageImpl.copy(long) it need to open the underlying file in order 
> to read and copy bytes into the new copied message. However there is a chance 
> that another thread can come in and close the file in the middle, making the 
> copy failed with "channel is null" error.
> This is happening in cases where a large message is sent to a jms topic 
> (multicast address). During delivery it to multiple subscribers, some 
> consumer is doing delivery and closed the underlying file after. Some other 
> consumer is rolling back the messages and eventually move it to DLQ (which 
> will call the above copy method). So there is a chance this bug being hit on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 09/Oct/19 13:29
Start Date: 09/Oct/19 13:29
Worklog Time Spent: 10m 
  Work Description: wy96f commented on pull request #2859: ARTEMIS-2513 
Large message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#discussion_r333012845
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/LargeServerMessageImpl.java
 ##
 @@ -368,52 +368,48 @@ public Message copy(final long newID) {
   try {
  LargeServerMessage newMessage = 
storageManager.createLargeMessage(newID, this);
 
- boolean originallyOpen = file != null && file.isOpen();
+ //clone a SequentialFile to avoid concurrent access
+ ensureFileExists(false);
+ SequentialFile cloneFile = file.cloneFile();
 
- validateFile();
-
- byte[] bufferBytes = new byte[100 * 1024];
-
- ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
+ try {
+byte[] bufferBytes = new byte[100 * 1024];
 
- long oldPosition = file.position();
+ByteBuffer buffer = ByteBuffer.wrap(bufferBytes);
 
- if (!file.isOpen()) {
-file.open();
- }
- file.position(0);
-
- for (;;) {
-// The buffer is reused...
-// We need to make sure we clear the limits and the buffer before 
reusing it
-buffer.clear();
-int bytesRead = file.read(buffer);
-
-byte[] bufferToWrite;
-if (bytesRead <= 0) {
-   break;
-} else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
-   // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
-   // otherwise there could be another thread still using the 
buffer on a
-   // replication.
-   bufferToWrite = bufferBytes;
-} else {
-   bufferToWrite = new byte[bytesRead];
-   System.arraycopy(bufferBytes, 0, bufferToWrite, 0, bytesRead);
+if (!cloneFile.isOpen()) {
+   cloneFile.open();
 }
 
-newMessage.addBytes(bufferToWrite);
-
-if (bytesRead < bufferBytes.length) {
-   break;
+cloneFile.position(0);
+
+for (;;) {
+   // The buffer is reused...
+   // We need to make sure we clear the limits and the buffer 
before reusing it
+   buffer.clear();
+   int bytesRead = cloneFile.read(buffer);
+
+   byte[] bufferToWrite;
+   if (bytesRead <= 0) {
+  break;
+   } else if (bytesRead == bufferBytes.length && 
!this.storageManager.isReplicated()) {
+  // ARTEMIS-1220: We cannot reuse the same buffer if it's 
replicated
+  // otherwise there could be another thread still using the 
buffer on a
+  // replication.
+  bufferToWrite = bufferBytes;
+   } else {
+  bufferToWrite = new byte[bytesRead];
+  System.arraycopy(bufferBytes, 0, bufferToWrite, 0, 
bytesRead);
+   }
+
+   newMessage.addBytes(bufferToWrite);
+
+   if (bytesRead < bufferBytes.length) {
+  break;
+   }
 }
- }
-
- file.position(oldPosition);
-
- if (!originallyOpen) {
-file.close(false);
-newMessage.getFile().close();
+ } finally {
+cloneFile.close();
  }
 
 Review comment:
   Do we need to close underlying file of new large message after copy?
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 

[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 09/Oct/19 13:18
Start Date: 09/Oct/19 13:18
Worklog Time Spent: 10m 
  Work Description: gaohoward commented on issue #2859: ARTEMIS-2513 Large 
message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859#issuecomment-539996782
 
 
   pls hold this, it's getting test failures in jenkins.
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In LargeMessageImpl.copy(long) it need to open the underlying file in order 
> to read and copy bytes into the new copied message. However there is a chance 
> that another thread can come in and close the file in the middle, making the 
> copy failed with "channel is null" error.
> This is happening in cases where a large message is sent to a jms topic 
> (multicast address). During delivery it to multiple subscribers, some 
> consumer is doing delivery and closed the underlying file after. Some other 
> consumer is rolling back the messages and eventually move it to DLQ (which 
> will call the above copy method). So there is a chance this bug being hit on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2508) Crititical analyser trigger shutdown if removeAllMessages

2019-10-09 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 09/Oct/19 07:50
Start Date: 09/Oct/19 07:50
Worklog Time Spent: 10m 
  Work Description: wy96f commented on issue #2855: ARTEMIS-2508 Crititical 
analyser trigger shutdown if removeAllMessages
URL: https://github.com/apache/activemq-artemis/pull/2855#issuecomment-539882836
 
 
   > @wy96f what about not use the page Executor for the delete?
   > 
   > The page executor was meant for cleanup and paging, not for deleting 
references on the queue.
   
   Yes, that's what i thought :)
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Crititical analyser trigger shutdown if removeAllMessages
> -
>
> Key: ARTEMIS-2508
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2508
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The crititical analyser trigger the broker shutdown if try to 
> removeAllMessages with a huge queue. 
> {code:java}
> WARN  [org.apache.activemq.artemis.utils.critical.CriticalMeasure] Component 
> org.apache.activemq.artemis.core.server.impl.QueueImpl is expired on path 3
> ERROR [org.apache.activemq.artemis.core.server] AMQ224079: The process for 
> the virtual machine will be killed, as component QueueImpl[name=TEST, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=ba803379-cfa8-11e9-8c2b-0c4de9ce8296], 
> temp=false]@3cf3f5cb is not responsive
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2513) Large message's copy may be interfered by other threads

2019-10-08 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 09/Oct/19 02:24
Start Date: 09/Oct/19 02:24
Worklog Time Spent: 10m 
  Work Description: gaohoward commented on pull request #2859: ARTEMIS-2513 
Large message's copy may be interfered by other threads
URL: https://github.com/apache/activemq-artemis/pull/2859
 
 
   In LargeMessageImpl.copy(long) it need to open the underlying
   file in order to read and copy bytes into the new copied message.
   However there is a chance that another thread can come in and close
   the file in the middle, making the copy failed
   with "channel is null" error.
   
   This is happening in cases where a large message is sent to a jms
   topic (multicast address). During delivery it to multiple
   subscribers, some consumer is doing delivery and closed the
   underlying file after. Some other consumer is rolling back
   the messages and eventually move it to DLQ (which will call
   the above copy method). So there is a chance this bug being hit on.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Large message's copy may be interfered by other threads
> ---
>
> Key: ARTEMIS-2513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2513
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.10.1
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.11.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In LargeMessageImpl.copy(long) it need to open the underlying file in order 
> to read and copy bytes into the new copied message. However there is a chance 
> that another thread can come in and close the file in the middle, making the 
> copy failed with "channel is null" error.
> This is happening in cases where a large message is sent to a jms topic 
> (multicast address). During delivery it to multiple subscribers, some 
> consumer is doing delivery and closed the underlying file after. Some other 
> consumer is rolling back the messages and eventually move it to DLQ (which 
> will call the above copy method). So there is a chance this bug being hit on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2514) Duplicate cache leak with clustered temp queues

2019-10-08 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 08/Oct/19 21:21
Start Date: 08/Oct/19 21:21
Worklog Time Spent: 10m 
  Work Description: asfgit commented on pull request #2858: ARTEMIS-2514 
dupl cache leak w/clustered temp q
URL: https://github.com/apache/activemq-artemis/pull/2858
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Duplicate cache leak with clustered temp queues
> ---
>
> Key: ARTEMIS-2514
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2514
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.10.1
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2514) Duplicate cache leak with clustered temp queues

2019-10-08 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 08/Oct/19 16:44
Start Date: 08/Oct/19 16:44
Worklog Time Spent: 10m 
  Work Description: jbertram commented on pull request #2858: ARTEMIS-2514 
dupl cache leak w/clustered temp q
URL: https://github.com/apache/activemq-artemis/pull/2858
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Duplicate cache leak with clustered temp queues
> ---
>
> Key: ARTEMIS-2514
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2514
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.10.1
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2512) Move the LocalMonitor tick log

2019-10-07 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 07/Oct/19 20:12
Start Date: 07/Oct/19 20:12
Worklog Time Spent: 10m 
  Work Description: asfgit commented on pull request #2857: ARTEMIS-2512 
Move the LocalMonitor tick log
URL: https://github.com/apache/activemq-artemis/pull/2857
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Move the LocalMonitor tick log
> --
>
> Key: ARTEMIS-2512
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2512
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Can we please move the logging below to its own logger. This is very useful 
> logging to establish a "heartbeat" log statement (logging consistently every 
> 5 seconds) when investigating potential CPU starvation or "pause" issues.
> {noformat}
> ...TRACE [org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl] 
> Tick from store...
> {noformat}
> Right now, it is TRACE on the PagingManager logger. That includes other log 
> statements that is too verbose to leave activated indefinitely in production.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2512) Move the LocalMonitor tick log

2019-10-07 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 07/Oct/19 20:12
Start Date: 07/Oct/19 20:12
Worklog Time Spent: 10m 
  Work Description: asfgit commented on pull request #2857: ARTEMIS-2512 
Move the LocalMonitor tick log
URL: https://github.com/apache/activemq-artemis/pull/2857
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Move the LocalMonitor tick log
> --
>
> Key: ARTEMIS-2512
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2512
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Can we please move the logging below to its own logger. This is very useful 
> logging to establish a "heartbeat" log statement (logging consistently every 
> 5 seconds) when investigating potential CPU starvation or "pause" issues.
> {noformat}
> ...TRACE [org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl] 
> Tick from store...
> {noformat}
> Right now, it is TRACE on the PagingManager logger. That includes other log 
> statements that is too verbose to leave activated indefinitely in production.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2508) Crititical analyser trigger shutdown if removeAllMessages

2019-10-07 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 07/Oct/19 19:29
Start Date: 07/Oct/19 19:29
Worklog Time Spent: 10m 
  Work Description: brusdev commented on issue #2855: ARTEMIS-2508 
Crititical analyser trigger shutdown if removeAllMessages
URL: https://github.com/apache/activemq-artemis/pull/2855#issuecomment-539167362
 
 
   I used the page Executor because the iteration on paged queue seemed like 
quite similar to depage. Now I see your points of views so I'll just remove the 
locks and I'll keep it in the caller thread.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Crititical analyser trigger shutdown if removeAllMessages
> -
>
> Key: ARTEMIS-2508
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2508
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The crititical analyser trigger the broker shutdown if try to 
> removeAllMessages with a huge queue. 
> {code:java}
> WARN  [org.apache.activemq.artemis.utils.critical.CriticalMeasure] Component 
> org.apache.activemq.artemis.core.server.impl.QueueImpl is expired on path 3
> ERROR [org.apache.activemq.artemis.core.server] AMQ224079: The process for 
> the virtual machine will be killed, as component QueueImpl[name=TEST, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=ba803379-cfa8-11e9-8c2b-0c4de9ce8296], 
> temp=false]@3cf3f5cb is not responsive
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2508) Crititical analyser trigger shutdown if removeAllMessages

2019-10-07 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 07/Oct/19 19:19
Start Date: 07/Oct/19 19:19
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on issue #2855: ARTEMIS-2508 
Crititical analyser trigger shutdown if removeAllMessages
URL: https://github.com/apache/activemq-artemis/pull/2855#issuecomment-539163812
 
 
   hold a future waiting for the result has the same result as using the main 
thread anyway, right?
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Crititical analyser trigger shutdown if removeAllMessages
> -
>
> Key: ARTEMIS-2508
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2508
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The crititical analyser trigger the broker shutdown if try to 
> removeAllMessages with a huge queue. 
> {code:java}
> WARN  [org.apache.activemq.artemis.utils.critical.CriticalMeasure] Component 
> org.apache.activemq.artemis.core.server.impl.QueueImpl is expired on path 3
> ERROR [org.apache.activemq.artemis.core.server] AMQ224079: The process for 
> the virtual machine will be killed, as component QueueImpl[name=TEST, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=ba803379-cfa8-11e9-8c2b-0c4de9ce8296], 
> temp=false]@3cf3f5cb is not responsive
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-07 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 07/Oct/19 18:19
Start Date: 07/Oct/19 18:19
Worklog Time Spent: 10m 
  Work Description: jbertram commented on issue #2850: ARTEMIS-2504 
implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-539140540
 
 
   > if an address is paging to disk, ring queue still gets new messages 
delivered, theyre just paged references.
   
   According to my tests the ring queue will *not* actually get those messages. 
From what I can tell messages are paged at the address level, and they aren't 
added to the actual queue until they are de-paged.
   
   Regarding the performance issues, my initial recommendation would be to 
limit the size of the ring queue to avoid such problems. As for your ideas...
   
   > is there a way to control the copy over so its not done as one big bang 
(e.g. as fast as broker can possible do), but feed the new queue at the rate 
the consumer is consuming there for avoiding the very big spike in object 
creation.
   
   I understand your point about throttling the copy speed, but I'm not sure 
that will provide the semantics a consumer expects. Once the queue is created 
then it will receive any "new" message sent to the queue's address (at least in 
the multicast use-case). If the "old," retroactive messages are not all 
immediately added to the queue then the consumer might receive "new" messages 
before it receives all the "old" ones. 
   
   Also, since messages are added to the queue when it is first created and 
before the client even consumes anything how can we calculate the consumption 
rate in order to throttle the copy rate?
   
   > Is it possible to make it so that we dont have to copy, but it simply is a 
message ref?
   
   I'll explore this possibility.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 324544)
Time Spent: 6h  (was: 5h 50m)

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 6h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2512) Move the LocalMonitor tick log

2019-10-07 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 07/Oct/19 16:17
Start Date: 07/Oct/19 16:17
Worklog Time Spent: 10m 
  Work Description: brusdev commented on pull request #2857: ARTEMIS-2512 
Move the LocalMonitor tick log
URL: https://github.com/apache/activemq-artemis/pull/2857
 
 
   The LocalMonitor tick log is very useful to establish a "heartbeat" log
   statement. It is moved into its own logger from PagingManager logger,
   which is too verbose to leave activated indefinitely in production.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Move the LocalMonitor tick log
> --
>
> Key: ARTEMIS-2512
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2512
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Can we please move the logging below to its own logger. This is very useful 
> logging to establish a "heartbeat" log statement (logging consistently every 
> 5 seconds) when investigating potential CPU starvation or "pause" issues.
> {noformat}
> ...TRACE [org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl] 
> Tick from store...
> {noformat}
> Right now, it is TRACE on the PagingManager logger. That includes other log 
> statements that is too verbose to leave activated indefinitely in production.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2508) Crititical analyser trigger shutdown if removeAllMessages

2019-10-07 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 07/Oct/19 14:19
Start Date: 07/Oct/19 14:19
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on issue #2855: ARTEMIS-2508 
Crititical analyser trigger shutdown if removeAllMessages
URL: https://github.com/apache/activemq-artemis/pull/2855#issuecomment-539034551
 
 
   @wy96f what about not use the page Executor for the delete?
   
   The page executor was meant for cleanup and paging, not for deleting 
references on the queue.
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Crititical analyser trigger shutdown if removeAllMessages
> -
>
> Key: ARTEMIS-2508
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2508
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The crititical analyser trigger the broker shutdown if try to 
> removeAllMessages with a huge queue. 
> {code:java}
> WARN  [org.apache.activemq.artemis.utils.critical.CriticalMeasure] Component 
> org.apache.activemq.artemis.core.server.impl.QueueImpl is expired on path 3
> ERROR [org.apache.activemq.artemis.core.server] AMQ224079: The process for 
> the virtual machine will be killed, as component QueueImpl[name=TEST, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=ba803379-cfa8-11e9-8c2b-0c4de9ce8296], 
> temp=false]@3cf3f5cb is not responsive
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2508) Crititical analyser trigger shutdown if removeAllMessages

2019-10-07 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 07/Oct/19 14:19
Start Date: 07/Oct/19 14:19
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on issue #2855: ARTEMIS-2508 
Crititical analyser trigger shutdown if removeAllMessages
URL: https://github.com/apache/activemq-artemis/pull/2855#issuecomment-539034933
 
 
   I don't understand why we are using an executor now for removing? why not 
just remove the locks and keep the change simple?
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Crititical analyser trigger shutdown if removeAllMessages
> -
>
> Key: ARTEMIS-2508
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2508
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The crititical analyser trigger the broker shutdown if try to 
> removeAllMessages with a huge queue. 
> {code:java}
> WARN  [org.apache.activemq.artemis.utils.critical.CriticalMeasure] Component 
> org.apache.activemq.artemis.core.server.impl.QueueImpl is expired on path 3
> ERROR [org.apache.activemq.artemis.core.server] AMQ224079: The process for 
> the virtual machine will be killed, as component QueueImpl[name=TEST, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=ba803379-cfa8-11e9-8c2b-0c4de9ce8296], 
> temp=false]@3cf3f5cb is not responsive
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2497) Allow configuring alternative reject behavior for AMQP

2019-10-06 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 06/Oct/19 08:06
Start Date: 06/Oct/19 08:06
Worklog Time Spent: 10m 
  Work Description: k-wall commented on pull request #2848: ARTEMIS-2497: 
[AMQP] Allow handling of the reject disposition to be configured
URL: https://github.com/apache/activemq-artemis/pull/2848#discussion_r331776305
 
 

 ##
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/config/impl/ConfigurationImpl.java
 ##
 @@ -306,6 +306,8 @@
 
private Long globalMaxSize;
 
+   private boolean amqpTreatRejectAsUnmodifiedDeliveryFailed = 
ActiveMQDefaultConfiguration.getDefaultTreatRejectAsUnmodifiedDeliveryFailed();
 
 Review comment:
   Done
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 324023)
Time Spent: 1.5h  (was: 1h 20m)

> Allow configuring alternative reject behavior for AMQP
> --
>
> Key: ARTEMIS-2497
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2497
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.10.0
>Reporter: Ulf Lilleengen
>Priority: Major
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
>  In EnMasse, we use a broker plugin to forward messages to a remote AMQP 
> endpoint. If the remote endpoint responds with a reject, we would like to 
> retry the message.
>  
> At present, the AMQP implementation will deal with rejects by immediately 
> putting the messages on a DLQ (if exists).
>  
> It would be nice to have a configuration option to have rejects be treated 
> similarly to released by attempting retransmit before moving to DLQ.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2497) Allow configuring alternative reject behavior for AMQP

2019-10-06 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 06/Oct/19 08:05
Start Date: 06/Oct/19 08:05
Worklog Time Spent: 10m 
  Work Description: k-wall commented on pull request #2848: ARTEMIS-2497: 
[AMQP] Allow handling of the reject disposition to be configured
URL: https://github.com/apache/activemq-artemis/pull/2848#discussion_r331776294
 
 

 ##
 File path: artemis-server/src/main/resources/schema/artemis-configuration.xsd
 ##
 @@ -54,6 +54,15 @@
 
  
 
+ 
 
 Review comment:
   Done
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Allow configuring alternative reject behavior for AMQP
> --
>
> Key: ARTEMIS-2497
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2497
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.10.0
>Reporter: Ulf Lilleengen
>Priority: Major
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
>  In EnMasse, we use a broker plugin to forward messages to a remote AMQP 
> endpoint. If the remote endpoint responds with a reject, we would like to 
> retry the message.
>  
> At present, the AMQP implementation will deal with rejects by immediately 
> putting the messages on a DLQ (if exists).
>  
> It would be nice to have a configuration option to have rejects be treated 
> similarly to released by attempting retransmit before moving to DLQ.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2497) Allow configuring alternative reject behavior for AMQP

2019-10-06 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 06/Oct/19 08:05
Start Date: 06/Oct/19 08:05
Worklog Time Spent: 10m 
  Work Description: k-wall commented on issue #2848: ARTEMIS-2497: [AMQP] 
Allow handling of the reject disposition to be configured
URL: https://github.com/apache/activemq-artemis/pull/2848#issuecomment-538721906
 
 
   @clebertsuconic review comments addressed and commits squashed.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Allow configuring alternative reject behavior for AMQP
> --
>
> Key: ARTEMIS-2497
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2497
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.10.0
>Reporter: Ulf Lilleengen
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
>  In EnMasse, we use a broker plugin to forward messages to a remote AMQP 
> endpoint. If the remote endpoint responds with a reject, we would like to 
> retry the message.
>  
> At present, the AMQP implementation will deal with rejects by immediately 
> putting the messages on a DLQ (if exists).
>  
> It would be nice to have a configuration option to have rejects be treated 
> similarly to released by attempting retransmit before moving to DLQ.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-619) Remote detach is not handled properly for sender link

2019-10-05 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-619?focusedWorklogId=323905=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-323905
 ]

ASF GitHub Bot logged work on AMQNET-619:
-

Author: ASF GitHub Bot
Created on: 05/Oct/19 11:02
Start Date: 05/Oct/19 11:02
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on pull request #42: 
AMQNET-619: Handle remote detach properly for sender link
URL: https://github.com/apache/activemq-nms-amqp/pull/42
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Remote detach is not handled properly for sender link
> -
>
> Key: AMQNET-619
> URL: https://issues.apache.org/jira/browse/AMQNET-619
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Remote detach is not handled properly for sender link. MessageProducer is 
> created even if no link terminus was created. It results in unexpected 
> behavior if we try to use MessageProducer immediately after its creation



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-619) Remote detach is not handled properly for sender link

2019-10-05 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-619?focusedWorklogId=323888=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-323888
 ]

ASF GitHub Bot logged work on AMQNET-619:
-

Author: ASF GitHub Bot
Created on: 05/Oct/19 08:23
Start Date: 05/Oct/19 08:23
Worklog Time Spent: 10m 
  Work Description: Havret commented on pull request #42: AMQNET-619: 
Handle remote detach properly for sender link
URL: https://github.com/apache/activemq-nms-amqp/pull/42#discussion_r331738433
 
 

 ##
 File path: src/NMS.AMQP/Provider/Amqp/AmqpProducer.cs
 ##
 @@ -53,13 +53,13 @@ public Task Attach()
 };
 
 string linkName = info.Id + ":" + target.Address;
-var taskCompletionSource = new TaskCompletionSource();
-senderLink = new SenderLink(session.UnderlyingSession, linkName, 
frame, (link, attach) => { taskCompletionSource.SetResult(true); });
+TaskCompletionSource tsc = new TaskCompletionSource();
 
 Review comment:
   Hope it's ok 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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Remote detach is not handled properly for sender link
> -
>
> Key: AMQNET-619
> URL: https://issues.apache.org/jira/browse/AMQNET-619
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Remote detach is not handled properly for sender link. MessageProducer is 
> created even if no link terminus was created. It results in unexpected 
> behavior if we try to use MessageProducer immediately after its creation



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-620) ConnectionFactory is not initialized properly with Uri overload

2019-10-05 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-620?focusedWorklogId=323885=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-323885
 ]

ASF GitHub Bot logged work on AMQNET-620:
-

Author: ASF GitHub Bot
Created on: 05/Oct/19 06:56
Start Date: 05/Oct/19 06:56
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on pull request #44: 
AMQNET-620: Initialize ConnectionFactory properly with System.Uri overload
URL: https://github.com/apache/activemq-nms-amqp/pull/44
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> ConnectionFactory is not initialized properly with Uri overload
> ---
>
> Key: AMQNET-620
> URL: https://issues.apache.org/jira/browse/AMQNET-620
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
> Fix For: 1.8.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> ConnectionFactory is not initialized properly with constructor that takes 
> System.Uri as a parameter. Additional properties that are specified in broker 
> uri (like username or password) are not applied on connection factory.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-619) Remote detach is not handled properly for sender link

2019-10-05 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-619?focusedWorklogId=323884=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-323884
 ]

ASF GitHub Bot logged work on AMQNET-619:
-

Author: ASF GitHub Bot
Created on: 05/Oct/19 06:55
Start Date: 05/Oct/19 06:55
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on pull request #42: 
AMQNET-619: Handle remote detach properly for sender link
URL: https://github.com/apache/activemq-nms-amqp/pull/42#discussion_r331736022
 
 

 ##
 File path: src/NMS.AMQP/Provider/Amqp/AmqpProducer.cs
 ##
 @@ -53,13 +53,13 @@ public Task Attach()
 };
 
 string linkName = info.Id + ":" + target.Address;
-var taskCompletionSource = new TaskCompletionSource();
-senderLink = new SenderLink(session.UnderlyingSession, linkName, 
frame, (link, attach) => { taskCompletionSource.SetResult(true); });
+TaskCompletionSource tsc = new TaskCompletionSource();
 
 Review comment:
   You made further changes...:s the name is still shortened  i meant to put it 
back to var taskCompletionService so there is no change in this line.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Remote detach is not handled properly for sender link
> -
>
> Key: AMQNET-619
> URL: https://issues.apache.org/jira/browse/AMQNET-619
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Remote detach is not handled properly for sender link. MessageProducer is 
> created even if no link terminus was created. It results in unexpected 
> behavior if we try to use MessageProducer immediately after its creation



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-619) Remote detach is not handled properly for sender link

2019-10-04 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-619?focusedWorklogId=323872=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-323872
 ]

ASF GitHub Bot logged work on AMQNET-619:
-

Author: ASF GitHub Bot
Created on: 05/Oct/19 04:54
Start Date: 05/Oct/19 04:54
Worklog Time Spent: 10m 
  Work Description: Havret commented on pull request #42: AMQNET-619: 
Handle remote detach properly for sender link
URL: https://github.com/apache/activemq-nms-amqp/pull/42#discussion_r331732826
 
 

 ##
 File path: src/NMS.AMQP/Provider/Amqp/AmqpProducer.cs
 ##
 @@ -53,13 +53,13 @@ public Task Attach()
 };
 
 string linkName = info.Id + ":" + target.Address;
-var taskCompletionSource = new TaskCompletionSource();
-senderLink = new SenderLink(session.UnderlyingSession, linkName, 
frame, (link, attach) => { taskCompletionSource.SetResult(true); });
+var tsc = new TaskCompletionSource();
 
 Review comment:
   Sure thing. Fixed. 
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Remote detach is not handled properly for sender link
> -
>
> Key: AMQNET-619
> URL: https://issues.apache.org/jira/browse/AMQNET-619
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Remote detach is not handled properly for sender link. MessageProducer is 
> created even if no link terminus was created. It results in unexpected 
> behavior if we try to use MessageProducer immediately after its creation



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-620) ConnectionFactory is not initialized properly with Uri overload

2019-10-04 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-620?focusedWorklogId=323871=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-323871
 ]

ASF GitHub Bot logged work on AMQNET-620:
-

Author: ASF GitHub Bot
Created on: 05/Oct/19 04:52
Start Date: 05/Oct/19 04:52
Worklog Time Spent: 10m 
  Work Description: HavretGC commented on pull request #44: AMQNET-620: 
Initialize ConnectionFactory properly with System.Uri overload
URL: https://github.com/apache/activemq-nms-amqp/pull/44#discussion_r331732767
 
 

 ##
 File path: src/NMS.AMQP/NmsConnectionFactory.cs
 ##
 @@ -58,7 +58,7 @@ public NmsConnectionFactory(string brokerUri)
 
 public NmsConnectionFactory(Uri brokerUri)
 {
-this.brokerUri = brokerUri;
+this.BrokerUri = brokerUri;
 
 Review comment:
   Amended.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> ConnectionFactory is not initialized properly with Uri overload
> ---
>
> Key: AMQNET-620
> URL: https://issues.apache.org/jira/browse/AMQNET-620
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
> Fix For: 1.8.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> ConnectionFactory is not initialized properly with constructor that takes 
> System.Uri as a parameter. Additional properties that are specified in broker 
> uri (like username or password) are not applied on connection factory.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-619) Remote detach is not handled properly for sender link

2019-10-04 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-619?focusedWorklogId=323866=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-323866
 ]

ASF GitHub Bot logged work on AMQNET-619:
-

Author: ASF GitHub Bot
Created on: 05/Oct/19 03:56
Start Date: 05/Oct/19 03:56
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on pull request #42: 
AMQNET-619: Handle remote detach properly for sender link
URL: https://github.com/apache/activemq-nms-amqp/pull/42#discussion_r331731380
 
 

 ##
 File path: src/NMS.AMQP/Provider/Amqp/AmqpProducer.cs
 ##
 @@ -53,13 +53,13 @@ public Task Attach()
 };
 
 string linkName = info.Id + ":" + target.Address;
-var taskCompletionSource = new TaskCompletionSource();
-senderLink = new SenderLink(session.UnderlyingSession, linkName, 
frame, (link, attach) => { taskCompletionSource.SetResult(true); });
+var tsc = new TaskCompletionSource();
 
 Review comment:
   Can you revert the shortening of the var. Unneeded 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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Remote detach is not handled properly for sender link
> -
>
> Key: AMQNET-619
> URL: https://issues.apache.org/jira/browse/AMQNET-619
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Remote detach is not handled properly for sender link. MessageProducer is 
> created even if no link terminus was created. It results in unexpected 
> behavior if we try to use MessageProducer immediately after its creation



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-620) ConnectionFactory is not initialized properly with Uri overload

2019-10-04 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-620?focusedWorklogId=323865=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-323865
 ]

ASF GitHub Bot logged work on AMQNET-620:
-

Author: ASF GitHub Bot
Created on: 05/Oct/19 03:54
Start Date: 05/Oct/19 03:54
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on pull request #44: 
AMQNET-620: Initialize ConnectionFactory properly with System.Uri overload
URL: https://github.com/apache/activemq-nms-amqp/pull/44#discussion_r331731333
 
 

 ##
 File path: src/NMS.AMQP/NmsConnectionFactory.cs
 ##
 @@ -58,7 +58,7 @@ public NmsConnectionFactory(string brokerUri)
 
 public NmsConnectionFactory(Uri brokerUri)
 {
-this.brokerUri = brokerUri;
+this.BrokerUri = brokerUri;
 
 Review comment:
   Nit. But so is consistent with other constructors can the "this" be removed
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> ConnectionFactory is not initialized properly with Uri overload
> ---
>
> Key: AMQNET-620
> URL: https://issues.apache.org/jira/browse/AMQNET-620
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
> Fix For: 1.8.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> ConnectionFactory is not initialized properly with constructor that takes 
> System.Uri as a parameter. Additional properties that are specified in broker 
> uri (like username or password) are not applied on connection factory.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-04 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 04/Oct/19 22:27
Start Date: 04/Oct/19 22:27
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on issue #2850: 
ARTEMIS-2504 implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-538579769
 
 
   @jbertram tbh im struggling to understand still the issue, if an address is 
paging to disk, ring queue still gets new messages delivered, theyre just paged 
references.
   
   on address-settings front thanks, that seems to make things work for custom 
wildcards.
   
   When i have a large retro-active queue, and a new consumer joins, and that 
consumer may take 5 minutes to process those messages, im seeing some nasty GC 
spikes at the initial few seconds, from debugging that seems to be when the 
messages are copied back to route to original address and the new queue, as the 
broker goes as fast as it can regardless of the consumer speed. This kind of 
behaviour could destabilise the broker.
   
   Ideas to solve or limit this issue:
   
   1) is there a way to control the copy over so its not done as one big bang 
(e.g. as fast as broker can possible do), but feed the new queue at the rate 
the consumer is consuming there for avoiding the very big spike in object 
creation.
   
   2) Is it possible to make it so that we dont have to copy, but it simply is 
a message ref? 
   
   3) If 2 is not possible because a separate address, could we have a toggle 
that will deploy under the original address and when deployed like such a copy 
isnt needed and simply message ref is added to the queue, so then its a choice 
for end users. this then gives a kind of flexibility depending on end user 
case, with trade off for either, but at least then its up for the end user.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 323768)
Time Spent: 5h 50m  (was: 5h 40m)

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 5h 50m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-04 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 04/Oct/19 22:26
Start Date: 04/Oct/19 22:26
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on issue #2850: 
ARTEMIS-2504 implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-538579769
 
 
   @jbertram tbh im struggling to understand still the issue, if an address is 
paging to disk, ring queue still gets new messages delivered.
   
   on address-settings front thanks, that seems to make things work for custom 
wildcards.
   
   When i have a large retro-active queue, and a new consumer joins, and that 
consumer may take 5 minutes to process those messages, im seeing some nasty GC 
spikes at the initial few seconds, from debugging that seems to be when the 
messages are copied back to route to original address and the new queue, as the 
broker goes as fast as it can regardless of the consumer speed. This kind of 
behaviour could destabilise the broker.
   
   Ideas to solve or limit this issue:
   
   1) is there a way to control the copy over so its not done as one big bang 
(e.g. as fast as broker can possible do), but feed the new queue at the rate 
the consumer is consuming there for avoiding the very big spike in object 
creation.
   
   2) Is it possible to make it so that we dont have to copy, but it simply is 
a message ref? 
   
   3) If 2 is not possible because a separate address, could we have a toggle 
that will deploy under the original address and when deployed like such a copy 
isnt needed and simply message ref is added to the queue, so then its a choice 
for end users. this then gives a kind of flexibility depending on end user 
case, with trade off for either, but at least then its up for the end user.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 323767)
Time Spent: 5h 40m  (was: 5.5h)

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 5h 40m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-620) ConnectionFactory is not initialized properly with Uri overload

2019-10-04 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-620?focusedWorklogId=323261=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-323261
 ]

ASF GitHub Bot logged work on AMQNET-620:
-

Author: ASF GitHub Bot
Created on: 04/Oct/19 07:31
Start Date: 04/Oct/19 07:31
Worklog Time Spent: 10m 
  Work Description: HavretGC commented on pull request #44: AMQNET-620: 
Initialize ConnectionFactory properly with System.Uri overload
URL: https://github.com/apache/activemq-nms-amqp/pull/44
 
 
   ConnectionFactory was not initialized properly with constructor that takes 
System.Uri as a parameter. Additional properties that were specified in broker 
uri (like username or password) were not applied on connection factory.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> ConnectionFactory is not initialized properly with Uri overload
> ---
>
> Key: AMQNET-620
> URL: https://issues.apache.org/jira/browse/AMQNET-620
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
> Fix For: 1.8.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> ConnectionFactory is not initialized properly with constructor that takes 
> System.Uri as a parameter. Additional properties that are specified in broker 
> uri (like username or password) are not applied on connection factory.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-593) Add IsCompositeUri utility method

2019-10-03 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-593?focusedWorklogId=322872=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-322872
 ]

ASF GitHub Bot logged work on AMQNET-593:
-

Author: ASF GitHub Bot
Created on: 03/Oct/19 19:18
Start Date: 03/Oct/19 19:18
Worklog Time Spent: 10m 
  Work Description: Havret commented on pull request #10: AMQNET-593: Add 
IsCompositeUri utility method
URL: https://github.com/apache/activemq-nms-api/pull/10
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Add IsCompositeUri utility method
> -
>
> Key: AMQNET-593
> URL: https://issues.apache.org/jira/browse/AMQNET-593
> Project: ActiveMQ .Net
>  Issue Type: Wish
>  Components: NMS
>Reporter: Krzysztof Porebski
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I would like to extend URISupport class with IsCompositeUri utility method to 
> determine if passed Uri is composite type or not.
> The method is already defined in NMS AMQP but I think it makes sense to move 
> it API where the rest of URISupport is defined. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (ARTEMIS-2504) Support retroactive addresses

2019-10-02 Thread ASF GitHub Bot (Jira)


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

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

Author: ASF GitHub Bot
Created on: 03/Oct/19 00:32
Start Date: 03/Oct/19 00:32
Worklog Time Spent: 10m 
  Work Description: jbertram commented on issue #2850: ARTEMIS-2504 
implement retroactive addresses
URL: https://github.com/apache/activemq-artemis/pull/2850#issuecomment-537736577
 
 
   > It def shouldnt break if paging occurs not entirely sure what you meant 
here.
   
   The explanation is in my previous comment, "...newly created queues won't 
get any of the messages sent after paging started." I assumed you were familiar 
with the caveats for ring queues and paging given they are outlined in the 
documentation and you reviewed that PR.
   
   > One of the bits myself and clebert have discussed once a time ago.
   
   Clebert hasn't been involved in this implementation.
   
   > For address setting match like that it will break if someone uses 
different wildcard configuration...
   
   I addressed this issue in my last push. The names of the resources will 
reflect the delimiter configuration.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 322382)
Time Spent: 5.5h  (was: 5h 20m)

> Support retroactive addresses
> -
>
> Key: ARTEMIS-2504
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2504
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>  Time Spent: 5.5h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-619) Remote detach is not handled properly for sender link

2019-10-02 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-619?focusedWorklogId=322126=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-322126
 ]

ASF GitHub Bot logged work on AMQNET-619:
-

Author: ASF GitHub Bot
Created on: 02/Oct/19 18:31
Start Date: 02/Oct/19 18:31
Worklog Time Spent: 10m 
  Work Description: Havret commented on pull request #42: AMQNET-619: 
Handle remote detach properly for sender link
URL: https://github.com/apache/activemq-nms-amqp/pull/42
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Remote detach is not handled properly for sender link
> -
>
> Key: AMQNET-619
> URL: https://issues.apache.org/jira/browse/AMQNET-619
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Remote detach is not handled properly for sender link. MessageProducer is 
> created even if no link terminus was created. It results in unexpected 
> behavior if we try to use MessageProducer immediately after its creation



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-618) Support noLocal filter

2019-10-01 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-618?focusedWorklogId=321551=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-321551
 ]

ASF GitHub Bot logged work on AMQNET-618:
-

Author: ASF GitHub Bot
Created on: 01/Oct/19 21:31
Start Date: 01/Oct/19 21:31
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on pull request #40: 
AMQNET-618: Support noLocal filter
URL: https://github.com/apache/activemq-nms-amqp/pull/40
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Support noLocal filter
> --
>
> Key: AMQNET-618
> URL: https://issues.apache.org/jira/browse/AMQNET-618
> Project: ActiveMQ .Net
>  Issue Type: New Feature
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add support for noLocal message filter. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-605) Pre-buffered messages aren't released when consumer closes down

2019-10-01 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-605?focusedWorklogId=321549=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-321549
 ]

ASF GitHub Bot logged work on AMQNET-605:
-

Author: ASF GitHub Bot
Created on: 01/Oct/19 21:30
Start Date: 01/Oct/19 21:30
Worklog Time Spent: 10m 
  Work Description: michaelandrepearce commented on pull request #41: 
AMQNET-605: Pre-buffered messages shouldn't be released when consumer closes 
down
URL: https://github.com/apache/activemq-nms-amqp/pull/41
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Pre-buffered messages aren't released when consumer closes down
> ---
>
> Key: AMQNET-605
> URL: https://issues.apache.org/jira/browse/AMQNET-605
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.8.0
>Reporter: Krzysztof Porebski
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Failing unit test 
> ConsumerIntegrationTest.cs --> 
> TestCloseDurableSubscriberWithUnackedAndUnconsumedPrefetchedMessages



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-605) Pre-buffered messages aren't released when consumer closes down

2019-10-01 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-605?focusedWorklogId=321377=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-321377
 ]

ASF GitHub Bot logged work on AMQNET-605:
-

Author: ASF GitHub Bot
Created on: 01/Oct/19 17:19
Start Date: 01/Oct/19 17:19
Worklog Time Spent: 10m 
  Work Description: Havret commented on pull request #41: AMQNET-605: 
Pre-buffered messages shouldn't be released when consumer closes down
URL: https://github.com/apache/activemq-nms-amqp/pull/41
 
 
   This PR removes failing unit test, as we shouldn't support this scenario, 
hence this behavior is specific for _proton_ implementation and is not required 
by amq specification. 
   
   As a reference here's the discussion from dev mailing list discussing the 
issue:
   
   @Havret 
   > Hi guys,
   > 
   > We have an issue in NMS-AMQP 
https://issues.apache.org/jira/browse/AMQNET-605 which simply results in 
prefetched messages not being released after consumer closes down. I looked at 
it today, and it seems to be not as simple to fix as I expected.
   > We have one failing unit tests which was written based on qpid-jms 
implementation --> 
https://github.com/apache/activemq-nms-amqp/blob/65989e154c34c67b284c91b861d0ddc0a7c47b69/test/Apache-NMS-AMQP-Test/Integration/ConsumerIntegrationTest.cs#L235-L294
   > 
   > Can you please help mi to understand how it is possible to send release 
disposition after receiver link is closed? From what I've seen in qpid-jms 
there is no explicit disposition being send while receiver link is being 
closed. Therefore I assume proton must be sending this disposition implicitly. 
If so, my question is, whether this behavior meets the amqp spec. If so, I 
assume that AmqpNetLite which is our equivalent of proton, should mimic this 
behavior. 
   > 
   > Thanks,
   > Chris
   
   @gemmellr
   > It is proton that sends the disposition, as you assumed. The spec
   > allows for dispositions to be sent after links have detached, as the
   > deliveries can still be 'live' in some of these cases, but when it
   > occurs after the link is closed like below they actually have no
   > effect sincee the deliveries arent 'live' anymore as the link/terminus
   > is already gone. I wouldnt try to mimmick the behaviour, just delete
   > that test.
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Pre-buffered messages aren't released when consumer closes down
> ---
>
> Key: AMQNET-605
> URL: https://issues.apache.org/jira/browse/AMQNET-605
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.8.0
>Reporter: Krzysztof Porebski
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Failing unit test 
> ConsumerIntegrationTest.cs --> 
> TestCloseDurableSubscriberWithUnackedAndUnconsumedPrefetchedMessages



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Work logged] (AMQNET-618) Support noLocal filter

2019-10-01 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/AMQNET-618?focusedWorklogId=321374=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-321374
 ]

ASF GitHub Bot logged work on AMQNET-618:
-

Author: ASF GitHub Bot
Created on: 01/Oct/19 17:08
Start Date: 01/Oct/19 17:08
Worklog Time Spent: 10m 
  Work Description: Havret commented on pull request #40: AMQNET-618: 
Support noLocal filter
URL: https://github.com/apache/activemq-nms-amqp/pull/40
 
 
   This PR adds support for noLocal message filter.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

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

> Support noLocal filter
> --
>
> Key: AMQNET-618
> URL: https://issues.apache.org/jira/browse/AMQNET-618
> Project: ActiveMQ .Net
>  Issue Type: New Feature
>  Components: AMQP
>Reporter: Krzysztof Porebski
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add support for noLocal message filter. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


  1   2   3   4   5   6   7   8   9   10   >