[jira] [Commented] (ARTEMIS-857) JMX+API support for viewing and manually clearing message group caches

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-857:


Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2023
  
At the core layer it’s called group eg that’s the name within core message, 
and other settings around this. 

I’ll add test though.


> JMX+API support for viewing and manually clearing message group caches
> --
>
> Key: ARTEMIS-857
> URL: https://issues.apache.org/jira/browse/ARTEMIS-857
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: Broker
>Reporter: Matt Pavlovich
>Priority: Major
>
> Need an API to support for viewing message group infomration and optionally 
> flushing group-id maps that are not cleared by mis-behaving clients.
> ie.. client never sends the JMSXSeqID -1 message



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1812) [core] Any Subsequent messages are lost after queue is emptied from slave broker (succ failover from master kill)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1812:
-

Github user gaohoward commented on the issue:

https://github.com/apache/activemq-artemis/pull/2020
  
@stanlyDoge I think that may be fixed somewhere else probably? can you 
provide your test?


> [core] Any Subsequent messages are lost after queue is emptied from slave 
> broker (succ failover from master kill)
> -
>
> Key: ARTEMIS-1812
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1812
> Project: ActiveMQ Artemis
>  Issue Type: Bug
> Environment: single HA pair - failover to slave
> Core protocol
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Blocker
>
> # Form HA pair (with auto-create)
>  # Send 10 messages via Core protocol
>  # Kill master broker
>  # Receive 10 messages from this Core queue
>  # Observe that queue is removed, but address is present (via hawtio f.e.)
>  # Send few messages to this Core queue again -> No messages are received by 
> broker, they seem to be lost in time & space



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1744) Address or queue containing '*' or '?' cannot be deleted from hawtio console

[ASF subversion and git services (JIRA)]

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

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

Commit 49bb4424990ed11166ec0509d61e20c733937315 in activemq-artemis's branch 
refs/heads/master from [~sknot]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=49bb442 ]

ARTEMIS-1744 fix removing addresses and queues with '*' or '?' in their names 
via hawtio console


> Address or queue containing '*' or '?' cannot be deleted from hawtio console
> 
>
> Key: ARTEMIS-1744
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1744
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1744) Address or queue containing '*' or '?' cannot be deleted from hawtio console

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1744:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1951


> Address or queue containing '*' or '?' cannot be deleted from hawtio console
> 
>
> Key: ARTEMIS-1744
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1744
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1782) Missing drop-down menu with create/delete/browse buttons in hawtio console

[ASF subversion and git services (JIRA)]

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

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

Commit 6537877d7a209d2d53107585e6ca198af2f8b585 in activemq-artemis's branch 
refs/heads/master from [~sknot]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=6537877 ]

ARTEMIS-1782 fix for displaying hawtio console sub-level tabs


> Missing drop-down menu with create/delete/browse buttons in hawtio console
> --
>
> Key: ARTEMIS-1782
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1782
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> When hawtio console is opened, there is drop-down menu, that usually contains 
> 'create' 'delete' or 'browse' buttons, missing. Even though refreshing the 
> page helps, it is not obvious that it will solve the issue. It causes 
> confusion and is annoying to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1782) Missing drop-down menu with create/delete/browse buttons in hawtio console

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1782:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1988


> Missing drop-down menu with create/delete/browse buttons in hawtio console
> --
>
> Key: ARTEMIS-1782
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1782
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> When hawtio console is opened, there is drop-down menu, that usually contains 
> 'create' 'delete' or 'browse' buttons, missing. Even though refreshing the 
> page helps, it is not obvious that it will solve the issue. It causes 
> confusion and is annoying to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1782) Missing drop-down menu with create/delete/browse buttons in hawtio console

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1782:
-

Github user gaohoward commented on the issue:

https://github.com/apache/activemq-artemis/pull/1988
  
@stanlyDoge @clebertsuconic I think for the moment we can stay with the 
current version of hawtio. I'll bring your fix in.


> Missing drop-down menu with create/delete/browse buttons in hawtio console
> --
>
> Key: ARTEMIS-1782
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1782
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> When hawtio console is opened, there is drop-down menu, that usually contains 
> 'create' 'delete' or 'browse' buttons, missing. Even though refreshing the 
> page helps, it is not obvious that it will solve the issue. It causes 
> confusion and is annoying to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1792) Race condition when auto deleting an address

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1792:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/2001


> Race condition when auto deleting an address
> 
>
> Key: ARTEMIS-1792
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1792
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: STOMP
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Major
>
> It seems that there is a race condition when auto deleting an address (i.e. 
> via {{auto-delete-addresses=true}}), at least when using STOMP.
> Here is the scenario:
>  - 2 consumers on the same topic
>  - they issue an {{UNSUBSCRIBE}} frame at the same time
> Artemis returns a  AMQ119203 error: Address Does Not Exist.
> Here are logs.
> consumer 1 subscribes:
> {code}
> # 2018/04/09-11:43:24 mbtf[1699.1]: => SUBSCRIBE frame
> # 2018/04/09-11:43:24 mbtf[1699.1]:  H ack:client
> # 2018/04/09-11:43:24 mbtf[1699.1]:  H destination:/topic/test.mbtf.o7zlADh7
> # 2018/04/09-11:43:24 mbtf[1699.1]:  H id:324b068-5acb35bc-6a3-32d-1
> # 2018/04/09-11:43:24 mbtf[1699.1]:  H receipt:324b068-5acb35bc-6a3-32d-2
> {code}
> consumer 2 subscribes:
> {code}
> # 2018/04/09-11:43:24 mbtf[1699.2]: => SUBSCRIBE frame
> # 2018/04/09-11:43:24 mbtf[1699.2]:  H ack:client
> # 2018/04/09-11:43:24 mbtf[1699.2]:  H destination:/topic/test.mbtf.o7zlADh7
> # 2018/04/09-11:43:24 mbtf[1699.2]:  H id:3e00c10-5acb35bc-6a3-f3a6-1
> # 2018/04/09-11:43:24 mbtf[1699.2]:  H receipt:3e00c10-5acb35bc-6a3-f3a6-2
> {code}
> receipts are received
> producer (a third thread/connection) sends one message and disconnects
> both consumers receive the message and acknowledge it
> consumer 1 and 2 unsubscribe at the same time:
> {code}
> # 2018/04/09-11:43:29 mbtf[1699.2]: => UNSUBSCRIBE frame
> # 2018/04/09-11:43:29 mbtf[1699.1]: => UNSUBSCRIBE frame
> # 2018/04/09-11:43:29 mbtf[1699.2]:  H id:3e00c10-5acb35bc-6a3-f3a6-1
> # 2018/04/09-11:43:29 mbtf[1699.1]:  H id:324b068-5acb35bc-6a3-32d-1
> # 2018/04/09-11:43:29 mbtf[1699.2]: <= ERROR frame
> # 2018/04/09-11:43:29 mbtf[1699.2]:  H message:AMQ339017 Error unsubscribing 
> 3e00c10-5acb35bc-6a3-f3a6-1
> # 2018/04/09-11:43:29 mbtf[1699.2]:  H content-type:text/plain
> # 2018/04/09-11:43:29 mbtf[1699.2]:  H content-length:53
> # 2018/04/09-11:43:29 mbtf[1699.2]:  B  414d5131 31393230 333a2041 
> 64647265  AMQ1 1920 3: A ddre
> # 2018/04/09-11:43:29 mbtf[1699.2]:  B 0010 73732044 6f657320 4e6f7420 
> 45786973  ss D oes  Not  Exis
> # 2018/04/09-11:43:29 mbtf[1699.2]:  B 0020 743a2074 6573742e 6d627466 
> 2e6f377a  t: t est. mbtf .o7z
> # 2018/04/09-11:43:29 mbtf[1699.2]:  B 0030 6c414468 37   
>lADh 7
> # 2018/04/09-11:43:29 mbtf[1699.2]: => DISCONNECT frame
> Thread 2 terminated abnormally: unexpected ERROR frame received: AMQ339017 
> Error unsubscribing 3e00c10-5acb35bc-6a3-f3a6-1
> {code}
> I do not see this error when unsubscriptions happen sequentially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1792) Race condition when auto deleting an address

[ASF subversion and git services (JIRA)]

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

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

Commit 81d9c74d6f53a595042cbc273e630cd71d93b7e4 in activemq-artemis's branch 
refs/heads/master from [~jbertram]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=81d9c74 ]

ARTEMIS-1792 race in STOMP unsubscribe


> Race condition when auto deleting an address
> 
>
> Key: ARTEMIS-1792
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1792
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: STOMP
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Major
>
> It seems that there is a race condition when auto deleting an address (i.e. 
> via {{auto-delete-addresses=true}}), at least when using STOMP.
> Here is the scenario:
>  - 2 consumers on the same topic
>  - they issue an {{UNSUBSCRIBE}} frame at the same time
> Artemis returns a  AMQ119203 error: Address Does Not Exist.
> Here are logs.
> consumer 1 subscribes:
> {code}
> # 2018/04/09-11:43:24 mbtf[1699.1]: => SUBSCRIBE frame
> # 2018/04/09-11:43:24 mbtf[1699.1]:  H ack:client
> # 2018/04/09-11:43:24 mbtf[1699.1]:  H destination:/topic/test.mbtf.o7zlADh7
> # 2018/04/09-11:43:24 mbtf[1699.1]:  H id:324b068-5acb35bc-6a3-32d-1
> # 2018/04/09-11:43:24 mbtf[1699.1]:  H receipt:324b068-5acb35bc-6a3-32d-2
> {code}
> consumer 2 subscribes:
> {code}
> # 2018/04/09-11:43:24 mbtf[1699.2]: => SUBSCRIBE frame
> # 2018/04/09-11:43:24 mbtf[1699.2]:  H ack:client
> # 2018/04/09-11:43:24 mbtf[1699.2]:  H destination:/topic/test.mbtf.o7zlADh7
> # 2018/04/09-11:43:24 mbtf[1699.2]:  H id:3e00c10-5acb35bc-6a3-f3a6-1
> # 2018/04/09-11:43:24 mbtf[1699.2]:  H receipt:3e00c10-5acb35bc-6a3-f3a6-2
> {code}
> receipts are received
> producer (a third thread/connection) sends one message and disconnects
> both consumers receive the message and acknowledge it
> consumer 1 and 2 unsubscribe at the same time:
> {code}
> # 2018/04/09-11:43:29 mbtf[1699.2]: => UNSUBSCRIBE frame
> # 2018/04/09-11:43:29 mbtf[1699.1]: => UNSUBSCRIBE frame
> # 2018/04/09-11:43:29 mbtf[1699.2]:  H id:3e00c10-5acb35bc-6a3-f3a6-1
> # 2018/04/09-11:43:29 mbtf[1699.1]:  H id:324b068-5acb35bc-6a3-32d-1
> # 2018/04/09-11:43:29 mbtf[1699.2]: <= ERROR frame
> # 2018/04/09-11:43:29 mbtf[1699.2]:  H message:AMQ339017 Error unsubscribing 
> 3e00c10-5acb35bc-6a3-f3a6-1
> # 2018/04/09-11:43:29 mbtf[1699.2]:  H content-type:text/plain
> # 2018/04/09-11:43:29 mbtf[1699.2]:  H content-length:53
> # 2018/04/09-11:43:29 mbtf[1699.2]:  B  414d5131 31393230 333a2041 
> 64647265  AMQ1 1920 3: A ddre
> # 2018/04/09-11:43:29 mbtf[1699.2]:  B 0010 73732044 6f657320 4e6f7420 
> 45786973  ss D oes  Not  Exis
> # 2018/04/09-11:43:29 mbtf[1699.2]:  B 0020 743a2074 6573742e 6d627466 
> 2e6f377a  t: t est. mbtf .o7z
> # 2018/04/09-11:43:29 mbtf[1699.2]:  B 0030 6c414468 37   
>lADh 7
> # 2018/04/09-11:43:29 mbtf[1699.2]: => DISCONNECT frame
> Thread 2 terminated abnormally: unexpected ERROR frame received: AMQ339017 
> Error unsubscribing 3e00c10-5acb35bc-6a3-f3a6-1
> {code}
> I do not see this error when unsubscriptions happen sequentially.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1793) Do not expose the _AMQ_ROUTING_TYPE header (at least) in STOMP

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1793:
-

Github user gaohoward commented on the issue:

https://github.com/apache/activemq-artemis/pull/2004
  
+1. The failed tests seems not relevant. Maybe a forced re-run would solve 
this problem?


> Do not expose the _AMQ_ROUTING_TYPE header (at least) in STOMP
> --
>
> Key: ARTEMIS-1793
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1793
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: STOMP
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Minor
>
> Artemis currently exposes the {{_AMQ_ROUTING_TYPE}} at least when using STOMP.
> Here is what a STOMP {{MESSAGE}} frame currently looks like (header part 
> only):
> {code}
> _AMQ_ROUTING_TYPE:1
> content-length:1
> content-type:text/unknown
> destination:whatever
> expires:0
> message-id:123
> persistent:false
> priority:4
> redelivered:false
> timestamp:1523267009887
> {code}
> All the header lines are useful (and with typical lowercase names) except 
> {{_AMQ_ROUTING_TYPE}}.
> If this information can be useful to messaging clients then a more "user 
> friendly" name should be used and documented.
> Otherwise, this header should probably not be exposed, at least not by 
> default.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1805) Some broker operations in hawtio causes error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1805:
-

Github user gaohoward commented on the issue:

https://github.com/apache/activemq-artemis/pull/2013
  
@stanlyDoge I didn't see that the two methods (sendQueueInfo.. and 
updateDuplicate...) in ActiveMQServerControl are used anywhere. Could simple 
deleting them from the interface solve the hawtio error?


> Some broker operations in hawtio causes error
> -
>
> Key: ARTEMIS-1805
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1805
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> updateQueue, sendQueueInfoToQueue and updateDuplicateIdCache operations cause 
> an error if selected in hawtio console. Adding @Operation annotation fixes 
> error, but methods are exposed and I am not 100% sure it is correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1809) Add example showing Virtual Topic Mapping

[Howard Gao (JIRA)]

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

Howard Gao commented on ARTEMIS-1809:
-

[~pgfox]Can you assign this issue to yourself and update the status?
Thanks


> Add example showing Virtual Topic Mapping 
> --
>
> Key: ARTEMIS-1809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1809
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: OpenWire
>Affects Versions: 2.5.0
>Reporter: Pat Fox
>Priority: Minor
>
> Add a simple example to demonstrate the use of 
> "virtualTopicConsumerWildcards" to map ActiveMQ 5.x virtual topic consumers 
> to use the Artemis Address model.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1809) Add example showing Virtual Topic Mapping

[ASF subversion and git services (JIRA)]

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

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

Commit 2f0149c7598ed8c3adc2c0e5b0315fa07756dd4b in activemq-artemis's branch 
refs/heads/master from [~pgfox]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=2f0149c ]

 ARTEMIS-1809 adding example of mapping ActiveMQ 5.x Virtual Topic consumers


> Add example showing Virtual Topic Mapping 
> --
>
> Key: ARTEMIS-1809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1809
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: OpenWire
>Affects Versions: 2.5.0
>Reporter: Pat Fox
>Priority: Minor
>
> Add a simple example to demonstrate the use of 
> "virtualTopicConsumerWildcards" to map ActiveMQ 5.x virtual topic consumers 
> to use the Artemis Address model.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1809) Add example showing Virtual Topic Mapping

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1809:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/2017


> Add example showing Virtual Topic Mapping 
> --
>
> Key: ARTEMIS-1809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1809
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: OpenWire
>Affects Versions: 2.5.0
>Reporter: Pat Fox
>Priority: Minor
>
> Add a simple example to demonstrate the use of 
> "virtualTopicConsumerWildcards" to map ActiveMQ 5.x virtual topic consumers 
> to use the Artemis Address model.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-857) JMX+API support for viewing and manually clearing message group caches

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-857:


Github user gaohoward commented on the issue:

https://github.com/apache/activemq-artemis/pull/2023
  
@michaelandrepearce The code is fine I think. It'll be nice you add some 
unittests (e.g. in QueueControlTest) to verify it works. Also I find that the 
"Group" in method names a bit confusing.
Would be using MessageGoup instead more clear? I'm not sure about that as 
I'm not a native speaker, just a personal opinion.


> JMX+API support for viewing and manually clearing message group caches
> --
>
> Key: ARTEMIS-857
> URL: https://issues.apache.org/jira/browse/ARTEMIS-857
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: Broker
>Reporter: Matt Pavlovich
>Priority: Major
>
> Need an API to support for viewing message group infomration and optionally 
> flushing group-id maps that are not cleared by mis-behaving clients.
> ie.. client never sends the JMSXSeqID -1 message



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1814) Try Original Connector when Live and Backup are both restarted

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1814:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/2024
  
There are test failures.. I will fix them and reopen this.


> Try Original Connector when Live and Backup are both restarted
> --
>
> Key: ARTEMIS-1814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1814
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1814) Try Original Connector when Live and Backup are both restarted

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1814:
-

Github user clebertsuconic closed the pull request at:

https://github.com/apache/activemq-artemis/pull/2024


> Try Original Connector when Live and Backup are both restarted
> --
>
> Key: ARTEMIS-1814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1814
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1814) Try Original Connector when Live and Backup are both restarted

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1814:
-

GitHub user clebertsuconic opened a pull request:

https://github.com/apache/activemq-artemis/pull/2024

ARTEMIS-1814 Try original connection when every other node failed

@michaelandrepearce @mtaylor this one will interest you I think

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/clebertsuconic/activemq-artemis ARTEMIS-1814

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/2024.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2024


commit 415fb3ead284464824b0bbe51a6fc1cebdb27950
Author: Clebert Suconic 
Date:   2018-04-16T21:44:21Z

ARTEMIS-1814 Try original connection when every other node failed




> Try Original Connector when Live and Backup are both restarted
> --
>
> Key: ARTEMIS-1814
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1814
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1814) Try Original Connector when Live and Backup are both restarted

[clebert suconic (JIRA)]

clebert suconic created ARTEMIS-1814:


 Summary: Try Original Connector when Live and Backup are both 
restarted
 Key: ARTEMIS-1814
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1814
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 2.5.0
Reporter: clebert suconic
Assignee: clebert suconic
 Fix For: 2.5.1






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (ARTEMIS-854) Create basic exclusive consumer support within the broker

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-854.
---
Resolution: Fixed

> Create basic exclusive consumer support within the broker
> -
>
> Key: ARTEMIS-854
> URL: https://issues.apache.org/jira/browse/ARTEMIS-854
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Matt Pavlovich
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1807) File-based Large Message encoding should use read-only mmap

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1807:
-

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2015
  
@michaelandrepearce
> we are using it for latency reasons
Nice!! Happy to hear that :):)  no datasync, no party! :)


> File-based Large Message encoding should use read-only mmap
> ---
>
> Key: ARTEMIS-1807
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1807
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> File-based LargeServerMessageImpl should use read-only memory mapping while 
> reading the file, in order to:
>  * reduce the number of copies 
>  * reduce the context switches



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1807) File-based Large Message encoding should use read-only mmap

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1807:
-

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2015
  
@michaelandrepearce Good points: paging (the consuming side) , this PR and 
a mapped journal should contend the OS page cache , so it depends on the 
dirty/dirty background ratio and total system memory.
Probably should makes sense to allow this feature to be configurable (and 
paging as well) in order to avoid contention between them or just tune the OS 
according (tricky IMO). Wdyt?



> File-based Large Message encoding should use read-only mmap
> ---
>
> Key: ARTEMIS-1807
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1807
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> File-based LargeServerMessageImpl should use read-only memory mapping while 
> reading the file, in order to:
>  * reduce the number of copies 
>  * reduce the context switches



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-839) Support multiple backend data stores

[Michael Andre Pearce (JIRA)]

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

Michael Andre Pearce commented on ARTEMIS-839:
--

[~clebertsuconic] did you get any progress on this. Indeed for ourselves, this 
is on our wishlist e.g. there is genuine use case for this, though not that 
high priority for us as we just purchase faster and bigger disks. But i noted 
this is on the roadmap docs for ActiveMQ 6 promotion for Artemis. 

 

> Support multiple backend data stores
> 
>
> Key: ARTEMIS-839
> URL: https://issues.apache.org/jira/browse/ARTEMIS-839
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Matt Pavlovich
>Priority: Major
>
> ActiveMQ 5.x supports multi-kahahdb where destinations matching the 
> destination wildcard naming convention are stored in separate data stores in 
> order to overcome disk I/O performance issues
> Artemis should support this to achieve parity with ActiveMQ and other 
> commercial brokers, such as Tibco EMS that support multiple back-end data 
> stores.
> The primary use case:
> 1. Increase overall disk I/O by having multiple mount points to allow busy 
> destinations to have separate disks
> Enhancement: It would be great if the full path could optionally be 
> specified. Currently, in ActiveMQ 5.x the path is automatically generated 
> based on the destination name filter and complicates the ability to separate 
> destinations due to funky character names on all OS's and filesystems.
> For example, support multiple journal entries:
>
> Examples:
> 
>   *  < ... address-setting match="anycast://Ordering.#" 
> path="file:/volumes/ordering">
>   * < .. address-setting match="anycast://Billing.#" 
> path="file:/volumes/billing">
>   * < .. address-setting match="anycast://#" path="file:/volumes/default">
>
> 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1807) File-based Large Message encoding should use read-only mmap

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1807:
-

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2015
  
@franz1981 can you provide a perf test before and after for normal usage of 
the mapped journal e.g. as the main journal. 

I ask as we have ended up using it for a specific use case internally, 
where we are using it for latency reasons, so i want to be sure theres no 
degrade for the current usage.


> File-based Large Message encoding should use read-only mmap
> ---
>
> Key: ARTEMIS-1807
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1807
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> File-based LargeServerMessageImpl should use read-only memory mapping while 
> reading the file, in order to:
>  * reduce the number of copies 
>  * reduce the context switches



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-857) JMX+API support for viewing and manually clearing message group caches

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-857:


Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2023
  
Just working through the low hanging fruit thats needed to unblock artemis 
to become activemq 6.
as per:
http://activemq.apache.org/activemq-artemis-roadmap.html


> JMX+API support for viewing and manually clearing message group caches
> --
>
> Key: ARTEMIS-857
> URL: https://issues.apache.org/jira/browse/ARTEMIS-857
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: Broker
>Reporter: Matt Pavlovich
>Priority: Major
>
> Need an API to support for viewing message group infomration and optionally 
> flushing group-id maps that are not cleared by mis-behaving clients.
> ie.. client never sends the JMSXSeqID -1 message



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-857) JMX+API support for viewing and manually clearing message group caches

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-857:


GitHub user michaelandrepearce opened a pull request:

https://github.com/apache/activemq-artemis/pull/2023

ARTEMIS-857 Add JMX endpoints to view and reset groups

Expose method to return current mappings of groups to consumers
Expose methods to reset (remove) specific group mapping from groupID to 
Consumer
Expose methods to reset (remove) all group mappings

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/michaelandrepearce/activemq-artemis 
ARTEMIS-857

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/2023.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2023


commit c28a27d5db942d2a148adaff2e0b90f4863233f1
Author: Michael André Pearce 
Date:   2018-04-16T16:11:44Z

ARTEMIS-857 Add JMX endpoints to view and reset groups

Expose method to return current mappings of groups to consumers
Expose methods to reset (remove) specific group mapping from groupID to 
Consumer
Expose methods to reset (remove) all group mappings




> JMX+API support for viewing and manually clearing message group caches
> --
>
> Key: ARTEMIS-857
> URL: https://issues.apache.org/jira/browse/ARTEMIS-857
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: Broker
>Reporter: Matt Pavlovich
>Priority: Major
>
> Need an API to support for viewing message group infomration and optionally 
> flushing group-id maps that are not cleared by mis-behaving clients.
> ie.. client never sends the JMSXSeqID -1 message



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1813) DB2 BLOB size should be set to match its SQL definition

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1813:
-

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2022
  
Please wait to merge it that I'm performing several tests on DB2 to see if 
is a sane value/default :+1: 


> DB2 BLOB size should be set to match its SQL definition
> ---
>
> Key: ARTEMIS-1813
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1813
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1813) DB2 BLOB size should be set to match its SQL definition

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1813:
-

GitHub user franz1981 opened a pull request:

https://github.com/apache/activemq-artemis/pull/2022

ARTEMIS-1813 DB2 BLOB size should be set to match its SQL definition

max-blob-size.db2 and create-file-table.db2 are changed to match the
2 GB max blob size limit allowed by DB2.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/franz1981/activemq-artemis ARTEMIS-1813

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/2022.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2022






> DB2 BLOB size should be set to match its SQL definition
> ---
>
> Key: ARTEMIS-1813
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1813
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (ARTEMIS-854) Create basic exclusive consumer support within the broker

[Michael Andre Pearce (JIRA)]

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

Michael Andre Pearce edited comment on ARTEMIS-854 at 4/16/18 3:15 PM:
---

Can someone with rights, mark this complete? Seems i cannot change the status 
on tasks/issues that i haven't created even though a committer. This was 
delivered in 2.5.0

 

[~clebertsuconic] ? you able to help me?


was (Author: michael.andre.pearce):
Can someone with rights, mark this complete? Seems i cannot change the status 
on tasks/issues that i haven't created even though a committer. This was 
delivered in 2.5.0

> Create basic exclusive consumer support within the broker
> -
>
> Key: ARTEMIS-854
> URL: https://issues.apache.org/jira/browse/ARTEMIS-854
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Matt Pavlovich
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-854) Create basic exclusive consumer support within the broker

[Michael Andre Pearce (JIRA)]

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

Michael Andre Pearce commented on ARTEMIS-854:
--

Can someone with rights, mark this complete? Seems i cannot change the status 
on tasks/issues that i haven't created even though a committer. This was 
delivered in 2.5.0

> Create basic exclusive consumer support within the broker
> -
>
> Key: ARTEMIS-854
> URL: https://issues.apache.org/jira/browse/ARTEMIS-854
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Matt Pavlovich
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-854) Create basic exclusive consumer support within the broker

[Michael Andre Pearce (JIRA)]

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

Michael Andre Pearce updated ARTEMIS-854:
-
Issue Type: New Feature  (was: Sub-task)
Parent: (was: ARTEMIS-853)

> Create basic exclusive consumer support within the broker
> -
>
> Key: ARTEMIS-854
> URL: https://issues.apache.org/jira/browse/ARTEMIS-854
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Matt Pavlovich
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ARTEMIS-854) Create basic exclusive consumer support within the broker

[Michael Andre Pearce (JIRA)]

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

Michael Andre Pearce reassigned ARTEMIS-854:


 Assignee: Michael Andre Pearce
Fix Version/s: 2.5.0

> Create basic exclusive consumer support within the broker
> -
>
> Key: ARTEMIS-854
> URL: https://issues.apache.org/jira/browse/ARTEMIS-854
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: Broker
>Reporter: Matt Pavlovich
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1763) Remove 'quick check' before quorum

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1763:
-

GitHub user gaohoward opened a pull request:

https://github.com/apache/activemq-artemis/pull/2021

NO-JIRA: Fix test regression

QuorumFailOverTest.testQuorumVotingLiveNotDead fails
because the quorum vote takes longer time to finish than
the test expects to.
(The test used to pass until commit ARTEMIS-1763)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gaohoward/activemq-artemis h_fix_regress

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/2021.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2021


commit 64f974ff52470553de8520ec7b374a78494d861e
Author: Howard Gao 
Date:   2018-04-16T14:02:32Z

NO-JIRA: Fix test regression

QuorumFailOverTest.testQuorumVotingLiveNotDead fails
because the quorum vote takes longer time to finish than
the test expects to.
(The test used to pass until commit ARTEMIS-1763)




> Remove 'quick check' before quorum
> --
>
> Key: ARTEMIS-1763
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1763
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Fix For: 2.5.1
>
>
> A check was added to SharedNothingBackupQuorum in isLiveDown method to 
> quickly check if the backup could still connect to the live. This should be 
> removed as it is unreliable and by passes the actual quorum vote.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1813) DB2 BLOB size should be set to match its SQL definition

[Francesco Nigro (JIRA)]

Francesco Nigro created ARTEMIS-1813:


 Summary: DB2 BLOB size should be set to match its SQL definition
 Key: ARTEMIS-1813
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1813
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 2.5.0
Reporter: Francesco Nigro






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Work started] (ARTEMIS-1812) [core] Any Subsequent messages are lost after queue is emptied from slave broker (succ failover from master kill)

[Stanislav Knot (JIRA)]

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

Work on ARTEMIS-1812 started by Stanislav Knot.
---
> [core] Any Subsequent messages are lost after queue is emptied from slave 
> broker (succ failover from master kill)
> -
>
> Key: ARTEMIS-1812
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1812
> Project: ActiveMQ Artemis
>  Issue Type: Bug
> Environment: single HA pair - failover to slave
> Core protocol
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Blocker
>
> # Form HA pair (with auto-create)
>  # Send 10 messages via Core protocol
>  # Kill master broker
>  # Receive 10 messages from this Core queue
>  # Observe that queue is removed, but address is present (via hawtio f.e.)
>  # Send few messages to this Core queue again -> No messages are received by 
> broker, they seem to be lost in time & space



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1807) File-based Large Message encoding should use read-only mmap

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1807:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/2015
  
@franz1981 I think so too.. but I would do it in the context of a 
refactoring in AMQP also. we need to properly implement large messages in AMQP.


> File-based Large Message encoding should use read-only mmap
> ---
>
> Key: ARTEMIS-1807
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1807
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> File-based LargeServerMessageImpl should use read-only memory mapping while 
> reading the file, in order to:
>  * reduce the number of copies 
>  * reduce the context switches



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1812) [core] Any Subsequent messages are lost after queue is emptied from slave broker (succ failover from master kill)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1812:
-

GitHub user stanlyDoge opened a pull request:

https://github.com/apache/activemq-artemis/pull/2020

ARTEMIS-1812 fix for missing (core) messages after master kill (HA)

When I try to send some core messages to slave broker (master is dead), 
messages are lost. Debug console says "Couldn't find any bindings for 
address=TEST.foo". By digging into code, I think this is the spot, which is 
responsible for this bug: 
https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/PostOfficeImpl.java#L832
 

I have tried to create queue with default values here. It fixes the bug, 
but i am afraid it can create much more new bugs. Git blame says 
@clebertsuconic and @jbertram could know more about this. Can you guys please 
approve/disprove this fix? If it is ok, please do not merge, I would like to 
bring some test for this and delete comments. Thank you.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/stanlyDoge/activemq-artemis ARTEMIS-1812

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/2020.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2020


commit 688397ea74897d5ad49d4694a74c14849148b8de
Author: Stanislav Knot 
Date:   2018-04-16T13:46:22Z

ARTEMIS-1812 fix for missing (core) messages after master kill (HA)




> [core] Any Subsequent messages are lost after queue is emptied from slave 
> broker (succ failover from master kill)
> -
>
> Key: ARTEMIS-1812
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1812
> Project: ActiveMQ Artemis
>  Issue Type: Bug
> Environment: single HA pair - failover to slave
> Core protocol
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Blocker
>
> # Form HA pair (with auto-create)
>  # Send 10 messages via Core protocol
>  # Kill master broker
>  # Receive 10 messages from this Core queue
>  # Observe that queue is removed, but address is present (via hawtio f.e.)
>  # Send few messages to this Core queue again -> No messages are received by 
> broker, they seem to be lost in time & space



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1812) [core] Any Subsequent messages are lost after queue is emptied from slave broker (succ failover from master kill)

[Stanislav Knot (JIRA)]

Stanislav Knot created ARTEMIS-1812:
---

 Summary: [core] Any Subsequent messages are lost after queue is 
emptied from slave broker (succ failover from master kill)
 Key: ARTEMIS-1812
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1812
 Project: ActiveMQ Artemis
  Issue Type: Bug
 Environment: single HA pair - failover to slave
Core protocol
Reporter: Stanislav Knot
Assignee: Stanislav Knot


# Form HA pair (with auto-create)
 # Send 10 messages via Core protocol
 # Kill master broker
 # Receive 10 messages from this Core queue
 # Observe that queue is removed, but address is present (via hawtio f.e.)
 # Send few messages to this Core queue again -> No messages are received by 
broker, they seem to be lost in time & space



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1810) JDBCSequentialFileFactoryDriver should check <=0 read length

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1810:
-

GitHub user franz1981 opened a pull request:

https://github.com/apache/activemq-artemis/pull/2019

ARTEMIS-1810 JDBCSequentialFileFactoryDriver should check <=0 read length

In order to avoid out of bounds reads to happen, the reading of the file
should avoid those readings to hit the DMBS and just return the expected
value.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/franz1981/activemq-artemis ARTEMIS-1810

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/2019.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2019


commit 63c4b5007058e86ad20ed8d23ec100b3ec71ed01
Author: Francesco Nigro 
Date:   2018-04-16T11:20:22Z

ARTEMIS-1810 JDBCSequentialFileFactoryDriver should check <=0 read length

In order to avoid out of bounds reads to happen, the reading of the file
should avoid those readings to hit the DMBS and just return the expected
value.




> JDBCSequentialFileFactoryDriver should check <=0 read length
> 
>
> Key: ARTEMIS-1810
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1810
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
> Fix For: 2.5.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1807) File-based Large Message encoding should use read-only mmap

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1807:
-

Github user gaohoward commented on the issue:

https://github.com/apache/activemq-artemis/pull/2015
  
I think using mapped file will get better performance over the NIO channel 
read. 
It would be better to have a unit test with it. @clebertsuconic wdyt?


> File-based Large Message encoding should use read-only mmap
> ---
>
> Key: ARTEMIS-1807
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1807
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> File-based LargeServerMessageImpl should use read-only memory mapping while 
> reading the file, in order to:
>  * reduce the number of copies 
>  * reduce the context switches



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1811) JournalStorageManager::addBytesToLargeMessage should not use heap buffers

[Francesco Nigro (JIRA)]

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

Francesco Nigro updated ARTEMIS-1811:
-
Description: 
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
jdk.nio.maxCachedBufferSize, as shown on 
[https://bugs.openjdk.java.net/browse/JDK-8147468]) and when not pooled are 
cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well, dependently on the written message chunk size.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies

  was:
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
jdk.nio.maxCachedBufferSize, as shown on 
[https://bugs.openjdk.java.net/browse/JDK-8147468]) and when not pooled are 
cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well, dependently on the written message chunk size.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #


> JournalStorageManager::addBytesToLargeMessage should not use heap buffers
> -
>
> Key: ARTEMIS-1811
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1811
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
> direct ByteBuffers performed internally by NIO.
> Those buffers are pooled until certain size limit (ie 
> jdk.nio.maxCachedBufferSize, as shown on 
> [https://bugs.openjdk.java.net/browse/JDK-8147468]) and when not pooled are 
> cleaned at the end of its usage.
> That's stress the native memory allocator and would lead to poor performances 
> and potential OOMs as well, dependently on the written message chunk size.
> The proposed solutions are:
>  # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
> read lock
>  # replace the NIO SequentialFile usage and just use RandomAccessFile that 
> provide the right API to append byte[] without creating additional native 
> copies



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1811) JournalStorageManager::addBytesToLargeMessage should not use heap buffers

[Francesco Nigro (JIRA)]

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

Francesco Nigro updated ARTEMIS-1811:
-
Description: 
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
jdk.nio.maxCachedBufferSize, as shown on 
[https://bugs.openjdk.java.net/browse/JDK-8147468]) and when not pooled are 
cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well, dependently on the written message chunk size.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #

  was:
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
jdk.nio.maxCachedBufferSize, as shown on 
[https://bugs.openjdk.java.net/browse/JDK-8147468]) and when not pooled are 
cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #


> JournalStorageManager::addBytesToLargeMessage should not use heap buffers
> -
>
> Key: ARTEMIS-1811
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1811
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
> direct ByteBuffers performed internally by NIO.
> Those buffers are pooled until certain size limit (ie 
> jdk.nio.maxCachedBufferSize, as shown on 
> [https://bugs.openjdk.java.net/browse/JDK-8147468]) and when not pooled are 
> cleaned at the end of its usage.
> That's stress the native memory allocator and would lead to poor performances 
> and potential OOMs as well, dependently on the written message chunk size.
> The proposed solutions are:
>  # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
> read lock
>  # replace the NIO SequentialFile usage and just use RandomAccessFile that 
> provide the right API to append byte[] without creating additional native 
> copies
>  #



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1811) JournalStorageManager::addBytesToLargeMessage should not use heap buffers

[Francesco Nigro (JIRA)]

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

Francesco Nigro updated ARTEMIS-1811:
-
Description: 
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
jdk.nio.maxCachedBufferSize, as shown on 
[https://bugs.openjdk.java.net/browse/JDK-8147468]) and when not pooled are 
cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #

  was:
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
jdk.nio.maxCachedBufferSize, as shown 
https://bugs.openjdk.java.net/browse/JDK-8147468) and when not pooled are 
cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #


> JournalStorageManager::addBytesToLargeMessage should not use heap buffers
> -
>
> Key: ARTEMIS-1811
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1811
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
> direct ByteBuffers performed internally by NIO.
> Those buffers are pooled until certain size limit (ie 
> jdk.nio.maxCachedBufferSize, as shown on 
> [https://bugs.openjdk.java.net/browse/JDK-8147468]) and when not pooled are 
> cleaned at the end of its usage.
> That's stress the native memory allocator and would lead to poor performances 
> and potential OOMs as well.
> The proposed solutions are:
>  # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
> read lock
>  # replace the NIO SequentialFile usage and just use RandomAccessFile that 
> provide the right API to append byte[] without creating additional native 
> copies
>  #



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1811) JournalStorageManager::addBytesToLargeMessage should not use heap buffers

[Francesco Nigro (JIRA)]

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

Francesco Nigro updated ARTEMIS-1811:
-
Description: 
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
[https://bugs.openjdk.java.net/browse/JDK-8147468 
|jdk.nio.maxCachedBufferSize]) and when not pooled are cleaned at the end of 
its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #

  was:
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
[jdk.nio.maxCachedBufferSize|[https://bugs.openjdk.java.net/browse/JDK-8147468]]
 and when not pooled are cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #


> JournalStorageManager::addBytesToLargeMessage should not use heap buffers
> -
>
> Key: ARTEMIS-1811
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1811
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
> direct ByteBuffers performed internally by NIO.
> Those buffers are pooled until certain size limit (ie 
> [https://bugs.openjdk.java.net/browse/JDK-8147468 
> |jdk.nio.maxCachedBufferSize]) and when not pooled are cleaned at the end of 
> its usage.
> That's stress the native memory allocator and would lead to poor performances 
> and potential OOMs as well.
> The proposed solutions are:
>  # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
> read lock
>  # replace the NIO SequentialFile usage and just use RandomAccessFile that 
> provide the right API to append byte[] without creating additional native 
> copies
>  #



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1811) JournalStorageManager::addBytesToLargeMessage should not use heap buffers

[Francesco Nigro (JIRA)]

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

Francesco Nigro updated ARTEMIS-1811:
-
Description: 
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
[https://bugs.openjdk.java.net/browse/JDK-8147468|jdk.nio.maxCachedBufferSize]) 
and when not pooled are cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #

  was:
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
[https://bugs.openjdk.java.net/browse/JDK-8147468 
|jdk.nio.maxCachedBufferSize]) and when not pooled are cleaned at the end of 
its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #


> JournalStorageManager::addBytesToLargeMessage should not use heap buffers
> -
>
> Key: ARTEMIS-1811
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1811
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
> direct ByteBuffers performed internally by NIO.
> Those buffers are pooled until certain size limit (ie 
> [https://bugs.openjdk.java.net/browse/JDK-8147468|jdk.nio.maxCachedBufferSize])
>  and when not pooled are cleaned at the end of its usage.
> That's stress the native memory allocator and would lead to poor performances 
> and potential OOMs as well.
> The proposed solutions are:
>  # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
> read lock
>  # replace the NIO SequentialFile usage and just use RandomAccessFile that 
> provide the right API to append byte[] without creating additional native 
> copies
>  #



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1811) JournalStorageManager::addBytesToLargeMessage should not use heap buffers

[Francesco Nigro (JIRA)]

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

Francesco Nigro updated ARTEMIS-1811:
-
Description: 
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
jdk.nio.maxCachedBufferSize, as shown 
https://bugs.openjdk.java.net/browse/JDK-8147468) and when not pooled are 
cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #

  was:
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
[https://bugs.openjdk.java.net/browse/JDK-8147468|jdk.nio.maxCachedBufferSize]) 
and when not pooled are cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #


> JournalStorageManager::addBytesToLargeMessage should not use heap buffers
> -
>
> Key: ARTEMIS-1811
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1811
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
> direct ByteBuffers performed internally by NIO.
> Those buffers are pooled until certain size limit (ie 
> jdk.nio.maxCachedBufferSize, as shown 
> https://bugs.openjdk.java.net/browse/JDK-8147468) and when not pooled are 
> cleaned at the end of its usage.
> That's stress the native memory allocator and would lead to poor performances 
> and potential OOMs as well.
> The proposed solutions are:
>  # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
> read lock
>  # replace the NIO SequentialFile usage and just use RandomAccessFile that 
> provide the right API to append byte[] without creating additional native 
> copies
>  #



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1811) JournalStorageManager::addBytesToLargeMessage should not use heap buffers

[Francesco Nigro (JIRA)]

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

Francesco Nigro updated ARTEMIS-1811:
-
Description: 
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
[jdk.nio.maxCachedBufferSize|[https://bugs.openjdk.java.net/browse/JDK-8147468])]
 and when not pooled are cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #

  was:
JournalStorageManager::addBytesToLargeMessage is relying on the pooled direct 
ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
[jdk.nio.maxCachedBufferSize|[https://bugs.openjdk.java.net/browse/JDK-8147468])]
 and when not pooled are cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #


> JournalStorageManager::addBytesToLargeMessage should not use heap buffers
> -
>
> Key: ARTEMIS-1811
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1811
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
> direct ByteBuffers performed internally by NIO.
> Those buffers are pooled until certain size limit (ie 
> [jdk.nio.maxCachedBufferSize|[https://bugs.openjdk.java.net/browse/JDK-8147468])]
>  and when not pooled are cleaned at the end of its usage.
> That's stress the native memory allocator and would lead to poor performances 
> and potential OOMs as well.
> The proposed solutions are:
>  # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
> read lock
>  # replace the NIO SequentialFile usage and just use RandomAccessFile that 
> provide the right API to append byte[] without creating additional native 
> copies
>  #



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1811) JournalStorageManager::addBytesToLargeMessage should not use heap buffers

[Francesco Nigro (JIRA)]

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

Francesco Nigro updated ARTEMIS-1811:
-
Description: 
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
[jdk.nio.maxCachedBufferSize|[https://bugs.openjdk.java.net/browse/JDK-8147468]]
 and when not pooled are cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #

  was:
JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
direct ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
[jdk.nio.maxCachedBufferSize|[https://bugs.openjdk.java.net/browse/JDK-8147468])]
 and when not pooled are cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #


> JournalStorageManager::addBytesToLargeMessage should not use heap buffers
> -
>
> Key: ARTEMIS-1811
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1811
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> JournalStorageManager::addBytesToLargeMessage is relying on the pooling of 
> direct ByteBuffers performed internally by NIO.
> Those buffers are pooled until certain size limit (ie 
> [jdk.nio.maxCachedBufferSize|[https://bugs.openjdk.java.net/browse/JDK-8147468]]
>  and when not pooled are cleaned at the end of its usage.
> That's stress the native memory allocator and would lead to poor performances 
> and potential OOMs as well.
> The proposed solutions are:
>  # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
> read lock
>  # replace the NIO SequentialFile usage and just use RandomAccessFile that 
> provide the right API to append byte[] without creating additional native 
> copies
>  #



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1811) JournalStorageManager::addBytesToLargeMessage should not use heap buffers

[Francesco Nigro (JIRA)]

Francesco Nigro created ARTEMIS-1811:


 Summary: JournalStorageManager::addBytesToLargeMessage should not 
use heap buffers
 Key: ARTEMIS-1811
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1811
 Project: ActiveMQ Artemis
  Issue Type: Improvement
  Components: Broker
Affects Versions: 2.5.0
Reporter: Francesco Nigro
Assignee: Francesco Nigro


JournalStorageManager::addBytesToLargeMessage is relying on the pooled direct 
ByteBuffers performed internally by NIO.

Those buffers are pooled until certain size limit (ie 
[jdk.nio.maxCachedBufferSize|[https://bugs.openjdk.java.net/browse/JDK-8147468])]
 and when not pooled are cleaned at the end of its usage.

That's stress the native memory allocator and would lead to poor performances 
and potential OOMs as well.

The proposed solutions are:
 # perform ad hoc direct ByteBuffer caching on the write path thanks to the 
read lock
 # replace the NIO SequentialFile usage and just use RandomAccessFile that 
provide the right API to append byte[] without creating additional native copies
 #



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1810) JDBCSequentialFileFactoryDriver should check <=0 read length

[Francesco Nigro (JIRA)]

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

Francesco Nigro updated ARTEMIS-1810:
-
Summary: JDBCSequentialFileFactoryDriver should check <=0 read length  
(was: JDBCSequentialFileFactoryDriver should check <= read length)

> JDBCSequentialFileFactoryDriver should check <=0 read length
> 
>
> Key: ARTEMIS-1810
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1810
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
> Fix For: 2.5.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1810) JDBCSequentialFileFactoryDriver should check <= read length

[Francesco Nigro (JIRA)]

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

Francesco Nigro updated ARTEMIS-1810:
-
Summary: JDBCSequentialFileFactoryDriver should check <= read length  (was: 
JDBCSequentialFileFactoryDriver should check zero and negative read length)

> JDBCSequentialFileFactoryDriver should check <= read length
> ---
>
> Key: ARTEMIS-1810
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1810
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
> Fix For: 2.5.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1776) Implement asynchronous flow control on bridge and clustered bridge

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1776:
-

GitHub user JiriOndrusek opened a pull request:

https://github.com/apache/activemq-artemis/pull/2018

[ARTEMIS-1776] - Implement asynchronous flow control on bridge and 
clustered bridge

Issue: https://issues.apache.org/jira/browse/ARTEMIS-1776

Currently the flow control on the Bridge is based on back pressure only, 
through Netty writeable interfaces.
 
If the user selected a positive producerWindowSize the Queue may block 
while the Processing is happening. What could lead to distributed deadlocks on 
the Bridge.
 
These changes avoids that possibility.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/JiriOndrusek/activemq-artemis 
Asynchronous_flow_control_on_the_bridge

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/2018.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2018


commit 1e6e1f77d0323e87c5129fa187b7841f0a4d34e2
Author: Howard Gao 
Date:   2018-01-19T08:36:47Z

ARTEMIS-1621 Make producerWindowSize configurable on clusterconnection 
bridges

The cluster connection bridge hard codes its producerWindowSize to -1
(meaning no producer flow control) even if you configure it otherwise.

Cherry-picked from 98ce31bf588a314a0408216e4ad4b85597a15186

commit 2c73bd0462b3818d49ce7c4557e1b48587707cb1
Author: Clebert Suconic 
Date:   2018-03-28T16:40:06Z

ARTEMIS-1776 Asynchronous Flow control on the bridge

Cherry-picked from 70bdfe760393a9d7d17ec175ea68ce83819fe83c

commit 3c546092788c1d6cf7f16d5a2b0938de00f2410a
Author: Clebert Suconic 
Date:   2018-04-06T14:00:43Z

ARTEMIS-1776 Blocked Bridge is not resuming after reconnect

This is still part of ARTEMIS-1776 fix, which still part of the same 
release as we are on now.
Hence I'm not opening a new JIRA for this one.

Cherry-picked from e5bce13316f7e81bb15a12592622df2ea2632a35




> Implement asynchronous flow control on bridge and clustered bridge
> --
>
> Key: ARTEMIS-1776
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1776
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.5.0
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.1
>
>
> Currently the flow control on the Bridge is based on back pressure only, 
> through Netty writeable interfaces.
>  
> If the user selected a positive producerWindowSize the Queue may block while 
> the Processing is happening. What could lead to distributed deadlocks on the 
> Bridge.
>  
> This will avoid that possibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1810) JDBCSequentialFileFactoryDriver should check zero and negative read length

[Francesco Nigro (JIRA)]

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

Francesco Nigro updated ARTEMIS-1810:
-
Summary: JDBCSequentialFileFactoryDriver should check zero and negative 
read length  (was: JDBCSequentialFileFactoryDriver should check negative read 
length)

> JDBCSequentialFileFactoryDriver should check zero and negative read length
> --
>
> Key: ARTEMIS-1810
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1810
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
> Fix For: 2.5.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1810) JDBCSequentialFileFactoryDriver should check negative read length

[Francesco Nigro (JIRA)]

Francesco Nigro created ARTEMIS-1810:


 Summary: JDBCSequentialFileFactoryDriver should check negative 
read length
 Key: ARTEMIS-1810
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1810
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 2.5.0
Reporter: Francesco Nigro
Assignee: Francesco Nigro
 Fix For: 2.5.1






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1807) File-based Large Message encoding should use read-only mmap

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1807:
-

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2015
  
`JournalStorageManager::addBytesToLargeMessage` is another point that need 
to be improved to avoid OOM and better performances too


> File-based Large Message encoding should use read-only mmap
> ---
>
> Key: ARTEMIS-1807
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1807
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>
> File-based LargeServerMessageImpl should use read-only memory mapping while 
> reading the file, in order to:
>  * reduce the number of copies 
>  * reduce the context switches



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1809) Add example showing Virtual Topic Mapping

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1809:
-

GitHub user pgfox opened a pull request:

https://github.com/apache/activemq-artemis/pull/2017

 ARTEMIS-1809 adding example of mapping ActiveMQ 5.x Virtual Topic consumers

see contained examples/protocols/openwire/virtual-topic-mapping/readme.md 
for details.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pgfox/activemq-artemis 
virtualTopic-mapping-example

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/2017.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2017


commit 39a8e8265c2956f63fc45e97aff5a03e2576bada
Author: Pat Fox 
Date:   2018-04-15T19:22:26Z

 ARTEMIS-1809 adding example of mapping ActiveMQ 5.x Virtual Topic consumers




> Add example showing Virtual Topic Mapping 
> --
>
> Key: ARTEMIS-1809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1809
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: OpenWire
>Affects Versions: 2.5.0
>Reporter: Pat Fox
>Priority: Minor
>
> Add a simple example to demonstrate the use of 
> "virtualTopicConsumerWildcards" to map ActiveMQ 5.x virtual topic consumers 
> to use the Artemis Address model.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1809) Add example showing Virtual Topic Mapping

[Pat Fox (JIRA)]

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

Pat Fox commented on ARTEMIS-1809:
--

PR to follow

> Add example showing Virtual Topic Mapping 
> --
>
> Key: ARTEMIS-1809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1809
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: OpenWire
>Affects Versions: 2.5.0
>Reporter: Pat Fox
>Priority: Minor
>
> Add a simple example to demonstrate the use of 
> "virtualTopicConsumerWildcards" to map ActiveMQ 5.x virtual topic consumers 
> to use the Artemis Address model.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1809) Add example showing Virtual Topic Mapping

[Pat Fox (JIRA)]

Pat Fox created ARTEMIS-1809:


 Summary: Add example showing Virtual Topic Mapping 
 Key: ARTEMIS-1809
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1809
 Project: ActiveMQ Artemis
  Issue Type: Improvement
  Components: OpenWire
Affects Versions: 2.5.0
Reporter: Pat Fox


Add a simple example to demonstrate the use of "virtualTopicConsumerWildcards" 
to map ActiveMQ 5.x virtual topic consumers to use the Artemis Address model.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)