date:20210222



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

Michael Andre Pearce commented on ARTEMIS-2802:
---

[~jbertram] I modified [^FederatedQueueTest.java]and 
[^FederatedTestBase.java]to start up an actual port, instead of invm only, and 
then adjusted the test cases to use the activemq 5.x jms client, and ran the 
tests, and they pass. So currently im unsure of the issue, it be great if 
FederatedQueueTest.java can be extended with a failure test case that will run 
within unit, then we can look at more.

> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>  
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>  
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>  
> and adding dependency:
> {code:java}
> 
>   org.apache.activemq
>   activemq-client
>   ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter: 
> hyphenated_props:federation-name IS NOT NULL}}
>  



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

[jira] [Comment Edited] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol



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

Michael Andre Pearce edited comment on ARTEMIS-2802 at 2/23/21, 2:25 AM:
-

[~jbertram] I modified [^FederatedQueueTest.java]and 
[^FederatedTestBase.java]to start up an actual port, instead of invm only, and 
then adjusted the test cases to use the activemq 5.x jms client, and ran the 
tests, and they pass. So currently im unsure of the issue, it be great if 
FederatedQueueTest.java can be extended with a failure test case that will run 
within junit to demonstrate the issue, then we can look at more.


was (Author: michael.andre.pearce):
[~jbertram] I modified [^FederatedQueueTest.java]and 
[^FederatedTestBase.java]to start up an actual port, instead of invm only, and 
then adjusted the test cases to use the activemq 5.x jms client, and ran the 
tests, and they pass. So currently im unsure of the issue, it be great if 
FederatedQueueTest.java can be extended with a failure test case that will run 
within unit, then we can look at more.

> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>  
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>  
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>  
> and adding dependency:
> {code:java}
> 
>   org.apache.activemq
>   activemq-client
>   ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter: 
> hyphenated_props:federation-name IS NOT NULL}}
>  



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

[jira] [Comment Edited] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol



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

Michael Andre Pearce edited comment on ARTEMIS-2802 at 2/23/21, 2:26 AM:
-

[~jbertram] I modified [^FederatedQueueTest.java]and [^FederatedTestBase.java] 
attached to start up an actual port, instead of invm only, and then adjusted 
the test cases to use the activemq 5.x jms client, and ran the tests, and they 
pass. So currently im unsure of the issue, it be great if 
FederatedQueueTest.java can be extended with a failure test case that will run 
within junit to demonstrate the issue, then we can look at more.


was (Author: michael.andre.pearce):
[~jbertram] I modified [^FederatedQueueTest.java]and 
[^FederatedTestBase.java]to start up an actual port, instead of invm only, and 
then adjusted the test cases to use the activemq 5.x jms client, and ran the 
tests, and they pass. So currently im unsure of the issue, it be great if 
FederatedQueueTest.java can be extended with a failure test case that will run 
within junit to demonstrate the issue, then we can look at more.

> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>  
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>  
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>  
> and adding dependency:
> {code:java}
> 
>   org.apache.activemq
>   activemq-client
>   ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter: 
> hyphenated_props:federation-name IS NOT NULL}}
>  



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

[jira] [Comment Edited] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol



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

Michael Andre Pearce edited comment on ARTEMIS-2802 at 2/23/21, 2:31 AM:
-

[~jbertram] I modified [^FederatedQueueTest.java]and [^FederatedTestBase.java] 
attached to start up an actual port, instead of invm only, and then adjusted 
the test cases to use the activemq 5.x jms client, and ran the tests, and they 
pass. So currently im unsure of the issue, it be great if 
FederatedQueueTest.java can be extended with a failure test case that will run 
within junit to demonstrate the issue, then we can look at more.

 

>From what i understand, "hyphenated_props:federation-name IS NOT NULL" is a 
>valid filter, infact the extra "hyphenated_props:" prefix on the filter is 
>something [~cshannon] added to fix a filter issue. 


was (Author: michael.andre.pearce):
[~jbertram] I modified [^FederatedQueueTest.java]and [^FederatedTestBase.java] 
attached to start up an actual port, instead of invm only, and then adjusted 
the test cases to use the activemq 5.x jms client, and ran the tests, and they 
pass. So currently im unsure of the issue, it be great if 
FederatedQueueTest.java can be extended with a failure test case that will run 
within junit to demonstrate the issue, then we can look at more.

> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>  
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>  
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>  
> and adding dependency:
> {code:java}
> 
>   org.apache.activemq
>   activemq-client
>   ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter: 
> hyphenated_props:federation-name IS NOT NULL}}
>  



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

[jira] [Comment Edited] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol



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

Michael Andre Pearce edited comment on ARTEMIS-2802 at 2/23/21, 2:35 AM:
-

[~jbertram] I modified [^FederatedQueueTest.java]and [^FederatedTestBase.java] 
attached to start up an actual port, instead of invm only, and then adjusted 
the test cases to use the activemq 5.x jms client, and ran the tests, and they 
pass. So currently im unsure of the issue, it be great if 
FederatedQueueTest.java can be extended with a failure test case that will run 
within junit to demonstrate the issue, then we can look at more.

 

>From what i understand, "hyphenated_props:federation-name IS NOT NULL" is a 
>valid filter, infact the extra "hyphenated_props:" prefix on the filter is 
>something [~cshannon] added to fix a filter issue. in ARTEMIS-2531

git hash:

ad0581bf76043322934290d489f3f4489ac2536b


was (Author: michael.andre.pearce):
[~jbertram] I modified [^FederatedQueueTest.java]and [^FederatedTestBase.java] 
attached to start up an actual port, instead of invm only, and then adjusted 
the test cases to use the activemq 5.x jms client, and ran the tests, and they 
pass. So currently im unsure of the issue, it be great if 
FederatedQueueTest.java can be extended with a failure test case that will run 
within junit to demonstrate the issue, then we can look at more.

 

>From what i understand, "hyphenated_props:federation-name IS NOT NULL" is a 
>valid filter, infact the extra "hyphenated_props:" prefix on the filter is 
>something [~cshannon] added to fix a filter issue. 

> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>  
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>  
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>  
> and adding dependency:
> {code:java}
> 
>   org.apache.activemq
>   activemq-client
>   ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter: 
> hyphenated_props:federation-name IS NOT NULL}}
>  



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

[jira] [Work logged] (ARTEMIS-3133) Reduce memory usage for Null an Ping packets



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

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

Author: ASF GitHub Bot
Created on: 23/Feb/21 01:23
Start Date: 23/Feb/21 01:23
Worklog Time Spent: 10m 
  Work Description: clebertsuconic commented on pull request #3462:
URL: https://github.com/apache/activemq-artemis/pull/3462#issuecomment-783797533


   I had a few test failures when I rebased this and run the whole test suite.
   
   Did you run a full test on this?
   
   
   Test Name | Duration | Age
   -- | -- | --
   
org.apache.activemq.artemis.tests.integration.cluster.distribution.LargeMessageRedistributionTest.testRedistributionLargeMessageDirCleanup
 | 33 sec | 1
   
org.apache.activemq.artemis.tests.integration.federation.FederatedQueueTest.testFederatedQueueBiDirectionalDownstream
 | 2.5 sec | 1
   
org.apache.activemq.artemis.tests.integration.jms.cluster.TopicClusterPageStoreSizeTest.testPageStoreSizeWithClusteredDurableSub
 | 61 ms | 1
   
org.apache.activemq.artemis.tests.integration.persistence.SyncSendTest.testSendConsumeAudoACK[storage=libaio,
 protocol=core] | 0.48 sec | 1
   
org.apache.activemq.artemis.tests.integration.persistence.SyncSendTest.testSendConsumeAudoACK[storage=libaio,
 protocol=openwire] | 0.47 sec | 1
   
org.apache.activemq.artemis.tests.integration.persistence.SyncSendTest.testSendConsumeAudoACK[storage=libaio,
 protocol=amqp] | 0.29 sec | 1
   
org.apache.activemq.artemis.tests.integration.persistence.SyncSendTest.testSendConsumeAudoACK[storage=nio,
 protocol=core] | 0.34 sec | 1
   
org.apache.activemq.artemis.tests.integration.persistence.SyncSendTest.testSendConsumeAudoACK[storage=nio,
 protocol=openwire] | 0.28 sec | 1
   
org.apache.activemq.artemis.tests.integration.persistence.SyncSendTest.testSendConsumeAudoACK[storage=nio,
 protocol=amqp] | 0.29 sec | 1
   
   



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: 556115)
Time Spent: 20m  (was: 10m)

> Reduce memory usage for Null an Ping packets
> 
>
> Key: ARTEMIS-3133
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3133
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently NullResponseMessage and Ping report a wrong expected size (== 
> 1500): it means that the allocated Netty buffers will be much bigger then 
> necessary eg null is 13 bytes, while null v2 is 21.
>  
> In addition, NullReponseMessage could be cached if the transport channel 
> won't use any resend cache, greatly reducing the memory used under load.



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

[jira] [Updated] (ARTEMIS-2802) Federation not working when clients connect using OpenWire protocol



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

Michael Andre Pearce updated ARTEMIS-2802:
--
Attachment: FederatedTestBase.java
FederatedQueueTest.java

> Federation not working when clients connect using OpenWire protocol
> ---
>
> Key: ARTEMIS-2802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2802
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 2.13.0
>Reporter: jerhat
>Priority: Minor
> Attachments: FederatedQueueTest.java, FederatedTestBase.java
>
>
> Reproducible by switching from:
>  
> {code:java}
> import org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory;{code}
>  
> to:
> {code:java}
> import org.apache.activemq.ActiveMQConnectionFactory;{code}
>  
> and adding dependency:
> {code:java}
> 
>   org.apache.activemq
>   activemq-client
>   ${activemq5-version}
> {code}
> to *federated-queue* example.
> Test will fail, below error is logged:
> {{ERROR [org.apache.activemq.artemis.core.server] AMQ224006: Invalid filter: 
> hyphenated_props:federation-name IS NOT NULL}}
>  



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

[jira] [Work logged] (ARTEMIS-3133) Reduce memory usage for Null an Ping packets



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

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

Author: ASF GitHub Bot
Created on: 23/Feb/21 07:13
Start Date: 23/Feb/21 07:13
Worklog Time Spent: 10m 
  Work Description: franz1981 edited a comment on pull request #3462:
URL: https://github.com/apache/activemq-artemis/pull/3462#issuecomment-783960692


   @clebertsuconic I just noticed the reason :+1:  thanks
   
   I see that we cannot recycle null packets instances that easily because of 
`sendResponse` that can send responses back on 
`storageManager.afterCompleteOperations` using a different thread :(
   
   I'm preparing something to handle this case as a separate commit 



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: 556206)
Time Spent: 40m  (was: 0.5h)

> Reduce memory usage for Null an Ping packets
> 
>
> Key: ARTEMIS-3133
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3133
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently NullResponseMessage and Ping report a wrong expected size (== 
> 1500): it means that the allocated Netty buffers will be much bigger then 
> necessary eg null is 13 bytes, while null v2 is 21.
>  
> In addition, NullReponseMessage could be cached if the transport channel 
> won't use any resend cache, greatly reducing the memory used under load.



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

[jira] [Work logged] (ARTEMIS-3133) Reduce memory usage for Null an Ping packets



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

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

Author: ASF GitHub Bot
Created on: 23/Feb/21 07:05
Start Date: 23/Feb/21 07:05
Worklog Time Spent: 10m 
  Work Description: franz1981 commented on pull request #3462:
URL: https://github.com/apache/activemq-artemis/pull/3462#issuecomment-783960692


   @clebertsuconic I just noticed the reason :+1:  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: 556200)
Time Spent: 0.5h  (was: 20m)

> Reduce memory usage for Null an Ping packets
> 
>
> Key: ARTEMIS-3133
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3133
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently NullResponseMessage and Ping report a wrong expected size (== 
> 1500): it means that the allocated Netty buffers will be much bigger then 
> necessary eg null is 13 bytes, while null v2 is 21.
>  
> In addition, NullReponseMessage could be cached if the transport channel 
> won't use any resend cache, greatly reducing the memory used under load.



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

[jira] [Work logged] (ARTEMIS-3133) Reduce memory usage for Null an Ping packets



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

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

Author: ASF GitHub Bot
Created on: 23/Feb/21 07:14
Start Date: 23/Feb/21 07:14
Worklog Time Spent: 10m 
  Work Description: franz1981 edited a comment on pull request #3462:
URL: https://github.com/apache/activemq-artemis/pull/3462#issuecomment-783960692


   @clebertsuconic I just noticed the reason :+1:  thanks
   
   I see that we cannot recycle null packets instances that easily because of 
`sendResponse` that can send responses back on 
`storageManager.afterCompleteOperations` using a different thread :(
   
   I'm preparing something to handle this case 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: 556209)
Time Spent: 50m  (was: 40m)

> Reduce memory usage for Null an Ping packets
> 
>
> Key: ARTEMIS-3133
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3133
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Currently NullResponseMessage and Ping report a wrong expected size (== 
> 1500): it means that the allocated Netty buffers will be much bigger then 
> necessary eg null is 13 bytes, while null v2 is 21.
>  
> In addition, NullReponseMessage could be cached if the transport channel 
> won't use any resend cache, greatly reducing the memory used under load.



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

[jira] [Work logged] (ARTEMIS-3133) Reduce memory usage for Null an Ping packets



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

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

Author: ASF GitHub Bot
Created on: 23/Feb/21 07:55
Start Date: 23/Feb/21 07:55
Worklog Time Spent: 10m 
  Work Description: franz1981 commented on pull request #3462:
URL: https://github.com/apache/activemq-artemis/pull/3462#issuecomment-783984909


   I'm just getting a failure on 
`org.apache.activemq.artemis.tests.integration.jms.cluster.TopicClusterPageStoreSizeTest.testPageStoreSizeWithClusteredDurableSub`
 that I'm addressing 



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: 556219)
Time Spent: 1h  (was: 50m)

> Reduce memory usage for Null an Ping packets
> 
>
> Key: ARTEMIS-3133
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3133
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Currently NullResponseMessage and Ping report a wrong expected size (== 
> 1500): it means that the allocated Netty buffers will be much bigger then 
> necessary eg null is 13 bytes, while null v2 is 21.
>  
> In addition, NullReponseMessage could be cached if the transport channel 
> won't use any resend cache, greatly reducing the memory used under load.



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

[jira] [Commented] (ARTEMIS-3093) Message Order broken with Core Protocol when rolling back transactions



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

John Behm commented on ARTEMIS-3093:


Well, the main problem was that not those messages that were touched by 
consumers were out of order, but the whole queue.

But yeah, it would be great if the order was preserved after the rollback (but 
not the main point)

> Message Order broken with Core Protocol when rolling back transactions
> --
>
> Key: ARTEMIS-3093
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3093
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.16.0
>Reporter: John Behm
>Priority: Critical
>  Labels: artemis, bug, order, queue
>
> ARTEMIS-2458
> This issue still persists.
>  
> Consuming from a queue with two threads with distinct sessions while rolling 
> back directly in each thread when receiving a message breaks the whole order 
> of the queue. Even with delays of 500ms.
> The queue/addresse is configured as ANYCAST queue.
>  
> (In 2.10 this issue persists as well.)
> Basic Test setup is like this:
> You have a non-clustered single instance of Artemis.
> You do have a redelivery-delay of 0.
> You fill an anycast queue with 1000/1 ordered messages.
> You disconnect your producer and start the two or more consumers that try to 
> fetch all of the messages from that exact same queue, but can only get one, 
> as you always roll back the session.
> Each time any of those two(or more) consumers receives a message, they 
> rollback the session instantly and sleep 0 to 500 ms.
> After rolling back every time you receive a message on any of your consumer 
> threads, you expect to always get the message with the content "0".
> After like ten iterations of this ping-pong rollback between your two 
> consumer threads, you start to get completely random messages, not even 
> within the range of 0 through 10, but completely arbitrary ones from within 
> the queue.
> You disconnect your consumers and try dumping the queue. You get a completely 
> unordered message queue.



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

[jira] [Comment Edited] (AMQ-8149) Create Docker Image

[
https://issues.apache.org/jira/browse/AMQ-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288265#comment-17288265
]

John Behm edited comment on AMQ-8149 at 2/22/21, 9:55 AM:
--

Thanks for the comments.

I did not have much time on friday, so I took all of my previous input and
combined it in that one comment, as this issue did get some traction, so I felt
like I had to be fast here.

My comment is directed at the ActiveMQ Artemis product, I did not touch on the
ActiveMQ topic at all.

(the part of me being somewhat diappointed is not really necessary for this
discussion at all, as we did really expect to use Artemis and we think that it
has great potential and hopefully a great future, but currently not for us,
thus not production ready for us. In the end it does not matter, whether I or
some expert company get paid for taking their time to investigate an open
source product, I might take longer, but I might also learn some new
technologies along the way that might help the company on the long run).

I did try to summarize my problems I faced when trying to run Artemis in a
Kubernetes environment, but might go further into detail about what exactly
hinders Artemis from being ready to be officially put into a Docker container.

The efforts to actually take this step and go into the real cloud native
direction is great.

The configuration Artemis on the other hand does not really seem to be made to
be put into a container as one does not have an immutable image but a two stage
process (referring to the current Dockerfile that is somewhere in the Github
repository).

The configuration of an application that runs inside of a Docker container is
usually passed through either environment variables or mounted at a specific
location or a combination of both.

For that to work Artemis needs to have a static configuration which is not the
case.

In the first startup step (referring to the Dockerfile example in the github
repo mirror) Artemis generates a somewhat generic broker.xml with some specific
values that are inherent to the underlying container, hostmachine, etc.

I think those performance values of the storage should be handled outside of
the broker.xml (or calculated on every startup, whatever ideas you may have) as
they usually cannot be known by the person configuring Artemis.

Also the redundant passing of environment variables to the container and the
JVM should preferrably also be done directly.

So that Artemis does directly fetch all environment variables (I don't know if
that's feasible without passing them to the JVM, I hope yes, as it's possible
in other languages).

These two key points would make Artemis way better configurable inside of a
Docker container.

I know that this issue is about the Docker image and I do not expect anyone to
create anything else, yet.

BUT one has to look ahead of the current stage and look at what might come
after the Docker image is ready. What do people want and what the image is
goind to be used for.

The Docker image will be the foundation that every other technology like
Kubernetes and should work properly for it to be successful now and in the
future.

The roadmap ahead for the Artemis product seems to be something along the lines
of
# Make Artemis container ready <-- this should be done first
# Put Artemis in a Docker container
# Run Artemis in Kubernetes <-- I don't expect anyone to
take on any of these tasks in the near future at all.
# Create a Kubernetes Operator

was (Author: behm015):
Thanks for the comments.

I did not have much time on friday, so I took all of my previous input and
combined it in that one comment, as this issue did get some traction, so I felt
like I had to be fast here.

My comment is directed at the ActiveMQ Artemis product, I did not touch on the
ActiveMQ topic at all.

The efforts to actually take this step and go into the real cloud native
direction is great.

The configuration Artemis on the other hand does not really seem to be made to
be put into a container as

[jira] [Comment Edited] (ARTEMIS-3093) Message Order broken with Core Protocol when rolling back transactions



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

John Behm edited comment on ARTEMIS-3093 at 2/22/21, 10:06 AM:
---

Well, the main problem was that not those messages that were touched by 
consumers were out of order, but the whole queue.

But yeah, it would be great if the order was preserved after the rollback (but 
not the main point)

 

I guess the description is not that on point there.

Sorry about that.


was (Author: behm015):
Well, the main problem was that not those messages that were touched by 
consumers were out of order, but the whole queue.

But yeah, it would be great if the order was preserved after the rollback (but 
not the main point)

> Message Order broken with Core Protocol when rolling back transactions
> --
>
> Key: ARTEMIS-3093
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3093
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.16.0
>Reporter: John Behm
>Priority: Critical
>  Labels: artemis, bug, order, queue
>
> ARTEMIS-2458
> This issue still persists.
>  
> Consuming from a queue with two threads with distinct sessions while rolling 
> back directly in each thread when receiving a message breaks the whole order 
> of the queue. Even with delays of 500ms.
> The queue/addresse is configured as ANYCAST queue.
>  
> (In 2.10 this issue persists as well.)
> Basic Test setup is like this:
> You have a non-clustered single instance of Artemis.
> You do have a redelivery-delay of 0.
> You fill an anycast queue with 1000/1 ordered messages.
> You disconnect your producer and start the two or more consumers that try to 
> fetch all of the messages from that exact same queue, but can only get one, 
> as you always roll back the session.
> Each time any of those two(or more) consumers receives a message, they 
> rollback the session instantly and sleep 0 to 500 ms.
> After rolling back every time you receive a message on any of your consumer 
> threads, you expect to always get the message with the content "0".
> After like ten iterations of this ping-pong rollback between your two 
> consumer threads, you start to get completely random messages, not even 
> within the range of 0 through 10, but completely arbitrary ones from within 
> the queue.
> You disconnect your consumers and try dumping the queue. You get a completely 
> unordered message queue.



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

[jira] [Work logged] (AMQNET-656) AMQP failover implementation fails to reconnect in some cases



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

ASF GitHub Bot logged work on AMQNET-656:
-

Author: ASF GitHub Bot
Created on: 22/Feb/21 09:04
Start Date: 22/Feb/21 09:04
Worklog Time Spent: 10m 
  Work Description: lukeabsent commented on pull request #59:
URL: https://github.com/apache/activemq-nms-amqp/pull/59#issuecomment-783215340


   Had a little look, and it seems overall that there could be more Reconnect() 
going 
   at the same time than just one (which I believe was the original intention), 
and that is one risk. 
   If you suspect deadlock happening around HandleProviderError-lock(SyncRoot) 
then maybe 
   it is being possible cause there is provider.Close inside - though deeper 
inside it seems to be timeouted for 1m.
   Other risk is that HandleProviderError looks like it may be called from 
underlying AsyncPump (AmqpNetLite) thread (inline execution) and if it locks or 
waits on something, then pump stops pumping and if thing being expected is 
something that was supposed to be delivered by AsyncPump, then there is 
deadlock.
   In general, it looks like it requires some work, if I have some time I will 
see if I can recreate it in some 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: 555704)
Time Spent: 5.5h  (was: 5h 20m)

> AMQP failover implementation fails to reconnect in some cases
> -
>
> Key: AMQNET-656
> URL: https://issues.apache.org/jira/browse/AMQNET-656
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: AMQP-1.8.1
>Reporter: Bruce Dodson
>Priority: Major
>  Time Spent: 5.5h
>  Remaining Estimate: 0h
>
> We recently had an issue where some of our producer instances were able to 
> reconnect immediately after the master/slave (or primary/standby) broker 
> cluster failed over, while others never reconnected.
> It appears to be related to two existing JIRAs, AMQNET-624 (addressed in 
> GitHub PR#45) and AMQNET-626 (new issue raised in the same PR, but closed 
> without any changes).
> Regarding the bug identified and fixed in AMQNET-624, part of the original 
> solution was pulled back: where TriggerReconnectionAttempt was called via 
> Task.Run, to instead call it directly. The second issue, AMQNET-626 was to 
> raise concern about the unawaited task returned by TriggerReconnectionAttempt.
> I think perhaps calling from Task.Run may have been beneficial after all: it 
> ensured that TriggerReconnectionAttempt was running on a thread from the 
> thread pool. Otherwise, when TriggerReconnectionAttempt calls 
> ScheduleReconnect, and ScheduleReconnect does an await, that is occurring 
> from within a lock statement.
> As noted in MSDN, an await statement _cannot_ occur inside of a lock 
> statement. That includes anywhere in the call stack, as far as I understand. 
> If you do, it is not caught by the compiler, but can lead to failures e.g. 
> where the task being awaited never gets scheduled.
> Invoking TriggerReconnectionAttempt from a thread pool thread (or another 
> background thread) is one way to avoid this issue, and using Task.Run() might 
> be the easiest way, even though it may also raise eyebrows. Any performance 
> overhead of Task.Run() shouldn't be a factor, since it is only invoked upon 
> losing connection, not continuously.
> The call to Task.Run() could also be moved into TriggerReconnectionAttempt, 
> like so:
> {code:java}
> // this is invoked using Task.Run, to ensure it runs on a thread pool thread
> // in case this was invoked from inside a lock statement (which it is)
> return Task.Run(async () => await 
> reconnectControl.ScheduleReconnect(Reconnect));{code}
> It does still leave the issue identified in AMQNET-626, that the result is 
> not checked, but it resolves the failover failure caused by calling await 
> inside of a lock.
> (Another way around this would be to use a SemaphoreSlim, or other 
> async-compatible synchronization mechanism instead of a lock statement. 
> However, that could have far-reaching implications, since lock statements are 
> used in many parts of the AMQP implementation.)



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

[jira] [Comment Edited] (AMQ-8149) Create Docker Image

[
https://issues.apache.org/jira/browse/AMQ-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288265#comment-17288265
]

John Behm edited comment on AMQ-8149 at 2/22/21, 9:10 AM:
--

Thanks for the comments.

I did not have much time on friday, so I took all of my previous input and
combined it in that one comment, as this issue did get some traction, so I felt
like I had to be fast here.

My comment is directed at the ActiveMQ Artemis product, I did not touch on the
ActiveMQ topic at all.

The efforts to actually take this step and go into the real cloud native
direction is great.

The configuration of an application that runs inside of a Docker container is
usually passed through either environment variables or mounted at a specific
location or a combination of both.

For that to work Artemis needs to have a static configuration file which is not
the case.

Also the redundant passing of environment variables to the container and the
JVM should preferrably also be done directly.

So that Artemis does directly fetch all environment variables (I don't know if
that's feasible without passing them to the JVM, I hope yes, as it's possible
in other languages).

These two key points would make Artemis way better configurable inside of a
Docker container.

I know that this issue is about the Docker image and I do not expect anyone to
create anything else, yet.

BUT one has to look ahead of the current stage and look at what might come
after the Docker image is ready. What do people want and what the image is
goind to be used for.

The Docker image will be the foundation that every other technology like
Kubernetes and should work properly for it to be successful now and in the
future.

was (Author: behm015):
Thanks for the comments.

I did not have much time on friday, so I took all of my previous input and
combined it in that one comment, as this issue did get some traction, so I felt
like I had to be fast here.

My comment is directed at the ActiveMQ Artemis product, I did not touch on the
ActiveMQ topic at all.

The efforts to actually take this step and go into the real cloud native
direction is great.

The configuration Artemis on the other hand does not really seem to be made to
be put into a container

[jira] [Commented] (AMQ-8149) Create Docker Image



[ 
https://issues.apache.org/jira/browse/AMQ-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288265#comment-17288265
 ] 

John Behm commented on AMQ-8149:


Thanks for the comments.

I did not have much time on friday, so I took all of my previous input and 
combined it in that one comment, as this issue did get some traction, so I felt 
like I had to be fast here.

 

My comment is directed at the ActiveMQ Artemis product, I did not touch on the 
ActiveMQ topic at all.

 

(the part of me being somewhat diappointed is not really necessary for this 
discussion at all, as we did really expect to use Artemis and we think that it 
has great potential and hopefully a great future, but currently not for us, 
thus not production ready for us. In the end it does not matter, whether I or 
some expert company get paid for taking their time to investigate an open 
source product, I might take longer, but I might also learn some new 
technologies along the way that might help the company on the long run).

 

I did try to summarize my problems I faced when trying to run Artemis in a 
Kubernetes environment, but might go further into detail about what exactly 
hinders Artemis from being ready to be officially put into a Docker container.

The efforts to actually take this step and go into the real cloud native 
direction is great.

The configuration Artemis on the other hand does not really seem to be made to 
be put into a container as one does not have an immutable image but a two stage 
process (referring to the current Dockerfile that is somewhere in the Github 
repository).

 

The configuration of an application that runs inside of a Docker container is 
usually passed through either environment variables or mounted at a specific 
location or a combination of both.

For that to work Artemis needs to have a static configuration file which is not 
the case.

In the first startup step (referring to the Dockerfile example in the github 
repo mirror) Artemis generates a somewhat generic broker.xml with some specific 
values that are inherent to the underlying container, hostmachine, etc.

I think those performance values of the storage should be handled outside of 
the broker.xml (or calculated on every startup, whatever ideas you may have) as 
they usually cannot be known by the person configuring  Artemis.

Also the redundant passing of environment variables to the container and the 
JVM should preferrably also be done directly.

So that Artemis does directly fetch all environment variables (I don't know if 
that's feasible without passing them to the JVM, I hope yes, as it's possible 
in other languages).

 

These two key points would make Artemis way better configurable inside of a 
Docker container.

 

I know that this issue is about the Docker image and I do not expect anyone to 
create anything else, yet.

BUT one has to look ahead of the current stage and look at what might come 
after the Docker image is ready. What do people want and what the image is 
goind to be used for.

The Docker image will be the foundation that every other technology like 
Kubernetes needs to work properly for it to be successful.

 

The roadmap ahead for the Artemis product seems to be something along the lines 
of
 # Make Artemis container ready               <-- this should be done first
 # Put Artemis in a Docker container
 # Run Artemis in Kubernetes                    <-- I don't expect anyone to 
take on any of these tasks in the near future at all.
 # Create a Kubernetes Operator 

 

 

 

 

> Create Docker Image
> ---
>
> Key: AMQ-8149
> URL: https://issues.apache.org/jira/browse/AMQ-8149
> Project: ActiveMQ
>  Issue Type: New Feature
>Affects Versions: 5.17.0
>Reporter: Matt Pavlovich
>Assignee: Matt Pavlovich
>Priority: Major
>
> Create an Apache ActiveMQ docker image
> Ideas:
> [ ] jib or jkube mvn plugin
> [ ] Create a general container that supports most use cases (enable all 
> protocols on default ports, etc)
> [ ] Provide artifacts for users to build customized containers
> Tasks:
> [Pending] Creation of Docker repository for ActiveMQ INFRA-21430
> [ ] Add activemq-docker module to 5.17.x
> [ ] Add dockerhub deployment to release process



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

[jira] [Work logged] (AMQNET-656) AMQP failover implementation fails to reconnect in some cases



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

ASF GitHub Bot logged work on AMQNET-656:
-

Author: ASF GitHub Bot
Created on: 22/Feb/21 09:11
Start Date: 22/Feb/21 09:11
Worklog Time Spent: 10m 
  Work Description: lukeabsent edited a comment on pull request #59:
URL: https://github.com/apache/activemq-nms-amqp/pull/59#issuecomment-783215340


   Had a little look, and it seems overall that there could be more Reconnect() 
going 
   at the same time than just one (which I believe was the original intention), 
and that is one risk. 
   If you suspect deadlock happening around HandleProviderError-lock(SyncRoot) 
then maybe 
   it is being possible cause there is provider.Close inside - though deeper 
inside it seems to be timeouted for 1m.
   Other risk is that HandleProviderError looks like it may be called from 
underlying AsyncPump (AmqpNetLite) thread (inline execution) and if it locks or 
waits on something, then pump stops pumping and if thing being expected is 
something that was supposed to be delivered by AsyncPump, then there is 
deadlock.
   In general, it looks like it requires some work, we could be good to be able 
to reproduce it in some 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: 555710)
Time Spent: 5h 40m  (was: 5.5h)

> AMQP failover implementation fails to reconnect in some cases
> -
>
> Key: AMQNET-656
> URL: https://issues.apache.org/jira/browse/AMQNET-656
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: AMQP-1.8.1
>Reporter: Bruce Dodson
>Priority: Major
>  Time Spent: 5h 40m
>  Remaining Estimate: 0h
>
> We recently had an issue where some of our producer instances were able to 
> reconnect immediately after the master/slave (or primary/standby) broker 
> cluster failed over, while others never reconnected.
> It appears to be related to two existing JIRAs, AMQNET-624 (addressed in 
> GitHub PR#45) and AMQNET-626 (new issue raised in the same PR, but closed 
> without any changes).
> Regarding the bug identified and fixed in AMQNET-624, part of the original 
> solution was pulled back: where TriggerReconnectionAttempt was called via 
> Task.Run, to instead call it directly. The second issue, AMQNET-626 was to 
> raise concern about the unawaited task returned by TriggerReconnectionAttempt.
> I think perhaps calling from Task.Run may have been beneficial after all: it 
> ensured that TriggerReconnectionAttempt was running on a thread from the 
> thread pool. Otherwise, when TriggerReconnectionAttempt calls 
> ScheduleReconnect, and ScheduleReconnect does an await, that is occurring 
> from within a lock statement.
> As noted in MSDN, an await statement _cannot_ occur inside of a lock 
> statement. That includes anywhere in the call stack, as far as I understand. 
> If you do, it is not caught by the compiler, but can lead to failures e.g. 
> where the task being awaited never gets scheduled.
> Invoking TriggerReconnectionAttempt from a thread pool thread (or another 
> background thread) is one way to avoid this issue, and using Task.Run() might 
> be the easiest way, even though it may also raise eyebrows. Any performance 
> overhead of Task.Run() shouldn't be a factor, since it is only invoked upon 
> losing connection, not continuously.
> The call to Task.Run() could also be moved into TriggerReconnectionAttempt, 
> like so:
> {code:java}
> // this is invoked using Task.Run, to ensure it runs on a thread pool thread
> // in case this was invoked from inside a lock statement (which it is)
> return Task.Run(async () => await 
> reconnectControl.ScheduleReconnect(Reconnect));{code}
> It does still leave the issue identified in AMQNET-626, that the result is 
> not checked, but it resolves the failover failure caused by calling await 
> inside of a lock.
> (Another way around this would be to use a SemaphoreSlim, or other 
> async-compatible synchronization mechanism instead of a lock statement. 
> However, that could have far-reaching implications, since lock statements are 
> used in many parts of the AMQP implementation.)



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

[jira] [Work logged] (AMQNET-656) AMQP failover implementation fails to reconnect in some cases



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

ASF GitHub Bot logged work on AMQNET-656:
-

Author: ASF GitHub Bot
Created on: 22/Feb/21 09:13
Start Date: 22/Feb/21 09:13
Worklog Time Spent: 10m 
  Work Description: lukeabsent edited a comment on pull request #59:
URL: https://github.com/apache/activemq-nms-amqp/pull/59#issuecomment-783215340


   Had a little look, and it seems overall that there could be more Reconnect() 
going 
   at the same time than just one (which I believe was the original intention), 
and that is one risk. 
   If you suspect deadlock happening around HandleProviderError-lock(SyncRoot) 
then maybe 
   it is being possible cause there is provider.Close inside - though deeper 
inside it seems to be timeouted for 1m.
   Other risk is that HandleProviderError looks like it may be called from 
underlying AsyncPump (AmqpNetLite) thread (inline execution) and if it locks or 
waits on something, then pump stops pumping and if thing being expected is 
something that was supposed to be delivered by AsyncPump, then there is 
deadlock.
   In general, it looks like it requires some work, it would be good to be able 
to reproduce it in some 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: 555713)
Time Spent: 5h 50m  (was: 5h 40m)

> AMQP failover implementation fails to reconnect in some cases
> -
>
> Key: AMQNET-656
> URL: https://issues.apache.org/jira/browse/AMQNET-656
> Project: ActiveMQ .Net
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: AMQP-1.8.1
>Reporter: Bruce Dodson
>Priority: Major
>  Time Spent: 5h 50m
>  Remaining Estimate: 0h
>
> We recently had an issue where some of our producer instances were able to 
> reconnect immediately after the master/slave (or primary/standby) broker 
> cluster failed over, while others never reconnected.
> It appears to be related to two existing JIRAs, AMQNET-624 (addressed in 
> GitHub PR#45) and AMQNET-626 (new issue raised in the same PR, but closed 
> without any changes).
> Regarding the bug identified and fixed in AMQNET-624, part of the original 
> solution was pulled back: where TriggerReconnectionAttempt was called via 
> Task.Run, to instead call it directly. The second issue, AMQNET-626 was to 
> raise concern about the unawaited task returned by TriggerReconnectionAttempt.
> I think perhaps calling from Task.Run may have been beneficial after all: it 
> ensured that TriggerReconnectionAttempt was running on a thread from the 
> thread pool. Otherwise, when TriggerReconnectionAttempt calls 
> ScheduleReconnect, and ScheduleReconnect does an await, that is occurring 
> from within a lock statement.
> As noted in MSDN, an await statement _cannot_ occur inside of a lock 
> statement. That includes anywhere in the call stack, as far as I understand. 
> If you do, it is not caught by the compiler, but can lead to failures e.g. 
> where the task being awaited never gets scheduled.
> Invoking TriggerReconnectionAttempt from a thread pool thread (or another 
> background thread) is one way to avoid this issue, and using Task.Run() might 
> be the easiest way, even though it may also raise eyebrows. Any performance 
> overhead of Task.Run() shouldn't be a factor, since it is only invoked upon 
> losing connection, not continuously.
> The call to Task.Run() could also be moved into TriggerReconnectionAttempt, 
> like so:
> {code:java}
> // this is invoked using Task.Run, to ensure it runs on a thread pool thread
> // in case this was invoked from inside a lock statement (which it is)
> return Task.Run(async () => await 
> reconnectControl.ScheduleReconnect(Reconnect));{code}
> It does still leave the issue identified in AMQNET-626, that the result is 
> not checked, but it resolves the failover failure caused by calling await 
> inside of a lock.
> (Another way around this would be to use a SemaphoreSlim, or other 
> async-compatible synchronization mechanism instead of a lock statement. 
> However, that could have far-reaching implications, since lock statements are 
> used in many parts of the AMQP implementation.)



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

[jira] [Created] (AMQ-8153) Slot Online

2021-02-22 Thread slot online (Jira)

slot online created AMQ-8153:


 Summary: Slot Online
 Key: AMQ-8153
 URL: https://issues.apache.org/jira/browse/AMQ-8153
 Project: ActiveMQ
  Issue Type: Bug
 Environment: h1. Situs Judi Slot Online Terbaik

GMWIN adalah agen situs judi [Slot Online|https://172.105.125.44/mobile/slots] 
terpercaya yang menyediakan game judi online dengan menggunakan uang asli yang 
terlengkap dan mempunyai ribuan player yang bermain online secara bersamaan 
setiap harinya. GMWIN menyediakan segala jenis permainan judi yang dimainkan 
secara online seperti judi bola sbobet, judi tembak ikan, casino online, poker 
online, slot online, togel dan masih banyak permainan judi online lainnya. Para 
player yang hendak bergabung dengan GMWIN juga tidak perlu khawatir, para 
player yang join dengan GMWIN akan diberikan satu ID yang dapat dimainkan 
disemua jenis permainan judi online yang tersedia. Jadi apabila player yang 
tadinya misalkan bermain game judi tembak ikan dan hendak beralih ke permainan 
judi slot, credit balance nya tetap 1 dan ID nya juga tetap sama. Jadi apabila 
player yang sudah menang bermain judi tembak ikan maka dari sana credit nya 
akan bertambah dan begitu melanjutkan permainan ke judi slot nominal creditnya 
akan sama seperti sesudah memenangkan permainan yang dimainkan sebelumnya. 
GMWIN sebagai agen situs judi online terpercaya yang bekerja sama dengan 
Nexusengine memastikan bahwa akan membayarkan seluruh uang kemenangan player 
atau pun apabila player memenangkan jackpot progressive yang dapat memberikan 
keuntungan bagi player hingga ratusan juta rupiah, GMWIN pasti akan membayarkan 
seluruh uang kemenangan player secara 100% tanpa pakai ribet.
h2. Daftar Situs Judi Slot Online Terpercaya GMWIN

Bermain judi slot online di GMWIN, segala jenis permainan judi slot dapat anda 
temukan disini. Cara bermain judi slot merupakan jenis permainan judi yang 
sangat mudah dilakukan, tidak perlu memikirkan strategi untuk mengatur kartu 
semisalkan bermain game judi online seperti dominoqq ataupun poker. Anda cukup 
mengklik 1x dan mesin slot akan menampilkan gambar yang diputar secara acak dan 
dimana hasil akhir dari gambar tersebut yang akan menentukan apakah anda 
memenangkan permainan dari ronde slot tersebut. Pola dari gambar slot agar anda 
dapat memenangkan permainan slot tergantung dari jenis permainan slot yang anda 
mainkan. Permainan judi slot yang tersedia antara lain adalah [Habanero 
Slot|https://172.105.125.44/mobile/slots], RTG, Microgaming, Joker Gaming, 
[Pragmatic Slot|https://172.105.125.44/mobile/slots] dan masih banyak yang 
lainnya dengan kemenangan win rate yang tinggi. Anda tidak perlu khawatir akan 
bosan memainkan permainan game slot ini, dikarenakan banyaknya jenis permainan 
game slot itu sendiri dan setiap game slot mempunyai tampilan graphic yang 
sangatlah menarik. Variasi gambar dan pola permainan dari game slot ini sudah 
pasti dapat menambahkan keseruan anda dalam bermain.
h2. Judi Slot Online Banyak Bonus

Bermain judi slot di GMWIN memberikan banyak bonus bagi anda para player, ada 
bonus cashback, bonus turnover, bonus new member dan masih banyak lagi bonus 
dan promo yang bisa didapatkan para player. Selain itu juga untuk memastikan 
kepuasan dan kenyamanan para player, GMWIN juga menyediakan customer service 
professional yang dapat membantu anda dalam segala hal secara 24 jam non stop. 
Jadi apabila anda hendak ingin menarik hasil uang kemenangan anda, anda tinggal 
meminta bantuan kepada customer service kami melalui live chat yang telah 
disediakan. Anda juga dapat meminta bantuan kepada customer service melalui 
live chat apabila anda masih bingung bagaimana cara untuk mendaftar di situs 
judi online GMWIN. Jadi janganlah anda ragu, segera bergabung dengan GMWIN 
bersama player lain dan raih keuntungan anda setiap harinya.
Reporter: slot online


h1. Situs Judi Slot Online Terbaik

GMWIN adalah agen situs judi [Slot Online|https://172.105.125.44/mobile/slots] 
terpercaya yang menyediakan game judi online dengan menggunakan uang asli yang 
terlengkap dan mempunyai ribuan player yang bermain online secara bersamaan 
setiap harinya. GMWIN menyediakan segala jenis permainan judi yang dimainkan 
secara online seperti judi bola sbobet, judi tembak ikan, casino online, poker 
online, slot online, togel dan masih banyak permainan judi online lainnya. Para 
player yang hendak bergabung dengan GMWIN juga tidak perlu khawatir, para 
player yang join dengan GMWIN akan diberikan satu ID yang dapat dimainkan 
disemua jenis permainan judi online yang tersedia. Jadi apabila player yang 
tadinya misalkan bermain game judi tembak ikan dan hendak beralih ke permainan 
judi slot, credit balance nya tetap 1 dan ID nya juga tetap sama. Jadi apabila 
player yang sudah menang bermain judi tembak ikan maka dari sana credit nya 
akan bertambah dan begitu melanjutkan permainan ke

[jira] [Comment Edited] (AMQ-8149) Create Docker Image