[GitHub] activemq-artemis pull request #2462: ARTEMIS-2197 Page deleted before transa...
GitHub user gaohoward opened a pull request: https://github.com/apache/activemq-artemis/pull/2462 ARTEMIS-2197 Page deleted before transaction finishes When a receiving transaction is committed in a paging situation, if a page happens to be completed and it will be deleted in a transaction operation (PageCursorTx). The other tx operation RefsOperation needs to access the page (in PageCache) to finish its job. There is a chance that the PageCursorTx removes the page before RefsOperation and it will cause the RefsOperation failed to find a message in a page. (cherry picked from b36dc37c152cabe3a0d9af178db043f842bfcdc0) You can merge this pull request into a Git repository by running: $ git pull https://github.com/gaohoward/activemq-artemis a_26x_2100 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2462.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 #2462 commit 44a0487f8fdb503a8b1ed849b1d0c2e039c133b8 Author: Howard Gao Date: 2018-12-10T05:35:04Z ARTEMIS-2197 Page deleted before transaction finishes When a receiving transaction is committed in a paging situation, if a page happens to be completed and it will be deleted in a transaction operation (PageCursorTx). The other tx operation RefsOperation needs to access the page (in PageCache) to finish its job. There is a chance that the PageCursorTx removes the page before RefsOperation and it will cause the RefsOperation failed to find a message in a page. (cherry picked from b36dc37c152cabe3a0d9af178db043f842bfcdc0) ---
[GitHub] activemq-artemis pull request #2461: ARTEMIS-2202 Improve MSSQL support for ...
GitHub user franz1981 opened a pull request: https://github.com/apache/activemq-artemis/pull/2461 ARTEMIS-2202 Improve MSSQL support for JDBC storage You can merge this pull request into a Git repository by running: $ git pull https://github.com/franz1981/activemq-artemis ARTEMIS-2202 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2461.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 #2461 commit d063b2dcc94a05e6b5324b4a70e1e0c74c48979a Author: Francesco Nigro Date: 2018-12-11T15:51:20Z ARTEMIS-2202 Improve MSSQL support for JDBC storage ---
[GitHub] activemq-artemis pull request #2455: ARTEMIS-2197 Page deleted before transa...
Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2455 ---
[GitHub] activemq-artemis pull request #2460: ARTEMIS-2201 Added tests on DEFAULT_JOU...
GitHub user feuillemorte opened a pull request: https://github.com/apache/activemq-artemis/pull/2460 ARTEMIS-2201 Added tests on DEFAULT_JOURNAL_FILE_OPEN_TIMEOUT value You can merge this pull request into a Git repository by running: $ git pull https://github.com/feuillemorte/activemq-artemis ARTEMIS-2201_default_journal_file_open_timeout Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2460.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 #2460 commit b67a624a5282e263938351ac89c21b01734609cf Author: feuillemorte Date: 2018-12-11T14:05:45Z #ARTEMIS-2201 Added tests on DEFAULT_JOURNAL_FILE_OPEN_TIMEOUT value ---
[GitHub] activemq-artemis issue #2287: ARTEMIS-2069 Backup doesn't activate after sha...
Github user TomasHofman commented on the issue: https://github.com/apache/activemq-artemis/pull/2287 No, if `lockAcquisitionTimeout` is set to -1, it will wait 2 seconds, and then retry the lock. I don't see what you are referring to. There are two situations: * `tryLock(pos)` returns null (= lock is already taken), *this hasn't changed*. * `tryLock(pos)` throws IOException: * If `lockAcquisitionTimeout == -1` it will wait 2 seconds and then retry, forever. * If `lockAcquisitionTimeout != -1`, it will wait 2 seconds or remaining time until timeout and retry, or if remaining time is <= 0 exception is thrown. ---
[GitHub] activemq-artemis issue #2459: ARTEMIS-2200 NPE while dropping/failing large ...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2459 I need to implement a better test for this one, given that is happening with any protocol :+1: ---
[GitHub] activemq-artemis issue #2457: ARTEMIS-2193 Artemis fails on OutOfMemoryError...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2457 I'm closing this one that will be replaced by https://github.com/apache/activemq-artemis/pull/2459 ---
[GitHub] activemq-artemis pull request #2457: ARTEMIS-2193 Artemis fails on OutOfMemo...
Github user franz1981 closed the pull request at: https://github.com/apache/activemq-artemis/pull/2457 ---
[GitHub] activemq-artemis pull request #2459: ARTEMIS-2200 NPE while dropping/failing...
GitHub user franz1981 opened a pull request: https://github.com/apache/activemq-artemis/pull/2459 ARTEMIS-2200 NPE while dropping/failing large messages on paging Large messages pendingRecordID is not accessed atomically, leading to races that would lead to records that cannot been found on the journal for deletion: it would lead to cause NPE that won't clean the pending tasks on the current OperationContextImpl. Adding a cleanup on error of those tasks and avoiding the race to happen by adding proper synchronization will both enforce correct clean up when something bad happen and avoid NPE. You can merge this pull request into a Git repository by running: $ git pull https://github.com/franz1981/activemq-artemis ARTEMIS-2200 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2459.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 #2459 commit 47e17ee754044ec1b2bcf0f1712f71a994ed0009 Author: Francesco Nigro Date: 2018-12-07T08:35:08Z ARTEMIS-2200 NPE while dropping/failing large messages on paging Large messages pendingRecordID is not accessed atomically, leading to races that would lead to records that cannot been found on the journal for deletion: it would lead to cause NPE that won't clean the pending tasks on the current OperationContextImpl. Adding a cleanup on error of those tasks and avoiding the race to happen by adding proper synchronization will both enforce correct clean up when something bad happen and avoid NPE. ---
