date:20181004

[jira] [Updated] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

2018-10-04 Thread Jamie goodyear (JIRA)



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

Jamie goodyear updated AMQ-7067:

Attachment: amq7067test.patch

> KahaDB Recovery can experience a dangling transaction when prepare and commit 
> occur on different pagefiles.
> ---
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit 
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with 
> 512 * 1024 characters in message payload). This forces a new pagefile to be 
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it 
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is 
> GC'd, hence the prepare & commit can not be matched. 
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}] 
> != {color:#cc7832}null{color}) {
>  {color:#cc7832}for {color}({color:#cc7832}int 
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
>  {color}pendingTx <= 
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832}; 
> {color}pendingTx++) {
>  gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles 
> with respect to GCing files.



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

[jira] [Comment Edited] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

2018-10-04 Thread Jamie goodyear (JIRA)



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

Jamie goodyear edited comment on AMQ-7067 at 10/4/18 5:40 PM:
--

Please see the amq7067 unit test.

This patch is for AMQ 5.15.x branch.

You can execute using the following command:
 mvn -Dtest=AMQ7067Test test


Keeping original comment for history:

I've attached a stand alone test case to reproduce the issue.

Here's how to use the test case:

0. Setup AMQ 5.15.6 broker on local system. Use default configuration, no 
special settings required. Start broker.
 1. Extract AMQ7067 zip file.
 2. Run XATransactionTest while Broker is live using :  mvn clean compile 
exec:java -Dexec.mainClass="XATransactionTest"

The test case will output:

[INFO] — exec-maven-plugin:1.6.0:java (default-cli) @ transaction —
 SLF4J: Class path contains multiple SLF4J bindings.
 SLF4J: Found binding in 
[jar:file:/Users/icbts/.m2/repository/org/apache/activemq/activemq-all/5.15.6/activemq-all-5.15.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: Found binding in 
[jar:file:/Users/icbts/.m2/repository/org/slf4j/slf4j-log4j12/1.6.1/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: See [http://www.slf4j.org/codes.html#multiple_bindings] for an 
explanation.
 SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
 createDanglingTransaction txid: 
XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]
 createXATransaction txid: XID:[55,globalId=15333ec,branchId=15333ec]
 Pending Transactions 1: 
[XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]]
  INFO | I/O exception (org.apache.http.NoHttpResponseException) caught when 
processing request to {}->[http://localhost:8161:] The target server failed to 
respond
  INFO | Retrying request to {}->[http://localhost:8161|http://localhost:8161/]
 Pending Transactions 2: 
[XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1],
 XID:[55,globalId=15333ec,branchId=15333ec]]
 [INFO] 

In the Broker log you'll see:

 INFO | KahaDB is version 6
  INFO | Recovering from the journal @1:741
  INFO | Recovery replayed 429 operations from the journal in 0.081 seconds.
  WARN | Recovered prepared XA TX: 
[XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]]
  WARN | Recovered prepared XA TX: 
[XID:[55,globalId=15333ec,branchId=15333ec]]
  
 On JConsole you'll see two messages in org.apache.activemq > Broker > 
RecoveredXaTransaction MBean.

Given we commit the transaction, I'd expect there to not be a message in 
Recovered state.

Note:  If we do not send additional messages to force a new page file, than we 
do not see the message in Recovered state after broker restart.

It appears to be that the prepared statement in db-1.log,. and commit in 
db-2.log will result in the commit getting GC'd (hence no pare to match) and 
having the message being seen as being in prepared state, and hence getting 
recovered.


was (Author: jgoodyear):
I've attached a stand alone test case to reproduce the issue.

Here's how to use the test case:

0. Setup AMQ 5.15.6 broker on local system. Use default configuration, no 
special settings required. Start broker.
 1. Extract AMQ7067 zip file.
2. Run XATransactionTest while Broker is live using :  mvn clean compile 
exec:java -Dexec.mainClass="XATransactionTest"

The test case will output:

[INFO] — exec-maven-plugin:1.6.0:java (default-cli) @ transaction —
 SLF4J: Class path contains multiple SLF4J bindings.
 SLF4J: Found binding in 
[jar:file:/Users/icbts/.m2/repository/org/apache/activemq/activemq-all/5.15.6/activemq-all-5.15.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: Found binding in 
[jar:file:/Users/icbts/.m2/repository/org/slf4j/slf4j-log4j12/1.6.1/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: See [http://www.slf4j.org/codes.html#multiple_bindings] for an 
explanation.
 SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
 createDanglingTransaction txid: 
XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]
 createXATransaction txid: XID:[55,globalId=15333ec,branchId=15333ec]
 Pending Transactions 1:

[jira] [Updated] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

2018-10-04 Thread Jamie goodyear (JIRA)



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

Jamie goodyear updated AMQ-7067:

Attachment: (was: AMQ7067.zip)

> KahaDB Recovery can experience a dangling transaction when prepare and commit 
> occur on different pagefiles.
> ---
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit 
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with 
> 512 * 1024 characters in message payload). This forces a new pagefile to be 
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it 
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is 
> GC'd, hence the prepare & commit can not be matched. 
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}] 
> != {color:#cc7832}null{color}) {
>  {color:#cc7832}for {color}({color:#cc7832}int 
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
>  {color}pendingTx <= 
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832}; 
> {color}pendingTx++) {
>  gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles 
> with respect to GCing files.



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

[jira] [Commented] (ARTEMIS-2110) JDBC LeaseLocker repeated renew or renew after aquire can fail in error

2018-10-04 Thread ASF GitHub Bot (JIRA)



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

ASF GitHub Bot commented on ARTEMIS-2110:
-

GitHub user gtully opened a pull request:

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

ARTEMIS-2110 allow a lease renew without update to the expiry timesta…

…mp. Fix intermittent failure of 
org.apache.activemq.artemis.core.server.impl.jdbc.JdbcLeaseLockTest#shouldRenewAcquiredLock

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

$ git pull https://github.com/gtully/activemq-artemis ARTEMIS-2110

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

https://github.com/apache/activemq-artemis/pull/2346.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 #2346


commit ddf0cac2d7531dc49484c283a7f4cbe44d8e278e
Author: gtully 
Date:   2018-10-04T15:47:16Z

ARTEMIS-2110 allow a lease renew without update to the expiry timestamp. 
Fix intermittent failure of 
org.apache.activemq.artemis.core.server.impl.jdbc.JdbcLeaseLockTest#shouldRenewAcquiredLock




> JDBC LeaseLocker repeated renew or renew after aquire can fail in error
> ---
>
> Key: ARTEMIS-2110
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2110
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.6.3
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Minor
> Fix For: 2.7.0
>
>
> There is an intermittent failure in:
> org.apache.activemq.artemis.core.server.impl.jdbc.JdbcLeaseLockTest#shouldRenewAcquiredLock
> (seems to block pr ci, and reproduced for me 20% of the time)
> if the db currentTime has not moved on, using the same lease time results in 
> a failure. A renew immediately after acquiring the lock is a sensible pattern 
> to verify the aquire. 
>  
> The lock renew needs >= in place or > on the WHERE clause to allow an 
> 'identity' lease to succeed.



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

[jira] [Comment Edited] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

2018-10-04 Thread Jamie goodyear (JIRA)



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

Jamie goodyear edited comment on AMQ-7067 at 10/4/18 3:53 PM:
--

I've attached a stand alone test case to reproduce the issue.

Here's how to use the test case:

0. Setup AMQ 5.15.6 broker on local system. Use default configuration, no 
special settings required. Start broker.
 1. Extract AMQ7067 zip file.
2. Run XATransactionTest while Broker is live using :  mvn clean compile 
exec:java -Dexec.mainClass="XATransactionTest"

The test case will output:

[INFO] — exec-maven-plugin:1.6.0:java (default-cli) @ transaction —
 SLF4J: Class path contains multiple SLF4J bindings.
 SLF4J: Found binding in 
[jar:file:/Users/icbts/.m2/repository/org/apache/activemq/activemq-all/5.15.6/activemq-all-5.15.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: Found binding in 
[jar:file:/Users/icbts/.m2/repository/org/slf4j/slf4j-log4j12/1.6.1/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
 SLF4J: See [http://www.slf4j.org/codes.html#multiple_bindings] for an 
explanation.
 SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
 createDanglingTransaction txid: 
XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]
 createXATransaction txid: XID:[55,globalId=15333ec,branchId=15333ec]
 Pending Transactions 1: 
[XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]]
  INFO | I/O exception (org.apache.http.NoHttpResponseException) caught when 
processing request to {}->[http://localhost:8161:] The target server failed to 
respond
  INFO | Retrying request to {}->[http://localhost:8161|http://localhost:8161/]
 Pending Transactions 2: 
[XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1],
 XID:[55,globalId=15333ec,branchId=15333ec]]
 [INFO] 

In the Broker log you'll see:

 INFO | KahaDB is version 6
  INFO | Recovering from the journal @1:741
  INFO | Recovery replayed 429 operations from the journal in 0.081 seconds.
  WARN | Recovered prepared XA TX: 
[XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]]
  WARN | Recovered prepared XA TX: 
[XID:[55,globalId=15333ec,branchId=15333ec]]
  
 On JConsole you'll see two messages in org.apache.activemq > Broker > 
RecoveredXaTransaction MBean.

Given we commit the transaction, I'd expect there to not be a message in 
Recovered state.

Note:  If we do not send additional messages to force a new page file, than we 
do not see the message in Recovered state after broker restart.

It appears to be that the prepared statement in db-1.log,. and commit in 
db-2.log will result in the commit getting GC'd (hence no pare to match) and 
having the message being seen as being in prepared state, and hence getting 
recovered.


was (Author: jgoodyear):
I've attached a stand alone test case to reproduce the issue.

Here's how to use the test case:

0. Setup AMQ 5.15.6 broker on local system. Use default configuration, no 
special settings required. Start broker.
1. Extract AMQ7067 zip file.
2. Use maven to build the test case.
3. Run XATransactionTest while Broker is live using :  mvn clean compile 
exec:java -Dexec.mainClass="XATransactionTest"

The test case will output:


[INFO] --- exec-maven-plugin:1.6.0:java (default-cli) @ transaction ---
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:/Users/icbts/.m2/repository/org/apache/activemq/activemq-all/5.15.6/activemq-all-5.15.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:/Users/icbts/.m2/repository/org/slf4j/slf4j-log4j12/1.6.1/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
createDanglingTransaction txid: 
XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]
createXATransaction txid: XID:[55,globalId=15333ec,branchId=15333ec]
Pending Transactions 1: 
[XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]]
 INFO | I/O exception (org.apache.http.NoHttpResponseException) caught when 
processing request to {}->http://localhost:8161: The target

[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

2018-10-04 Thread Jamie goodyear (JIRA)



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

Jamie goodyear commented on AMQ-7067:
-

I've attached a stand alone test case to reproduce the issue.

Here's how to use the test case:

0. Setup AMQ 5.15.6 broker on local system. Use default configuration, no 
special settings required. Start broker.
1. Extract AMQ7067 zip file.
2. Use maven to build the test case.
3. Run XATransactionTest while Broker is live using :  mvn clean compile 
exec:java -Dexec.mainClass="XATransactionTest"

The test case will output:


[INFO] --- exec-maven-plugin:1.6.0:java (default-cli) @ transaction ---
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:/Users/icbts/.m2/repository/org/apache/activemq/activemq-all/5.15.6/activemq-all-5.15.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:/Users/icbts/.m2/repository/org/slf4j/slf4j-log4j12/1.6.1/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
createDanglingTransaction txid: 
XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]
createXATransaction txid: XID:[55,globalId=15333ec,branchId=15333ec]
Pending Transactions 1: 
[XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]]
 INFO | I/O exception (org.apache.http.NoHttpResponseException) caught when 
processing request to {}->http://localhost:8161: The target server failed to 
respond
 INFO | Retrying request to {}->http://localhost:8161
Pending Transactions 2: 
[XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1],
 XID:[55,globalId=15333ec,branchId=15333ec]]
[INFO] 

In the Broker log you'll see:

 INFO | KahaDB is version 6
 INFO | Recovering from the journal @1:741
 INFO | Recovery replayed 429 operations from the journal in 0.081 seconds.
 WARN | Recovered prepared XA TX: 
[XID:[55,globalId=ffe9ffb8fff7ffa1,branchId=ffe9ffb8fff7ffa1]]
 WARN | Recovered prepared XA TX: 
[XID:[55,globalId=15333ec,branchId=15333ec]]
 
On JConsole you'll see two messages in org.apache.activemq > Broker > 
RecoveredXaTransaction MBean.

Given we commit the transaction, I'd expect there to not be a message in 
Recovered state.

Note:  If we do not send additional messages to force a new page file, than we 
do not see the message in Recovered state after broker restart.

It appears to be that the prepared statement in db-1.log,. and commit in 
db-2.log will result in the commit getting GC'd (hence no pare to match) and 
having the message being seen as being in prepared state, and hence getting 
recovered.

> KahaDB Recovery can experience a dangling transaction when prepare and commit 
> occur on different pagefiles.
> ---
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: AMQ7067.zip
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit 
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with 
> 512 * 1024 characters in message payload). This forces a new pagefile to be 
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it 
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is 
> GC'd, hence the prepare & commit can not be matched. 
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}] 
> != {color:#cc7832}null{color}) {
>  {color:#cc7832}for {color}({color:#cc7832}int 
>

[jira] [Created] (ARTEMIS-2110) JDBC LeaseLocker repeated renew or renew after aquire can fail in error

2018-10-04 Thread Gary Tully (JIRA)

Gary Tully created ARTEMIS-2110:
---

 Summary: JDBC LeaseLocker repeated renew or renew after aquire can 
fail in error
 Key: ARTEMIS-2110
 URL: https://issues.apache.org/jira/browse/ARTEMIS-2110
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 2.6.3
Reporter: Gary Tully
Assignee: Gary Tully
 Fix For: 2.7.0


There is an intermittent failure in:

org.apache.activemq.artemis.core.server.impl.jdbc.JdbcLeaseLockTest#shouldRenewAcquiredLock

(seems to block pr ci, and reproduced for me 20% of the time)

if the db currentTime has not moved on, using the same lease time results in a 
failure. A renew immediately after acquiring the lock is a sensible pattern to 
verify the aquire. 

 

The lock renew needs >= in place or > on the WHERE clause to allow an 
'identity' lease to succeed.



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

[jira] [Updated] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

2018-10-04 Thread Jamie goodyear (JIRA)



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

Jamie goodyear updated AMQ-7067:

Attachment: AMQ7067.zip

> KahaDB Recovery can experience a dangling transaction when prepare and commit 
> occur on different pagefiles.
> ---
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: AMQ7067.zip
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit 
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with 
> 512 * 1024 characters in message payload). This forces a new pagefile to be 
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it 
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is 
> GC'd, hence the prepare & commit can not be matched. 
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}] 
> != {color:#cc7832}null{color}) {
>  {color:#cc7832}for {color}({color:#cc7832}int 
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
>  {color}pendingTx <= 
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832}; 
> {color}pendingTx++) {
>  gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles 
> with respect to GCing files.



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

[jira] [Created] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

2018-10-04 Thread Jamie goodyear (JIRA)

Jamie goodyear created AMQ-7067:
---

 Summary: KahaDB Recovery can experience a dangling transaction 
when prepare and commit occur on different pagefiles.
 Key: AMQ-7067
 URL: https://issues.apache.org/jira/browse/AMQ-7067
 Project: ActiveMQ
  Issue Type: Bug
  Components: KahaDB, XA
Affects Versions: 5.15.6
Reporter: Jamie goodyear
 Fix For: 5.16.0, 5.15.7


KahaDB Recovery can experience a dangling transaction when prepare and commit 
occur on different pagefiles.

Scenario:

A XA Transaction is started, message is prepared and sent into Broker.

We then send into broker enough messages to file page file (100 message with 
512 * 1024 characters in message payload). This forces a new pagefile to be 
created.

Commit the XA transaction. Commit will land on the new page file.

Restart the Broker.

Upon restart a KahaDB recovery is executed.

The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it 
will appear in recovered message state.

Looking deeper into this scenario, it appears that the commit message is GC'd, 
hence the prepare & commit can not be matched. 

The MessageDatabase only checks the following for GC:

{color:#808080}// Don't GC files referenced by in-progress tx
{color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}] != 
{color:#cc7832}null{color}) {
 {color:#cc7832}for {color}({color:#cc7832}int 
{color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
 {color}pendingTx <= 
inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832}; 
{color}pendingTx++) {
 gcCandidateSet.remove(pendingTx){color:#cc7832};
{color} }
}

We need to become aware of where the prepare & commits occur in pagefiles with 
respect to GCing files.



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

[jira] [Commented] (ARTEMIS-1980) Warn on failed check of table existence should be info

2018-10-04 Thread ASF GitHub Bot (JIRA)



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

ASF GitHub Bot commented on ARTEMIS-1980:
-

Github user franz1981 commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/2181#discussion_r222663365
  
--- Diff: 
artemis-jdbc-store/src/main/java/org/apache/activemq/artemis/jdbc/store/drivers/AbstractJDBCDriver.java
 ---
@@ -227,7 +227,11 @@ private void createTableIfNotExists(String tableName, 
String... sqls) throws SQL
   }
}
 } catch (SQLException e) {
-   logger.warn(JDBCUtils.appendSQLExceptionDetails(new 
StringBuilder("Can't verify the initialization of table 
").append(tableName).append(" due to:"), e, 
sqlProvider.getCountJournalRecordsSQL()));
+   if (logger.isDebugEnabled()) {
--- End diff --

I have addressed it maintaining the relevant information about the error 
only on trace level :+1: 


> Warn on failed check of table existence should be info
> --
>
> Key: ARTEMIS-1980
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1980
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.6.2
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Trivial
> Fix For: 2.7.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> DB2 metadata checks should erroneously report stale table existence on
> not existing/just deleted table, making the subsequent warning logs of failed
> SELECT COUNT useless and scaring: should be better to let them lowered to 
> INFO level, avoiding users log reporting tools (if any) to react to an 
> expected behaviour.
>  



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

[jira] [Commented] (ARTEMIS-2103) VirtualTopic doesn't work correctly with multiple consumers

2018-10-04 Thread ASF GitHub Bot (JIRA)



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

ASF GitHub Bot commented on ARTEMIS-2103:
-

Github user gtully commented on the issue:

https://github.com/apache/activemq-artemis/pull/2341
  
going to try again, the tests that fails is lease.tryAquire/renew which 
seems to be b/c it happens in the same millisecond. Will work on a fix for that.


> VirtualTopic doesn't work correctly with multiple consumers
> ---
>
> Key: ARTEMIS-2103
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2103
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker, OpenWire
>Affects Versions: 2.6.3
>Reporter: Pawel
>Assignee: Gary Tully
>Priority: Major
>
> It's impossibe to subscribe multiple virtual topics with the same consumer 
> name.
> I've configured acceptor like described in documentation:
> {code:java}
> tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;virtualTopicConsumerWildcards=Consumer.*.%3E%3B2{code}
> When I'm connecting first consumer:  
> *Consumer.cons1.VirtualTopic.t1*
> proper binding is created.
> Next I'm trying to connect second consumer with the same name:
> *Consumer.cons1.VirtualTopic.t2*
> But no binding is created.



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

[jira] [Commented] (ARTEMIS-2103) VirtualTopic doesn't work correctly with multiple consumers

2018-10-04 Thread ASF GitHub Bot (JIRA)



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

ASF GitHub Bot commented on ARTEMIS-2103:
-

GitHub user gtully reopened a pull request:

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

ARTEMIS-2103 - use the full openwire consumer queue for the mapped vi…

…rtual topic queue binding, fix and test

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

$ git pull https://github.com/gtully/activemq-artemis ARTEMIS-2103

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

https://github.com/apache/activemq-artemis/pull/2341.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 #2341


commit 6281101971bdbc32f8932738b59f01cf3adfbd0d
Author: gtully 
Date:   2018-10-03T12:24:42Z

ARTEMIS-2103 - use the full openwire consumer queue for the mapped virtual 
topic queue binding, fix and test




> VirtualTopic doesn't work correctly with multiple consumers
> ---
>
> Key: ARTEMIS-2103
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2103
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker, OpenWire
>Affects Versions: 2.6.3
>Reporter: Pawel
>Assignee: Gary Tully
>Priority: Major
>
> It's impossibe to subscribe multiple virtual topics with the same consumer 
> name.
> I've configured acceptor like described in documentation:
> {code:java}
> tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;virtualTopicConsumerWildcards=Consumer.*.%3E%3B2{code}
> When I'm connecting first consumer:  
> *Consumer.cons1.VirtualTopic.t1*
> proper binding is created.
> Next I'm trying to connect second consumer with the same name:
> *Consumer.cons1.VirtualTopic.t2*
> But no binding is created.



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

[jira] [Commented] (ARTEMIS-2103) VirtualTopic doesn't work correctly with multiple consumers

2018-10-04 Thread ASF GitHub Bot (JIRA)



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

ASF GitHub Bot commented on ARTEMIS-2103:
-

Github user gtully closed the pull request at:

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


> VirtualTopic doesn't work correctly with multiple consumers
> ---
>
> Key: ARTEMIS-2103
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2103
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker, OpenWire
>Affects Versions: 2.6.3
>Reporter: Pawel
>Assignee: Gary Tully
>Priority: Major
>
> It's impossibe to subscribe multiple virtual topics with the same consumer 
> name.
> I've configured acceptor like described in documentation:
> {code:java}
> tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;virtualTopicConsumerWildcards=Consumer.*.%3E%3B2{code}
> When I'm connecting first consumer:  
> *Consumer.cons1.VirtualTopic.t1*
> proper binding is created.
> Next I'm trying to connect second consumer with the same name:
> *Consumer.cons1.VirtualTopic.t2*
> But no binding is created.



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

[jira] [Created] (ARTEMIS-2109) Cannot build Artemis with JDK 11

2018-10-04 Thread Miroslav Novak (JIRA)

Miroslav Novak created ARTEMIS-2109:
---

 Summary: Cannot build Artemis with JDK 11
 Key: ARTEMIS-2109
 URL: https://issues.apache.org/jira/browse/ARTEMIS-2109
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 2.6.3
Reporter: Miroslav Novak


Artemis cannot be build with JDK 11:
{code}
$ java -version
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
{code}

Build fails with:
{code}
$ mvn clean install
...
[INFO] 
[INFO] Building ActiveMQ Artemis Parent 2.7.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ artemis-pom ---
[INFO] Deleting /home/mnovak/projects/activemq-artemis/target
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4:enforce (enforce-maven) @ artemis-pom ---
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4:enforce (enforce-java) @ artemis-pom ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] ActiveMQ Artemis Parent  FAILURE [  0.302 s]
[INFO] ActiveMQ Artemis Commons ... SKIPPED
[INFO] ActiveMQ Artemis Core Client ... SKIPPED
[INFO] ActiveMQ Artemis Selector Implementation ... SKIPPED
[INFO] ActiveMQ Artemis JMS Client  SKIPPED
[INFO] ActiveMQ Artemis Native POM  SKIPPED
[INFO] ActiveMQ Artemis Journal ... SKIPPED
[INFO] ActiveMQ Artemis JDBC Store  SKIPPED
[INFO] ActiveMQ Artemis Server  SKIPPED
[INFO] ActiveMQ Artemis Protocols . SKIPPED
[INFO] ActiveMQ Artemis AMQP Protocol . SKIPPED
[INFO] ActiveMQ Artemis STOMP Protocol  SKIPPED
[INFO] ActiveMQ Artemis OpenWire Protocol . SKIPPED
[INFO] ActiveMQ Artemis HQClient Protocol . SKIPPED
[INFO] ActiveMQ Artemis HornetQ Protocol .. SKIPPED
[INFO] ActiveMQ Artemis MQTT Protocol . SKIPPED
[INFO] ActiveMQ Artemis DTO ... SKIPPED
[INFO] ActiveMQ Artemis Service Extensions  SKIPPED
[INFO] ActiveMQ Artemis JMS Server  SKIPPED
[INFO] ActiveMQ Artemis CDI Integration ... SKIPPED
[INFO] ActiveMQ Artemis Boot .. SKIPPED
[INFO] ActiveMQ Artemis Tools . SKIPPED
[INFO] ActiveMQ Artemis CLI ... SKIPPED
[INFO] ActiveMQ Artemis Web ... SKIPPED
[INFO] ActiveMQ Artemis Web ... SKIPPED
[INFO] ActiveMQ Artemis Core Client All ... SKIPPED
[INFO] ActiveMQ Artemis Client OSGi ... SKIPPED
[INFO] ActiveMQ Artemis JUnit Rules ... SKIPPED
[INFO] ActiveMQ Artemis JMS Client All  SKIPPED
[INFO] ActiveMQ Artemis JMS Client OSGi ... SKIPPED
[INFO] ActiveMQ Artemis RAR POM ... SKIPPED
[INFO] ActiveMQ Artemis REST Interface Implementation . SKIPPED
[INFO] ActiveMQ Artemis Maven Plugin .. SKIPPED
[INFO] ActiveMQ Artemis Server OSGi ... SKIPPED
[INFO] ActiveMQ Artemis Cons .. SKIPPED
[INFO] ActiveMQ Artemis HawtIO Branding ... SKIPPED
[INFO] ActiveMQ Artemis HawtIO Plugin . SKIPPED
[INFO] ActiveMQ Artemis Console ... SKIPPED
[INFO] ActiveMQ Artemis Spring Integration  SKIPPED
[INFO] Apache ActiveMQ Artemis Distribution ... SKIPPED
[INFO] ActiveMQ Artemis Tests POM . SKIPPED
[INFO] ActiveMQ Artemis Test Support .. SKIPPED
[INFO] ActiveMQ Artemis Unit Tests  SKIPPED
[INFO] ActiveMQ Artemis Joram Tests ... SKIPPED
[INFO] ActiveMQ Artemis timing Tests .. SKIPPED
[INFO] ActiveMQ Artemis JMS Tests . SKIPPED
[INFO] ActiveMQ Artemis Features .. SKIPPED
[INFO] ActiveMQ Artemis Integration Tests . SKIPPED
[INFO] ActiveMQ Artemis Client Integration Tests .. SKIPPED
[INFO] ActiveMQ Artemis Compatibility Tests ... SKIPPED
[INFO] ActiveMQ Artemis soak Tests  SKIPPED
[INFO] ActiveMQ Artemis stress Tests .. SKIPPED
[INFO] ActiveMQ Artemis performance Tests . SKIPPED
[INFO] Smoke Tests  SKIPPED
[INFO]

[jira] [Commented] (ARTEMIS-2104) Implement tests for Import/Export (replay) of messages

2018-10-04 Thread ASF GitHub Bot (JIRA)



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

ASF GitHub Bot commented on ARTEMIS-2104:
-

Github user michalxo commented on the issue:

https://github.com/apache/activemq-artemis/pull/2260
  
Can this be merged now?


> Implement tests for Import/Export (replay) of messages
> --
>
> Key: ARTEMIS-2104
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2104
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: Broker
>Reporter: Oleg Sushchenko
>Priority: Major
>




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

[jira] [Updated] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

[jira] [Comment Edited] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

[jira] [Updated] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

[jira] [Commented] (ARTEMIS-2110) JDBC LeaseLocker repeated renew or renew after aquire can fail in error

[jira] [Comment Edited] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

[jira] [Created] (ARTEMIS-2110) JDBC LeaseLocker repeated renew or renew after aquire can fail in error

[jira] [Updated] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

[jira] [Created] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.

[jira] [Commented] (ARTEMIS-1980) Warn on failed check of table existence should be info

[jira] [Commented] (ARTEMIS-2103) VirtualTopic doesn't work correctly with multiple consumers

[jira] [Commented] (ARTEMIS-2103) VirtualTopic doesn't work correctly with multiple consumers

[jira] [Commented] (ARTEMIS-2103) VirtualTopic doesn't work correctly with multiple consumers

[jira] [Created] (ARTEMIS-2109) Cannot build Artemis with JDK 11

[jira] [Commented] (ARTEMIS-2104) Implement tests for Import/Export (replay) of messages

15 matches

Site Navigation

Mail list logo

Footer information