[jira] [Commented] (AMQ-7132) ActiveMQ reads lots of index pages upon startup (after a graceful or ungraceful shutdown)
[
https://issues.apache.org/jira/browse/AMQ-7132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743471#comment-16743471
]
Jamie goodyear commented on AMQ-7132:
-
Those tests passed for me as well.
---
T E S T S
---
Running org.apache.activemq.broker.RecoveryStatsBrokerTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.901 sec - in
org.apache.activemq.broker.RecoveryStatsBrokerTest
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
icbts-2:activemq-unit-tests icbts$ mvn -version
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T16:19:05-03:30)
Maven home: /x1/maven/apache-maven-3.5.3
Java version: 1.8.0_171, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre
Default locale: en_CA, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.1", arch: "x86_64", family: "mac"
> ActiveMQ reads lots of index pages upon startup (after a graceful or
> ungraceful shutdown)
> -
>
> Key: AMQ-7132
> URL: https://issues.apache.org/jira/browse/AMQ-7132
> Project: ActiveMQ
> Issue Type: Improvement
> Components: KahaDB
>Affects Versions: 5.15.8
>Reporter: Alan Protasio
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.16.0
>
> Attachments: output.tgz
>
>
> Hi.
> We noticed that ActiveMQ reads lots of pages in the index file when is
> starting up to recover the destinations statistics:
> [https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/KahaDBStore.java#L819]
> Nowadays, in order to do that, activemq traverse the
> storedDestination.locationIndex to get the messageCount and totalMessageSize
> of each destination. For destinations with lots of messages this process can
> take a while making the startup process take long time.
> In a case of a master-slave broker, this prevent the broker to fast failover
> and does not meet what is stated on
> [http://activemq.apache.org/shared-file-system-master-slave.html.]
> {quote}If you have a SAN or shared file system it can be used to provide
> _high availability_ such that if a broker is killed, another broker can take
> over immediately.
> {quote}
> One solution for this is keep track of the destination statistics summary in
> the index file and doing so, we dont need to read all the locationIndex on
> the start up.
> The code change proposed is backward compatible but need a bump on the kahadb
> version. If this information is not in the index, the broker will fall back
> to the current implementation, which means that the first time people upgrade
> to the new version, it will still have to read the locationIndex, but
> subsequent restarts will be fast.
> This change should have a negligible performance impact during normal
> activemq operation, as this change introduce a few more bytes of data to the
> index and this information will be on checkpoints. Also, this new information
> is synchronized with the locationIndex as they are update at the same
> transaction.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMQ-7135) Deleting a destination with a large number of page files cause OOM.
[
https://issues.apache.org/jira/browse/AMQ-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jamie goodyear resolved AMQ-7135.
-
Resolution: Fixed
Fix Version/s: 5.15.9
5.16.0
Thank you Heath Kesler for the patch.
> Deleting a destination with a large number of page files cause OOM.
>
>
> Key: AMQ-7135
> URL: https://issues.apache.org/jira/browse/AMQ-7135
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.15.8
>Reporter: Heath Kesler
>Assignee: Jamie goodyear
>Priority: Major
> Fix For: 5.16.0, 5.15.9
>
>
> When removing (delete) a destination using the console an error is reported.
> It appears all the page files are batched into memory. If you have a large
> set of page files and a relatively small heap, this will cause the system to
> run out of memory.
> This can be reproduced by doing the following:
> env: heap size: 384MB
> 1. Create a “test” queue and send more than 2 millions of persistent messages
> with size of 100KB to the “test”queue (this take some times).
> 2. Delete “test” queue by clicking “delete” button on ActiveMQ Console.
> 3. Wait and broker will die eventually.
> 4. Broker won’t reboot successfully
> The observed error below can be seen in the logs.
> {{org.springframework.web.util.NestedServletException: Handler dispatch
> failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit
> exceeded}}
> {{ at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:982)[spring-webmvc-4.3.18.RELEASE.jar:4.3.18.RELEASE]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (AMQ-7135) Deleting a destination with a large number of page files cause OOM.
[
https://issues.apache.org/jira/browse/AMQ-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on AMQ-7135 started by Jamie goodyear.
---
> Deleting a destination with a large number of page files cause OOM.
>
>
> Key: AMQ-7135
> URL: https://issues.apache.org/jira/browse/AMQ-7135
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.15.8
>Reporter: Heath Kesler
>Assignee: Jamie goodyear
>Priority: Major
>
> When removing (delete) a destination using the console an error is reported.
> It appears all the page files are batched into memory. If you have a large
> set of page files and a relatively small heap, this will cause the system to
> run out of memory.
> This can be reproduced by doing the following:
> env: heap size: 384MB
> 1. Create a “test” queue and send more than 2 millions of persistent messages
> with size of 100KB to the “test”queue (this take some times).
> 2. Delete “test” queue by clicking “delete” button on ActiveMQ Console.
> 3. Wait and broker will die eventually.
> 4. Broker won’t reboot successfully
> The observed error below can be seen in the logs.
> {{org.springframework.web.util.NestedServletException: Handler dispatch
> failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit
> exceeded}}
> {{ at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:982)[spring-webmvc-4.3.18.RELEASE.jar:4.3.18.RELEASE]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7135) Deleting a destination with a large number of page files cause OOM.
[
https://issues.apache.org/jira/browse/AMQ-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742325#comment-16742325
]
Jamie goodyear commented on AMQ-7135:
-
I've merged [~heathkesler]'s PR into Activemq-5.15.x and cherry picked it into
Master.
Thank you [~heathkesler] for the patch! :)
> Deleting a destination with a large number of page files cause OOM.
>
>
> Key: AMQ-7135
> URL: https://issues.apache.org/jira/browse/AMQ-7135
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.15.8
>Reporter: Heath Kesler
>Assignee: Jamie goodyear
>Priority: Major
>
> When removing (delete) a destination using the console an error is reported.
> It appears all the page files are batched into memory. If you have a large
> set of page files and a relatively small heap, this will cause the system to
> run out of memory.
> This can be reproduced by doing the following:
> env: heap size: 384MB
> 1. Create a “test” queue and send more than 2 millions of persistent messages
> with size of 100KB to the “test”queue (this take some times).
> 2. Delete “test” queue by clicking “delete” button on ActiveMQ Console.
> 3. Wait and broker will die eventually.
> 4. Broker won’t reboot successfully
> The observed error below can be seen in the logs.
> {{org.springframework.web.util.NestedServletException: Handler dispatch
> failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit
> exceeded}}
> {{ at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:982)[spring-webmvc-4.3.18.RELEASE.jar:4.3.18.RELEASE]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (AMQ-7135) Deleting a destination with a large number of page files cause OOM.
[
https://issues.apache.org/jira/browse/AMQ-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jamie goodyear reassigned AMQ-7135:
---
Assignee: Jamie goodyear
> Deleting a destination with a large number of page files cause OOM.
>
>
> Key: AMQ-7135
> URL: https://issues.apache.org/jira/browse/AMQ-7135
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.15.8
>Reporter: Heath Kesler
>Assignee: Jamie goodyear
>Priority: Major
>
> When removing (delete) a destination using the console an error is reported.
> It appears all the page files are batched into memory. If you have a large
> set of page files and a relatively small heap, this will cause the system to
> run out of memory.
> This can be reproduced by doing the following:
> env: heap size: 384MB
> 1. Create a “test” queue and send more than 2 millions of persistent messages
> with size of 100KB to the “test”queue (this take some times).
> 2. Delete “test” queue by clicking “delete” button on ActiveMQ Console.
> 3. Wait and broker will die eventually.
> 4. Broker won’t reboot successfully
> The observed error below can be seen in the logs.
> {{org.springframework.web.util.NestedServletException: Handler dispatch
> failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit
> exceeded}}
> {{ at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:982)[spring-webmvc-4.3.18.RELEASE.jar:4.3.18.RELEASE]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7135) Deleting a destination with a large number of page files cause OOM.
[
https://issues.apache.org/jira/browse/AMQ-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742067#comment-16742067
]
Jamie goodyear commented on AMQ-7135:
-
Purging a destination before deleting it seems fare. The purge operation for a
destination appears to perform the remove message per pageFile instead of
reading all pageFiles into memory before taking action (preferable memory
wise).
Looking closer at PageFile, the routine (writeBatch) appears to pick up the
PageFiles, do a recovery check for all pageFiles, then process the pageFiles.
The only way i see to reduce the memory load would be to stream pageFile by
pageFile through or use small batches of the batch... perhaps a bit too much
extra complexity (introducing a potential tuning area for delete performance -
batch size).
> Deleting a destination with a large number of page files cause OOM.
>
>
> Key: AMQ-7135
> URL: https://issues.apache.org/jira/browse/AMQ-7135
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.15.8
>Reporter: Heath Kesler
>Priority: Major
>
> When removing (delete) a destination using the console an error is reported.
> It appears all the page files are batched into memory. If you have a large
> set of page files and a relatively small heap, this will cause the system to
> run out of memory.
> This can be reproduced by doing the following:
> env: heap size: 384MB
> 1. Create a “test” queue and send more than 2 millions of persistent messages
> with size of 100KB to the “test”queue (this take some times).
> 2. Delete “test” queue by clicking “delete” button on ActiveMQ Console.
> 3. Wait and broker will die eventually.
> 4. Broker won’t reboot successfully
> The observed error below can be seen in the logs.
> {{org.springframework.web.util.NestedServletException: Handler dispatch
> failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit
> exceeded}}
> {{ at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:982)[spring-webmvc-4.3.18.RELEASE.jar:4.3.18.RELEASE]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7126) Prevent OOM when recovering KahaDB and memory space is insufficient to load full page
[ https://issues.apache.org/jira/browse/AMQ-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736542#comment-16736542 ] Jamie goodyear commented on AMQ-7126: - Performance did indeed appear to be an issue so submitted a change that does not affect performance > Prevent OOM when recovering KahaDB and memory space is insufficient to load > full page > - > > Key: AMQ-7126 > URL: https://issues.apache.org/jira/browse/AMQ-7126 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.8 >Reporter: Heath Kesler >Assignee: Jamie goodyear >Priority: Critical > Fix For: 5.16.0, 5.15.9 > > Attachments: OOM.patch, amq7126.patch > > > We have some brokers that are having OOM issues (on reboot) after having > accepted messages without OOM. We investigated the problem and diagnosed that > this happens when we attempt to load a full page during recovery. > If we update KahaDBStore recoverNextMessage to use the following: > "if (counter >= maxReturned || !listener.hasSpace())" > To check if we have enough space to load the next message, than our OOM is > averted. > AMQ-4495 had the above change that was backed out due to performance > concerns, our testing does not show us a degradation - perhaps we could > provide an optional parameter to use this code? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.
[
https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735223#comment-16735223
]
Jamie goodyear edited comment on AMQ-7118 at 1/6/19 4:43 PM:
-
{{I've pulled latest on Master and built locally:}}
{{---}}
{{ T E S T S}}
{{---}}
{{Running org.apache.activemq.bugs.AMQ7118Test}}
{{Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 22.474 sec -
in org.apache.activemq.bugs.AMQ7118Test}}
{{Results :}}
{{Tests run: 1, Failures: 0, Errors: 0, Skipped: 0}}
{{Can you please supply more information on your environment? }}
{{I've also run the kahadb store tests as well:}}
{{Results :}}
{{Tests run: 140, Failures: 0, Errors: 0, Skipped: 1}}
was (Author: jgoodyear):
{{I've pulled latest on Master and built locally:}}
{{---}}
{{ T E S T S}}
{{---}}
{{Running org.apache.activemq.bugs.AMQ7118Test}}
{{Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 22.474 sec -
in org.apache.activemq.bugs.AMQ7118Test}}
{{Results :}}
{{Tests run: 1, Failures: 0, Errors: 0, Skipped: 0}}
{{Can you please supply more information on your environment? }}
> KahaDB store limit can be exceeded with durable subscribers.
>
>
> Key: AMQ-7118
> URL: https://issues.apache.org/jira/browse/AMQ-7118
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB
>Affects Versions: 5.16.0, 5.15.8
> Environment: JDK 8
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.8
>
> Attachments: kahaCommands.jpg
>
>
> KahaDB store limit can be exceeded with durable subscribers.
> AMQ with store limit set, we can observe that the usage continues to increase
> AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having
> exceeded the store limit remains.
> See below output from KahaDB dump in attachments:
> This appears to be caused by checkpointAckMessageFileMap. The log files are
> not GC'd, and the KAHA_ACK_MESSAGE_FILE_MAP_COMMAND is replicated and the DB
> log files continue to expand - this can become exponential. Side effect of
> also not checking storage size in checkpoint update can cause the DB log
> files to exceed any set limits. The real critical part is the duplicated and
> leaking Kaha messages which appears to happen with durable subscribers.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.
[
https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735223#comment-16735223
]
Jamie goodyear commented on AMQ-7118:
-
{{I've pulled latest on Master and built locally:}}
{{---}}
{{ T E S T S}}
{{---}}
{{Running org.apache.activemq.bugs.AMQ7118Test}}
{{Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 22.474 sec -
in org.apache.activemq.bugs.AMQ7118Test}}
{{Results :}}
{{Tests run: 1, Failures: 0, Errors: 0, Skipped: 0}}
{{Can you please supply more information on your environment? }}
> KahaDB store limit can be exceeded with durable subscribers.
>
>
> Key: AMQ-7118
> URL: https://issues.apache.org/jira/browse/AMQ-7118
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB
>Affects Versions: 5.16.0, 5.15.8
> Environment: JDK 8
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.8
>
> Attachments: kahaCommands.jpg
>
>
> KahaDB store limit can be exceeded with durable subscribers.
> AMQ with store limit set, we can observe that the usage continues to increase
> AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having
> exceeded the store limit remains.
> See below output from KahaDB dump in attachments:
> This appears to be caused by checkpointAckMessageFileMap. The log files are
> not GC'd, and the KAHA_ACK_MESSAGE_FILE_MAP_COMMAND is replicated and the DB
> log files continue to expand - this can become exponential. Side effect of
> also not checking storage size in checkpoint update can cause the DB log
> files to exceed any set limits. The real critical part is the duplicated and
> leaking Kaha messages which appears to happen with durable subscribers.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMQ-7126) Prevent OOM when recovering KahaDB and memory space is insufficient to load full page
[ https://issues.apache.org/jira/browse/AMQ-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear resolved AMQ-7126. - Resolution: Fixed Fix Version/s: 5.15.9 5.16.0 > Prevent OOM when recovering KahaDB and memory space is insufficient to load > full page > - > > Key: AMQ-7126 > URL: https://issues.apache.org/jira/browse/AMQ-7126 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.8 >Reporter: Heath Kesler >Assignee: Jamie goodyear >Priority: Critical > Fix For: 5.16.0, 5.15.9 > > Attachments: OOM.patch, amq7126.patch > > > We have some brokers that are having OOM issues (on reboot) after having > accepted messages without OOM. We investigated the problem and diagnosed that > this happens when we attempt to load a full page during recovery. > If we update KahaDBStore recoverNextMessage to use the following: > "if (counter >= maxReturned || !listener.hasSpace())" > To check if we have enough space to load the next message, than our OOM is > averted. > AMQ-4495 had the above change that was backed out due to performance > concerns, our testing does not show us a degradation - perhaps we could > provide an optional parameter to use this code? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (AMQ-7126) Prevent OOM when recovering KahaDB and memory space is insufficient to load full page
[ https://issues.apache.org/jira/browse/AMQ-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear reassigned AMQ-7126: --- Assignee: Jamie goodyear > Prevent OOM when recovering KahaDB and memory space is insufficient to load > full page > - > > Key: AMQ-7126 > URL: https://issues.apache.org/jira/browse/AMQ-7126 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.8 >Reporter: Heath Kesler >Assignee: Jamie goodyear >Priority: Critical > Attachments: OOM.patch, amq7126.patch > > > We have some brokers that are having OOM issues (on reboot) after having > accepted messages without OOM. We investigated the problem and diagnosed that > this happens when we attempt to load a full page during recovery. > If we update KahaDBStore recoverNextMessage to use the following: > "if (counter >= maxReturned || !listener.hasSpace())" > To check if we have enough space to load the next message, than our OOM is > averted. > AMQ-4495 had the above change that was backed out due to performance > concerns, our testing does not show us a degradation - perhaps we could > provide an optional parameter to use this code? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (AMQ-7126) Prevent OOM when recovering KahaDB and memory space is insufficient to load full page
[ https://issues.apache.org/jira/browse/AMQ-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQ-7126 started by Jamie goodyear. --- > Prevent OOM when recovering KahaDB and memory space is insufficient to load > full page > - > > Key: AMQ-7126 > URL: https://issues.apache.org/jira/browse/AMQ-7126 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.8 >Reporter: Heath Kesler >Assignee: Jamie goodyear >Priority: Critical > Attachments: OOM.patch, amq7126.patch > > > We have some brokers that are having OOM issues (on reboot) after having > accepted messages without OOM. We investigated the problem and diagnosed that > this happens when we attempt to load a full page during recovery. > If we update KahaDBStore recoverNextMessage to use the following: > "if (counter >= maxReturned || !listener.hasSpace())" > To check if we have enough space to load the next message, than our OOM is > averted. > AMQ-4495 had the above change that was backed out due to performance > concerns, our testing does not show us a degradation - perhaps we could > provide an optional parameter to use this code? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7126) Prevent OOM when recovering KahaDB and memory space is insufficient to load full page
[ https://issues.apache.org/jira/browse/AMQ-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733406#comment-16733406 ] Jamie goodyear commented on AMQ-7126: - Thank you [~heathkesler] and [~joed] for the investigation and patch supplied for this card. > Prevent OOM when recovering KahaDB and memory space is insufficient to load > full page > - > > Key: AMQ-7126 > URL: https://issues.apache.org/jira/browse/AMQ-7126 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.8 >Reporter: Heath Kesler >Priority: Critical > Attachments: OOM.patch, amq7126.patch > > > We have some brokers that are having OOM issues (on reboot) after having > accepted messages without OOM. We investigated the problem and diagnosed that > this happens when we attempt to load a full page during recovery. > If we update KahaDBStore recoverNextMessage to use the following: > "if (counter >= maxReturned || !listener.hasSpace())" > To check if we have enough space to load the next message, than our OOM is > averted. > AMQ-4495 had the above change that was backed out due to performance > concerns, our testing does not show us a degradation - perhaps we could > provide an optional parameter to use this code? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7126) Prevent OOM when recovering KahaDB and memory space is insufficient to load full page
[ https://issues.apache.org/jira/browse/AMQ-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-7126: Attachment: amq7126.patch > Prevent OOM when recovering KahaDB and memory space is insufficient to load > full page > - > > Key: AMQ-7126 > URL: https://issues.apache.org/jira/browse/AMQ-7126 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.8 >Reporter: Heath Kesler >Priority: Critical > Attachments: OOM.patch, amq7126.patch > > > We have some brokers that are having OOM issues (on reboot) after having > accepted messages without OOM. We investigated the problem and diagnosed that > this happens when we attempt to load a full page during recovery. > If we update KahaDBStore recoverNextMessage to use the following: > "if (counter >= maxReturned || !listener.hasSpace())" > To check if we have enough space to load the next message, than our OOM is > averted. > AMQ-4495 had the above change that was backed out due to performance > concerns, our testing does not show us a degradation - perhaps we could > provide an optional parameter to use this code? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear resolved AMQCPP-619. --- Resolution: Fixed Fix Version/s: 3.10.0 Thank you Francois Godin for the patch. This update will be included in a future 3.10.0 release. > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Jamie goodyear >Priority: Major > Fix For: 3.10.0 > > Attachments: amqcpp-619.patch, sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMQCPP-642) Create 3.10.x branch based upon 3.9.x code.
[ https://issues.apache.org/jira/browse/AMQCPP-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear resolved AMQCPP-642. --- Resolution: Fixed Branch created. > Create 3.10.x branch based upon 3.9.x code. > --- > > Key: AMQCPP-642 > URL: https://issues.apache.org/jira/browse/AMQCPP-642 > Project: ActiveMQ C++ Client > Issue Type: Task >Affects Versions: 3.10 >Reporter: Jamie goodyear >Assignee: Jamie goodyear >Priority: Major > Fix For: 3.10 > > > Create 3.10.x branch based upon 3.9.x code base. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (AMQCPP-642) Create 3.10.x branch based upon 3.9.x code.
[ https://issues.apache.org/jira/browse/AMQCPP-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQCPP-642 started by Jamie goodyear. - > Create 3.10.x branch based upon 3.9.x code. > --- > > Key: AMQCPP-642 > URL: https://issues.apache.org/jira/browse/AMQCPP-642 > Project: ActiveMQ C++ Client > Issue Type: Task >Affects Versions: 3.10 >Reporter: Jamie goodyear >Assignee: Jamie goodyear >Priority: Major > Fix For: 3.10 > > > Create 3.10.x branch based upon 3.9.x code base. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (AMQCPP-642) Create 3.10.x branch based upon 3.9.x code.
[ https://issues.apache.org/jira/browse/AMQCPP-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear reassigned AMQCPP-642: - Assignee: Jamie goodyear (was: Timothy Bish) > Create 3.10.x branch based upon 3.9.x code. > --- > > Key: AMQCPP-642 > URL: https://issues.apache.org/jira/browse/AMQCPP-642 > Project: ActiveMQ C++ Client > Issue Type: Task >Affects Versions: 3.10 >Reporter: Jamie goodyear >Assignee: Jamie goodyear >Priority: Major > Fix For: 3.10 > > > Create 3.10.x branch based upon 3.9.x code base. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQCPP-642) Create 3.10.x branch based upon 3.9.x code.
Jamie goodyear created AMQCPP-642: - Summary: Create 3.10.x branch based upon 3.9.x code. Key: AMQCPP-642 URL: https://issues.apache.org/jira/browse/AMQCPP-642 Project: ActiveMQ C++ Client Issue Type: Task Affects Versions: 3.10 Reporter: Jamie goodyear Assignee: Timothy Bish Fix For: 3.10 Create 3.10.x branch based upon 3.9.x code base. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712972#comment-16712972 ] Jamie goodyear commented on AMQCPP-619: --- I replaced the tabs in master. Before I revert on 3.9.x can you please comment on the dev thread so that I know where to put this and other AMQ CPP patches. > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Jamie goodyear >Priority: Major > Attachments: amqcpp-619.patch, sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712943#comment-16712943 ] Jamie goodyear edited comment on AMQCPP-619 at 12/7/18 2:52 PM: Hi Tim, According to [http://activemq.apache.org/cms/activemq-cpp-product-version-number.html] , it seems as though this is proper to go into 3.9.x branch. I'm happy to back this out if you can please answer in the following thread regarding master and 3.10.x. [http://activemq.2283324.n4.nabble.com/Discuss-ActiveMQ-CPP-Client-td4745898.html] As well as please specify the code formatting so i may update this. Your input and more information would be appreciated. Also i would be interested to know the compatibility it is breaking as the unit tests all pass, as well as our hand testing of the SSL certs. was (Author: jgoodyear): Hi Tim, According to [http://activemq.apache.org/cms/activemq-cpp-product-version-number.html] , it seems as though this is proper to go into 3.9.x branch. I'm happy to back this out if you can please answer in the following thread regarding master and 3.10.x. [http://activemq.2283324.n4.nabble.com/Discuss-ActiveMQ-CPP-Client-td4745898.html] As well as please specify the code formatting so i may update this. Your input and more information would be appreciated. > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Jamie goodyear >Priority: Major > Attachments: amqcpp-619.patch, sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712943#comment-16712943 ] Jamie goodyear commented on AMQCPP-619: --- Hi Tim, According to [http://activemq.apache.org/cms/activemq-cpp-product-version-number.html] , it seems as though this is proper to go into 3.9.x branch. I'm happy to back this out if you can please answer in the following thread regarding master and 3.10.x. [http://activemq.2283324.n4.nabble.com/Discuss-ActiveMQ-CPP-Client-td4745898.html] As well as please specify the code formatting so i may update this. Your input and more information would be appreciated. > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Jamie goodyear >Priority: Major > Attachments: amqcpp-619.patch, sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQCPP-619 started by Jamie goodyear. - > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Jamie goodyear >Priority: Major > Attachments: amqcpp-619.patch, sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear reassigned AMQCPP-619: - Assignee: Jamie goodyear (was: Timothy Bish) > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Jamie goodyear >Priority: Major > Attachments: amqcpp-619.patch, sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQCPP-619: -- Attachment: (was: amqcpp-619.patch) > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Timothy Bish >Priority: Major > Attachments: amqcpp-619.patch, sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQCPP-619: -- Attachment: amqcpp-619.patch > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Timothy Bish >Priority: Major > Attachments: amqcpp-619.patch, sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQCPP-619: -- Attachment: (was: amq-619-diff.patch) > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Timothy Bish >Priority: Major > Attachments: amqcpp-619.patch, sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQCPP-619: -- Attachment: amqcpp-619.patch > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Timothy Bish >Priority: Major > Attachments: amqcpp-619.patch, sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQCPP-619: -- Attachment: amq-619-diff.patch > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Timothy Bish >Priority: Major > Attachments: amq-619-diff.patch, sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQCPP-619) Support for SSL wilcard certificate
[ https://issues.apache.org/jira/browse/AMQCPP-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710088#comment-16710088 ] Jamie goodyear commented on AMQCPP-619: --- I can confirm that i can compile AMQCPP using OpenSSL 1.0.2g on Ubuntu, with existing integration test suites passing. > Support for SSL wilcard certificate > --- > > Key: AMQCPP-619 > URL: https://issues.apache.org/jira/browse/AMQCPP-619 > Project: ActiveMQ C++ Client > Issue Type: New Feature >Affects Versions: 3.9.4 >Reporter: Francois Godin >Assignee: Timothy Bish >Priority: Major > Attachments: sslCertificateWildcard.patch > > > SSL certificate can contain wildcard in the hostname. For example, the > certificate URL "*.proxy.app.com" should match the following address: > * 1.proxy.app.com > * 2.proxy.app.com > Sadly, ActiveMQ-CPP simply compare the two values and thus does not accept > such certificates. > The Openssl page https://wiki.openssl.org/index.php/Hostname_validation > describe some possible implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.
[ https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-7118: Fix Version/s: 5.16.0 > KahaDB store limit can be exceeded with durable subscribers. > > > Key: AMQ-7118 > URL: https://issues.apache.org/jira/browse/AMQ-7118 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.16.0, 5.15.8 > Environment: JDK 8 >Reporter: Jamie goodyear >Priority: Critical > Fix For: 5.16.0, 5.15.8 > > Attachments: kahaCommands.jpg > > > KahaDB store limit can be exceeded with durable subscribers. > AMQ with store limit set, we can observe that the usage continues to increase > AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having > exceeded the store limit remains. > See below output from KahaDB dump in attachments: > This appears to be caused by checkpointAckMessageFileMap. The log files are > not GC'd, and the KAHA_ACK_MESSAGE_FILE_MAP_COMMAND is replicated and the DB > log files continue to expand - this can become exponential. Side effect of > also not checking storage size in checkpoint update can cause the DB log > files to exceed any set limits. The real critical part is the duplicated and > leaking Kaha messages which appears to happen with durable subscribers. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.
[ https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear resolved AMQ-7118. - Resolution: Fixed Thank you [~heathkesler] for the patch. > KahaDB store limit can be exceeded with durable subscribers. > > > Key: AMQ-7118 > URL: https://issues.apache.org/jira/browse/AMQ-7118 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.16.0, 5.15.8 > Environment: JDK 8 >Reporter: Jamie goodyear >Priority: Critical > Fix For: 5.16.0, 5.15.8 > > Attachments: kahaCommands.jpg > > > KahaDB store limit can be exceeded with durable subscribers. > AMQ with store limit set, we can observe that the usage continues to increase > AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having > exceeded the store limit remains. > See below output from KahaDB dump in attachments: > This appears to be caused by checkpointAckMessageFileMap. The log files are > not GC'd, and the KAHA_ACK_MESSAGE_FILE_MAP_COMMAND is replicated and the DB > log files continue to expand - this can become exponential. Side effect of > also not checking storage size in checkpoint update can cause the DB log > files to exceed any set limits. The real critical part is the duplicated and > leaking Kaha messages which appears to happen with durable subscribers. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.
[ https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706385#comment-16706385 ] Jamie goodyear commented on AMQ-7118: - Thanks Heath! This looks really great. [~gtully], can you take a gander as well? > KahaDB store limit can be exceeded with durable subscribers. > > > Key: AMQ-7118 > URL: https://issues.apache.org/jira/browse/AMQ-7118 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.16.0, 5.15.8 > Environment: JDK 8 >Reporter: Jamie goodyear >Priority: Critical > Fix For: 5.15.8 > > Attachments: kahaCommands.jpg > > > KahaDB store limit can be exceeded with durable subscribers. > AMQ with store limit set, we can observe that the usage continues to increase > AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having > exceeded the store limit remains. > See below output from KahaDB dump in attachments: > This appears to be caused by checkpointAckMessageFileMap. The log files are > not GC'd, and the KAHA_ACK_MESSAGE_FILE_MAP_COMMAND is replicated and the DB > log files continue to expand - this can become exponential. Side effect of > also not checking storage size in checkpoint update can cause the DB log > files to exceed any set limits. The real critical part is the duplicated and > leaking Kaha messages which appears to happen with durable subscribers. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.
[ https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-7118: Description: KahaDB store limit can be exceeded with durable subscribers. AMQ with store limit set, we can observe that the usage continues to increase AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having exceeded the store limit remains. See below output from KahaDB dump in attachments: This appears to be caused by checkpointAckMessageFileMap. The log files are not GC'd, and the KAHA_ACK_MESSAGE_FILE_MAP_COMMAND is replicated and the DB log files continue to expand - this can become exponential. Side effect of also not checking storage size in checkpoint update can cause the DB log files to exceed any set limits. The real critical part is the duplicated and leaking Kaha messages which appears to happen with durable subscribers. was: KahaDB store limit can be exceeded with durable subscribers. AMQ with store limit set, we can observe that the usage continues to increase AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having exceeded the store limit remains. See below output from KahaDB dump in attachments: This appears to be caused by checkpointAckMessageFileMap. The log files are not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files continue to expand - this can become exponential. Side effect of also not checking storage size in checkpoint update can cause the DB log files to exceed any set limits. The real critical part is the duplicated and leaking Kaha messages which appears to happen with durable subscribers. > KahaDB store limit can be exceeded with durable subscribers. > > > Key: AMQ-7118 > URL: https://issues.apache.org/jira/browse/AMQ-7118 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.16.0, 5.15.8 > Environment: JDK 8 >Reporter: Jamie goodyear >Priority: Critical > Fix For: 5.15.8 > > Attachments: kahaCommands.jpg > > > KahaDB store limit can be exceeded with durable subscribers. > AMQ with store limit set, we can observe that the usage continues to increase > AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having > exceeded the store limit remains. > See below output from KahaDB dump in attachments: > This appears to be caused by checkpointAckMessageFileMap. The log files are > not GC'd, and the KAHA_ACK_MESSAGE_FILE_MAP_COMMAND is replicated and the DB > log files continue to expand - this can become exponential. Side effect of > also not checking storage size in checkpoint update can cause the DB log > files to exceed any set limits. The real critical part is the duplicated and > leaking Kaha messages which appears to happen with durable subscribers. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.
[ https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706371#comment-16706371 ] Jamie goodyear commented on AMQ-7118: - To close the loop from IRC chat: Heath, this looks good, but I would use AtomicBoolen with lazySet may be a bit cleaner for this. > KahaDB store limit can be exceeded with durable subscribers. > > > Key: AMQ-7118 > URL: https://issues.apache.org/jira/browse/AMQ-7118 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.16.0, 5.15.8 > Environment: JDK 8 >Reporter: Jamie goodyear >Priority: Critical > Fix For: 5.15.8 > > Attachments: kahaCommands.jpg > > > KahaDB store limit can be exceeded with durable subscribers. > AMQ with store limit set, we can observe that the usage continues to increase > AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having > exceeded the store limit remains. > See below output from KahaDB dump in attachments: > This appears to be caused by checkpointAckMessageFileMap. The log files are > not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files > continue to expand - this can become exponential. Side effect of also not > checking storage size in checkpoint update can cause the DB log files to > exceed any set limits. The real critical part is the duplicated and leaking > Kaha messages which appears to happen with durable subscribers. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.
[ https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-7118: Description: KahaDB store limit can be exceeded with durable subscribers. AMQ with store limit set, we can observe that the usage continues to increase AFTER PFC is engaged. See below output from KahaDB dump in attachments: This appears to be caused by checkpointAckMessageFileMap. The log files are not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files continue to expand - this can become exponential. Side effect of also not checking storage size in checkpoint update can cause the DB log files to exceed any set limits. The real critical part is the duplicated and leaking Kaha messages which appears to happen with durable subscribers. was: KahaDB leak causing store limit to be exceeded with durable subscribers. AMQ with store limit set, we can observe that the usage continues to increase AFTER PFC is engaged. See below output from KahaDB dump in attachments: This appears to be caused by checkpointAckMessageFileMap. The log files are not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files continue to expand - this can become exponential. Side effect of also not checking storage size in checkpoint update can cause the DB log files to exceed any set limits. The real critical part is the duplicated and leaking Kaha messages which appears to happen with durable subscribers. > KahaDB store limit can be exceeded with durable subscribers. > > > Key: AMQ-7118 > URL: https://issues.apache.org/jira/browse/AMQ-7118 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.16.0, 5.15.8 > Environment: JDK 8 >Reporter: Jamie goodyear >Priority: Critical > Fix For: 5.15.8 > > Attachments: kahaCommands.jpg > > > KahaDB store limit can be exceeded with durable subscribers. > AMQ with store limit set, we can observe that the usage continues to increase > AFTER PFC is engaged. > See below output from KahaDB dump in attachments: > This appears to be caused by checkpointAckMessageFileMap. The log files are > not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files > continue to expand - this can become exponential. Side effect of also not > checking storage size in checkpoint update can cause the DB log files to > exceed any set limits. The real critical part is the duplicated and leaking > Kaha messages which appears to happen with durable subscribers. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.
[ https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-7118: Description: KahaDB store limit can be exceeded with durable subscribers. AMQ with store limit set, we can observe that the usage continues to increase AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having exceeded the store limit remains. See below output from KahaDB dump in attachments: This appears to be caused by checkpointAckMessageFileMap. The log files are not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files continue to expand - this can become exponential. Side effect of also not checking storage size in checkpoint update can cause the DB log files to exceed any set limits. The real critical part is the duplicated and leaking Kaha messages which appears to happen with durable subscribers. was: KahaDB store limit can be exceeded with durable subscribers. AMQ with store limit set, we can observe that the usage continues to increase AFTER PFC is engaged. See below output from KahaDB dump in attachments: This appears to be caused by checkpointAckMessageFileMap. The log files are not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files continue to expand - this can become exponential. Side effect of also not checking storage size in checkpoint update can cause the DB log files to exceed any set limits. The real critical part is the duplicated and leaking Kaha messages which appears to happen with durable subscribers. > KahaDB store limit can be exceeded with durable subscribers. > > > Key: AMQ-7118 > URL: https://issues.apache.org/jira/browse/AMQ-7118 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.16.0, 5.15.8 > Environment: JDK 8 >Reporter: Jamie goodyear >Priority: Critical > Fix For: 5.15.8 > > Attachments: kahaCommands.jpg > > > KahaDB store limit can be exceeded with durable subscribers. > AMQ with store limit set, we can observe that the usage continues to increase > AFTER PFC is engaged. Given time, this growth stabilizes. The issue of having > exceeded the store limit remains. > See below output from KahaDB dump in attachments: > This appears to be caused by checkpointAckMessageFileMap. The log files are > not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files > continue to expand - this can become exponential. Side effect of also not > checking storage size in checkpoint update can cause the DB log files to > exceed any set limits. The real critical part is the duplicated and leaking > Kaha messages which appears to happen with durable subscribers. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7118) KahaDB store limit can be exceeded with durable subscribers.
[ https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-7118: Summary: KahaDB store limit can be exceeded with durable subscribers. (was: KahaDB leak causing store limit to be exceeded with durable subscribers.) > KahaDB store limit can be exceeded with durable subscribers. > > > Key: AMQ-7118 > URL: https://issues.apache.org/jira/browse/AMQ-7118 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.16.0, 5.15.8 > Environment: JDK 8 >Reporter: Jamie goodyear >Priority: Critical > Fix For: 5.15.8 > > Attachments: kahaCommands.jpg > > > KahaDB leak causing store limit to be exceeded with durable subscribers. > AMQ with store limit set, we can observe that the usage continues to increase > AFTER PFC is engaged. > See below output from KahaDB dump in attachments: > This appears to be caused by checkpointAckMessageFileMap. The log files are > not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files > continue to expand - this can become exponential. Side effect of also not > checking storage size in checkpoint update can cause the DB log files to > exceed any set limits. The real critical part is the duplicated and leaking > Kaha messages which appears to happen with durable subscribers. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7118) KahaDB leak causing store limit to be exceeded with durable subscribers.
[ https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-7118: Description: KahaDB leak causing store limit to be exceeded with durable subscribers. AMQ with store limit set, we can observe that the usage continues to increase AFTER PFC is engaged. See below output from KahaDB dump in attachments: This appears to be caused by checkpointAckMessageFileMap. The log files are not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files continue to expand - this can become exponential. Side effect of also not checking storage size in checkpoint update can cause the DB log files to exceed any set limits. The real critical part is the duplicated and leaking Kaha messages which appears to happen with durable subscribers. was: KahaDB leak causing store limit to be exceeded with durable subscribers. AMQ with store limit set, we can observe that the usage continues to increase AFTER PFC is engaged. See below output from KahaDB dump: !kahaCommands.png|width=674,height=558! This appears to be caused by checkpointAckMessageFileMap. The log files are not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files continue to expand - this can become exponential. Side effect of also not checking storage size in checkpoint update can cause the DB log files to exceed any set limits. The real critical part is the duplicated and leaking Kaha messages which appears to happen with durable subscribers. > KahaDB leak causing store limit to be exceeded with durable subscribers. > > > Key: AMQ-7118 > URL: https://issues.apache.org/jira/browse/AMQ-7118 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.16.0, 5.15.8 > Environment: JDK 8 >Reporter: Jamie goodyear >Priority: Critical > Fix For: 5.15.8 > > Attachments: kahaCommands.jpg > > > KahaDB leak causing store limit to be exceeded with durable subscribers. > AMQ with store limit set, we can observe that the usage continues to increase > AFTER PFC is engaged. > See below output from KahaDB dump in attachments: > This appears to be caused by checkpointAckMessageFileMap. The log files are > not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files > continue to expand - this can become exponential. Side effect of also not > checking storage size in checkpoint update can cause the DB log files to > exceed any set limits. The real critical part is the duplicated and leaking > Kaha messages which appears to happen with durable subscribers. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7118) KahaDB leak causing store limit to be exceeded with durable subscribers.
[ https://issues.apache.org/jira/browse/AMQ-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-7118: Attachment: kahaCommands.jpg > KahaDB leak causing store limit to be exceeded with durable subscribers. > > > Key: AMQ-7118 > URL: https://issues.apache.org/jira/browse/AMQ-7118 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.16.0, 5.15.8 > Environment: JDK 8 >Reporter: Jamie goodyear >Priority: Critical > Fix For: 5.15.8 > > Attachments: kahaCommands.jpg > > > KahaDB leak causing store limit to be exceeded with durable subscribers. > AMQ with store limit set, we can observe that the usage continues to increase > AFTER PFC is engaged. > See below output from KahaDB dump: > !kahaCommands.png|width=674,height=558! > This appears to be caused by checkpointAckMessageFileMap. The log files are > not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files > continue to expand - this can become exponential. Side effect of also not > checking storage size in checkpoint update can cause the DB log files to > exceed any set limits. The real critical part is the duplicated and leaking > Kaha messages which appears to happen with durable subscribers. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-7118) KahaDB leak causing store limit to be exceeded with durable subscribers.
Jamie goodyear created AMQ-7118: --- Summary: KahaDB leak causing store limit to be exceeded with durable subscribers. Key: AMQ-7118 URL: https://issues.apache.org/jira/browse/AMQ-7118 Project: ActiveMQ Issue Type: Bug Components: KahaDB Affects Versions: 5.15.8, 5.16.0 Environment: JDK 8 Reporter: Jamie goodyear Fix For: 5.15.8 KahaDB leak causing store limit to be exceeded with durable subscribers. AMQ with store limit set, we can observe that the usage continues to increase AFTER PFC is engaged. See below output from KahaDB dump: !kahaCommands.png|width=674,height=558! This appears to be caused by checkpointAckMessageFileMap. The log files are not GC'd, and the KAHA_ACK_MESSAGE is replicated and the DB log files continue to expand - this can become exponential. Side effect of also not checking storage size in checkpoint update can cause the DB log files to exceed any set limits. The real critical part is the duplicated and leaking Kaha messages which appears to happen with durable subscribers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7107) QueueBrowsingTest and UsageBlockedDispatchTest are failing with ConcurrentStoreAndDispachQueues=false
[ https://issues.apache.org/jira/browse/AMQ-7107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16695285#comment-16695285 ] Jamie goodyear commented on AMQ-7107: - Thank you for the patch submission, I'll take a gander. > QueueBrowsingTest and UsageBlockedDispatchTest are failing with > ConcurrentStoreAndDispachQueues=false > - > > Key: AMQ-7107 > URL: https://issues.apache.org/jira/browse/AMQ-7107 > Project: ActiveMQ > Issue Type: Test >Reporter: Alan Protasio >Priority: Minor > > Hi, > I was working towards https://issues.apache.org/jira/browse/AMQ-7028 and > after my change QueueBrowsingTest and UsageBlockedDispatchTest were failing. > QueueBrowsingTest was changed by > https://issues.apache.org/jira/browse/AMQ-4495 and it is testing if a full > page was pagedIn by the cursor. > The problem is because this test was only succeeding due how > ConcurrentStoreAndDispachQueues=true is implemented. When this flag is set to > True, we increase the memory usage when start the async task and when > decrease it when the task is done: > https://github.com/alanprot/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/region/Queue.java#L897 > So, imagine this timeline: > 1 . Send message 1 > 2. The cursor get full and the cache is disabled > 3. Message1 finish and the memory is freed > 4. messages 2 to 100 are sent and the cache is skipped > 5. We call browser queue and the cursor can pageIn messages because the > cursorMemory is not full > Now with ConcurrentStoreAndDispachQueues=false > 1 . Send message 1 > 2 . Send message 2 > 3. The cursor get full and the cache is disabled > 4. messages 3 to 100 are sent and the cache is skipped (memory still full) > 5. We call browser queue and the cursor cannot pageIn messages because the > cursorMemory is full > So, in order to make this test work with > ConcurrentStoreAndDispachQueues=false i did a simple change on it... After > sending all the messages, consume one of them and make sure that the cursor > has memory to pageIn messages. > Similar thing is happening with UsageBlockedDispatchTest. > I create 2 more test to do the same test with > ConcurrentStoreAndDispachQueues=false and changed it a little bit to make > them works with this flag false. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7091) O(n) Memory consumption when broker has inactive durable subscribes causing OOM
[ https://issues.apache.org/jira/browse/AMQ-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684398#comment-16684398 ] Jamie goodyear commented on AMQ-7091: - Thank you Alan Protasio for the PR :) > O(n) Memory consumption when broker has inactive durable subscribes causing > OOM > --- > > Key: AMQ-7091 > URL: https://issues.apache.org/jira/browse/AMQ-7091 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.7 >Reporter: Alan Protasio >Priority: Major > Attachments: After.png, Before.png, > InactiveDurableSubscriberTest.java, memoryAllocation.jpg > > > Hi :D > One of our brokers was bouncing indefinitely due OOM even though the load > (TPS) was pretty low. > Getting the memory dump I could see that almost 90% of the memory was being > used by > [messageReferences|https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java#L2368] > TreeMap to keep track of what messages were already acked by all Subscribes > in order to delete them. > This seems to be a problem as if the broker has an inactive durable > subscribe, the memory footprint increase proportionally (O) with the number > of messages sent to the topic in question, causing the broker to die due OOM > sooner or later (the high memory footprint continue even after a restart). > You can find attached (memoryAllocation.jpg) a screen shot showing my broker > using 90% of the memory to keep track of those messages, making it barely > usable. > Looking at the code, I could do a change to change the messageReferences to > use a BTreeIndex: > final TreeMap messageReferences = new TreeMap<>(); > + BTreeIndex messageReferences; > Making this change, the memory allocation of the broker stabilized and the > broker didn't run OOM anymore. > Attached you can see the code that I used to reproduce this scenario, also > the memory utilization (HEAP and GC graphs) before and after this change. > Before the change the broker died in 5 minutes and I could send 48. After > then change the broker was still pretty healthy after 5 minutes and i could > send 2265000 to the topic (almost 5x more due high GC pauses). > > All test are passing: mvn clean install -Dactivemq.tests=all -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7091) O(n) Memory consumption when broker has inactive durable subscribes causing OOM
[ https://issues.apache.org/jira/browse/AMQ-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677021#comment-16677021 ] Jamie goodyear commented on AMQ-7091: - Hi [~alanprot], After some conversation with the community, the SeuqnceSet in AMQ is good to use for this scenario, because then we can control the sizes and toss them when memory is short: https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/disk/util/SequenceSet.java Please have a look at the above, and lets update your PR. > O(n) Memory consumption when broker has inactive durable subscribes causing > OOM > --- > > Key: AMQ-7091 > URL: https://issues.apache.org/jira/browse/AMQ-7091 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.7 >Reporter: Alan Protasio >Priority: Major > Attachments: After.png, Before.png, > InactiveDurableSubscriberTest.java, memoryAllocation.jpg > > > Hi :D > One of our brokers was bouncing indefinitely due OOM even though the load > (TPS) was pretty low. > Getting the memory dump I could see that almost 90% of the memory was being > used by > [messageReferences|https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java#L2368] > TreeMap to keep track of what messages were already acked by all Subscribes > in order to delete them. > This seems to be a problem as if the broker has an inactive durable > subscribe, the memory footprint increase proportionally (O) with the number > of messages sent to the topic in question, causing the broker to die due OOM > sooner or later (the high memory footprint continue even after a restart). > You can find attached (memoryAllocation.jpg) a screen shot showing my broker > using 90% of the memory to keep track of those messages, making it barely > usable. > Looking at the code, I could do a change to change the messageReferences to > use a BTreeIndex: > final TreeMap messageReferences = new TreeMap<>(); > + BTreeIndex messageReferences; > Making this change, the memory allocation of the broker stabilized and the > broker didn't run OOM anymore. > Attached you can see the code that I used to reproduce this scenario, also > the memory utilization (HEAP and GC graphs) before and after this change. > Before the change the broker died in 5 minutes and I could send 48. After > then change the broker was still pretty healthy after 5 minutes and i could > send 2265000 to the topic (almost 5x more due high GC pauses). > > All test are passing: mvn clean install -Dactivemq.tests=all -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7091) O(n) Memory consumption when broker has inactive durable subscribes causing OOM
[ https://issues.apache.org/jira/browse/AMQ-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676861#comment-16676861 ] Jamie goodyear commented on AMQ-7091: - Thanks Gary. > O(n) Memory consumption when broker has inactive durable subscribes causing > OOM > --- > > Key: AMQ-7091 > URL: https://issues.apache.org/jira/browse/AMQ-7091 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.7 >Reporter: Alan Protasio >Priority: Major > Attachments: After.png, Before.png, > InactiveDurableSubscriberTest.java, memoryAllocation.jpg > > > Hi :D > One of our brokers was bouncing indefinitely due OOM even though the load > (TPS) was pretty low. > Getting the memory dump I could see that almost 90% of the memory was being > used by > [messageReferences|https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java#L2368] > TreeMap to keep track of what messages were already acked by all Subscribes > in order to delete them. > This seems to be a problem as if the broker has an inactive durable > subscribe, the memory footprint increase proportionally (O) with the number > of messages sent to the topic in question, causing the broker to die due OOM > sooner or later (the high memory footprint continue even after a restart). > You can find attached (memoryAllocation.jpg) a screen shot showing my broker > using 90% of the memory to keep track of those messages, making it barely > usable. > Looking at the code, I could do a change to change the messageReferences to > use a BTreeIndex: > final TreeMap messageReferences = new TreeMap<>(); > + BTreeIndex messageReferences; > Making this change, the memory allocation of the broker stabilized and the > broker didn't run OOM anymore. > Attached you can see the code that I used to reproduce this scenario, also > the memory utilization (HEAP and GC graphs) before and after this change. > Before the change the broker died in 5 minutes and I could send 48. After > then change the broker was still pretty healthy after 5 minutes and i could > send 2265000 to the topic (almost 5x more due high GC pauses). > > All test are passing: mvn clean install -Dactivemq.tests=all -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7091) O(n) Memory consumption when broker has inactive durable subscribes causing OOM
[ https://issues.apache.org/jira/browse/AMQ-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676857#comment-16676857 ] Jamie goodyear commented on AMQ-7091: - [~cshannon], [~gtully] I've reviewed Alan's patch and it looks good. The bump in KahaDB version to 7 on Master would open the door to us doing some more changes to KahaDB/MessageDatabase (perhaps some gentle refactoring). I'd like to know what you think. > O(n) Memory consumption when broker has inactive durable subscribes causing > OOM > --- > > Key: AMQ-7091 > URL: https://issues.apache.org/jira/browse/AMQ-7091 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.7 >Reporter: Alan Protasio >Priority: Major > Attachments: After.png, Before.png, > InactiveDurableSubscriberTest.java, memoryAllocation.jpg > > > Hi :D > One of our brokers was bouncing indefinitely due OOM even though the load > (TPS) was pretty low. > Getting the memory dump I could see that almost 90% of the memory was being > used by > [messageReferences|https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java#L2368] > TreeMap to keep track of what messages were already acked by all Subscribes > in order to delete them. > This seems to be a problem as if the broker has an inactive durable > subscribe, the memory footprint increase proportionally (O) with the number > of messages sent to the topic in question, causing the broker to die due OOM > sooner or later (the high memory footprint continue even after a restart). > You can find attached (memoryAllocation.jpg) a screen shot showing my broker > using 90% of the memory to keep track of those messages, making it barely > usable. > Looking at the code, I could do a change to change the messageReferences to > use a BTreeIndex: > final TreeMap messageReferences = new TreeMap<>(); > + BTreeIndex messageReferences; > Making this change, the memory allocation of the broker stabilized and the > broker didn't run OOM anymore. > Attached you can see the code that I used to reproduce this scenario, also > the memory utilization (HEAP and GC graphs) before and after this change. > Before the change the broker died in 5 minutes and I could send 48. After > then change the broker was still pretty healthy after 5 minutes and i could > send 2265000 to the topic (almost 5x more due high GC pauses). > > All test are passing: mvn clean install -Dactivemq.tests=all -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7091) O(n) Memory consumption when broker has inactive durable subscribes causing OOM
[ https://issues.apache.org/jira/browse/AMQ-7091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676851#comment-16676851 ] Jamie goodyear commented on AMQ-7091: - The patch looks good to me - thank you Alan. > O(n) Memory consumption when broker has inactive durable subscribes causing > OOM > --- > > Key: AMQ-7091 > URL: https://issues.apache.org/jira/browse/AMQ-7091 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.7 >Reporter: Alan Protasio >Priority: Major > Attachments: After.png, Before.png, > InactiveDurableSubscriberTest.java, memoryAllocation.jpg > > > Hi :D > One of our brokers was bouncing indefinitely due OOM even though the load > (TPS) was pretty low. > Getting the memory dump I could see that almost 90% of the memory was being > used by > [messageReferences|https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java#L2368] > TreeMap to keep track of what messages were already acked by all Subscribes > in order to delete them. > This seems to be a problem as if the broker has an inactive durable > subscribe, the memory footprint increase proportionally (O) with the number > of messages sent to the topic in question, causing the broker to die due OOM > sooner or later (the high memory footprint continue even after a restart). > You can find attached (memoryAllocation.jpg) a screen shot showing my broker > using 90% of the memory to keep track of those messages, making it barely > usable. > Looking at the code, I could do a change to change the messageReferences to > use a BTreeIndex: > final TreeMap messageReferences = new TreeMap<>(); > + BTreeIndex messageReferences; > Making this change, the memory allocation of the broker stabilized and the > broker didn't run OOM anymore. > Attached you can see the code that I used to reproduce this scenario, also > the memory utilization (HEAP and GC graphs) before and after this change. > Before the change the broker died in 5 minutes and I could send 48. After > then change the broker was still pretty healthy after 5 minutes and i could > send 2265000 to the topic (almost 5x more due high GC pauses). > > All test are passing: mvn clean install -Dactivemq.tests=all -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653909#comment-16653909
]
Jamie goodyear commented on AMQ-7067:
-
I see the commit message for master, are we putting this on 5.15 too?
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> 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
>Assignee: Gary Tully
>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 data files.
> 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 data file to be
> created.
> Commit the XA transaction. Commit will land on the new data 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] (AMQ-6590) KahaDB index loses track of free pages on unclean shutdown
[ https://issues.apache.org/jira/browse/AMQ-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653549#comment-16653549 ] Jamie goodyear commented on AMQ-6590: - Can we back port this change to the 5.15.x line as well? > KahaDB index loses track of free pages on unclean shutdown > -- > > Key: AMQ-6590 > URL: https://issues.apache.org/jira/browse/AMQ-6590 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.14.3 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.15.0, 5.14.4 > > > I have discovered an issue with the KahaDB index recovery after an unclean > shutdown (OOM error, kill -9, etc) that leads to excessive disk space usage. > Normally on clean shutdown the index stores the known set of free pages to > db.free and reads that in on start up to know which pages can be re-used. On > an unclean shutdown this is not written to disk so on start up the index is > supposed to scan the page file to figure out all of the free pages. > Unfortunately it turns out that this scan of the page file is being done > before the total page count value has been set so when the iterator is > created it always thinks there are 0 pages to scan. > The end result is that every time an unclean shutdown occurs all known free > pages are lost and no longer tracked. This of course means new free pages > have to be allocated and all of the existing space is now lost which will > lead to excessive index file growth over time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16643497#comment-16643497
]
Jamie goodyear commented on AMQ-7067:
-
Thank you :)
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> 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
>Assignee: Gary Tully
>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 data files.
> 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 data file to be
> created.
> Commit the XA transaction. Commit will land on the new data 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] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16643488#comment-16643488
]
Jamie goodyear commented on AMQ-7067:
-
Are the changes we're making to MessageDatabase small enough such that we could
back port the fix to 5.15.x line?
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> 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
>Assignee: Gary Tully
>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 data files.
> 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 data file to be
> created.
> Commit the XA transaction. Commit will land on the new data 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] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16643380#comment-16643380
]
Jamie goodyear commented on AMQ-7067:
-
I'll note that I ran the full unit test suite through using the patch with out
breaking existing test cases.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> 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
>Assignee: Gary Tully
>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 data files.
> 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 data file to be
> created.
> Commit the XA transaction. Commit will land on the new data 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] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16643377#comment-16643377
]
Jamie goodyear commented on AMQ-7067:
-
The following test case can be inserted into the AMQ7067Test file:
[https://gist.github.com/jgoodyear/f3c716aec99c066894047ed996cdcdc9]
Its a non-completing test, it just allows us to setup the scenario, load up a
lot of db page files, than let compaction occur.
In my IDEA environment i can watch the data folder populate:
{code:java}
icbts-2:activemq-unit-tests icbts$ ls target/data/kahadb/
db-1.log db-115.log db-131.log db-148.log db-164.log
db-180.log db-197.log db-212.log db-229.log db-245.log
db-261.log db-278.log db-4.log db-56.log db-72.log
db-89.log
db-10.log db-116.log db-132.log db-149.log db-165.log
db-181.log db-198.log db-213.log db-23.log db-246.log
db-262.log db-279.log db-40.log db-57.log db-73.log
db-9.log
db-100.log db-117.log db-133.log db-15.log db-166.log
db-182.log db-199.log db-214.log db-230.log db-247.log
db-263.log db-28.log db-41.log db-58.log db-74.log
db-90.log
db-101.log db-118.log db-134.log db-150.log db-167.log
db-183.log db-2.log db-215.log db-231.log db-248.log
db-264.log db-280.log db-42.log db-59.log db-75.log
db-91.log
db-102.log db-119.log db-135.log db-151.log db-168.log
db-184.log db-20.log db-216.log db-232.log db-249.log
db-265.log db-281.log db-43.log db-6.log db-76.log
db-92.log
db-103.log db-12.log db-136.log db-152.log db-169.log
db-185.log db-200.log db-217.log db-233.log db-25.log
db-266.log db-282.log db-44.log db-60.log db-77.log
db-93.log
db-104.log db-120.log db-137.log db-153.log db-17.log
db-186.log db-201.log db-218.log db-234.log db-250.log
db-267.log db-29.log db-45.log db-61.log db-78.log
db-94.log
db-105.log db-121.log db-138.log db-154.log db-170.log
db-187.log db-202.log db-219.log db-235.log db-251.log
db-268.log db-3.log db-46.log db-62.log db-79.log
db-95.log
db-106.log db-122.log db-139.log db-155.log db-171.log
db-188.log db-203.log db-22.log db-236.log db-252.log
db-269.log db-30.log db-47.log db-63.log db-8.log
db-96.log
db-107.log db-123.log db-14.log db-156.log db-172.log
db-189.log db-204.log db-220.log db-237.log db-253.log
db-27.log db-31.log db-48.log db-64.log db-80.log
db-97.log
db-108.log db-124.log db-140.log db-157.log db-173.log
db-19.log db-205.log db-221.log db-238.log db-254.log
db-270.log db-32.log db-49.log db-65.log db-81.log
db-98.log
db-109.log db-125.log db-141.log db-158.log db-174.log
db-190.log db-206.log db-222.log db-239.log db-255.log
db-271.log db-33.log db-5.log db-66.log db-82.log
db-99.log
db-11.log db-126.log db-142.log db-159.log db-175.log
db-191.log db-207.log db-223.log db-24.log db-256.log
db-272.log db-34.log db-50.log db-67.log db-83.log
db.data
db-110.log db-127.log db-143.log db-16.log db-176.log
db-192.log db-208.log db-224.log db-240.log db-257.log
db-273.log db-35.log db-51.log db-68.log db-84.log
db.redo
db-111.log db-128.log db-144.log db-160.log db-177.log
db-193.log db-209.log db-225.log db-241.log db-258.log
db-274.log db-36.log db-52.log db-69.log db-85.log
lock
db-112.log db-129.log db-145.log db-161.log db-178.log
db-194.log db-21.log db-226.log db-242.log db-259.log
db-275.log db-37.log db-53.log db-7.log db-86.log
db-113.log db-13.log db-146.log db-162.log db-179.log
db-195.log db-210.log db-227.log db-243.log db-26.log
db-276.log db-38.log db-54.log db-70.log db-87.log
db-114.log db-130.log db-147.log db-163.log db-18.log
db-196.log db-211.log
[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16642593#comment-16642593
]
Jamie goodyear commented on AMQ-7067:
-
I've updated the PR after our discussion on IRC.
All locations are updated on commit/rollback/prepare.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> 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] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16642067#comment-16642067
]
Jamie goodyear commented on AMQ-7067:
-
Hi Gary,
The crux of this patch is to prevent the GC of the PageFile such that on
recovery Commit/Rollback can be processed as per existing logic. No changes
to the existing processors is required.
Please note, the problem was happening with Non-XA transactions as well, hence
the addition of non-xa unit tests. The commit/rollback would get lost via GC,
by updating the code to mark those index to not be GC'd the behavoir is fixed
for both XA and Non-XA transactions. Adding in a new structure and logic to
track the TX lifeCycle would not touch the Non-XA transaction case.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> 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] [Updated] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jamie goodyear updated AMQ-7067:
Flags: Patch
Patch Info: Patch Available
> 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] [Updated] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.
[
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.
[
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.
[
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] [Comment Edited] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.
[
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.
[
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] [Updated] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.
[
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.
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] (AMQ-7033) Broker not cleaning up session during high message rate
[
https://issues.apache.org/jira/browse/AMQ-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16616693#comment-16616693
]
Jamie goodyear commented on AMQ-7033:
-
Please supply more information about the broker and client(s).
activemq.xml, any parameters passed in via env/start scripts.
Sample client(s).
What is the broker topology? Single broker, NOB, store & forward, etc.
> Broker not cleaning up session during high message rate
> ---
>
> Key: AMQ-7033
> URL: https://issues.apache.org/jira/browse/AMQ-7033
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.15.4
>Reporter: Yogeshkumar More
>Priority: Major
>
> When we try to send large number of messages from multiple connections we see
> that some of the sockets don't get cleaned up. We initially thought
> [AMQ-6561|https://issues.apache.org/jira/browse/AMQ-6561] AMQ-6561 should
> have fixed this. But even after upgrading the version to 5.15.4 we see socket
> leak. Following stack trace proves that there is some blocking which is not
> clearing up the sockets. This grows gradually and causes out of memory issue
> as we are using non-persistent, embedded broker.
>
> {code:java}
> "ActiveMQ InactivityMonitor Worker" #17953 daemon prio=5 os_prio=0
> tid=0x7fdc64017800 nid=0xb27f waiting for monitor entry
> [0x7fda48fce000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.activemq.broker.TransportConnection.stopAsync(TransportConnection.java:1136)
> - waiting to lock <0x0006c2339d58> (a
> org.apache.activemq.broker.TransportConnection)
> at
> org.apache.activemq.broker.TransportConnection.stopAsync(TransportConnection.java:1131)
> at
> org.apache.activemq.broker.TransportConnection.serviceTransportException(TransportConnection.java:239)
> at
> org.apache.activemq.broker.TransportConnection$1.onException(TransportConnection.java:210)
> at
> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:114)
> at
> org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:114)
> at
> org.apache.activemq.transport.WireFormatNegotiator.onException(WireFormatNegotiator.java:173)
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.onException(AbstractInactivityMonitor.java:345)
> at
> org.apache.activemq.transport.AbstractInactivityMonitor$1$1.run(AbstractInactivityMonitor.java:92)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-6876) Project website does not render correctly over HTTPS in Firefox
[
https://issues.apache.org/jira/browse/AMQ-6876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16616691#comment-16616691
]
Jamie goodyear commented on AMQ-6876:
-
Looks like those resources are available via HTTPS.
Not sure whom would have perms to setup the wiki to publish the site with HTTPS
links enforced.
https://wiki.apache.org/httpd/RewriteHTTPToHTTPS
> Project website does not render correctly over HTTPS in Firefox
> ---
>
> Key: AMQ-6876
> URL: https://issues.apache.org/jira/browse/AMQ-6876
> Project: ActiveMQ
> Issue Type: Bug
> Components: Documentation
>Reporter: Jiri Daněk
>Priority: Critical
>
> Compare https://activemq.apache.org/mailing-lists.html (wrong)
> and http://activemq.apache.org/mailing-lists.html (correct).
> The HTTPS version is missing CSS styles.
> Browser log:
> {code}
> Blocked loading mixed active content
> “http://activemq.apache.org/styles/site.css”
> [Learn More]
> mailing-lists.html
> Blocked loading mixed active content
> “http://activemq.apache.org/styles/type-settings.css”
> [Learn More]
> mailing-lists.html
> Blocked loading mixed active content
> “http://activemq.apache.org/styles/prototype.js”
> [Learn More]
> mailing-lists.html
> Blocked loading mixed active content
> “http://activemq.apache.org/styles/rico.js”
> [Learn More]
> mailing-lists.html
> Blocked loading mixed active content
> “http://activemq.apache.org/styles/site.js”
> [Learn More]
> mailing-lists.html
> Blocked loading mixed active content
> “http://activemq.apache.org/styles/site.css”
> [Learn More]
> mailing-lists.html
> Blocked loading mixed active content
> “http://activemq.apache.org/styles/type-settings.css”
> [Learn More]
> mailing-lists.html
> Blocked loading mixed active content
> “http://activemq.apache.org/styles/prototype.js”
> [Learn More]
> mailing-lists.html
> Loading failed for the
[jira] [Created] (AMQ-7053) Update Jetty to version 9.2.26.v20180806
Jamie goodyear created AMQ-7053: --- Summary: Update Jetty to version 9.2.26.v20180806 Key: AMQ-7053 URL: https://issues.apache.org/jira/browse/AMQ-7053 Project: ActiveMQ Issue Type: Task Reporter: Jamie goodyear Fix For: 5.16.0 Jetty 9.2.25.v20180606 is picked up by owasp utility, update to 9.2.26.v20180806 to remove issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6224) The Web Console Exception
[
https://issues.apache.org/jira/browse/AMQ-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16616264#comment-16616264
]
Jamie goodyear commented on AMQ-6224:
-
Hi,
I've tested the above scenario with ActiveMQ 5.15.6.
Broker A with openwire port 61616, and web console port 8161.
Broker B with openwire port 61618, and web console port 8162.
Both Brokers start up, and both web consoles were operational.
Given the AMQ version bump, could you confirm the error you encountered is
resolved?
> The Web Console Exception
> -
>
> Key: AMQ-6224
> URL: https://issues.apache.org/jira/browse/AMQ-6224
> Project: ActiveMQ
> Issue Type: Bug
> Components: webconsole
>Affects Versions: 5.13.2, 5.14.3
> Environment: java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Linux 2.6.32-573.3.1.el6.x86_64 #1 SMP Thu Aug 13 10:38:46 PDT 2015 x86_64
> x86_64 x86_64 GNU/Linux
>Reporter: Ren PengFei
>Priority: Major
> Labels: console, web
>
> i create 2 broker within the same machine and with the same os user.
> they named : "amq_pro" and "amq_test".
> They all work very well.
> but,the webconsole has a problem.
> the first started borker'webconsole is fine,
> the second started borker'webconsole has an exception occurred processing JSP
> page.
> org.apache.jasper.JasperException: An exception occurred processing JSP page
> /topics.jsp at line 55
> 52:
> 53:
> 54:
> 55: value="${row.name}" />
> 56: value="topic"/>"> length="50"/>
> 57:
> 58:
> Stacktrace:
> at
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:568)[apache-jsp-8.0.9.M3.jar:2.3]
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:470)[apache-jsp-8.0.9.M3.jar:2.3]
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:405)[apache-jsp-8.0.9.M3.jar:2.3]
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:349)[apache-jsp-8.0.9.M3.jar:2.3]
> at
> org.eclipse.jetty.jsp.JettyJspServlet.service(JettyJspServlet.java:107)[apache-jsp-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:729)[tomcat-servlet-api-8.0.24.jar:]
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)[spring-web-4.1.9.RELEASE.jar:4.1.9.RELEASE]
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)[spring-web-4.1.9.RELEASE.jar:4.1.9.RELEASE]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> org.apache.activemq.web.SessionFilter.doFilter(SessionFilter.java:45)[activemq-web-5.13.2.jar:5.13.2]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> org.apache.activemq.web.filter.ApplicationContextFilter.doFilter(ApplicationContextFilter.java:102)[file:/home/egagamq/activemq/apache-activemq-5.13.2_2/webapps/admin/WEB-INF/classes/:]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:542)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)[jetty-all-9.2.13.v20150730.jar:9.2.13.v20150730]
> at
>
[jira] [Updated] (AMQ-7032) Update Shiro to version 1.2.6
[ https://issues.apache.org/jira/browse/AMQ-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-7032: Flags: Patch Patch Info: Patch Available PR submitted [https://github.com/apache/activemq/pull/296] Tested build, unit tests, and activemq-shire module. Removes flagged issue from Owasp report. > Update Shiro to version 1.2.6 > - > > Key: AMQ-7032 > URL: https://issues.apache.org/jira/browse/AMQ-7032 > Project: ActiveMQ > Issue Type: Task >Reporter: Jamie goodyear >Priority: Major > Fix For: 5.16.0 > > > Shiro-core 1.2.4 is picked up by owasp utility, update to 1.2.6 to remove > issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-7032) Update Shiro to version 1.2.6
Jamie goodyear created AMQ-7032: --- Summary: Update Shiro to version 1.2.6 Key: AMQ-7032 URL: https://issues.apache.org/jira/browse/AMQ-7032 Project: ActiveMQ Issue Type: Task Reporter: Jamie goodyear Fix For: 5.16.0 Shiro-core 1.2.4 is picked up by owasp utility, update to 1.2.6 to remove issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7026) Update Derby version to 10.14.2.0
[ https://issues.apache.org/jira/browse/AMQ-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561817#comment-16561817 ] Jamie goodyear commented on AMQ-7026: - Thank you for applying my patch > Update Derby version to 10.14.2.0 > - > > Key: AMQ-7026 > URL: https://issues.apache.org/jira/browse/AMQ-7026 > Project: ActiveMQ > Issue Type: Task >Reporter: Jamie goodyear >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 5.16.0, 5.15.5 > > Attachments: AMQ7026.patch > > > Update Derby version to 10.14.2.0. > Current Derby version is picked up by owasp scan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7026) Update Derby version to 10.14.2.0
[ https://issues.apache.org/jira/browse/AMQ-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-7026: Patch Info: Patch Available > Update Derby version to 10.14.2.0 > - > > Key: AMQ-7026 > URL: https://issues.apache.org/jira/browse/AMQ-7026 > Project: ActiveMQ > Issue Type: Task >Reporter: Jamie goodyear >Priority: Major > Fix For: 5.16.0 > > Attachments: AMQ7026.patch > > > Update Derby version to 10.14.2.0. > Current Derby version is picked up by owasp scan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7026) Update Derby version to 10.14.2.0
[ https://issues.apache.org/jira/browse/AMQ-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-7026: Attachment: AMQ7026.patch > Update Derby version to 10.14.2.0 > - > > Key: AMQ-7026 > URL: https://issues.apache.org/jira/browse/AMQ-7026 > Project: ActiveMQ > Issue Type: Task >Reporter: Jamie goodyear >Priority: Major > Fix For: 5.16.0 > > Attachments: AMQ7026.patch > > > Update Derby version to 10.14.2.0. > Current Derby version is picked up by owasp scan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-7026) Update Derby version to 10.14.2.0
Jamie goodyear created AMQ-7026: --- Summary: Update Derby version to 10.14.2.0 Key: AMQ-7026 URL: https://issues.apache.org/jira/browse/AMQ-7026 Project: ActiveMQ Issue Type: Task Reporter: Jamie goodyear Fix For: 5.16.0 Update Derby version to 10.14.2.0. Current Derby version is picked up by owasp scan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7023) Add OWASP Dependency Check to build (all open source projects everywhere)
[ https://issues.apache.org/jira/browse/AMQ-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16560871#comment-16560871 ] Jamie goodyear commented on AMQ-7023: - Hi, I've added a PR to provide a Profile for executing the owasp plugin: [https://github.com/apache/activemq/pull/294] The Jenkins job seems to be having trouble, being unable to fetch HEAD to run a build. The way i see this plugin being used is as follows: mvn -Powasp -Dtest=false -DfailIfNoTests=false clean install This allows AMQ to quickly build, and verify via owasp. > Add OWASP Dependency Check to build (all open source projects everywhere) > - > > Key: AMQ-7023 > URL: https://issues.apache.org/jira/browse/AMQ-7023 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 5.15.3, 5.15.4 > Environment: All development, build, test, environments. >Reporter: Albert Baker >Priority: Major > Labels: build, easyfix, security > Original Estimate: 1h > Remaining Estimate: 1h > > Please add OWASP Dependency Check to the ActiveMQ build (pom.xml). OWASP DC > makes an outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) > to perform a lookup for each dependant .jar > OWASP Dependency check : > [https://www.owasp.org/index.php/OWASP_Dependency_Check > |https://www.owasp.org/index.php/OWASP_Dependency_Check]has plug-ins for most > Java build/make types (ant, maven, gradle). Add the appropriate command to > the nightly build to generate a report of all known vulnerabilities in > any/all third party libraries/dependencies that get pulled in. > Generating this report nightly/weekly will help inform the project's > development team if any dependant libraries have a reported known > vulneraility. Project teams that keep up with removing vulnerabilities on a > weekly basis weekly basis will help protect businesses that rely on these > open source componets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6990) ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559826#comment-16559826 ] Jamie goodyear commented on AMQ-6990: - I attached patch files 3 days ago :) > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > > > Key: AMQ-6990 > URL: https://issues.apache.org/jira/browse/AMQ-6990 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > Attachments: AMQ-6990-AMQ-5.15.x.patch, AMQ-6990-AMQ-master.patch > > > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2014-0114 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar > in Apache Struts 1.x through 1.3.10 and in other products requiring > commons-beanutils > through 1.9.2, does not suppress the class property, which allows remote > attackers to "manipulate" the ClassLoader and execute arbitrary code via the > class parameter, as > demonstrated by the passing of this parameter to the getClass method of the > ActionForm object in Struts 1. > BID - 67121 > BUGTRAQ - 20141205 NEW: VMSA-2014-0012 - VMware vSphere product updates > address security vulnerabilities > CONFIRM - http://advisories.mageia.org/MGASA-2014-0219.html > CONFIRM - > http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674128 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674812 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675266 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675387 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675689 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675898 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675972 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676091 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676303 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676375 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676931 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21677110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg27042296 > CONFIRM - http://www.ibm.com/support/docview.wss?uid=swg21675496 > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2014-0008.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6991) ActiveMQ 5.15.4 hadoop-core-1.0.0.jar which has two high severity CVEs against it.
[ https://issues.apache.org/jira/browse/AMQ-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553622#comment-16553622 ] Jamie goodyear commented on AMQ-6991: - The hadoop library is only used for testing LevelDB: ./activemq-leveldb-store/src/test/scala/org/apache/activemq/leveldb/dfs/DFSLevelDBClient.scala ./activemq-leveldb-store/src/test/scala/org/apache/activemq/leveldb/dfs/DFSLevelDBStore.scala ./activemq-leveldb-store/src/test/scala/org/apache/activemq/leveldb/test/TestingHDFSServer.scala ./activemq-leveldb-store/src/test/scala/org/apache/activemq/leveldb/test/DFSLevelDBFastEnqueueTest.scala The impact of using that library in a unit test is minimal - I'd suggest we could close this card as not-an-issue. > ActiveMQ 5.15.4 hadoop-core-1.0.0.jar which has two high severity CVEs > against it. > -- > > Key: AMQ-6991 > URL: https://issues.apache.org/jira/browse/AMQ-6991 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 hadoop-core-1.0.0.jar which has two high severity CVEs > against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2012-4449 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-327 Use of a Broken or Risky Cryptographic Algorithm > Apache Hadoop before 0.23.4, 1.x before 1.0.4, and 2.x before 2.0.2 generate > token passwords using a 20-bit secret when Kerberos security features are > enabled, which > makes it easier for context-dependent attackers to crack secret keys via a > brute-force attack. > CONFIRM - > https://www.cloudera.com/documentation/other/security-bulletins/topics/csb_topic_1.html#topic_1_0 > MLIST - [hadoop-general] 20121012 [ANNOUNCE] Hadoop-1.0.4 release, with > Security fix > Vulnerable Software & Versions: (show all) > cpe:/a:apache:hadoop:1.0.0 > CVE-2017-3162 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > HDFS clients interact with a servlet on the DataNode to browse the HDFS > namespace. The NameNode is provided as a query parameter that is not > validated in Apache > Hadoop before 2.7.0. > BID - 98017 > MLIST - [hadoop-common-dev] 20170425 CVE-2017-3162: Apache Hadoop DataNode > web UI vulnerability > Vulnerable Software & Versions: > cpe:/a:apache:hadoop:2.6.5 and all previous versions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-6990) ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-6990: Attachment: AMQ-6990-AMQ-master.patch > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > > > Key: AMQ-6990 > URL: https://issues.apache.org/jira/browse/AMQ-6990 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > Attachments: AMQ-6990-AMQ-5.15.x.patch, AMQ-6990-AMQ-master.patch > > > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2014-0114 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar > in Apache Struts 1.x through 1.3.10 and in other products requiring > commons-beanutils > through 1.9.2, does not suppress the class property, which allows remote > attackers to "manipulate" the ClassLoader and execute arbitrary code via the > class parameter, as > demonstrated by the passing of this parameter to the getClass method of the > ActionForm object in Struts 1. > BID - 67121 > BUGTRAQ - 20141205 NEW: VMSA-2014-0012 - VMware vSphere product updates > address security vulnerabilities > CONFIRM - http://advisories.mageia.org/MGASA-2014-0219.html > CONFIRM - > http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674128 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674812 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675266 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675387 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675689 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675898 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675972 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676091 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676303 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676375 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676931 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21677110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg27042296 > CONFIRM - http://www.ibm.com/support/docview.wss?uid=swg21675496 > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2014-0008.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-6990) ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-6990: Attachment: AMQ-6990-AMQ-5.15.x.patch > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > > > Key: AMQ-6990 > URL: https://issues.apache.org/jira/browse/AMQ-6990 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > Attachments: AMQ-6990-AMQ-5.15.x.patch > > > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2014-0114 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar > in Apache Struts 1.x through 1.3.10 and in other products requiring > commons-beanutils > through 1.9.2, does not suppress the class property, which allows remote > attackers to "manipulate" the ClassLoader and execute arbitrary code via the > class parameter, as > demonstrated by the passing of this parameter to the getClass method of the > ActionForm object in Struts 1. > BID - 67121 > BUGTRAQ - 20141205 NEW: VMSA-2014-0012 - VMware vSphere product updates > address security vulnerabilities > CONFIRM - http://advisories.mageia.org/MGASA-2014-0219.html > CONFIRM - > http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674128 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674812 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675266 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675387 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675689 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675898 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675972 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676091 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676303 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676375 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676931 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21677110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg27042296 > CONFIRM - http://www.ibm.com/support/docview.wss?uid=swg21675496 > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2014-0008.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6990) ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity CVE against it.
[
https://issues.apache.org/jira/browse/AMQ-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553590#comment-16553590
]
Jamie goodyear commented on AMQ-6990:
-
Upon closer examination, hadoop is being used by the scala unit tests in
activemq-leveldb-store.
Adding an exclusion:
{color:#e8bf6a}
{color}{color:#e8bf6a}
{color}commons-beanutils{color:#e8bf6a}
{color}{color:#e8bf6a}
{color}commons-beanutils-core{color:#e8bf6a}
{color}{color:#e8bf6a}{color}
To the hadoop dependency removed commons-beanutils-core 1.8.0 from ActiveMQ
build.
> ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity
> CVE against it.
>
>
> Key: AMQ-6990
> URL: https://issues.apache.org/jira/browse/AMQ-6990
> Project: ActiveMQ
> Issue Type: Bug
> Components: webconsole
>Affects Versions: 5.15.4
> Environment: Environment: Customer environment is a mix of Linux and
> Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of
> having even one high severity CVE in thier environment. The cost of
> (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed
> systems.
>Reporter: Albert Baker
>Priority: Blocker
>
> ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity
> CVE against it.
> Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running
> the OWASP report.
> CVE-2014-0114 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
> CWE: CWE-20 Improper Input Validation
> Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar
> in Apache Struts 1.x through 1.3.10 and in other products requiring
> commons-beanutils
> through 1.9.2, does not suppress the class property, which allows remote
> attackers to "manipulate" the ClassLoader and execute arbitrary code via the
> class parameter, as
> demonstrated by the passing of this parameter to the getClass method of the
> ActionForm object in Struts 1.
> BID - 67121
> BUGTRAQ - 20141205 NEW: VMSA-2014-0012 - VMware vSphere product updates
> address security vulnerabilities
> CONFIRM - http://advisories.mageia.org/MGASA-2014-0219.html
> CONFIRM -
> http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674128
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674812
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675266
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675387
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675689
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675898
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675972
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676091
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676110
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676303
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676375
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676931
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21677110
> CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg27042296
> CONFIRM - http://www.ibm.com/support/docview.wss?uid=swg21675496
> CONFIRM -
> http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html
> CONFIRM -
> http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html
> CONFIRM -
> http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html
> CONFIRM -
> http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html
> CONFIRM -
> http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html
> CONFIRM -
> http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html
> CONFIRM - http://www.vmware.com/security/advisories/VMSA-2014-0008.html
> CONFIRM - http://www.vmware.com/security/advisories/VMSA-2
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-6990) ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553555#comment-16553555 ] Jamie goodyear commented on AMQ-6990: - We need a release of hadoop which does not include the commons-beanutil 1.8.0 > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > > > Key: AMQ-6990 > URL: https://issues.apache.org/jira/browse/AMQ-6990 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2014-0114 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar > in Apache Struts 1.x through 1.3.10 and in other products requiring > commons-beanutils > through 1.9.2, does not suppress the class property, which allows remote > attackers to "manipulate" the ClassLoader and execute arbitrary code via the > class parameter, as > demonstrated by the passing of this parameter to the getClass method of the > ActionForm object in Struts 1. > BID - 67121 > BUGTRAQ - 20141205 NEW: VMSA-2014-0012 - VMware vSphere product updates > address security vulnerabilities > CONFIRM - http://advisories.mageia.org/MGASA-2014-0219.html > CONFIRM - > http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674128 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674812 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675266 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675387 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675689 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675898 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675972 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676091 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676303 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676375 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676931 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21677110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg27042296 > CONFIRM - http://www.ibm.com/support/docview.wss?uid=swg21675496 > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2014-0008.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (AMQ-6990) ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553551#comment-16553551 ] Jamie goodyear edited comment on AMQ-6990 at 7/23/18 11:33 PM: --- AMQ itself does not import commons-beanutil, however it is present as a transitive dep: [INFO] +- org.apache.hadoop:hadoop-core:jar:1.0.0:compile [INFO] | - commons-configuration:commons-configuration:jar:1.6:compile [INFO] | +- commons-collections:commons-collections:jar:3.2.2:compile [INFO] | +- commons-logging:commons-logging:jar:1.2:compile [INFO] | +- commons-digester:commons-digester:jar:1.8:compile [INFO] | | - commons-beanutils:commons-beanutils:jar:1.9.3:compile [INFO] | - commons-beanutils:commons-beanutils-core:jar:1.8.0:compile [INFO] | \- org.apache.hadoop:hadoop-core:jar:1.0.0:compile [INFO] | \- commons-configuration:commons-configuration:jar:1.6:compile [INFO] | +- commons-digester:commons-digester:jar:1.8:compile [INFO] | | \- commons-beanutils:commons-beanutils:jar:1.9.3:compile [INFO] | \- commons-beanutils:commons-beanutils-core:jar:1.8.0:compile was (Author: jgoodyear): AMQ itself does not import commons-beanutil, however it is present as a transitive dep: [INFO] +- org.apache.hadoop:hadoop-core:jar:1.0.0:compile [INFO] | \- commons-configuration:commons-configuration:jar:1.6:compile [INFO] | +- commons-collections:commons-collections:jar:3.2.2:compile [INFO] | +- commons-logging:commons-logging:jar:1.2:compile [INFO] | +- commons-digester:commons-digester:jar:1.8:compile [INFO] | | \- commons-beanutils:commons-beanutils:jar:1.9.3:compile [INFO] | \- commons-beanutils:commons-beanutils-core:jar:1.8.0:compile > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > > > Key: AMQ-6990 > URL: https://issues.apache.org/jira/browse/AMQ-6990 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2014-0114 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar > in Apache Struts 1.x through 1.3.10 and in other products requiring > commons-beanutils > through 1.9.2, does not suppress the class property, which allows remote > attackers to "manipulate" the ClassLoader and execute arbitrary code via the > class parameter, as > demonstrated by the passing of this parameter to the getClass method of the > ActionForm object in Struts 1. > BID - 67121 > BUGTRAQ - 20141205 NEW: VMSA-2014-0012 - VMware vSphere product updates > address security vulnerabilities > CONFIRM - http://advisories.mageia.org/MGASA-2014-0219.html > CONFIRM - > http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674128 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674812 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675266 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675387 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675689 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675898 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675972 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676091 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676303 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676375 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676931 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21677110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg27042296 > CONFIRM - http://www.ibm.com/support/docview.wss?uid=swg21675496 > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html > CONFIRM - >
[jira] [Commented] (AMQ-6990) ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553551#comment-16553551 ] Jamie goodyear commented on AMQ-6990: - AMQ itself does not import commons-beanutil, however it is present as a transitive dep: [INFO] +- org.apache.hadoop:hadoop-core:jar:1.0.0:compile [INFO] | \- commons-configuration:commons-configuration:jar:1.6:compile [INFO] | +- commons-collections:commons-collections:jar:3.2.2:compile [INFO] | +- commons-logging:commons-logging:jar:1.2:compile [INFO] | +- commons-digester:commons-digester:jar:1.8:compile [INFO] | | \- commons-beanutils:commons-beanutils:jar:1.9.3:compile [INFO] | \- commons-beanutils:commons-beanutils-core:jar:1.8.0:compile > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > > > Key: AMQ-6990 > URL: https://issues.apache.org/jira/browse/AMQ-6990 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 commons-beanutils-core-1.8.0.jar which has one high severity > CVE against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2014-0114 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar > in Apache Struts 1.x through 1.3.10 and in other products requiring > commons-beanutils > through 1.9.2, does not suppress the class property, which allows remote > attackers to "manipulate" the ClassLoader and execute arbitrary code via the > class parameter, as > demonstrated by the passing of this parameter to the getClass method of the > ActionForm object in Struts 1. > BID - 67121 > BUGTRAQ - 20141205 NEW: VMSA-2014-0012 - VMware vSphere product updates > address security vulnerabilities > CONFIRM - http://advisories.mageia.org/MGASA-2014-0219.html > CONFIRM - > http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674128 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21674812 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675266 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675387 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675689 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675898 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21675972 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676091 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676303 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676375 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21676931 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg21677110 > CONFIRM - http://www-01.ibm.com/support/docview.wss?uid=swg27042296 > CONFIRM - http://www.ibm.com/support/docview.wss?uid=swg21675496 > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2014-0008.html > CONFIRM - http://www.vmware.com/security/advisories/VMSA-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6995) ActiveMQ 5.15.4 activemq-ra-5.15.4.jar which has two high severity CVEs against it.
[ https://issues.apache.org/jira/browse/AMQ-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553235#comment-16553235 ] Jamie goodyear commented on AMQ-6995: - Hi, I believe this is a misfiled ticket. Hawtio is not controlled by Apache ActiveMQ. > ActiveMQ 5.15.4 activemq-ra-5.15.4.jar which has two high severity CVEs > against it. > --- > > Key: AMQ-6995 > URL: https://issues.apache.org/jira/browse/AMQ-6995 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > Environment: Environment: Customer environment is a mix of Linux and > Windows, Gig-LAN (Medical & Finacial services). Will not accept the risk of > having even one high severity CVE in thier environment. The cost of > (SOX/HIPPA) insurence is too high to allow even one CVE with newly deployed > systems. >Reporter: Albert Baker >Priority: Blocker > > CVE-2015-5183 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-254 Security Features > The Hawtio console in A-MQ does not set HTTPOnly or Secure attributes on > cookies. > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1249182 > Vulnerable Software & Versions: > cpe:/a:apache:activemq:- > CVE-2015-5184 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-254 Security Features > The Hawtio console in A-MQ allows remote attackers to obtain sensitive > information and perform other unspecified impact. > CONFIRM - https://bugzilla.redhat.c -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7015) Startup performance improvement when log contains prepared transactions.
[ https://issues.apache.org/jira/browse/AMQ-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549638#comment-16549638 ] Jamie goodyear commented on AMQ-7015: - I've updated [http://activemq.apache.org/kahadb.html] to reference the new optional parameter. > Startup performance improvement when log contains prepared transactions. > > > Key: AMQ-7015 > URL: https://issues.apache.org/jira/browse/AMQ-7015 > Project: ActiveMQ > Issue Type: New Feature >Affects Versions: 5.15.4 >Reporter: Heath Kesler >Priority: Minor > > I have a KahaDB that's performing a recovery on each startup. > Digging deeper into it I've found that the issue is that the db.log contains > prepared transactions. > The MessageDatabase will discard those entries in memory, however it does not > remove transaction info from those messages (I believe that's by design). So > on each restart, the broker will find those entries and again discard them in > memory. > If I access the broker via JMX, I can go to the prepared XAs and execute a > clear on them one by one. > When i restart my broker, i don't have a recovery attempted again. > Performing a remove operation for each message can be very time consuming, so > i'd like to introduce an optional parameter to allow all prepared XAs to be > removed on recovery. > Please see my forth coming patch with unit test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7013) XATransactionID hash function may generate duplicates.
[ https://issues.apache.org/jira/browse/AMQ-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547978#comment-16547978 ] Jamie goodyear commented on AMQ-7013: - Please see PR'd unit test: [https://github.com/apache/activemq/pull/288] The hash function was bad, returning 131077. After discussing with Chrino on apache-activemq IRC room, decided to try JenkinsHash to perform hash generation. Now we get unique hashes in this scenario. > XATransactionID hash function may generate duplicates. > -- > > Key: AMQ-7013 > URL: https://issues.apache.org/jira/browse/AMQ-7013 > Project: ActiveMQ > Issue Type: Bug >Reporter: Jamie goodyear >Priority: Major > > XATransactionID hash function may generate duplicates. > Scenario: > XID formatId, GlobalTransaction, and BranchQualifier values are identical for > many entries. We need to use a better hash function to avoid populating a map > with many entries in the same bucket (results in bucket having O(n) > performance on recovery). > Example using existing Hash Function: > 2018-07-18 06:13:29,866 | INFO | Recovering from the journal @1:28 | > org.apache.activemq.store.kahadb.MessageDatabase | main > 2018-07-18 06:23:04,070 | INFO | @2:484592, 10 entries recovered .. | > org.apache.activemq.store.kahadb.MessageDatabase | main > 2018-07-18 06:23:04,099 | INFO | Recovery replayed 100453 operations from > the journal in 574.233 seconds. | > org.apache.activemq.store.kahadb.MessageDatabase | main > Using JenkinsHash: > 2018-07-18 10:58:43,713 | INFO | Recovering from the journal @1:28 | > org.apache.activemq.store.kahadb.MessageDatabase | main > 2018-07-18 10:58:51,302 | INFO | @2:484592, 10 entries recovered .. | > org.apache.activemq.store.kahadb.MessageDatabase | main > 2018-07-18 10:58:51,329 | INFO | Recovery replayed 100453 operations from > the journal in 7.618 seconds. | > org.apache.activemq.store.kahadb.MessageDatabase | main -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-7013) XATransactionID hash function may generate duplicates.
Jamie goodyear created AMQ-7013: --- Summary: XATransactionID hash function may generate duplicates. Key: AMQ-7013 URL: https://issues.apache.org/jira/browse/AMQ-7013 Project: ActiveMQ Issue Type: Bug Reporter: Jamie goodyear XATransactionID hash function may generate duplicates. Scenario: XID formatId, GlobalTransaction, and BranchQualifier values are identical for many entries. We need to use a better hash function to avoid populating a map with many entries in the same bucket (results in bucket having O(n) performance on recovery). Example using existing Hash Function: 2018-07-18 06:13:29,866 | INFO | Recovering from the journal @1:28 | org.apache.activemq.store.kahadb.MessageDatabase | main 2018-07-18 06:23:04,070 | INFO | @2:484592, 10 entries recovered .. | org.apache.activemq.store.kahadb.MessageDatabase | main 2018-07-18 06:23:04,099 | INFO | Recovery replayed 100453 operations from the journal in 574.233 seconds. | org.apache.activemq.store.kahadb.MessageDatabase | main Using JenkinsHash: 2018-07-18 10:58:43,713 | INFO | Recovering from the journal @1:28 | org.apache.activemq.store.kahadb.MessageDatabase | main 2018-07-18 10:58:51,302 | INFO | @2:484592, 10 entries recovered .. | org.apache.activemq.store.kahadb.MessageDatabase | main 2018-07-18 10:58:51,329 | INFO | Recovery replayed 100453 operations from the journal in 7.618 seconds. | org.apache.activemq.store.kahadb.MessageDatabase | main -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7011) Activemq 5.15.4 Stomp protocol allowed to enter deadlock via dispatch sync
[
https://issues.apache.org/jira/browse/AMQ-7011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544650#comment-16544650
]
Jamie goodyear commented on AMQ-7011:
-
I'm made a PR for this card:
[https://github.com/apache/activemq/pulls]
https://github.com/apache/activemq/pull/287
> Activemq 5.15.4 Stomp protocol allowed to enter deadlock via dispatch sync
> --
>
> Key: AMQ-7011
> URL: https://issues.apache.org/jira/browse/AMQ-7011
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Jamie goodyear
>Priority: Major
>
> Activemq 5.15.4 Stomp protocol allowed to enter deadlock via dispatch sync.
> Scenario:
> Stomp client setting the following:
> header.put("id", subId);
> header.put("activemq.dispatchAsync", "false");
> The setup of locks between TopicSubscription and MutexTransport while using
> Stomp in sync mode can result in a Deadlock as found below (Add and Destroy
> calls processing), each lock is identified by a + or * to show lock order in
> each stack trace.
>
Found one Java-level deadlock:
> =
> "ActiveMQ Transport: tcp:///127.0.0.1:58303@61613":
> waiting to lock monitor 0x7f9c565d4d28 (object 0x0007acc44708, a
> java.lang.Object),
> which is held by "ActiveMQ Transport: tcp:///127.0.0.1:58302@61613"
> "ActiveMQ Transport: tcp:///127.0.0.1:58302@61613":
> waiting for ownable synchronizer 0x0007ac872730, (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "ActiveMQ Transport: tcp:///127.0.0.1:58303@61613"
> Java stack information for the threads listed above:
> ===
> "ActiveMQ Transport: tcp:///127.0.0.1:58303@61613":
> ++ at
> org.apache.activemq.broker.region.TopicSubscription.destroy(TopicSubscription.java:757)
> - waiting to lock <0x0007acc44708> (a java.lang.Object)
> at
> org.apache.activemq.broker.region.AbstractRegion.destroySubscription(AbstractRegion.java:488)
> at
> org.apache.activemq.broker.jmx.ManagedTopicRegion.destroySubscription(ManagedTopicRegion.java:52)
> at
> org.apache.activemq.broker.region.AbstractRegion.removeConsumer(AbstractRegion.java:480)
> at
> org.apache.activemq.broker.region.TopicRegion.removeConsumer(TopicRegion.java:206)
> at
> org.apache.activemq.broker.region.RegionBroker.removeConsumer(RegionBroker.java:429)
> at
> org.apache.activemq.broker.jmx.ManagedRegionBroker.removeConsumer(ManagedRegionBroker.java:258)
> at
> org.apache.activemq.broker.BrokerFilter.removeConsumer(BrokerFilter.java:139)
> at
> org.apache.activemq.advisory.AdvisoryBroker.removeConsumer(AdvisoryBroker.java:352)
> at
> org.apache.activemq.broker.BrokerFilter.removeConsumer(BrokerFilter.java:139)
> at
> org.apache.activemq.broker.BrokerFilter.removeConsumer(BrokerFilter.java:139)
> at
> org.apache.activemq.broker.BrokerFilter.removeConsumer(BrokerFilter.java:139)
> at
> org.apache.activemq.broker.TransportConnection.processRemoveConsumer(TransportConnection.java:729)
> at
> org.apache.activemq.broker.TransportConnection.processRemoveSession(TransportConnection.java:768)
> at
> org.apache.activemq.broker.TransportConnection.processRemoveConnection(TransportConnection.java:879)
> - locked <0x0007ac999f00> (a
> org.apache.activemq.broker.jmx.ManagedTransportConnection)
> at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:73)
> at
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:330)
> at
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:194)
> * at
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:45)
> at
> org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:301)
> at
> org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:97)
> at
> org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:202)
> at
> org.apache.activemq.transport.stomp.ProtocolConverter.onStompDisconnect(ProtocolConverter.java:838)
> at
> org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:267)
> at
> org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:85)
> at
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
> at
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:233)
> at
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)
> at java.lang.Thread.run(Thread.java:748)
> "ActiveMQ Transport: tcp:///127.0.0.1:58302@61613":
> at
[jira] [Created] (AMQ-7011) Activemq 5.15.4 Stomp protocol allowed to enter deadlock via dispatch sync
Jamie goodyear created AMQ-7011:
---
Summary: Activemq 5.15.4 Stomp protocol allowed to enter deadlock
via dispatch sync
Key: AMQ-7011
URL: https://issues.apache.org/jira/browse/AMQ-7011
Project: ActiveMQ
Issue Type: Bug
Reporter: Jamie goodyear
Activemq 5.15.4 Stomp protocol allowed to enter deadlock via dispatch sync.
Scenario:
Stomp client setting the following:
header.put("id", subId);
header.put("activemq.dispatchAsync", "false");
The setup of locks between TopicSubscription and MutexTransport while using
Stomp in sync mode can result in a Deadlock as found below (Add and Destroy
calls processing), each lock is identified by a + or * to show lock order in
each stack trace.
Found one Java-level deadlock:
=
"ActiveMQ Transport: tcp:///127.0.0.1:58303@61613":
waiting to lock monitor 0x7f9c565d4d28 (object 0x0007acc44708, a
java.lang.Object),
which is held by "ActiveMQ Transport: tcp:///127.0.0.1:58302@61613"
"ActiveMQ Transport: tcp:///127.0.0.1:58302@61613":
waiting for ownable synchronizer 0x0007ac872730, (a
java.util.concurrent.locks.ReentrantLock$NonfairSync),
which is held by "ActiveMQ Transport: tcp:///127.0.0.1:58303@61613"
Java stack information for the threads listed above:
===
"ActiveMQ Transport: tcp:///127.0.0.1:58303@61613":
++ at
org.apache.activemq.broker.region.TopicSubscription.destroy(TopicSubscription.java:757)
- waiting to lock <0x0007acc44708> (a java.lang.Object)
at
org.apache.activemq.broker.region.AbstractRegion.destroySubscription(AbstractRegion.java:488)
at
org.apache.activemq.broker.jmx.ManagedTopicRegion.destroySubscription(ManagedTopicRegion.java:52)
at
org.apache.activemq.broker.region.AbstractRegion.removeConsumer(AbstractRegion.java:480)
at
org.apache.activemq.broker.region.TopicRegion.removeConsumer(TopicRegion.java:206)
at
org.apache.activemq.broker.region.RegionBroker.removeConsumer(RegionBroker.java:429)
at
org.apache.activemq.broker.jmx.ManagedRegionBroker.removeConsumer(ManagedRegionBroker.java:258)
at
org.apache.activemq.broker.BrokerFilter.removeConsumer(BrokerFilter.java:139)
at
org.apache.activemq.advisory.AdvisoryBroker.removeConsumer(AdvisoryBroker.java:352)
at
org.apache.activemq.broker.BrokerFilter.removeConsumer(BrokerFilter.java:139)
at
org.apache.activemq.broker.BrokerFilter.removeConsumer(BrokerFilter.java:139)
at
org.apache.activemq.broker.BrokerFilter.removeConsumer(BrokerFilter.java:139)
at
org.apache.activemq.broker.TransportConnection.processRemoveConsumer(TransportConnection.java:729)
at
org.apache.activemq.broker.TransportConnection.processRemoveSession(TransportConnection.java:768)
at
org.apache.activemq.broker.TransportConnection.processRemoveConnection(TransportConnection.java:879)
- locked <0x0007ac999f00> (a
org.apache.activemq.broker.jmx.ManagedTransportConnection)
at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:73)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:330)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:194)
* at
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:45)
at
org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:301)
at
org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:97)
at
org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:202)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompDisconnect(ProtocolConverter.java:838)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:267)
at
org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:85)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:233)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)
at java.lang.Thread.run(Thread.java:748)
"ActiveMQ Transport: tcp:///127.0.0.1:58302@61613":
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0007ac872730> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at
[jira] [Commented] (AMQ-7002) Activemq SchedulerBroker doSchedule can schedule duplicate jobIds leading to runtime exception
[
https://issues.apache.org/jira/browse/AMQ-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16525217#comment-16525217
]
Jamie goodyear commented on AMQ-7002:
-
[^AMQ7002-messageId.patch]
Hi [~tabish121], [~gtully], please see the above update patch.
This patch ensures that MessageID format is honored.
> Activemq SchedulerBroker doSchedule can schedule duplicate jobIds leading to
> runtime exception
> ---
>
> Key: AMQ-7002
> URL: https://issues.apache.org/jira/browse/AMQ-7002
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Job Scheduler
>Affects Versions: 5.15.4
> Environment: Java 8
> AMQ 5.15.4
>Reporter: Jamie goodyear
>Assignee: Gary Tully
>Priority: Major
> Fix For: 5.16.0
>
> Attachments: AMQ7002-messageId.patch, amq7002-master.patch
>
>
> Under load we've observed that SchedulerBroker will attempt to schedule jobs
> using the same JobId.
> When JobScheduleView attempts to process these jobs we'll encounter an
> exception during the below put call:
> {color:#bbb529}@Override{color}{color:#cc7832}public {color}TabularData
> {color:#ffc66d}getAllJobs{color}() {color:#cc7832}throws {color}Exception {
> OpenTypeFactory factory =
> OpenTypeSupport.getFactory(Job.{color:#cc7832}class{color}){color:#cc7832};{color}
> CompositeType ct = factory.getCompositeType(){color:#cc7832};{color}
> TabularType tt = {color:#cc7832}new
> {color}TabularType({color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
> {color}{color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
> {color}ct{color:#cc7832}, new {color}String[] { {color:#6a8759}"jobId"
> \{color}});{color} TabularDataSupport rc = {color:#cc7832}new
> {color}TabularDataSupport(tt){color:#cc7832};{color} List jobs =
> {color:#cc7832}this{color}.{color:#9876aa}jobScheduler{color}.getAllJobs(){color:#cc7832};{color}{color:#cc7832}
> for {color}(Job job : jobs) {
> rc.put({color:#cc7832}new {color}CompositeDataSupport(ct{color:#cc7832},
> {color}factory.getFields(job))){color:#cc7832};{color} }
> {color:#cc7832}return {color}rc;
> \{color}}
> This can be triggered by clicking on the Schduled tab in the webconsole.
> The error only occurs due to duplicate JobIds.
> Debugging this error, we can see that two jobs with different payloads have
> the same JobId - this should not be allowed to occur.
> We need to ensure that JobIds are unique.
> Note:
> In test scenario virtual topics are in use, with two consumers.
> Redelivery plugin is also in use on the Broker.
>
> sendToDlqIfMaxRetriesExceeded="false">
>
>
>
> initialRedeliveryDelay="6" maximumRedeliveries="20"
> maximumRedeliveryDelay="30" useExponentialBackOff="true"/>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMQ-7002) Activemq SchedulerBroker doSchedule can schedule duplicate jobIds leading to runtime exception
[
https://issues.apache.org/jira/browse/AMQ-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jamie goodyear updated AMQ-7002:
Attachment: AMQ7002-messageId.patch
> Activemq SchedulerBroker doSchedule can schedule duplicate jobIds leading to
> runtime exception
> ---
>
> Key: AMQ-7002
> URL: https://issues.apache.org/jira/browse/AMQ-7002
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Job Scheduler
>Affects Versions: 5.15.4
> Environment: Java 8
> AMQ 5.15.4
>Reporter: Jamie goodyear
>Assignee: Gary Tully
>Priority: Major
> Fix For: 5.16.0
>
> Attachments: AMQ7002-messageId.patch, amq7002-master.patch
>
>
> Under load we've observed that SchedulerBroker will attempt to schedule jobs
> using the same JobId.
> When JobScheduleView attempts to process these jobs we'll encounter an
> exception during the below put call:
> {color:#bbb529}@Override{color}{color:#cc7832}public {color}TabularData
> {color:#ffc66d}getAllJobs{color}() {color:#cc7832}throws {color}Exception {
> OpenTypeFactory factory =
> OpenTypeSupport.getFactory(Job.{color:#cc7832}class{color}){color:#cc7832};{color}
> CompositeType ct = factory.getCompositeType(){color:#cc7832};{color}
> TabularType tt = {color:#cc7832}new
> {color}TabularType({color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
> {color}{color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
> {color}ct{color:#cc7832}, new {color}String[] { {color:#6a8759}"jobId"
> \{color}});{color} TabularDataSupport rc = {color:#cc7832}new
> {color}TabularDataSupport(tt){color:#cc7832};{color} List jobs =
> {color:#cc7832}this{color}.{color:#9876aa}jobScheduler{color}.getAllJobs(){color:#cc7832};{color}{color:#cc7832}
> for {color}(Job job : jobs) {
> rc.put({color:#cc7832}new {color}CompositeDataSupport(ct{color:#cc7832},
> {color}factory.getFields(job))){color:#cc7832};{color} }
> {color:#cc7832}return {color}rc;
> \{color}}
> This can be triggered by clicking on the Schduled tab in the webconsole.
> The error only occurs due to duplicate JobIds.
> Debugging this error, we can see that two jobs with different payloads have
> the same JobId - this should not be allowed to occur.
> We need to ensure that JobIds are unique.
> Note:
> In test scenario virtual topics are in use, with two consumers.
> Redelivery plugin is also in use on the Broker.
>
> sendToDlqIfMaxRetriesExceeded="false">
>
>
>
> initialRedeliveryDelay="6" maximumRedeliveries="20"
> maximumRedeliveryDelay="30" useExponentialBackOff="true"/>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7002) Activemq SchedulerBroker doSchedule can schedule duplicate jobIds leading to runtime exception
[
https://issues.apache.org/jira/browse/AMQ-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16525025#comment-16525025
]
Jamie goodyear commented on AMQ-7002:
-
[^amq7002-master.patch]
Please find attached a patch for AMQ-7002.
The code change is to start using ID_GENERATOR to set JobId when scheduling a
job instead of using messageId.
The test suits in Broker, unit tests & use cases all pass with this change in
place.
A unit test, AMQ7002Test, has been created to exercise this code.
In short the unit test configures a broker with redelivery plugin installed,
and send a message to a virtual topic with two consumers.
The consumers will perform a rollback operation, this causes the scheduler to
come into play.
When then check that the jobs in the scheduler have unique IDs.
If we do not have the ID_GENERATOR in play than this test case fails, with the
ID_GENERATOR we get the unique IDs we require.
JobIDs need to be unique in the scheduler. Under the existing code its possible
for a race condition in which two or more jobs get the same JobID while having
different payloads, the ID_GENERATOR resolves this issue by ensuring each job
ID is unique.
Please review this patch for both the AMQ 5.15.x and 5.16.x (master) branches.
I'd like to thank jgenender, joed, hkesler, and gtully for helping in
identifying the issue and how to test/exercise the fix.
> Activemq SchedulerBroker doSchedule can schedule duplicate jobIds leading to
> runtime exception
> ---
>
> Key: AMQ-7002
> URL: https://issues.apache.org/jira/browse/AMQ-7002
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Job Scheduler
>Affects Versions: 5.15.4
> Environment: Java 8
> AMQ 5.15.4
>Reporter: Jamie goodyear
>Priority: Major
> Fix For: 5.x
>
> Attachments: amq7002-master.patch
>
>
> Under load we've observed that SchedulerBroker will attempt to schedule jobs
> using the same JobId.
> When JobScheduleView attempts to process these jobs we'll encounter an
> exception during the below put call:
> {color:#bbb529}@Override{color}{color:#cc7832}public {color}TabularData
> {color:#ffc66d}getAllJobs{color}() {color:#cc7832}throws {color}Exception {
> OpenTypeFactory factory =
> OpenTypeSupport.getFactory(Job.{color:#cc7832}class{color}){color:#cc7832};{color}
> CompositeType ct = factory.getCompositeType(){color:#cc7832};{color}
> TabularType tt = {color:#cc7832}new
> {color}TabularType({color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
> {color}{color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
> {color}ct{color:#cc7832}, new {color}String[] { {color:#6a8759}"jobId"
> \{color}});{color} TabularDataSupport rc = {color:#cc7832}new
> {color}TabularDataSupport(tt){color:#cc7832};{color} List jobs =
> {color:#cc7832}this{color}.{color:#9876aa}jobScheduler{color}.getAllJobs(){color:#cc7832};{color}{color:#cc7832}
> for {color}(Job job : jobs) {
> rc.put({color:#cc7832}new {color}CompositeDataSupport(ct{color:#cc7832},
> {color}factory.getFields(job))){color:#cc7832};{color} }
> {color:#cc7832}return {color}rc;
> \{color}}
> This can be triggered by clicking on the Schduled tab in the webconsole.
> The error only occurs due to duplicate JobIds.
> Debugging this error, we can see that two jobs with different payloads have
> the same JobId - this should not be allowed to occur.
> We need to ensure that JobIds are unique.
> Note:
> In test scenario virtual topics are in use, with two consumers.
> Redelivery plugin is also in use on the Broker.
>
> sendToDlqIfMaxRetriesExceeded="false">
>
>
>
> initialRedeliveryDelay="6" maximumRedeliveries="20"
> maximumRedeliveryDelay="30" useExponentialBackOff="true"/>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMQ-7002) Activemq SchedulerBroker doSchedule can schedule duplicate jobIds leading to runtime exception
[
https://issues.apache.org/jira/browse/AMQ-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jamie goodyear updated AMQ-7002:
Attachment: amq7002-master.patch
> Activemq SchedulerBroker doSchedule can schedule duplicate jobIds leading to
> runtime exception
> ---
>
> Key: AMQ-7002
> URL: https://issues.apache.org/jira/browse/AMQ-7002
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Job Scheduler
>Affects Versions: 5.15.4
> Environment: Java 8
> AMQ 5.15.4
>Reporter: Jamie goodyear
>Priority: Major
> Fix For: 5.x
>
> Attachments: amq7002-master.patch
>
>
> Under load we've observed that SchedulerBroker will attempt to schedule jobs
> using the same JobId.
> When JobScheduleView attempts to process these jobs we'll encounter an
> exception during the below put call:
> {color:#bbb529}@Override{color}{color:#cc7832}public {color}TabularData
> {color:#ffc66d}getAllJobs{color}() {color:#cc7832}throws {color}Exception {
> OpenTypeFactory factory =
> OpenTypeSupport.getFactory(Job.{color:#cc7832}class{color}){color:#cc7832};{color}
> CompositeType ct = factory.getCompositeType(){color:#cc7832};{color}
> TabularType tt = {color:#cc7832}new
> {color}TabularType({color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
> {color}{color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
> {color}ct{color:#cc7832}, new {color}String[] { {color:#6a8759}"jobId"
> \{color}});{color} TabularDataSupport rc = {color:#cc7832}new
> {color}TabularDataSupport(tt){color:#cc7832};{color} List jobs =
> {color:#cc7832}this{color}.{color:#9876aa}jobScheduler{color}.getAllJobs(){color:#cc7832};{color}{color:#cc7832}
> for {color}(Job job : jobs) {
> rc.put({color:#cc7832}new {color}CompositeDataSupport(ct{color:#cc7832},
> {color}factory.getFields(job))){color:#cc7832};{color} }
> {color:#cc7832}return {color}rc;
> \{color}}
> This can be triggered by clicking on the Schduled tab in the webconsole.
> The error only occurs due to duplicate JobIds.
> Debugging this error, we can see that two jobs with different payloads have
> the same JobId - this should not be allowed to occur.
> We need to ensure that JobIds are unique.
> Note:
> In test scenario virtual topics are in use, with two consumers.
> Redelivery plugin is also in use on the Broker.
>
> sendToDlqIfMaxRetriesExceeded="false">
>
>
>
> initialRedeliveryDelay="6" maximumRedeliveries="20"
> maximumRedeliveryDelay="30" useExponentialBackOff="true"/>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMQ-7002) Activemq SchedulerBroker doSchedule can schedule duplicate jobIds leading to runtime exception
[
https://issues.apache.org/jira/browse/AMQ-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jamie goodyear updated AMQ-7002:
Description:
Under load we've observed that SchedulerBroker will attempt to schedule jobs
using the same JobId.
When JobScheduleView attempts to process these jobs we'll encounter an
exception during the below put call:
{color:#bbb529}@Override{color}{color:#cc7832}public {color}TabularData
{color:#ffc66d}getAllJobs{color}() {color:#cc7832}throws {color}Exception {
OpenTypeFactory factory =
OpenTypeSupport.getFactory(Job.{color:#cc7832}class{color}){color:#cc7832};{color}
CompositeType ct = factory.getCompositeType(){color:#cc7832};{color}
TabularType tt = {color:#cc7832}new
{color}TabularType({color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
{color}{color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
{color}ct{color:#cc7832}, new {color}String[] { {color:#6a8759}"jobId"
\{color}});{color} TabularDataSupport rc = {color:#cc7832}new
{color}TabularDataSupport(tt){color:#cc7832};{color} List jobs =
{color:#cc7832}this{color}.{color:#9876aa}jobScheduler{color}.getAllJobs(){color:#cc7832};{color}{color:#cc7832}
for {color}(Job job : jobs) {
rc.put({color:#cc7832}new {color}CompositeDataSupport(ct{color:#cc7832},
{color}factory.getFields(job))){color:#cc7832};{color} }
{color:#cc7832}return {color}rc;
\{color}}
This can be triggered by clicking on the Schduled tab in the webconsole.
The error only occurs due to duplicate JobIds.
Debugging this error, we can see that two jobs with different payloads have the
same JobId - this should not be allowed to occur.
We need to ensure that JobIds are unique.
Note:
In test scenario virtual topics are in use, with two consumers.
Redelivery plugin is also in use on the Broker.
was:
Under load we've observed that SchedulerBroker will attempt to schedule jobs
using the same JobId.
When JobScheduleView attempts to process these jobs we'll encounter an
exception during the below put call:
{color:#bbb529}@Override
{color}{color:#cc7832}public {color}TabularData
{color:#ffc66d}getAllJobs{color}() {color:#cc7832}throws {color}Exception {
OpenTypeFactory factory =
OpenTypeSupport.getFactory(Job.{color:#cc7832}class{color}){color:#cc7832};
{color} CompositeType ct = factory.getCompositeType(){color:#cc7832};
{color} TabularType tt = {color:#cc7832}new
{color}TabularType({color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
{color}{color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
{color}ct{color:#cc7832}, new {color}String[] { {color:#6a8759}"jobId"
{color}}){color:#cc7832};
{color} TabularDataSupport rc = {color:#cc7832}new
{color}TabularDataSupport(tt){color:#cc7832};
{color} List jobs =
{color:#cc7832}this{color}.{color:#9876aa}jobScheduler{color}.getAllJobs(){color:#cc7832};
{color}{color:#cc7832} for {color}(Job job : jobs) {
rc.put({color:#cc7832}new {color}CompositeDataSupport(ct{color:#cc7832},
{color}factory.getFields(job))){color:#cc7832};
{color} }
{color:#cc7832}return {color}rc{color:#cc7832};
{color}}
This can be triggered by clicking on the Schduled tab in the webconsole.
The error only occurs due to duplicate JobIds.
Debugging this error, we can see that two jobs with different payloads have the
same JobId - this should not be allowed to occur.
We need to ensure that JobIds are unique.
> Activemq SchedulerBroker doSchedule can schedule duplicate jobIds leading to
> runtime exception
> ---
>
> Key: AMQ-7002
> URL: https://issues.apache.org/jira/browse/AMQ-7002
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Job Scheduler
>Affects Versions: 5.15.4
> Environment: Java 8
> AMQ 5.15.4
>Reporter: Jamie goodyear
>Priority: Major
> Fix For: 5.x
>
>
> Under load we've observed that SchedulerBroker will attempt to schedule jobs
> using the same JobId.
> When JobScheduleView attempts to process these jobs we'll encounter an
> exception during the below put call:
> {color:#bbb529}@Override{color}{color:#cc7832}public {color}TabularData
> {color:#ffc66d}getAllJobs{color}() {color:#cc7832}throws {color}Exception {
> OpenTypeFactory factory =
> OpenTypeSupport.getFactory(Job.{color:#cc7832}class{color}){color:#cc7832};{color}
> CompositeType ct = factory.getCompositeType(){color:#cc7832};{color}
> TabularType tt = {color:#cc7832}new
> {color}TabularType({color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
> {color}{color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
> {color}ct{color:#cc7832}, new
[jira] [Created] (AMQ-7002) Activemq SchedulerBroker doSchedule can schedule duplicate jobIds leading to runtime exception
Jamie goodyear created AMQ-7002:
---
Summary: Activemq SchedulerBroker doSchedule can schedule
duplicate jobIds leading to runtime exception
Key: AMQ-7002
URL: https://issues.apache.org/jira/browse/AMQ-7002
Project: ActiveMQ
Issue Type: Bug
Components: Broker, Job Scheduler
Affects Versions: 5.15.4
Environment: Java 8
AMQ 5.15.4
Reporter: Jamie goodyear
Fix For: 5.x
Under load we've observed that SchedulerBroker will attempt to schedule jobs
using the same JobId.
When JobScheduleView attempts to process these jobs we'll encounter an
exception during the below put call:
{color:#bbb529}@Override
{color}{color:#cc7832}public {color}TabularData
{color:#ffc66d}getAllJobs{color}() {color:#cc7832}throws {color}Exception {
OpenTypeFactory factory =
OpenTypeSupport.getFactory(Job.{color:#cc7832}class{color}){color:#cc7832};
{color} CompositeType ct = factory.getCompositeType(){color:#cc7832};
{color} TabularType tt = {color:#cc7832}new
{color}TabularType({color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
{color}{color:#6a8759}"Scheduled Jobs"{color}{color:#cc7832},
{color}ct{color:#cc7832}, new {color}String[] { {color:#6a8759}"jobId"
{color}}){color:#cc7832};
{color} TabularDataSupport rc = {color:#cc7832}new
{color}TabularDataSupport(tt){color:#cc7832};
{color} List jobs =
{color:#cc7832}this{color}.{color:#9876aa}jobScheduler{color}.getAllJobs(){color:#cc7832};
{color}{color:#cc7832} for {color}(Job job : jobs) {
rc.put({color:#cc7832}new {color}CompositeDataSupport(ct{color:#cc7832},
{color}factory.getFields(job))){color:#cc7832};
{color} }
{color:#cc7832}return {color}rc{color:#cc7832};
{color}}
This can be triggered by clicking on the Schduled tab in the webconsole.
The error only occurs due to duplicate JobIds.
Debugging this error, we can see that two jobs with different payloads have the
same JobId - this should not be allowed to occur.
We need to ensure that JobIds are unique.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (AMQ-6930) bin/activemq should allow stdout/stderr to some file instead of /dev/null for daemon mode
[ https://issues.apache.org/jira/browse/AMQ-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432748#comment-16432748 ] Jamie goodyear edited comment on AMQ-6930 at 4/10/18 6:40 PM: -- Given the new behavior is controlled via environment variable switch, I think this is a fare change to make. Classic behavior is retained unless you need the optional output location set. was (Author: jgoodyear): Given the new behavior is controlled via environment variable switch, I think this is a fare change to make. > bin/activemq should allow stdout/stderr to some file instead of /dev/null for > daemon mode > - > > Key: AMQ-6930 > URL: https://issues.apache.org/jira/browse/AMQ-6930 > Project: ActiveMQ > Issue Type: Wish >Affects Versions: 5.15.0, 5.15.1, 5.15.2, 5.15.3 >Reporter: Alvin Lin >Priority: Major > > if I do "bin/activemq start" the ActiveMQ process is started with > stdout/stdin redirected to /dev/null. > This makes it hard to debug issue like out of memory error because we can't > see any log, for example, when the JVM flag "ExitOnOutOfMemoryError" is > turned on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6930) bin/activemq should allow stdout/stderr to some file instead of /dev/null for daemon mode
[ https://issues.apache.org/jira/browse/AMQ-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432748#comment-16432748 ] Jamie goodyear commented on AMQ-6930: - Given the new behavior is controlled via environment variable switch, I think this is a fare change to make. > bin/activemq should allow stdout/stderr to some file instead of /dev/null for > daemon mode > - > > Key: AMQ-6930 > URL: https://issues.apache.org/jira/browse/AMQ-6930 > Project: ActiveMQ > Issue Type: Wish >Affects Versions: 5.15.0, 5.15.1, 5.15.2, 5.15.3 >Reporter: Alvin Lin >Priority: Major > > if I do "bin/activemq start" the ActiveMQ process is started with > stdout/stdin redirected to /dev/null. > This makes it hard to debug issue like out of memory error because we can't > see any log, for example, when the JVM flag "ExitOnOutOfMemoryError" is > turned on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6176) Update Saxon version to 9.5.1-5_1
[ https://issues.apache.org/jira/browse/AMQ-6176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15156054#comment-15156054 ] Jamie goodyear commented on AMQ-6176: - I've submitted a patch for AMQ-6177, I'll return now to looking at this issue. > Update Saxon version to 9.5.1-5_1 > - > > Key: AMQ-6176 > URL: https://issues.apache.org/jira/browse/AMQ-6176 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 5.13.1, 5.14.0 >Reporter: Jamie goodyear > Fix For: 5.14.0, 5.13.2 > > Attachments: amq-5.13.x.patch, amq-master.patch > > > I had some Camel routes running embedded in the broker that were using xpath > filters and were throwing exceptions from Saxon until I upgraded the Saxon > dependency. The exceptions only occurred when running the broker with Java 8 > but not Java 7. > This is not the most recent version of the JAR. However, it is the earliest > version where the bug appears to be fixed (trying not to make too many > changes at once). > I'll supply patch files shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-6177) Make ActiveMQ build and test pass in Newfoundland
[ https://issues.apache.org/jira/browse/AMQ-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-6177: Attachment: amq6177-master.diff Patch for master branch. The check for half hour timezone assumed 12 hr clock instead of 24 hr. Updated to check for 20h instead of 8h. > Make ActiveMQ build and test pass in Newfoundland > - > > Key: AMQ-6177 > URL: https://issues.apache.org/jira/browse/AMQ-6177 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.13.1, 5.14.0 >Reporter: Jamie goodyear > Labels: test > Attachments: amq6177-513xpatch.diff, amq6177-master.diff > > > Certain tests such as org.apache.activemq.broker.scheduler.CronParserTest, > require a build/test to be run on an epoch that is aligned with the hour. In > timezones such as Newfounland, which is shifted by 30 minutes, these tests > fail. > Lets update the build/test suite to work in any time zone. > (Verified by changing timezone from NST to EST -- on EST the test suite > passes) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-6177) Make ActiveMQ build and test pass in Newfoundland
[ https://issues.apache.org/jira/browse/AMQ-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-6177: Flags: Patch Patch Info: Patch Available Labels: test (was: ) Regression: Unit Test Broken > Make ActiveMQ build and test pass in Newfoundland > - > > Key: AMQ-6177 > URL: https://issues.apache.org/jira/browse/AMQ-6177 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.13.1, 5.14.0 >Reporter: Jamie goodyear > Labels: test > Attachments: amq6177-513xpatch.diff, amq6177-master.diff > > > Certain tests such as org.apache.activemq.broker.scheduler.CronParserTest, > require a build/test to be run on an epoch that is aligned with the hour. In > timezones such as Newfounland, which is shifted by 30 minutes, these tests > fail. > Lets update the build/test suite to work in any time zone. > (Verified by changing timezone from NST to EST -- on EST the test suite > passes) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-6177) Make ActiveMQ build and test pass in Newfoundland
[ https://issues.apache.org/jira/browse/AMQ-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear updated AMQ-6177: Attachment: amq6177-513xpatch.diff Patch for 5.13.x branch. The existing check for half hour offsets wasn't in 24 hour clock format (8pm == 20h). > Make ActiveMQ build and test pass in Newfoundland > - > > Key: AMQ-6177 > URL: https://issues.apache.org/jira/browse/AMQ-6177 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.13.1, 5.14.0 >Reporter: Jamie goodyear > Attachments: amq6177-513xpatch.diff > > > Certain tests such as org.apache.activemq.broker.scheduler.CronParserTest, > require a build/test to be run on an epoch that is aligned with the hour. In > timezones such as Newfounland, which is shifted by 30 minutes, these tests > fail. > Lets update the build/test suite to work in any time zone. > (Verified by changing timezone from NST to EST -- on EST the test suite > passes) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
