[jira] [Commented] (AMQ-7052) Fix tests related to purgeRecoveredXATransactions property on the KahaDB
[ https://issues.apache.org/jira/browse/AMQ-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619926#comment-16619926 ] Alan Protasio commented on AMQ-7052: Thanks! :D > Fix tests related to purgeRecoveredXATransactions property on the KahaDB > > > Key: AMQ-7052 > URL: https://issues.apache.org/jira/browse/AMQ-7052 > Project: ActiveMQ > Issue Type: Test > Components: Test Cases >Affects Versions: 5.15.5, 5.15.6 >Reporter: Alan Protasio >Assignee: Gary Tully >Priority: Minor > Fix For: 5.16.0 > > > Fix the following tests: > JdbcXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > JdbcXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeCommitOnRestart:391 > null > mKahaDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > mKahaDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeCommitOnRestart:391 > null > mLevelDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > Those tests are failing because this feature (purge transactions after > reboot) was only implemented on the KahaDBPersistenceAdapter. > [https://github.com/apache/activemq/commit/ce7498c971b99e2515f07aab36418a1a0f19c03e] > The tests are failing because the class XARecoveryBrokerTest is used to test > multiples adapters that are not implementing the same feature. > Steps to reproduce: > > git checkout [https://github.com/apache/activemq/tree/activemq-5.15.x] > > cd activemq-unit-tests > > mvn clean install -Dtest=JdbcXARecoveryBrokerTest > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (AMQ-7028) Poor performance when concurrentStoreAndDispatchQueues + slow FS + Slow Consumers
[ https://issues.apache.org/jira/browse/AMQ-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619844#comment-16619844 ] Alan Protasio edited comment on AMQ-7028 at 9/19/18 12:47 AM: -- [~gtully] Hey... Can you merge this change to the 5.15.x branch? [https://github.com/apache/activemq/commit/4c972d97b95ea521493db5def6869eab663e5f64] This is fixing some tests.. I got to the same fix but then I saw that this is already fixed in the master branch! =p https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-unit-tests/src/test/java/org/apache/activemq/store/kahadb/AbstractMultiKahaDBDeletionTest.java#L179 And also I noticed that "When XA transactions has more than one destination, only the ack from the fist destination is rolled back". This is because this line: [https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/KahaDBStore.java#L615] All KahaDBMessageStore share the same instance of rolledBackAcks set - This is defined in MessageDatabase that KahaDBStore inherit - and when the first destination is rolled back it clear this set. https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java#L3040 Comparing again with the master, I noticed that this propriety is not defined anymore on kahaDbStore (MessageDatabase). This was moved to the KahaDBMessageStore and so this problem is fixed [https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/KahaDBStore.java#L421] This was the change that I cherry picked from master and solve the issue. [https://github.com/apache/activemq/commit/ea70e827c049cee9d455303a8cdb31a64b23763d#diff-e3b8fff8c2133dfd70999705bbb558b3] We dont have test for it, but if we add one destination in the kahadb test we can see this happening: [https://github.com/apache/activemq/blob/activemq-5.15.x/activemq-unit-tests/src/test/java/org/apache/activemq/broker/KahaDBXARecoveryBrokerTest.java#L36] was (Author: alanprot): [~gtully] Hey... Can you merge this change to the 5.15.x branch? [https://github.com/apache/activemq/commit/4c972d97b95ea521493db5def6869eab663e5f64] This is fixing some tests.. I got to the same fix but then I saw that this is already fixed in the master branch! =p > Poor performance when concurrentStoreAndDispatchQueues + slow FS + Slow > Consumers > - > > Key: AMQ-7028 > URL: https://issues.apache.org/jira/browse/AMQ-7028 > Project: ActiveMQ > Issue Type: Improvement > Components: KahaDB >Affects Versions: 5.15.4 >Reporter: Alan Protasio >Priority: Major > > Using high latency FS (as NFS) to store kahadb files and setting > concurrentStoreAndDispatchQueues=true may cause poor performance for slow > consumer. This happens because using this option makes activemq write the > produced messages one by one to the underlying file system (this is > implemented by using a SingleThread ExecutorService). > Lets say that for each write to the FS takes 10ms and the queue has slow > consumers. In this case, does not matter the number of concurrent messages > the producers try to send to the queue, the maximum performance we can > achieve is 100 TPS. Tuning this flag off, we can see a really better > performance for sending messages in parallel as those messages can be batched > to the FS in a single write (the performance increases with the number of > concurrent messages being sent in parallel). > Looking at Activemq code we found that there is an flag used on levelDb to > detect if the queue has fast or slow consumers, and decide if it will use > concurrentStoreAndDispach or not. > https://issues.apache.org/jira/browse/AMQ-3750 > but this flag is not used on the KahaDb implementation. > We made a code change to receive the flag in the KahaDbStore and use it to > decide if the message will be stored async or not. > We think that there is no reason to try to "StoreAndDispatch" if the > destination has slow consumers. This only brings overhead and in case of high > latency FS, really poor performance when the queue has slow consumer. > For fast consumers, this change will have no effect giving the better of the > 2 options. > Some Results: > Original Version: > Fast Consumers: > Producer > mean rate = 8248.50 calls/second > min = 0.42 milliseconds > max = 756.61 milliseconds > mean = 11.30 milliseconds > stddev = 44.05 milliseconds > median = 6.02 milliseconds > 75% <= 9.79 milliseconds > 95% <= 18.15 milliseconds > 98% <= 27.71 milliseconds > 99% <= 123.51 milliseconds > 99.9% <= 756.61 milliseconds > Slow consumers: > Producer > mean rate =
[jira] [Commented] (AMQ-7028) Poor performance when concurrentStoreAndDispatchQueues + slow FS + Slow Consumers
[ https://issues.apache.org/jira/browse/AMQ-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619844#comment-16619844 ] Alan Protasio commented on AMQ-7028: [~gtully] Hey... Can you merge this change to the 5.15.x branch? [https://github.com/apache/activemq/commit/4c972d97b95ea521493db5def6869eab663e5f64] This is fixing some tests.. I got to the same fix but then I saw that this is already fixed in the master branch! =p > Poor performance when concurrentStoreAndDispatchQueues + slow FS + Slow > Consumers > - > > Key: AMQ-7028 > URL: https://issues.apache.org/jira/browse/AMQ-7028 > Project: ActiveMQ > Issue Type: Improvement > Components: KahaDB >Affects Versions: 5.15.4 >Reporter: Alan Protasio >Priority: Major > > Using high latency FS (as NFS) to store kahadb files and setting > concurrentStoreAndDispatchQueues=true may cause poor performance for slow > consumer. This happens because using this option makes activemq write the > produced messages one by one to the underlying file system (this is > implemented by using a SingleThread ExecutorService). > Lets say that for each write to the FS takes 10ms and the queue has slow > consumers. In this case, does not matter the number of concurrent messages > the producers try to send to the queue, the maximum performance we can > achieve is 100 TPS. Tuning this flag off, we can see a really better > performance for sending messages in parallel as those messages can be batched > to the FS in a single write (the performance increases with the number of > concurrent messages being sent in parallel). > Looking at Activemq code we found that there is an flag used on levelDb to > detect if the queue has fast or slow consumers, and decide if it will use > concurrentStoreAndDispach or not. > https://issues.apache.org/jira/browse/AMQ-3750 > but this flag is not used on the KahaDb implementation. > We made a code change to receive the flag in the KahaDbStore and use it to > decide if the message will be stored async or not. > We think that there is no reason to try to "StoreAndDispatch" if the > destination has slow consumers. This only brings overhead and in case of high > latency FS, really poor performance when the queue has slow consumer. > For fast consumers, this change will have no effect giving the better of the > 2 options. > Some Results: > Original Version: > Fast Consumers: > Producer > mean rate = 8248.50 calls/second > min = 0.42 milliseconds > max = 756.61 milliseconds > mean = 11.30 milliseconds > stddev = 44.05 milliseconds > median = 6.02 milliseconds > 75% <= 9.79 milliseconds > 95% <= 18.15 milliseconds > 98% <= 27.71 milliseconds > 99% <= 123.51 milliseconds > 99.9% <= 756.61 milliseconds > Slow consumers: > Producer > mean rate = 84.29 calls/second > min = 86.27 milliseconds > max = 1467.53 milliseconds > mean = 1082.55 milliseconds > stddev = 154.04 milliseconds > median = 1075.94 milliseconds > 75% <= 1169.10 milliseconds > 95% <= 1308.90 milliseconds > 98% <= 1350.85 milliseconds > 99% <= 1363.61 milliseconds > 99.9% <= 1466.67 milliseconds > Patched Version: > Fast Consumers: > Producer > count = 890783 > mean rate = 8099.33 calls/second > min = 0.47 milliseconds > max = 2259.10 milliseconds > mean = 13.90 milliseconds > stddev = 84.84 milliseconds > median = 5.00 milliseconds > 75% <= 9.08 milliseconds > 95% <= 15.66 milliseconds > 98% <= 32.94 milliseconds > 99% <= 355.52 milliseconds > 99.9% <= 731.69 milliseconds > Slow consumers: > Producer > mean rate = 1732.25 calls/second > 1-minute rate = 1811.80 calls/second > min = 17.52 milliseconds > max = 1249.54 milliseconds > mean = 50.95 milliseconds > stddev = 130.68 milliseconds > median = 28.73 milliseconds > 75% <= 32.51 milliseconds > 95% <= 57.04 milliseconds > 98% <= 461.46 milliseconds > 99% <= 937.87 milliseconds > 99.9% <= 1249.48 milliseconds -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7028) Poor performance when concurrentStoreAndDispatchQueues + slow FS + Slow Consumers
[ https://issues.apache.org/jira/browse/AMQ-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619543#comment-16619543 ] ASF GitHub Bot commented on AMQ-7028: - Github user alanprot closed the pull request at: https://github.com/apache/activemq/pull/295 > Poor performance when concurrentStoreAndDispatchQueues + slow FS + Slow > Consumers > - > > Key: AMQ-7028 > URL: https://issues.apache.org/jira/browse/AMQ-7028 > Project: ActiveMQ > Issue Type: Improvement > Components: KahaDB >Affects Versions: 5.15.4 >Reporter: Alan Protasio >Priority: Major > > Using high latency FS (as NFS) to store kahadb files and setting > concurrentStoreAndDispatchQueues=true may cause poor performance for slow > consumer. This happens because using this option makes activemq write the > produced messages one by one to the underlying file system (this is > implemented by using a SingleThread ExecutorService). > Lets say that for each write to the FS takes 10ms and the queue has slow > consumers. In this case, does not matter the number of concurrent messages > the producers try to send to the queue, the maximum performance we can > achieve is 100 TPS. Tuning this flag off, we can see a really better > performance for sending messages in parallel as those messages can be batched > to the FS in a single write (the performance increases with the number of > concurrent messages being sent in parallel). > Looking at Activemq code we found that there is an flag used on levelDb to > detect if the queue has fast or slow consumers, and decide if it will use > concurrentStoreAndDispach or not. > https://issues.apache.org/jira/browse/AMQ-3750 > but this flag is not used on the KahaDb implementation. > We made a code change to receive the flag in the KahaDbStore and use it to > decide if the message will be stored async or not. > We think that there is no reason to try to "StoreAndDispatch" if the > destination has slow consumers. This only brings overhead and in case of high > latency FS, really poor performance when the queue has slow consumer. > For fast consumers, this change will have no effect giving the better of the > 2 options. > Some Results: > Original Version: > Fast Consumers: > Producer > mean rate = 8248.50 calls/second > min = 0.42 milliseconds > max = 756.61 milliseconds > mean = 11.30 milliseconds > stddev = 44.05 milliseconds > median = 6.02 milliseconds > 75% <= 9.79 milliseconds > 95% <= 18.15 milliseconds > 98% <= 27.71 milliseconds > 99% <= 123.51 milliseconds > 99.9% <= 756.61 milliseconds > Slow consumers: > Producer > mean rate = 84.29 calls/second > min = 86.27 milliseconds > max = 1467.53 milliseconds > mean = 1082.55 milliseconds > stddev = 154.04 milliseconds > median = 1075.94 milliseconds > 75% <= 1169.10 milliseconds > 95% <= 1308.90 milliseconds > 98% <= 1350.85 milliseconds > 99% <= 1363.61 milliseconds > 99.9% <= 1466.67 milliseconds > Patched Version: > Fast Consumers: > Producer > count = 890783 > mean rate = 8099.33 calls/second > min = 0.47 milliseconds > max = 2259.10 milliseconds > mean = 13.90 milliseconds > stddev = 84.84 milliseconds > median = 5.00 milliseconds > 75% <= 9.08 milliseconds > 95% <= 15.66 milliseconds > 98% <= 32.94 milliseconds > 99% <= 355.52 milliseconds > 99.9% <= 731.69 milliseconds > Slow consumers: > Producer > mean rate = 1732.25 calls/second > 1-minute rate = 1811.80 calls/second > min = 17.52 milliseconds > max = 1249.54 milliseconds > mean = 50.95 milliseconds > stddev = 130.68 milliseconds > median = 28.73 milliseconds > 75% <= 32.51 milliseconds > 95% <= 57.04 milliseconds > 98% <= 461.46 milliseconds > 99% <= 937.87 milliseconds > 99.9% <= 1249.48 milliseconds -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2091) Add support for hawt.io 2.x
[ https://issues.apache.org/jira/browse/ARTEMIS-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619133#comment-16619133 ] Justin Bertram commented on ARTEMIS-2091: - [~saschavogt], is there a specific reason to move to hawtio 2.x? My understanding is that the plugin architecture in 2.x is quite different from 1.x which would require the console to be essentially rewritten. That's a big chunk of work that probably isn't worth it unless there's a very clear and significant benefit to moving to 2.x. > Add support for hawt.io 2.x > --- > > Key: ARTEMIS-2091 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2091 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Reporter: Sascha Vogt >Priority: Minor > > Currently the provided hawt plugin is using hawt 1.x - this feature is about > implementing (either in parallel or updating the current one) to hawt 2.x -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2091) Add support for hawt.io 2.x
Sascha Vogt created ARTEMIS-2091: Summary: Add support for hawt.io 2.x Key: ARTEMIS-2091 URL: https://issues.apache.org/jira/browse/ARTEMIS-2091 Project: ActiveMQ Artemis Issue Type: Improvement Components: Web Console Reporter: Sascha Vogt Currently the provided hawt plugin is using hawt 1.x - this feature is about implementing (either in parallel or updating the current one) to hawt 2.x -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1991) Document Advanced Destination Options
[ https://issues.apache.org/jira/browse/ARTEMIS-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1991. - Resolution: Fixed > Document Advanced Destination Options > - > > Key: ARTEMIS-1991 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1991 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.7.0 >Reporter: clebert suconic >Assignee: Justin Bertram >Priority: Blocker > Fix For: 2.7.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2089) DB2 sending larger message (1MB) crashes the whole server
[ https://issues.apache.org/jira/browse/ARTEMIS-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618980#comment-16618980 ] ASF GitHub Bot commented on ARTEMIS-2089: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2323 I will close it because it wasn't containing the right commit and it has been already merged > DB2 sending larger message (1MB) crashes the whole server > - > > Key: ARTEMIS-2089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2089 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.7.0, 2.6.4 > > Original Estimate: 96h > Remaining Estimate: 96h > > IBM DB2 requires that BLOB fields with capacity > 1MB should be declared > using specific keywords: otherwise the max available capacity would be ~ 1MB. > By default the JDBC journal will handle a failed append due to a SQL > exception as a critical IO error, shutting down the broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2089) DB2 sending larger message (1MB) crashes the whole server
[ https://issues.apache.org/jira/browse/ARTEMIS-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618981#comment-16618981 ] ASF GitHub Bot commented on ARTEMIS-2089: - Github user franz1981 closed the pull request at: https://github.com/apache/activemq-artemis/pull/2323 > DB2 sending larger message (1MB) crashes the whole server > - > > Key: ARTEMIS-2089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2089 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.7.0, 2.6.4 > > Original Estimate: 96h > Remaining Estimate: 96h > > IBM DB2 requires that BLOB fields with capacity > 1MB should be declared > using specific keywords: otherwise the max available capacity would be ~ 1MB. > By default the JDBC journal will handle a failed append due to a SQL > exception as a critical IO error, shutting down the broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1991) Document Advanced Destination Options
[ https://issues.apache.org/jira/browse/ARTEMIS-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618972#comment-16618972 ] ASF subversion and git services commented on ARTEMIS-1991: -- Commit 5c8fcc19fdeeb64ef471a7d2d2e2a7c859f475bf in activemq-artemis's branch refs/heads/master from [~jbertram] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=5c8fcc1 ] ARTEMIS-1991 document advanced destination options > Document Advanced Destination Options > - > > Key: ARTEMIS-1991 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1991 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.7.0 >Reporter: clebert suconic >Assignee: Justin Bertram >Priority: Blocker > Fix For: 2.7.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1991) Document Advanced Destination Options
[ https://issues.apache.org/jira/browse/ARTEMIS-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618973#comment-16618973 ] ASF GitHub Bot commented on ARTEMIS-1991: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2322 > Document Advanced Destination Options > - > > Key: ARTEMIS-1991 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1991 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.7.0 >Reporter: clebert suconic >Assignee: Justin Bertram >Priority: Blocker > Fix For: 2.7.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2089) DB2 sending larger message (1MB) crashes the whole server
[ https://issues.apache.org/jira/browse/ARTEMIS-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618915#comment-16618915 ] ASF subversion and git services commented on ARTEMIS-2089: -- Commit 31c9d38e47c691f738ab9328a57e5538d5078d3f in activemq-artemis's branch refs/heads/2.6.x from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=31c9d38 ] ARTEMIS-2089 DB2 sending larger message (1MB) crashes the whole server It declares JDBC journal Blobs for IBM DB2 DBMS matching max-blob-size in order to allow to store data with size > 1 MB ie the default BLOB capacity (cherry picked from commit ead9b007579ad83fd6c808243e4c20035d4c4b4d) > DB2 sending larger message (1MB) crashes the whole server > - > > Key: ARTEMIS-2089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2089 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.7.0, 2.6.4 > > Original Estimate: 96h > Remaining Estimate: 96h > > IBM DB2 requires that BLOB fields with capacity > 1MB should be declared > using specific keywords: otherwise the max available capacity would be ~ 1MB. > By default the JDBC journal will handle a failed append due to a SQL > exception as a critical IO error, shutting down the broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2089) DB2 sending larger message (1MB) crashes the whole server
[ https://issues.apache.org/jira/browse/ARTEMIS-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618911#comment-16618911 ] ASF subversion and git services commented on ARTEMIS-2089: -- Commit ead9b007579ad83fd6c808243e4c20035d4c4b4d in activemq-artemis's branch refs/heads/master from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=ead9b00 ] ARTEMIS-2089 DB2 sending larger message (1MB) crashes the whole server It declares JDBC journal Blobs for IBM DB2 DBMS matching max-blob-size in order to allow to store data with size > 1 MB ie the default BLOB capacity > DB2 sending larger message (1MB) crashes the whole server > - > > Key: ARTEMIS-2089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2089 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.7.0, 2.6.4 > > Original Estimate: 96h > Remaining Estimate: 96h > > IBM DB2 requires that BLOB fields with capacity > 1MB should be declared > using specific keywords: otherwise the max available capacity would be ~ 1MB. > By default the JDBC journal will handle a failed append due to a SQL > exception as a critical IO error, shutting down the broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2089) DB2 sending larger message (1MB) crashes the whole server
[ https://issues.apache.org/jira/browse/ARTEMIS-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618912#comment-16618912 ] ASF GitHub Bot commented on ARTEMIS-2089: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2317 > DB2 sending larger message (1MB) crashes the whole server > - > > Key: ARTEMIS-2089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2089 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.7.0, 2.6.4 > > Original Estimate: 96h > Remaining Estimate: 96h > > IBM DB2 requires that BLOB fields with capacity > 1MB should be declared > using specific keywords: otherwise the max available capacity would be ~ 1MB. > By default the JDBC journal will handle a failed append due to a SQL > exception as a critical IO error, shutting down the broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2089) DB2 sending larger message (1MB) crashes the whole server
[ https://issues.apache.org/jira/browse/ARTEMIS-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618871#comment-16618871 ] ASF GitHub Bot commented on ARTEMIS-2089: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2323 @mtaylor Please do not merge it until the one on master will be merged! > DB2 sending larger message (1MB) crashes the whole server > - > > Key: ARTEMIS-2089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2089 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.7.0, 2.6.4 > > Original Estimate: 96h > Remaining Estimate: 96h > > IBM DB2 requires that BLOB fields with capacity > 1MB should be declared > using specific keywords: otherwise the max available capacity would be ~ 1MB. > By default the JDBC journal will handle a failed append due to a SQL > exception as a critical IO error, shutting down the broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2089) DB2 sending larger message (1MB) crashes the whole server
[ https://issues.apache.org/jira/browse/ARTEMIS-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618819#comment-16618819 ] ASF GitHub Bot commented on ARTEMIS-2089: - GitHub user franz1981 opened a pull request: https://github.com/apache/activemq-artemis/pull/2323 ARTEMIS-2089 DB2 sending larger message (1MB) crashes the whole server (cherry picked from commit f7602e520af66ac44d6e8166330e44dcfcda34d1) You can merge this pull request into a Git repository by running: $ git pull https://github.com/franz1981/activemq-artemis ARTEMIS-2089_2.6.x Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2323.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 #2323 commit 514bf57e1011beef128ca13e242ce2ef6978a002 Author: Francesco Nigro Date: 2018-09-14T14:11:44Z ARTEMIS-2089 DB2 sending larger message (1MB) crashes the whole server (cherry picked from commit f7602e520af66ac44d6e8166330e44dcfcda34d1) > DB2 sending larger message (1MB) crashes the whole server > - > > Key: ARTEMIS-2089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2089 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.7.0, 2.6.4 > > Original Estimate: 96h > Remaining Estimate: 96h > > IBM DB2 requires that BLOB fields with capacity > 1MB should be declared > using specific keywords: otherwise the max available capacity would be ~ 1MB. > By default the JDBC journal will handle a failed append due to a SQL > exception as a critical IO error, shutting down the broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMQ-7052) Fix tests related to purgeRecoveredXATransactions property on the KahaDB
[ https://issues.apache.org/jira/browse/AMQ-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-7052. - Resolution: Fixed Fix Version/s: (was: 5.x) 5.16.0 [~alanprot] Thanks for these fixes, much appreciated. > Fix tests related to purgeRecoveredXATransactions property on the KahaDB > > > Key: AMQ-7052 > URL: https://issues.apache.org/jira/browse/AMQ-7052 > Project: ActiveMQ > Issue Type: Test > Components: Test Cases >Affects Versions: 5.15.5, 5.15.6 >Reporter: Alan Protasio >Assignee: Gary Tully >Priority: Minor > Fix For: 5.16.0 > > > Fix the following tests: > JdbcXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > JdbcXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeCommitOnRestart:391 > null > mKahaDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > mKahaDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeCommitOnRestart:391 > null > mLevelDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > Those tests are failing because this feature (purge transactions after > reboot) was only implemented on the KahaDBPersistenceAdapter. > [https://github.com/apache/activemq/commit/ce7498c971b99e2515f07aab36418a1a0f19c03e] > The tests are failing because the class XARecoveryBrokerTest is used to test > multiples adapters that are not implementing the same feature. > Steps to reproduce: > > git checkout [https://github.com/apache/activemq/tree/activemq-5.15.x] > > cd activemq-unit-tests > > mvn clean install -Dtest=JdbcXARecoveryBrokerTest > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (AMQ-7052) Fix tests related to purgeRecoveredXATransactions property on the KahaDB
[ https://issues.apache.org/jira/browse/AMQ-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully reassigned AMQ-7052: --- Assignee: Gary Tully > Fix tests related to purgeRecoveredXATransactions property on the KahaDB > > > Key: AMQ-7052 > URL: https://issues.apache.org/jira/browse/AMQ-7052 > Project: ActiveMQ > Issue Type: Test > Components: Test Cases >Affects Versions: 5.15.5, 5.15.6 >Reporter: Alan Protasio >Assignee: Gary Tully >Priority: Minor > Fix For: 5.x > > > Fix the following tests: > JdbcXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > JdbcXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeCommitOnRestart:391 > null > mKahaDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > mKahaDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeCommitOnRestart:391 > null > mLevelDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > Those tests are failing because this feature (purge transactions after > reboot) was only implemented on the KahaDBPersistenceAdapter. > [https://github.com/apache/activemq/commit/ce7498c971b99e2515f07aab36418a1a0f19c03e] > The tests are failing because the class XARecoveryBrokerTest is used to test > multiples adapters that are not implementing the same feature. > Steps to reproduce: > > git checkout [https://github.com/apache/activemq/tree/activemq-5.15.x] > > cd activemq-unit-tests > > mvn clean install -Dtest=JdbcXARecoveryBrokerTest > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7052) Fix tests related to purgeRecoveredXATransactions property on the KahaDB
[ https://issues.apache.org/jira/browse/AMQ-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618777#comment-16618777 ] ASF subversion and git services commented on AMQ-7052: -- Commit b92aaa2f583e1ef92bd84678701ced43c1d1d9a9 in activemq's branch refs/heads/master from [~alanprot] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=b92aaa2 ] AMQ-7052 - Fix JdbcXARecoveryBrokerTest and mLevelDBXARecoveryBrokerTest tests Signed-off-by: gtully > Fix tests related to purgeRecoveredXATransactions property on the KahaDB > > > Key: AMQ-7052 > URL: https://issues.apache.org/jira/browse/AMQ-7052 > Project: ActiveMQ > Issue Type: Test > Components: Test Cases >Affects Versions: 5.15.5, 5.15.6 >Reporter: Alan Protasio >Priority: Minor > Fix For: 5.x > > > Fix the following tests: > JdbcXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > JdbcXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeCommitOnRestart:391 > null > mKahaDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > mKahaDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeCommitOnRestart:391 > null > mLevelDBXARecoveryBrokerTest>CombinationTestSupport.runBare:107->XARecoveryBrokerTest.testPreparedTransactionRecoveredPurgeRollbackOnRestart:332 > expected:<0> but was:<4> > Those tests are failing because this feature (purge transactions after > reboot) was only implemented on the KahaDBPersistenceAdapter. > [https://github.com/apache/activemq/commit/ce7498c971b99e2515f07aab36418a1a0f19c03e] > The tests are failing because the class XARecoveryBrokerTest is used to test > multiples adapters that are not implementing the same feature. > Steps to reproduce: > > git checkout [https://github.com/apache/activemq/tree/activemq-5.15.x] > > cd activemq-unit-tests > > mvn clean install -Dtest=JdbcXARecoveryBrokerTest > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1919) artemis-core-client TLS SNI and verifyHost operation are not independent
[ https://issues.apache.org/jira/browse/ARTEMIS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618574#comment-16618574 ] ASF subversion and git services commented on ARTEMIS-1919: -- Commit 737fbbab39dc613746136c8fa8d1d957714d2b28 in activemq-artemis's branch refs/heads/2.6.x from [~jbertram] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=737fbba ] ARTEMIS-1919 implement SNI properly (cherry picked from commit c60d17884a42b4bf4cb5e249f8020b19e0725eb6) > artemis-core-client TLS SNI and verifyHost operation are not independent > > > Key: ARTEMIS-1919 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1919 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.0 > Environment: Fedora 27 > OpenJDK 1.8.0_171 > Artemis master i.e. 2.7.0-SNAPSHOT build > OCP 3.9 running the default haproxy implementation >Reporter: Roddie Kieley >Priority: Major > > In testing connecting to the broker using the core client via ./bin/artemis > producer through a haproxy configured with a tls passthrough configuration > that requires sni it is observed that SNI information is not passed unless > verifyHost is true even if sniHost is set on the URI. > It is noted that with sniHost specified at the haproxy waypoint the if > verifyHost=false haproxy bounces the traffic to the no sni backend. If > verifyHost=true then haproxy passes it to the tcp backend and the traffic > reaches the broker at which point the connectivity fails. > As a point of comparison, testing using the Qpid JMS client over AMQP with > verifyHost = false this works without problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1919) artemis-core-client TLS SNI and verifyHost operation are not independent
[ https://issues.apache.org/jira/browse/ARTEMIS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618572#comment-16618572 ] ASF GitHub Bot commented on ARTEMIS-1919: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2315 > artemis-core-client TLS SNI and verifyHost operation are not independent > > > Key: ARTEMIS-1919 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1919 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.0 > Environment: Fedora 27 > OpenJDK 1.8.0_171 > Artemis master i.e. 2.7.0-SNAPSHOT build > OCP 3.9 running the default haproxy implementation >Reporter: Roddie Kieley >Priority: Major > > In testing connecting to the broker using the core client via ./bin/artemis > producer through a haproxy configured with a tls passthrough configuration > that requires sni it is observed that SNI information is not passed unless > verifyHost is true even if sniHost is set on the URI. > It is noted that with sniHost specified at the haproxy waypoint the if > verifyHost=false haproxy bounces the traffic to the no sni backend. If > verifyHost=true then haproxy passes it to the tcp backend and the traffic > reaches the broker at which point the connectivity fails. > As a point of comparison, testing using the Qpid JMS client over AMQP with > verifyHost = false this works without problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1919) artemis-core-client TLS SNI and verifyHost operation are not independent
[ https://issues.apache.org/jira/browse/ARTEMIS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618570#comment-16618570 ] ASF subversion and git services commented on ARTEMIS-1919: -- Commit c60d17884a42b4bf4cb5e249f8020b19e0725eb6 in activemq-artemis's branch refs/heads/master from [~jbertram] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=c60d178 ] ARTEMIS-1919 implement SNI properly > artemis-core-client TLS SNI and verifyHost operation are not independent > > > Key: ARTEMIS-1919 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1919 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.0 > Environment: Fedora 27 > OpenJDK 1.8.0_171 > Artemis master i.e. 2.7.0-SNAPSHOT build > OCP 3.9 running the default haproxy implementation >Reporter: Roddie Kieley >Priority: Major > > In testing connecting to the broker using the core client via ./bin/artemis > producer through a haproxy configured with a tls passthrough configuration > that requires sni it is observed that SNI information is not passed unless > verifyHost is true even if sniHost is set on the URI. > It is noted that with sniHost specified at the haproxy waypoint the if > verifyHost=false haproxy bounces the traffic to the no sni backend. If > verifyHost=true then haproxy passes it to the tcp backend and the traffic > reaches the broker at which point the connectivity fails. > As a point of comparison, testing using the Qpid JMS client over AMQP with > verifyHost = false this works without problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1919) artemis-core-client TLS SNI and verifyHost operation are not independent
[ https://issues.apache.org/jira/browse/ARTEMIS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16618571#comment-16618571 ] ASF subversion and git services commented on ARTEMIS-1919: -- Commit 4cbc3877821f23944dbc22e154b609deafd1789f in activemq-artemis's branch refs/heads/master from andytaylor [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=4cbc387 ] This closes #2315 ARTEMIS-1919 implement SNI properly > artemis-core-client TLS SNI and verifyHost operation are not independent > > > Key: ARTEMIS-1919 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1919 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.0 > Environment: Fedora 27 > OpenJDK 1.8.0_171 > Artemis master i.e. 2.7.0-SNAPSHOT build > OCP 3.9 running the default haproxy implementation >Reporter: Roddie Kieley >Priority: Major > > In testing connecting to the broker using the core client via ./bin/artemis > producer through a haproxy configured with a tls passthrough configuration > that requires sni it is observed that SNI information is not passed unless > verifyHost is true even if sniHost is set on the URI. > It is noted that with sniHost specified at the haproxy waypoint the if > verifyHost=false haproxy bounces the traffic to the no sni backend. If > verifyHost=true then haproxy passes it to the tcp backend and the traffic > reaches the broker at which point the connectivity fails. > As a point of comparison, testing using the Qpid JMS client over AMQP with > verifyHost = false this works without problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
