[jira] [Commented] (AMQ-6988) ActiveMQ 5.15.4 contains activemq-protobuf-1.1.jar which has three high severity CVEs against it.Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and run
[ https://issues.apache.org/jira/browse/AMQ-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559047#comment-16559047 ] Christopher L. Shannon commented on AMQ-6988: - Regardless of your feelings about how security issues should be handled the Apache software foundation has a process in place to report vulnerabilities. If you have been in this business for 30 years then you should understand that it's not appropriate to discuss vulnerabilities in a public forum regardless of how easy you think they are to discover. If you do not like Apache's policy then feel free to bring it up with the security team for discussion but as a PMC member of this project it is my responsibility to please ask you to follow the security process and not bypass by posting on a public forum. > ActiveMQ 5.15.4 contains activemq-protobuf-1.1.jar which has three high > severity CVEs against it.Discovered by adding OWASP Dependency check into > ActiveMQ pom.xml and running the OWASP report > --- > > Key: AMQ-6988 > URL: https://issues.apache.org/jira/browse/AMQ-6988 > 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. Will not accept the risk of having even one high severity > CVE in thier environment. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 contains activemq-protobuf-1.1.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-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. > 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. > CVE-2016-3088 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > The Fileserver web application in Apache ActiveMQ 5.x before 5.14.0 allows > remote attackers to upload and execute arbitrary files via an HTTP PUT > followed by an HTTP MOVE request. > CONFIRM - > http://activemq.apache.org/security-advisories.data/CVE-2016-3088-announcement.txt > EXPLOIT-DB - 42283 > MISC - http://www.zerodayinitiative.com/advisories/ZDI-16-356 > MISC - http://www.zerodayinitiative.com/advisories/ZDI-16-357 > REDHAT - RHSA-2016:2036 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7019) ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559013#comment-16559013 ] ASF subversion and git services commented on AMQ-7019: -- Commit 972b3fa6cf928e5ae7e008fa263e96c5ab71bf72 in activemq's branch refs/heads/activemq-5.15.x from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=972b3fa ] AMQ-7019 Update Jolokia to latest version Updates version to v1.6.0 (cherry picked from commit 2ebea251cdf58ddf0a29f41ccb6c6aadcfdb9b95) > ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it. > --- > > Key: AMQ-7019 > URL: https://issues.apache.org/jira/browse/AMQ-7019 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > 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 jolokia.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-2015-5182 Severity:High CVSS Score: 6.8 > allows Cross-site request forgery (CSRF) vulnerability in the jolokia API in > A-MQ. > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1248809 CONFIRM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7019) ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559012#comment-16559012 ] ASF subversion and git services commented on AMQ-7019: -- Commit 2ebea251cdf58ddf0a29f41ccb6c6aadcfdb9b95 in activemq's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=2ebea25 ] AMQ-7019 Update Jolokia to latest version Updates version to v1.6.0 > ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it. > --- > > Key: AMQ-7019 > URL: https://issues.apache.org/jira/browse/AMQ-7019 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > 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 jolokia.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-2015-5182 Severity:High CVSS Score: 6.8 > allows Cross-site request forgery (CSRF) vulnerability in the jolokia API in > A-MQ. > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1248809 CONFIRM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6988) ActiveMQ 5.15.4 contains activemq-protobuf-1.1.jar which has three high severity CVEs against it.Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and run
[ https://issues.apache.org/jira/browse/AMQ-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558996#comment-16558996 ] Albert Baker commented on AMQ-6988: --- Yeah but Russia China France, Israel, common crimminals can all freely download all open-source projects...have and continue to 24x7, edit the pom file to include OWASP dependency check and in 15 minutes know what vulnerabilities are in the projects. Google for proof-of-concept exploits to a CVE and in another 15 minutes have a missile. Is it better to : # shine the light of day on vulnerabilities to increase the urgency of fixing ? # send an email that gets ignored and nothing ever happens ? " Messages that do not relate to the reporting or managing of an undisclosed security vulnerability in Apache software are ignored and no further action is required." # or Have all apache projects add OWASP Depencency check into the pom ahead of time and run the report weekly to weed out vulnerabilities as part of the normal process, like what Apache Camel project now does ? I vote for #3. but until that is universal, #1 "shaming" is much more of an incentive than #2 which is where we have been for 20 yrs and everything is still broken. sorry to rant...Thanks for fighting the good fight ,but I been at this for 30 yrs...im done wasting time. Talk to Claus Ibsen, then push this call out to everyone in all Apache projects. > ActiveMQ 5.15.4 contains activemq-protobuf-1.1.jar which has three high > severity CVEs against it.Discovered by adding OWASP Dependency check into > ActiveMQ pom.xml and running the OWASP report > --- > > Key: AMQ-6988 > URL: https://issues.apache.org/jira/browse/AMQ-6988 > 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. Will not accept the risk of having even one high severity > CVE in thier environment. >Reporter: Albert Baker >Priority: Blocker > > ActiveMQ 5.15.4 contains activemq-protobuf-1.1.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-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. > 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. > CVE-2016-3088 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-20 Improper Input Validation > The Fileserver web application in Apache ActiveMQ 5.x before 5.14.0 allows > remote attackers to upload and execute arbitrary files via an HTTP PUT > followed by an HTTP MOVE request. > CONFIRM - > http://activemq.apache.org/security-advisories.data/CVE-2016-3088-announcement.txt > EXPLOIT-DB - 42283 > MISC - http://www.zerodayinitiative.com/advisories/ZDI-16-356 > MISC - http://www.zerodayinitiative.com/advisories/ZDI-16-357 > REDHAT - RHSA-2016:2036 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7019) ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558994#comment-16558994 ] Christopher L. Shannon commented on AMQ-7019: - Oops I misread that this was about Jolokia and not the AMQ console, I can update the dependency tomorrow > ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it. > --- > > Key: AMQ-7019 > URL: https://issues.apache.org/jira/browse/AMQ-7019 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > 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 jolokia.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-2015-5182 Severity:High CVSS Score: 6.8 > allows Cross-site request forgery (CSRF) vulnerability in the jolokia API in > A-MQ. > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1248809 CONFIRM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6989) ActiveMQ 5.15.4 contains scala-library-2.11.0.jar which has one high severity CVE against it.
[
https://issues.apache.org/jira/browse/AMQ-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558972#comment-16558972
]
Albert Baker commented on AMQ-6989:
---
Thank You Christopher !
> ActiveMQ 5.15.4 contains scala-library-2.11.0.jar which has one high severity
> CVE against it.
> -
>
> Key: AMQ-6989
> URL: https://issues.apache.org/jira/browse/AMQ-6989
> 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. Will not accept the risk of having even one high severity
> CVE in thier environment.
>Reporter: Albert Baker
>Priority: Blocker
>
> ActiveMQ 5.15.4 contains scala-library-2.11.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-2017-15288 Severity:High CVSS Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)
> CWE: CWE-264 Permissions, Privileges, and Access Controls
> The compilation daemon in Scala before 2.10.7, 2.11.x before 2.11.12, and
> 2.12.x before 2.12.4 uses weak permissions for private files in
> /tmp/scala-devel/${USER:shared}
> /scalac-compile-server-port, which allows local users to write to arbitrary
> class files and consequently gain privileges.
> CONFIRM - http://scala-lang.org/news/security-update-nov17.html
> CONFIRM - https://github.com/scala/scala/pull/6108
> CONFIRM - https://github.com/scala/scala/pull/6120
> CONFIRM - https://github.com/scala/scala/pull/6128
> Vulnerable Software & Versions: (show all)
--
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=16558970#comment-16558970 ] Albert Baker commented on AMQ-6991: --- Thanks Christopher ! > 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] [Commented] (AMQ-6992) ActiveMQ 5.15.4 jackson-databind-2.9.4.jar which has one high severity CVEs against it.
[ https://issues.apache.org/jira/browse/AMQ-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558968#comment-16558968 ] Albert Baker commented on AMQ-6992: --- Thanks Christopher > ActiveMQ 5.15.4 jackson-databind-2.9.4.jar which has one high severity CVEs > against it. > --- > > Key: AMQ-6992 > URL: https://issues.apache.org/jira/browse/AMQ-6992 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >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 >Assignee: Christopher L. Shannon >Priority: Blocker > Fix For: 5.16.0, 5.15.5 > > > ctiveMQ 5.15.4 jackson-databind-2.9.4.jar which has one high severity CVEs > against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > CVE-2018-7489 Severity:High CVSS Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) > CWE: CWE-184 Incomplete Blacklist > FasterXML jackson-databind before 2.8.11.1 and 2.9.x before 2.9.5 allows > unauthenticated remote code execution because of an incomplete fix for the > CVE-2017-7525 > deserialization flaw. This is exploitable by sending maliciously crafted JSON > input to the readValue method of the ObjectMapper, bypassing a blacklist that > is ineffective if the > c3p0 libraries are available in the classpath. > BID - 103203 > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html > CONFIRM - https://github.com/FasterXML/jackson-databind/issues/1931 > CONFIRM - https://security.netapp.com/advisory/ntap-20180328-0001/ > DEBIAN - DSA-4190 > REDHAT - RHSA-2018:1447 > REDHAT - RHSA-2018:1448 > REDHAT - RHSA-2018:1449 > REDHAT - RHSA-2018:1450 > REDHAT - RHSA-2018:1451 > REDHAT - RHSA-2018:1786 > SECTRACK - 1040693 > Vulnerable Software & Versions: (show all) > cpe:/a:fasterxml:jackson-databind:2.9.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6994) ActiveMQ 5.15.4 tomcat-servlet-api-8.0.24.jar which has four high severity CVEs against it.
[ https://issues.apache.org/jira/browse/AMQ-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558967#comment-16558967 ] Albert Baker commented on AMQ-6994: --- Thanks Timothy ! > ActiveMQ 5.15.4 tomcat-servlet-api-8.0.24.jar which has four high severity > CVEs against it. > > > Key: AMQ-6994 > URL: https://issues.apache.org/jira/browse/AMQ-6994 > 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 > Fix For: 5.15.5 > > > ActiveMQ 5.15.4 tomcat-servlet-api-8.0.24.jar which has four high severity > CVEs against it. > Discovered by adding OWASP Dependency check into ActiveMQ pom.xml and running > the OWASP report. > Referenced In Projects/Scopes: > ActiveMQ :: Assembly:compile > ActiveMQ :: Web:provided > ActiveMQ :: Web Console:provided > CVE-2016-3092 Severity:High CVSS Score: 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) > CWE: CWE-20 Improper Input Validation > The MultipartStream class in Apache Commons Fileupload before 1.3.2, as used > in Apache Tomcat 7.x before 7.0.70, 8.x before 8.0.36, 8.5.x before 8.5.3, > and 9.x before > 9.0.0.M7 and other products, allows remote attackers to cause a denial of > service (CPU consumption) via a long boundary string. > BID - 91453 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743480 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743722 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743738 > CONFIRM - http://svn.apache.org/viewvc?view=revision=1743742 > CONFIRM - http://tomcat.apache.org/security-7.html > CONFIRM - http://tomcat.apache.org/security-8.html > CONFIRM - http://tomcat.apache.org/security-9.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpujul2017-3236622.html > CONFIRM - > http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html > CONFIRM - > http://www.oracle.com/technetwork/topics/security/bulletinjul2016-3090568.html > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1349468 > CONFIRM - > https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05204371 > CONFIRM - > https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05289840 > CONFIRM - > https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05324759 > DEBIAN - DSA-3609 > DEBIAN - DSA-3611 > DEBIAN - DSA-3614 > GENTOO - GLSA-201705-09 > JVN - JVN#89379547 > JVNDB - JVNDB-2016-000121 > MLIST - [dev] 20160621 CVE-2016-3092: Apache Commons Fileupload information > disclosure vulnerability > REDHAT - RHSA-2016:2068 > REDHAT - RHSA-2016:2069 > REDHAT - RHSA-2016:2070 > REDHAT - RHSA-2016:2071 > REDHAT - RHSA-2016:2072 > REDHAT - RHSA-2016:2599 > REDHAT - RHSA-2016:2807 > REDHAT - RHSA-2016:2808 > REDHAT - RHSA-2017:0455 > REDHAT - RHSA-2017:0456 > REDHAT - RHSA-2017:0457 > SECTRACK - 1036427 > SECTRACK - 1036900 > SECTRACK - 1037029 > SECTRACK - 1039606 > SUSE - openSUSE-SU-2016:2252 > UBUNTU - USN-3024-1 > UBUNTU - USN-3027-1 > Vulnerable Software & Versions: (show all) > cpe:/a:apache:tomcat:8.0.24 > CVE-2016-5425 Severity:High CVSS Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C) > CWE: CWE-264 Permissions, Privileges, and Access Controls > The Tomcat package on Red Hat Enterprise Linux (RHEL) 7, Fedora, CentOS, > Oracle Linux, and possibly other Linux distributions uses weak permissions > for /usr/lib > /tmpfiles.d/tomcat.conf, which allows local users to gain root privileges by > leveraging membership in the tomcat group. > BID - 93472 > CONFIRM - > http://www.oracle.com/technetwork/topics/security/linuxbulletinoct2016-3090545.html > EXPLOIT-DB - 40488 > MISC - > http://legalhackers.com/advisories/Tomcat-RedHat-Pkgs-Root-PrivEsc-Exploit-CVE-2016-5425.html > MISC - > http://packetstormsecurity.com/files/139041/Apache-Tomcat-8-7-6-Privilege-Escalation.html > MLIST - [oss-security] 20161010 CVE-2016-5425 - Apache Tomcat packaging on > RedHat-based distros - Root Privilege Escalation (affecting CentOS, Fedora, > OracleLinux, RedHat etc.) > REDHAT - RHSA-2016:2046 > SECTRACK - 1036979 > Vulnerable Software & Versions: > cpe:/a:apache:tomcat > CVE-2016-6325 Severity:High CVSS Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C) > CWE: CWE-264 Permissions, Privileges, and Access Controls > The Tomcat package on Red Hat
[jira] [Issue Comment Deleted] (AMQ-7019) ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Baker updated AMQ-7019: -- Comment: was deleted (was: Doesnt matter that AMQ is not ActiveMQ. Jolokia is jalokia and is in both projects. Jalokia is the problem. Re-Open the issue, and fix the real issue.) > ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it. > --- > > Key: AMQ-7019 > URL: https://issues.apache.org/jira/browse/AMQ-7019 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > 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 jolokia.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-2015-5182 Severity:High CVSS Score: 6.8 > allows Cross-site request forgery (CSRF) vulnerability in the jolokia API in > A-MQ. > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1248809 CONFIRM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (AMQ-7019) ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Baker reopened AMQ-7019: --- Doesnt matter that AMQ is not ActiveMQ. Jolokia is jalokia and is in both projects. Jalokia is the problem. Re-Open the issue, and fix the real issue. Jalokia is the issue. Update the ActiveMQ pom.xml to point to the newer version of Jalokia that is fixed. If no new/fixed version of jalokia exists, keep the ticket open. > ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it. > --- > > Key: AMQ-7019 > URL: https://issues.apache.org/jira/browse/AMQ-7019 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > 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 jolokia.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-2015-5182 Severity:High CVSS Score: 6.8 > allows Cross-site request forgery (CSRF) vulnerability in the jolokia API in > A-MQ. > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1248809 CONFIRM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7019) ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it.
[ https://issues.apache.org/jira/browse/AMQ-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558961#comment-16558961 ] Albert Baker commented on AMQ-7019: --- Doesnt matter that AMQ is not ActiveMQ. Jolokia is jalokia and is in both projects. Jalokia is the problem. Re-Open the issue, and fix the real issue. > ActiveMQ 5.15.4 jolokia.jar which has one high severity CVE against it. > --- > > Key: AMQ-7019 > URL: https://issues.apache.org/jira/browse/AMQ-7019 > Project: ActiveMQ > Issue Type: Bug > Components: webconsole >Affects Versions: 5.15.4 > 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 jolokia.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-2015-5182 Severity:High CVSS Score: 6.8 > allows Cross-site request forgery (CSRF) vulnerability in the jolokia API in > A-MQ. > CONFIRM - https://bugzilla.redhat.com/show_bug.cgi?id=1248809 CONFIRM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-856) Support advanced destination options
[ https://issues.apache.org/jira/browse/ARTEMIS-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558901#comment-16558901 ] ASF GitHub Bot commented on ARTEMIS-856: Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2175 this is so weird.. I have no idea what changed.. but I can't build on artemis-features. Probably the double xsd on tools? I 've tried debugging... and I can't figure out I will keep trying tomorrow. but if you know anything @michaelandrepearce please let me know. > Support advanced destination options > > > Key: ARTEMIS-856 > URL: https://issues.apache.org/jira/browse/ARTEMIS-856 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 2.6.2 >Reporter: Matt Pavlovich >Assignee: Michael Andre Pearce >Priority: Major > Fix For: 2.7.0 > > > Add support enhancing destination consumer features (ActiveMQ 5.x parity): > consumersBeforeDispatchStarts > timeBeforeDispatchStarts > [http://activemq.apache.org/per-destination-policies.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1992) JDBC File Locks Map is not thread safe
[ https://issues.apache.org/jira/browse/ARTEMIS-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558443#comment-16558443 ] ASF GitHub Bot commented on ARTEMIS-1992: - GitHub user mtaylor opened a pull request: https://github.com/apache/activemq-artemis/pull/2195 ARTEMIS-1992 Make JDBC File Lock map thread safe You can merge this pull request into a Git repository by running: $ git pull https://github.com/mtaylor/activemq-artemis ARTEMIS-1992 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2195.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2195 commit 0c49ced1c11109d911394c2675ad477b30abde18 Author: Martyn Taylor Date: 2018-07-26T15:37:08Z ARTEMIS-1992 Make JDBC File Lock map thread safe > JDBC File Locks Map is not thread safe > -- > > Key: ARTEMIS-1992 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1992 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Martyn Taylor >Priority: Major > > Just need to use concurrent map -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1992) JDBC File Locks Map is not thread safe
Martyn Taylor created ARTEMIS-1992: -- Summary: JDBC File Locks Map is not thread safe Key: ARTEMIS-1992 URL: https://issues.apache.org/jira/browse/ARTEMIS-1992 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Martyn Taylor Just need to use concurrent map -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7021) DestinationMap access inside Abstract Region readwrite lock does not need sync
[ https://issues.apache.org/jira/browse/AMQ-7021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558433#comment-16558433 ] ASF subversion and git services commented on AMQ-7021: -- Commit c0a6f47a475e367ace5b96e19d98ec5ca97f2175 in activemq's branch refs/heads/activemq-5.15.x from gtully [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=c0a6f47 ] AMQ-7021 - add unsynchronised accessors to destination map for usage with rw lock from abstract region; allow concurrent read of the destination map (cherry picked from commit 0b76d3a0eac9802941b9dfc2a85589dac95ed40a) > DestinationMap access inside Abstract Region readwrite lock does not need sync > -- > > Key: AMQ-7021 > URL: https://issues.apache.org/jira/browse/AMQ-7021 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > Using multiple virtual topic publishers, there is unnecessary serialisation > via the destination map. > the read write lock introduced in AMQ-3454 is sufficient to guard access in > this case and reads should operate in parallel. > with many thousand destinations lookup can be expensive and the serialisation > becomes apparent. -- 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=16558411#comment-16558411 ] Jeff Genender commented on AMQ-7015: The new code calls commit and rollback with 28819aea4aa981d33c710d9d5e26f3cb6e03c1de calls commit and rollback, with the store command. Is that disabled? From the code paths, it looks like it does a full commit or rollback and isn't disabled. I think what I am failing to understand is how that does not act nearly identically to the MBean? > 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 >Assignee: Jeff Genender >Priority: Minor > Fix For: 5.16.0, 5.15.5 > > > 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-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=16558405#comment-16558405 ] Gary Tully commented on AMQ-7015: - Having a mbean.rollbackAll operation leaves the broker still capable to do XA recovery for subsequent XA transactions. Having a kahadb flag effectively disables xa recovery. If that flag is set and recovery will not be used, then there is no need to do the work of persisting the prepare outcome. That feature, to my mind is xaRecovery=false. I don't know the use case but do you really intend to disable xa recovery fully? > 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 >Assignee: Jeff Genender >Priority: Minor > Fix For: 5.16.0, 5.15.5 > > > 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] [Comment Edited] (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=16558378#comment-16558378 ] Jeff Genender edited comment on AMQ-7015 at 7/26/18 2:50 PM: - Hi Gary, I would love to have longer conversation to that we could discuss this more in-depth. I am a bit confused. The setting now acts nearly identical to the MBean, but works en-masse. It allows you to select comit/rollback/ or nothing (default). The unit tests appear to confirm that it works whereby the commit adds the messages through, the rollback removes them. It seems to so the same as the MBean. Could you help explain why this new change does not work? The new code does all with KahaDB along with processing the XA (or not). Thanks! was (Author: jgenender): Hi Gary, I would love to have longer conversation to that we could discuss this more in-depth. I am a bit confused. The setting now acts nearly identical to the MBean, but works en-masse. It allows you to select comit/rollback/ or nothing (default). The unit tests appear to confirm that it works whereby the commit adds the messages through, the rollback removes them. It seems to so the same as the MBean. Could you help explain why this new change does not work? > 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 >Assignee: Jeff Genender >Priority: Minor > Fix For: 5.16.0, 5.15.5 > > > 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] [Comment Edited] (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=16558378#comment-16558378 ] Jeff Genender edited comment on AMQ-7015 at 7/26/18 2:46 PM: - Hi Gary, I would love to have longer conversation to that we could discuss this more in-depth. I am a bit confused. The setting now acts nearly identical to the MBean, but works en-masse. It allows you to select comit/rollback/ or nothing (default). The unit tests appear to confirm that it works whereby the commit adds the messages through, the rollback removes them. It seems to so the same as the MBean. Could you help explain why this new change does not work? was (Author: jgenender): Hi Gary, I would love to have longer conversation to that we could discuss this more in-depth. I am a bit confused. The setting now acts nearly identical to the MBean, but works en-masse. It allows you to select comit/rollback/ nor nothing (default). The unit tests appear to confirm that it works whereby the commit adds the messages through, the rollback removes them. It seems to so the same as the MBean. Could you help explain why this new change does not work? > 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 >Assignee: Jeff Genender >Priority: Minor > Fix For: 5.16.0, 5.15.5 > > > 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-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=16558378#comment-16558378 ] Jeff Genender commented on AMQ-7015: Hi Gary, I would love to have longer conversation to that we could discuss this more in-depth. I am a bit confused. The setting now acts nearly identical to the MBean, but works en-masse. It allows you to select comit/rollback/ nor nothing (default). The unit tests appear to confirm that it works whereby the commit adds the messages through, the rollback removes them. It seems to so the same as the MBean. Could you help explain why this new change does not work? > 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 >Assignee: Jeff Genender >Priority: Minor > Fix For: 5.16.0, 5.15.5 > > > 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] [Resolved] (ARTEMIS-1979) Table names with DB2 should be upper-cases
[ https://issues.apache.org/jira/browse/ARTEMIS-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro resolved ARTEMIS-1979. -- Resolution: Fixed > Table names with DB2 should be upper-cases > -- > > Key: ARTEMIS-1979 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1979 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.2 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.7.0 > > > This issue is happening on Wildfly, but it affects Artemis as well. > To reproduce it: > * Configure Artemis in Wildfly to use DB2 JDBC persistence store. > * Redefine name of a database table and use lower case letters. > * Restart Wildfly > After the restart of Wildfly, boot of Artemis component fails. It seems that > if table name is in lower case, Artemis is not able to detect that the > particular table exists and tries to recreate it. The create operation fails > and thus initialization of JDBC driver fails as well. > The same scenario works with Oracle 12c database: the broker is turning > Oracle table names to upper cases thanks to table-names-case property on > journal-sql.properties configuration file. -- 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=16558171#comment-16558171
]
Gary Tully commented on AMQ-7015:
-
[~jgenender] there may be cross wires here, my suggestion was to have an op on
the MBean to commit/rollback all as a convenience. In any event, is needs to be
an explicit operation to force a heuristic outcome. From an XA transaction
point of view the heuristic has got to be informed by the other XA resources in
the mix or the state of the distributed transaction as observed by the
transaction manager and its log.
I can't think of a use case that would know in advance if commit is appropriate
broker wide. Possibly rolling back is ok, but it will upset the distributed
transaction manager which will have to record the adverse outcome in some way.
however, In the analogy with persistence=false, xaRecovery=false may make
sense, and we can avoid sync storing a prepare record such that on first
recovery any pending xa transaction will rollback.
To achieve that, from a kahadb perspective, deciding to not store prepare
messages would suffice. The trace timers get in the way, but the index
processing does not care about the location and the prepare record is always
sync. With this change I think you would get what you are after, ie: no xa
recovery on restart.
{code:java}
diff --git
a/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java
b/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java
index 0e5c237d4..1016a9087 100644
---
a/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java
+++
b/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/MessageDatabase.java
@@ -1117,16 +1117,22 @@ public abstract class MessageDatabase extends
ServiceSupport implements BrokerSe
* the JournalMessage is used to update the index just like it would be
done
* during a recovery process.
*/
+ boolean xaRecovery = true;
public Location store(JournalCommand data, boolean sync, IndexAware
before, Runnable after, Runnable onJournalStoreComplete) throws IOException {
try {
- ByteSequence sequence = toByteSequence(data);
- Location location;
+ ByteSequence sequence = null;
+ if (!xaRecovery || data.type() !=
KahaEntryType.KAHA_PREPARE_COMMAND) {
+ sequence = toByteSequence(data);
+ }
+ Location location = null;
checkpointLock.readLock().lock();
try {
long start = System.currentTimeMillis();
- location = onJournalStoreComplete == null ?
journal.write(sequence, sync) : journal.write(sequence, onJournalStoreComplete)
;
+ if (sequence != null) {
+ location = onJournalStoreComplete == null ?
journal.write(sequence, sync) : journal.write(sequence, onJournalStoreComplete);
+ }
long start2 = System.currentTimeMillis();
//Track the last async update so we know if we need to sync at
the next checkpoint
if (!sync && journal.isJournalDiskSyncPeriodic()) {{code}
> 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
>Assignee: Jeff Genender
>Priority: Minor
> Fix For: 5.16.0, 5.15.5
>
>
> 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] [Resolved] (AMQ-7021) DestinationMap access inside Abstract Region readwrite lock does not need sync
[ https://issues.apache.org/jira/browse/AMQ-7021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-7021. - Resolution: Fixed A virtual topic send intensive test is ~40% better with the changes b/c matching on the dest map can now operate in parallel as intended by the rw-lock refactor. Other users of destinationMap still retain the sync get/add semantics > DestinationMap access inside Abstract Region readwrite lock does not need sync > -- > > Key: AMQ-7021 > URL: https://issues.apache.org/jira/browse/AMQ-7021 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > Using multiple virtual topic publishers, there is unnecessary serialisation > via the destination map. > the read write lock introduced in AMQ-3454 is sufficient to guard access in > this case and reads should operate in parallel. > with many thousand destinations lookup can be expensive and the serialisation > becomes apparent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7021) DestinationMap access inside Abstract Region readwrite lock does not need sync
[ https://issues.apache.org/jira/browse/AMQ-7021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558106#comment-16558106 ] ASF subversion and git services commented on AMQ-7021: -- Commit 0b76d3a0eac9802941b9dfc2a85589dac95ed40a in activemq's branch refs/heads/master from gtully [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=0b76d3a ] AMQ-7021 - add unsynchronised accessors to destination map for usage with rw lock from abstract region; allow concurrent read of the destination map > DestinationMap access inside Abstract Region readwrite lock does not need sync > -- > > Key: AMQ-7021 > URL: https://issues.apache.org/jira/browse/AMQ-7021 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > Using multiple virtual topic publishers, there is unnecessary serialisation > via the destination map. > the read write lock introduced in AMQ-3454 is sufficient to guard access in > this case and reads should operate in parallel. > with many thousand destinations lookup can be expensive and the serialisation > becomes apparent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7009) ActiveMQ stop delivering messages
[ https://issues.apache.org/jira/browse/AMQ-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nezih BEN FREDJ updated AMQ-7009: - Attachment: MemoryMessageStoreQueueCursorTest.java > ActiveMQ stop delivering messages > - > > Key: AMQ-7009 > URL: https://issues.apache.org/jira/browse/AMQ-7009 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.4 >Reporter: Nezih BEN FREDJ >Priority: Critical > Attachments: MemoryMessageStore.java, > MemoryMessageStoreQueueCursorTest.java, activemq.log > > > We have a problem with ActiveMQ 5.15.4, it stop deliver messages to clients. > This happens completely randomly and we are not able to give a test case that > reproduce the problem > Activemq is configured to use the « memoryPersistenceAdapter » > > When examining memory dumps, we identified incoherent situation in the class > MemoryMessageStore that can lead to stop delivering messages. When : > - MemoryMessageStore.recoverNextMessages(...) is called > - « lastBatchId » is not null > - « messageTable » does not contains any entry with « lastBatchId » as key > no messages are recovered > > We added logs to try to understand how it is possible to have a non null « > lastBatchId » and « messageTable » with no entry having « lastBatchId » as > key. > > We noticed that the method setBatch is called with a non null « messageId » > parameter, but no message with this id is inserted in « messageTable ». After > that, when the method MemoryMessageStore.recoverNextMessages(...) is called, > it does nothing and no messages are recoverd. And the system go in a what > looks like an endless loop. > > We are testing a temporary solution by resetting « lastBatchId » to null when > the incoherent situation is detected. > > Can you help us resolving the problem at the source and not just get around. > I joined modified source code of the class MemoryMessageStore and an extract > of the log file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7009) ActiveMQ stop delivering messages
[ https://issues.apache.org/jira/browse/AMQ-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nezih BEN FREDJ updated AMQ-7009: - Attachment: (was: MemoryMessageStoreQueueCursor.java) > ActiveMQ stop delivering messages > - > > Key: AMQ-7009 > URL: https://issues.apache.org/jira/browse/AMQ-7009 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.4 >Reporter: Nezih BEN FREDJ >Priority: Critical > Attachments: MemoryMessageStore.java, > MemoryMessageStoreQueueCursorTest.java, activemq.log > > > We have a problem with ActiveMQ 5.15.4, it stop deliver messages to clients. > This happens completely randomly and we are not able to give a test case that > reproduce the problem > Activemq is configured to use the « memoryPersistenceAdapter » > > When examining memory dumps, we identified incoherent situation in the class > MemoryMessageStore that can lead to stop delivering messages. When : > - MemoryMessageStore.recoverNextMessages(...) is called > - « lastBatchId » is not null > - « messageTable » does not contains any entry with « lastBatchId » as key > no messages are recovered > > We added logs to try to understand how it is possible to have a non null « > lastBatchId » and « messageTable » with no entry having « lastBatchId » as > key. > > We noticed that the method setBatch is called with a non null « messageId » > parameter, but no message with this id is inserted in « messageTable ». After > that, when the method MemoryMessageStore.recoverNextMessages(...) is called, > it does nothing and no messages are recoverd. And the system go in a what > looks like an endless loop. > > We are testing a temporary solution by resetting « lastBatchId » to null when > the incoherent situation is detected. > > Can you help us resolving the problem at the source and not just get around. > I joined modified source code of the class MemoryMessageStore and an extract > of the log file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7009) ActiveMQ stop delivering messages
[ https://issues.apache.org/jira/browse/AMQ-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558093#comment-16558093 ] Nezih BEN FREDJ commented on AMQ-7009: -- Explanation : when activating TRACE level logs for the class "AbstractStoreCursor", I noticed the next two lines in the log file : 2018-07-18 12:02:06,136 | TRACE | org.apache.activemq.broker.region.cursors.QueueStorePrefetch@3a5f8f9a:retour.event.box4,batchResetNeeded=false,size=0,cacheEnabled=true,maxBatchSize:1,hasSpace:false,pendingCachedIds.size:0,lastSyncCachedId:ID:vhqve41.pprod.helios.cp-54155-1531902423423-1:10:2:1:282,lastSyncCachedId-seq:75,lastAsyncCachedId:null,lastAsyncCachedId-seq:null,store=org.apache.activemq.store.memory.MemoryMessageStore@349876a1 - disabling cache on add ID:vhqve41.pprod.helios.cp-54155-1531902423423-1:3:1:1:370 76 | org.apache.activemq.broker.region.cursors.AbstractStoreCursor | ActiveMQ Transport: tcp:///174.4.111.217:35610@ 2018-07-18 12:02:06,136 | WARN | @@@NBF@@@ setBatch called with param messageId : (ID:vhqve41.pprod.helios.cp-54155-1531902423423-1:10:2:1:282). lastBatchId : (null) the new lastBatchId : (ID:vhqve41.pprod.helios.cp-54155-1531902423423-1:10:2:1:282) is NOT in messageTable | org.apache.activemq.store.memory.MemoryMessageStore | ActiveMQ Transport: tcp:///174.4.111.217:35610@ The second line shows that setBatch is called with a parameter "messageId" corresponding to a probably old message that is already removed from store. The first line shows that just befor calling setBatch, we had (hasSpace:false while size=0) which mean : there is no messages in the queue but there is no free space too !!!. It seems like messages are consumed but their space is not rendered or not yet rendered at that moment. > ActiveMQ stop delivering messages > - > > Key: AMQ-7009 > URL: https://issues.apache.org/jira/browse/AMQ-7009 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.4 >Reporter: Nezih BEN FREDJ >Priority: Critical > Attachments: MemoryMessageStore.java, > MemoryMessageStoreQueueCursor.java, activemq.log > > > We have a problem with ActiveMQ 5.15.4, it stop deliver messages to clients. > This happens completely randomly and we are not able to give a test case that > reproduce the problem > Activemq is configured to use the « memoryPersistenceAdapter » > > When examining memory dumps, we identified incoherent situation in the class > MemoryMessageStore that can lead to stop delivering messages. When : > - MemoryMessageStore.recoverNextMessages(...) is called > - « lastBatchId » is not null > - « messageTable » does not contains any entry with « lastBatchId » as key > no messages are recovered > > We added logs to try to understand how it is possible to have a non null « > lastBatchId » and « messageTable » with no entry having « lastBatchId » as > key. > > We noticed that the method setBatch is called with a non null « messageId » > parameter, but no message with this id is inserted in « messageTable ». After > that, when the method MemoryMessageStore.recoverNextMessages(...) is called, > it does nothing and no messages are recoverd. And the system go in a what > looks like an endless loop. > > We are testing a temporary solution by resetting « lastBatchId » to null when > the incoherent situation is detected. > > Can you help us resolving the problem at the source and not just get around. > I joined modified source code of the class MemoryMessageStore and an extract > of the log file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
