[jira] [Resolved] (ARTEMIS-3535) management-message-attribute-size-limit = -1 does not unlimit
[
https://issues.apache.org/jira/browse/ARTEMIS-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-3535.
-
Resolution: Fixed
> management-message-attribute-size-limit = -1 does not unlimit
> -
>
> Key: ARTEMIS-3535
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3535
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.19.0
>Reporter: arne anka
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.20.0
>
> Attachments: artemis-rest-2.19.0.war, broken_message.png, broker.xml,
> limited.jpg, rest.messaging.config.file.xml, test.xml, unlimited.jpg, web.xml
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> With the new option messages are truncated.
> [https://activemq.apache.org/components/artemis/documentation/latest/versions.html]
> states for 2.18.0 that this may be overriden by using
> -1
> as value. But that doesn't work.
> {{broker.xml}}
> {code:xml}
>
> ...
>
> -1
>
> {code}
> Text shown is empty.
> Changing -1 to eg 1024 text appears partially.
> Seems -1 does not work as expected.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (ARTEMIS-3115) Incorrect default call-failover-timeout on clusterConnection in broker.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-3115. - Fix Version/s: 2.20.0 Resolution: Fixed > Incorrect default call-failover-timeout on clusterConnection in broker.xml > -- > > Key: ARTEMIS-3115 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3115 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.16.0 >Reporter: Mikhail Lukyanov >Assignee: Justin Bertram >Priority: Major > Fix For: 2.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > > ClusterConnectionConfiguration uses > ActiveMQDefaultConfiguration.getDefaultClusterCallFailoverTimeout() > = -1 > broker.xml uses in > FileConfigurationParser > ActiveMQClient.DEFAULT_CALL_FAILOVER_TIMEOUT = 3 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (ARTEMIS-3542) Avoid requesting the root attribute when binding a user to LDAP
[ https://issues.apache.org/jira/browse/ARTEMIS-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-3542. - Fix Version/s: 2.20.0 Resolution: Fixed > Avoid requesting the root attribute when binding a user to LDAP > --- > > Key: ARTEMIS-3542 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3542 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JAAS >Affects Versions: 2.19.0 >Reporter: Marlon Müller >Priority: Minor > Fix For: 2.20.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currently the bindUser-method of the LDAPLoginModule tries to verify the user > through requesting the root attribute of the LDAP tree. This check fails if > the user is not allowed to access the root element although everything else > is working properly. > To fix this problem the user should only request its own LDAP attribute as > this will always be possible. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3145) Failure when shutting down the broker
[
https://issues.apache.org/jira/browse/ARTEMIS-3145?focusedWorklogId=695506=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695506
]
ASF GitHub Bot logged work on ARTEMIS-3145:
---
Author: ASF GitHub Bot
Created on: 14/Dec/21 04:14
Start Date: 14/Dec/21 04:14
Worklog Time Spent: 10m
Work Description: jbertram commented on a change in pull request #3817:
URL: https://github.com/apache/activemq-artemis/pull/3817#discussion_r768303343
##
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/FileLockNodeManager.java
##
@@ -355,7 +355,7 @@ private byte getState() throws NodeManagerException {
result = bb.get(0);
}
} finally {
-if (lock != null) {
+if (lock != null && lock.isValid()) {
Review comment:
Although this isn't on a hot path, generating the exception is expensive
so I figured it would be best to avoid it if possible.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 695506)
Time Spent: 20m (was: 10m)
> Failure when shutting down the broker
> -
>
> Key: ARTEMIS-3145
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3145
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
>Reporter: Emmanuel Hugonnet
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While shutting down the broker in WildFly we came along the following issue:
> {noformat}
> 2021-02-23 13:17:50,852 INFO [org.apache.activemq.artemis.ra] (ServerService
> Thread Pool -- 39) AMQ151003: resource adaptor stopped
> 2021-02-23 13:17:50,994 ERROR
> [org.apache.activemq.artemis.core.server.impl.FileLockNodeManager] (Thread-1
> (ActiveMQ-scheduled-threads)) java.nio.channels.ClosedChannelException:
> org.apache.activemq.artemis.core.server.NodeManager$NodeManagerException:
> java.nio.channels.ClosedChannelException
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.getState(FileLockNodeManager.java:364)
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.access$500(FileLockNodeManager.java:36)
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager$MonitorLock.run(FileLockNodeManager.java:516)
> at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.runForExecutor(ActiveMQScheduledComponent.java:313)
> at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.bookedRunForScheduler(ActiveMQScheduledComponent.java:328)
> at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.runForScheduler(ActiveMQScheduledComponent.java:339)
> at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.lambda$start$0(ActiveMQScheduledComponent.java:166)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> Caused by: java.nio.channels.ClosedChannelException
> at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58)
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.getState(FileLockNodeManager.java:358)
> ... 13 more
> 2021-02-23 13:17:50,997 WARN
> [org.apache.activemq.artemis.core.server.impl.FileLockNodeManager] (Thread-1
> (ActiveMQ-scheduled-threads)) Lost the lock according to the monitor,
> notifying listeners
> 2021-02-23 13:17:51,493 WARN
> [org.apache.activemq.artemis.core.server.impl.FileLockNodeManager]
> (ServerService Thread Pool -- 39) Failure when accessing a lock file:
> java.nio.channels.ClosedChannelException
> at sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:110)
> at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:1100)
> at
[jira] [Work logged] (ARTEMIS-3535) management-message-attribute-size-limit = -1 does not unlimit
[
https://issues.apache.org/jira/browse/ARTEMIS-3535?focusedWorklogId=695501=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695501
]
ASF GitHub Bot logged work on ARTEMIS-3535:
---
Author: ASF GitHub Bot
Created on: 14/Dec/21 03:58
Start Date: 14/Dec/21 03:58
Worklog Time Spent: 10m
Work Description: asfgit closed pull request #3824:
URL: https://github.com/apache/activemq-artemis/pull/3824
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 695501)
Time Spent: 40m (was: 0.5h)
> management-message-attribute-size-limit = -1 does not unlimit
> -
>
> Key: ARTEMIS-3535
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3535
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.19.0
>Reporter: arne anka
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.20.0
>
> Attachments: artemis-rest-2.19.0.war, broken_message.png, broker.xml,
> limited.jpg, rest.messaging.config.file.xml, test.xml, unlimited.jpg, web.xml
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> With the new option messages are truncated.
> [https://activemq.apache.org/components/artemis/documentation/latest/versions.html]
> states for 2.18.0 that this may be overriden by using
> -1
> as value. But that doesn't work.
> {{broker.xml}}
> {code:xml}
>
> ...
>
> -1
>
> {code}
> Text shown is empty.
> Changing -1 to eg 1024 text appears partially.
> Seems -1 does not work as expected.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3535) management-message-attribute-size-limit = -1 does not unlimit
[
https://issues.apache.org/jira/browse/ARTEMIS-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458884#comment-17458884
]
ASF subversion and git services commented on ARTEMIS-3535:
--
Commit fb2270dc057c773f99e679132fd8ce926ff2fc58 in activemq-artemis's branch
refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=fb2270d ]
ARTEMIS-3535 bytes messages not obeying management limit
> management-message-attribute-size-limit = -1 does not unlimit
> -
>
> Key: ARTEMIS-3535
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3535
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Web Console
>Affects Versions: 2.19.0
>Reporter: arne anka
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.20.0
>
> Attachments: artemis-rest-2.19.0.war, broken_message.png, broker.xml,
> limited.jpg, rest.messaging.config.file.xml, test.xml, unlimited.jpg, web.xml
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> With the new option messages are truncated.
> [https://activemq.apache.org/components/artemis/documentation/latest/versions.html]
> states for 2.18.0 that this may be overriden by using
> -1
> as value. But that doesn't work.
> {{broker.xml}}
> {code:xml}
>
> ...
>
> -1
>
> {code}
> Text shown is empty.
> Changing -1 to eg 1024 text appears partially.
> Seems -1 does not work as expected.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3115) Incorrect default call-failover-timeout on clusterConnection in broker.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-3115?focusedWorklogId=695500=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695500 ] ASF GitHub Bot logged work on ARTEMIS-3115: --- Author: ASF GitHub Bot Created on: 14/Dec/21 03:57 Start Date: 14/Dec/21 03:57 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3816: URL: https://github.com/apache/activemq-artemis/pull/3816 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695500) Remaining Estimate: 0h Time Spent: 10m > Incorrect default call-failover-timeout on clusterConnection in broker.xml > -- > > Key: ARTEMIS-3115 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3115 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.16.0 >Reporter: Mikhail Lukyanov >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > ClusterConnectionConfiguration uses > ActiveMQDefaultConfiguration.getDefaultClusterCallFailoverTimeout() > = -1 > broker.xml uses in > FileConfigurationParser > ActiveMQClient.DEFAULT_CALL_FAILOVER_TIMEOUT = 3 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3115) Incorrect default call-failover-timeout on clusterConnection in broker.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458883#comment-17458883 ] ASF subversion and git services commented on ARTEMIS-3115: -- Commit 996f6f46fe11bf6ffc53cf97761bae1eb69ab8e4 in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=996f6f4 ] ARTEMIS-3115 use correct call timeout defaults for cluster-connection > Incorrect default call-failover-timeout on clusterConnection in broker.xml > -- > > Key: ARTEMIS-3115 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3115 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.16.0 >Reporter: Mikhail Lukyanov >Assignee: Justin Bertram >Priority: Major > > ClusterConnectionConfiguration uses > ActiveMQDefaultConfiguration.getDefaultClusterCallFailoverTimeout() > = -1 > broker.xml uses in > FileConfigurationParser > ActiveMQClient.DEFAULT_CALL_FAILOVER_TIMEOUT = 3 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3542) Avoid requesting the root attribute when binding a user to LDAP
[ https://issues.apache.org/jira/browse/ARTEMIS-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458882#comment-17458882 ] ASF subversion and git services commented on ARTEMIS-3542: -- Commit 47e947ad7b726474b61f5ead8056fcaf5c8f1ec2 in activemq-artemis's branch refs/heads/main from Marlon Müller [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=47e947a ] ARTEMIS-3542 Avoid requesting LDAP root attribute Check getAttributes with dn of user entry to avoid missing permissions > Avoid requesting the root attribute when binding a user to LDAP > --- > > Key: ARTEMIS-3542 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3542 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JAAS >Affects Versions: 2.19.0 >Reporter: Marlon Müller >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > Currently the bindUser-method of the LDAPLoginModule tries to verify the user > through requesting the root attribute of the LDAP tree. This check fails if > the user is not allowed to access the root element although everything else > is working properly. > To fix this problem the user should only request its own LDAP attribute as > this will always be possible. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3542) Avoid requesting the root attribute when binding a user to LDAP
[ https://issues.apache.org/jira/browse/ARTEMIS-3542?focusedWorklogId=695499=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695499 ] ASF GitHub Bot logged work on ARTEMIS-3542: --- Author: ASF GitHub Bot Created on: 14/Dec/21 03:56 Start Date: 14/Dec/21 03:56 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3820: URL: https://github.com/apache/activemq-artemis/pull/3820 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695499) Time Spent: 1h 10m (was: 1h) > Avoid requesting the root attribute when binding a user to LDAP > --- > > Key: ARTEMIS-3542 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3542 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: JAAS >Affects Versions: 2.19.0 >Reporter: Marlon Müller >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > Currently the bindUser-method of the LDAPLoginModule tries to verify the user > through requesting the root attribute of the LDAP tree. This check fails if > the user is not allowed to access the root element although everything else > is working properly. > To fix this problem the user should only request its own LDAP attribute as > this will always be possible. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3574) Allow multiple bindings for embedded webserver
[ https://issues.apache.org/jira/browse/ARTEMIS-3574?focusedWorklogId=695498=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695498 ] ASF GitHub Bot logged work on ARTEMIS-3574: --- Author: ASF GitHub Bot Created on: 14/Dec/21 03:53 Start Date: 14/Dec/21 03:53 Worklog Time Spent: 10m Work Description: jbertram commented on pull request #3853: URL: https://github.com/apache/activemq-artemis/pull/3853#issuecomment-993132047 @MM53, there's a conflict now. It's a simple change from c502e94ade9e050849a2d7fd2431c28ea77f4f0a. Once you resolve the conflict I'll merge the PR. Thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695498) Time Spent: 1h 10m (was: 1h) > Allow multiple bindings for embedded webserver > -- > > Key: ARTEMIS-3574 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3574 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.19.0 >Reporter: Marlon Müller >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > At the moment it is only possible to configure one binding for the embedded > jetty webserver to listen on. It would be great to have the possibility to > configure multiple bindings for different war-files in order to serve those > files on different ports and allow the usage of http and https at the same > time. > My current problem is the usage of the prometheus metrics plugin. In our > setup it is not possible to call the "/metrics" endpoint with SSL enabled. > Therefore I would like to define a second binding without SSL enabled for > this plugin. Disabling SSL completely is not an option as other endpoints > like the jolokia-api and the web-console require some user authentication > which should be protected. > The idea is to move all binding related configuration parameters of the > "web" element and the configured "apps" in "bootstrap.xml" to a new element > called "binding" and put a list of those "binding" elements inside the "web" > element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3601) Expose acceptors via management
[ https://issues.apache.org/jira/browse/ARTEMIS-3601?focusedWorklogId=695495=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695495 ] ASF GitHub Bot logged work on ARTEMIS-3601: --- Author: ASF GitHub Bot Created on: 14/Dec/21 03:49 Start Date: 14/Dec/21 03:49 Worklog Time Spent: 10m Work Description: jbertram edited a comment on pull request #3873: URL: https://github.com/apache/activemq-artemis/pull/3873#issuecomment-993130361 I just updated the branch. It should be ready to be merged. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695495) Time Spent: 40m (was: 0.5h) > Expose acceptors via management > --- > > Key: ARTEMIS-3601 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3601 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3601) Expose acceptors via management
[ https://issues.apache.org/jira/browse/ARTEMIS-3601?focusedWorklogId=695494=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695494 ] ASF GitHub Bot logged work on ARTEMIS-3601: --- Author: ASF GitHub Bot Created on: 14/Dec/21 03:49 Start Date: 14/Dec/21 03:49 Worklog Time Spent: 10m Work Description: jbertram commented on pull request #3873: URL: https://github.com/apache/activemq-artemis/pull/3873#issuecomment-993130361 I just update the branch. It should be ready to be merged. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695494) Time Spent: 0.5h (was: 20m) > Expose acceptors via management > --- > > Key: ARTEMIS-3601 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3601 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3601) Expose acceptors via management
[ https://issues.apache.org/jira/browse/ARTEMIS-3601?focusedWorklogId=695450=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695450 ] ASF GitHub Bot logged work on ARTEMIS-3601: --- Author: ASF GitHub Bot Created on: 14/Dec/21 01:33 Start Date: 14/Dec/21 01:33 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #3873: URL: https://github.com/apache/activemq-artemis/pull/3873#issuecomment-993072154 @jbertram can you rebase and fix conflicts? @jbertram is this ready to merge after @brusdev 's review? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695450) Time Spent: 20m (was: 10m) > Expose acceptors via management > --- > > Key: ARTEMIS-3601 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3601 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (AMQ-8433) Request for a formal response from Active MQ regarding Log4j vulnerability against CVE-2021-44228
Imran Ali created AMQ-8433: -- Summary: Request for a formal response from Active MQ regarding Log4j vulnerability against CVE-2021-44228 Key: AMQ-8433 URL: https://issues.apache.org/jira/browse/AMQ-8433 Project: ActiveMQ Issue Type: Bug Components: Documentation Affects Versions: 5.15.15 Reporter: Imran Ali Hi Guys, Active MQ is still using Log4j v1 and although its not directly impacted by the vulnerability CVE-2021-44228 we are getting follow up questions from the customers on what is the formal timeline for Active MQ to transitioned to the latest version of log4j. Can you please let us know what are the plans regarding this. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (AMQ-8430) Log4j 1.2.17 is being used in activemq-all - 5.16.3 : [CVE-2021-44228] [log4j] [1.2.17]
[
https://issues.apache.org/jira/browse/AMQ-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458670#comment-17458670
]
Doug Whitfield commented on AMQ-8430:
-
Log4j 1.2 is not vulnerable, only log4j*2*
That said, unless you have a patched version from a vendor, 1.2 is old and may
have other vulnerabilities.
> Log4j 1.2.17 is being used in activemq-all - 5.16.3 : [CVE-2021-44228]
> [log4j] [1.2.17]
>
>
> Key: AMQ-8430
> URL: https://issues.apache.org/jira/browse/AMQ-8430
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.16.3
>Reporter: Aman Mishra
>Priority: Critical
>
> *Aqua Description :* Apache Log4j2 <=2.14.1 JNDI features used in
> configuration, log messages, and parameters do not protect against attacker
> controlled LDAP and other JNDI related endpoints. An attacker who can control
> log messages or log message parameters can execute arbitrary code loaded from
> LDAP servers when message lookup substitution is enabled. From log4j 2.15.0,
> this behavior has been disabled by default. In previous releases (>2.10) this
> behavior can be mitigated by setting system property
> "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class
> from the classpath (example: zip {-}q -d log4j-core{-}*.jar
> org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see
> [https://www.oracle.com/java/technologies/javase/8u121-relnotes.html])
> protects against remote code execution by defaulting
> "com.sun.jndi.rmi.object.trustURLCodebase" and
> "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3605) Upgrade jetty version to 9.4.44.v20210927
[ https://issues.apache.org/jira/browse/ARTEMIS-3605?focusedWorklogId=695274=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695274 ] ASF GitHub Bot logged work on ARTEMIS-3605: --- Author: ASF GitHub Bot Created on: 13/Dec/21 18:37 Start Date: 13/Dec/21 18:37 Worklog Time Spent: 10m Work Description: clebertsuconic merged pull request #3879: URL: https://github.com/apache/activemq-artemis/pull/3879 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695274) Remaining Estimate: 0h Time Spent: 10m > Upgrade jetty version to 9.4.44.v20210927 > - > > Key: ARTEMIS-3605 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3605 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3605) Upgrade jetty version to 9.4.44.v20210927
[ https://issues.apache.org/jira/browse/ARTEMIS-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458615#comment-17458615 ] ASF subversion and git services commented on ARTEMIS-3605: -- Commit c502e94ade9e050849a2d7fd2431c28ea77f4f0a in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c502e94 ] ARTEMIS-3605 Upgrade jetty version to 9.4.44.v20210927 > Upgrade jetty version to 9.4.44.v20210927 > - > > Key: ARTEMIS-3605 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3605 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3559) Update netty version to 4.1.70.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458614#comment-17458614 ] ASF subversion and git services commented on ARTEMIS-3559: -- Commit 923d0dc02834b331c5bf360ce5eefba065341349 in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=923d0dc ] ARTEMIS-3559 Exclude netty-transport-native-epoll from zookeeper The netty-transport-native-epoll transitive dependency version of zookeeper doesn't match the netty version defined and causes a distribution issue. > Update netty version to 4.1.70.Final > > > Key: ARTEMIS-3559 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3559 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.20.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update netty version to 4.1.70.Final and netty-tcnative version to > 2.0.44.Final. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3559) Update netty version to 4.1.70.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-3559?focusedWorklogId=695273=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695273 ] ASF GitHub Bot logged work on ARTEMIS-3559: --- Author: ASF GitHub Bot Created on: 13/Dec/21 18:37 Start Date: 13/Dec/21 18:37 Worklog Time Spent: 10m Work Description: clebertsuconic merged pull request #3878: URL: https://github.com/apache/activemq-artemis/pull/3878 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695273) Time Spent: 40m (was: 0.5h) > Update netty version to 4.1.70.Final > > > Key: ARTEMIS-3559 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3559 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.20.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Update netty version to 4.1.70.Final and netty-tcnative version to > 2.0.44.Final. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3596) ServiceLoader.load causing issues in OSGi enviroments.
[ https://issues.apache.org/jira/browse/ARTEMIS-3596?focusedWorklogId=695263=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695263 ] ASF GitHub Bot logged work on ARTEMIS-3596: --- Author: ASF GitHub Bot Created on: 13/Dec/21 18:04 Start Date: 13/Dec/21 18:04 Worklog Time Spent: 10m Work Description: ryeats commented on pull request #3869: URL: https://github.com/apache/activemq-artemis/pull/3869#issuecomment-992732682 Apologies I just realized I was rebased off of master instead of main when i initially put up the PR so there was actually quite a lot of changes that could have fixed the issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695263) Time Spent: 2h 20m (was: 2h 10m) > ServiceLoader.load causing issues in OSGi enviroments. > -- > > Key: ARTEMIS-3596 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3596 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: osgi >Affects Versions: 2.19.0 >Reporter: Ryan Yeats >Priority: Major > Time Spent: 2h 20m > Remaining Estimate: 0h > > Our system runs Artemis inside of Karaf as an OSGi bundle. Starting with > version 2.19.0 of Artemis, Artemis fails to start correctly due to an > exception during the bundle resolution process. The problems happens when the > artemis-server-osgi bundle is reloaded by the bundle resolution process. The > bundle starts correctly the first time, but during the resolution process, an > import Artemis uses is refreshed causing the bundle to be reloaded. > Consequently, the ServiceLoader.load method is called again by the static > initializer block in the SSLContextFactoryProvider class. The > ServiceLoader.load is passed in a class loader is obtained by calling > Thread.currentThread.getContextClassloader(). The first time the static > initializer block is executed, the classes DefaultSSLContextFactory and its > interface, SSLContextFactory, are loaded. However, on reload > Thread.currentThread.getContextClassloader() returns the original > DefaultSSLContextFactory which is no long the one corresponding to the class > loader of the bundle the second time it is started. Resulting in the > following error message: > org.apache.activemq.artemis.spi.core.remoting.ssl.SSLContextFactory: > org.apache.activemq.artemis.core.remoting.impl.ssl.DefaultSSLContextFactory > not a subtype > I believe the best way to fix this is to change > ServiceLoader.load(SSLContextFactory.class, > Thread.currentThread().getContextClassLoader()) > to > ServiceLoader.load(SSLContextFactory.class, > SSLContextFactoryProvider.class.getClassLoader()) > Which for any environment that doesn’t juggle class-loaders like OSGi would > evaluate to the same class-loader. > I also noticed several places that ServiceLoader.load(.class) was > called which should also be changed to pass in the class-loader of the class > since they would default to the thread context class-loader also. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3557) ARTEMIS-1925 fix does not handle redistribution to "old" consumers
[ https://issues.apache.org/jira/browse/ARTEMIS-3557?focusedWorklogId=695227=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695227 ] ASF GitHub Bot logged work on ARTEMIS-3557: --- Author: ASF GitHub Bot Created on: 13/Dec/21 17:25 Start Date: 13/Dec/21 17:25 Worklog Time Spent: 10m Work Description: gtully commented on pull request #3858: URL: https://github.com/apache/activemq-artemis/pull/3858#issuecomment-992703010 I would like some more eyes from folks more familiar with redistribution to be sure to be sure. But this looks good to me. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695227) Time Spent: 5h 10m (was: 5h) > ARTEMIS-1925 fix does not handle redistribution to "old" consumers > -- > > Key: ARTEMIS-3557 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3557 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 5h 10m > Remaining Estimate: 0h > > OFF_WITH_REDISTRIBUTION does not handle this scenario: > If a destination and consumer exist on one node in a cluster and a producer > shows up on another node messages will not get redistributed until the old > consumer disconnects and reconnects. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3557) ARTEMIS-1925 fix does not handle redistribution to "old" consumers
[ https://issues.apache.org/jira/browse/ARTEMIS-3557?focusedWorklogId=695226=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695226 ] ASF GitHub Bot logged work on ARTEMIS-3557: --- Author: ASF GitHub Bot Created on: 13/Dec/21 17:24 Start Date: 13/Dec/21 17:24 Worklog Time Spent: 10m Work Description: gtully commented on pull request #3858: URL: https://github.com/apache/activemq-artemis/pull/3858#issuecomment-992702048 your test works and a sanity run of the full test suite does not show any regression. I think this is good to go. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695226) Time Spent: 5h (was: 4h 50m) > ARTEMIS-1925 fix does not handle redistribution to "old" consumers > -- > > Key: ARTEMIS-3557 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3557 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 5h > Remaining Estimate: 0h > > OFF_WITH_REDISTRIBUTION does not handle this scenario: > If a destination and consumer exist on one node in a cluster and a producer > shows up on another node messages will not get redistributed until the old > consumer disconnects and reconnects. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3604) Async sends could overflow server with messages in openwire
[ https://issues.apache.org/jira/browse/ARTEMIS-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458543#comment-17458543 ] ASF subversion and git services commented on ARTEMIS-3604: -- Commit b5eb7d234212d2e7ad0276f5a6b84857a6f1d842 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=b5eb7d2 ] ARTEMIS-3604 Test Improvement > Async sends could overflow server with messages in openwire > --- > > Key: ARTEMIS-3604 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3604 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.20.0 > > Time Spent: 9h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3598) Sending text message non-UTF-8 containing special characters from OpenWire
[ https://issues.apache.org/jira/browse/ARTEMIS-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458507#comment-17458507 ] Pierre-Henry Brasseur commented on ARTEMIS-3598: Hello [~gtully] , does the following fix good to integrate in a new version of activemq-cpp ? (see src/main/activemq/util/MarshallingSupport.cpp in attachment) It is working on my side, but I'm not aware of any possible impact this could be. [^MarshallingSupport.cpp] > Sending text message non-UTF-8 containing special characters from OpenWire > --- > > Key: ARTEMIS-3598 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3598 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: ActiveMQ-Artemis-Native, OpenWire >Affects Versions: 2.16.0, 2.17.0 >Reporter: Pierre-Henry Brasseur >Assignee: Gary Tully >Priority: Major > Attachments: Artemis - example cpp.png, Artemis - example-1.png, > Artemis - example.png, Artemis - stack traces from cpp client.png, Artemis - > stack traces.png, MarshallingSupport.cpp, Re Question about charset supported > by Artemis.msg, main.c, verifyUtf.patch > > > When a text message non-UTF-8 (ISO-8859-15) containing special characters is > sent from OpenWire, this raised an exception > :"java.io.UTFDataFormatException" which is not correctly handle and prevent > the sending of the text message. > See email from ActiveMQ Community in attachment for more details. > [^Re Question about charset supported by Artemis.msg] > > This was working with previous ActiveMQ version (v5.15.9). > > Identified during following test : > Text message sent from a C program using the Fuse ActiveMQ-Client C library > to Artemis v2.16. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3598) Sending text message non-UTF-8 containing special characters from OpenWire
[ https://issues.apache.org/jira/browse/ARTEMIS-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Henry Brasseur updated ARTEMIS-3598: --- Attachment: MarshallingSupport.cpp > Sending text message non-UTF-8 containing special characters from OpenWire > --- > > Key: ARTEMIS-3598 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3598 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: ActiveMQ-Artemis-Native, OpenWire >Affects Versions: 2.16.0, 2.17.0 >Reporter: Pierre-Henry Brasseur >Assignee: Gary Tully >Priority: Major > Attachments: Artemis - example cpp.png, Artemis - example-1.png, > Artemis - example.png, Artemis - stack traces from cpp client.png, Artemis - > stack traces.png, MarshallingSupport.cpp, Re Question about charset supported > by Artemis.msg, main.c, verifyUtf.patch > > > When a text message non-UTF-8 (ISO-8859-15) containing special characters is > sent from OpenWire, this raised an exception > :"java.io.UTFDataFormatException" which is not correctly handle and prevent > the sending of the text message. > See email from ActiveMQ Community in attachment for more details. > [^Re Question about charset supported by Artemis.msg] > > This was working with previous ActiveMQ version (v5.15.9). > > Identified during following test : > Text message sent from a C program using the Fuse ActiveMQ-Client C library > to Artemis v2.16. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (AMQ-8432) Broker shuts down randomly after some time
[
https://issues.apache.org/jira/browse/AMQ-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Mensinger updated AMQ-8432:
--
Description:
Our ActiveMQ broker shuts down after a certain amount of time (days) of
operation for no apparent reason:
{code:java}
2021-12-09 15:36:56,221 | DEBUG | WriteChecker: 10017ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,227 | DEBUG | Running WriteCheck[tcp://127.0.0.1:33638] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,216 | DEBUG | Running WriteCheck[tcp://127.0.0.1:56489] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,254 | DEBUG | WriteChecker: 1ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,221 | DEBUG | Running WriteCheck[tcp://127.0.0.1:53948] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,264 | DEBUG | WriteChecker: 10004ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,273 | DEBUG | Running WriteCheck[tcp://127.0.0.1:37383] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,284 | DEBUG | WriteChecker: 1ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,299 | DEBUG | Running WriteCheck[tcp://127.0.0.1:45952] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,302 | DEBUG | Running WriteCheck[tcp://127.0.0.1:58722] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,302 | DEBUG | WriteChecker: 10001ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,316 | DEBUG | Running WriteCheck[tcp://127.0.0.1:35706] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,328 | DEBUG | WriteChecker: 10006ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,344 | DEBUG | WriteChecker: 10003ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,351 | DEBUG | Running WriteCheck[tcp://127.0.0.1:44245] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,344 | DEBUG | Running WriteCheck[tcp://127.0.0.1:48056] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:57,085 | DEBUG | Checkpoint started. |
org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint
Worker
2021-12-09 15:36:57,088 | DEBUG | Checkpoint done. |
org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint
Worker
2021-12-09 15:36:57,718 | INFO | Apache ActiveMQ 5.16.3 (localhost,
ID::1) is shutting down |
org.apache.activemq.broker.BrokerService | ActiveMQ ShutdownHook
2021-12-09 15:36:57,722 | DEBUG | Caught exception, must be shutting down. This
exception is ignored. | org.apache.activemq.broker.BrokerService | ActiveMQ
ShutdownHook
java.lang.IllegalStateException: Shutdown in progress
at
java.lang.ApplicationShutdownHooks.remove(ApplicationShutdownHooks.java:82)[:1.8.0_201]
at java.lang.Runtime.removeShutdownHook(Runtime.java:239)[:1.8.0_201]
at
org.apache.activemq.broker.BrokerService.removeShutdownHook(BrokerService.java:2576)[activemq-broker-5.16.3.jar:5.16.3]
at
org.apache.activemq.broker.BrokerService.stop(BrokerService.java:847)[activemq-broker-5.16.3.jar:5.16.3]
at
org.apache.activemq.xbean.XBeanBrokerService.stop(XBeanBrokerService.java:122)[activemq-spring-5.16.3.jar:5.16.3]
at
org.apache.activemq.broker.BrokerService.containerShutdown(BrokerService.java:2599)[activemq-broker-5.16.3.jar:5.16.3]
at
org.apache.activemq.broker.BrokerService$7.run(BrokerService.java:2566)[activemq-broker-5.16.3.jar:5.16.3]
2021-12-09 15:36:57,728 | DEBUG | Unregistering MBean
org.apache.activemq:type=Broker,brokerName=localhost,connector=clientConnectors,connectorName=openwire
| org.apache.activemq.broker.jmx.ManagementContext | ActiveMQ ShutdownHook
2021-12-09 15:36:57,746 | DEBUG | Stopping connection:
[jira] [Created] (AMQ-8432) Broker shuts down randomly after some time
Daniel Mensinger created AMQ-8432:
-
Summary: Broker shuts down randomly after some time
Key: AMQ-8432
URL: https://issues.apache.org/jira/browse/AMQ-8432
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.16.3
Reporter: Daniel Mensinger
Attachments: activemq.log
Our ActiveMQ broker shuts down after a certain amount of time (days) of
operation for no apparent reason:
{code:java}
2021-12-09 15:36:56,221 | DEBUG | WriteChecker: 10017ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,227 | DEBUG | Running WriteCheck[tcp://127.0.0.1:33638] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,216 | DEBUG | Running WriteCheck[tcp://127.0.0.1:56489] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,254 | DEBUG | WriteChecker: 1ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,221 | DEBUG | Running WriteCheck[tcp://127.0.0.1:53948] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,264 | DEBUG | WriteChecker: 10004ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,273 | DEBUG | Running WriteCheck[tcp://127.0.0.1:37383] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,284 | DEBUG | WriteChecker: 1ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,299 | DEBUG | Running WriteCheck[tcp://127.0.0.1:45952] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,302 | DEBUG | Running WriteCheck[tcp://127.0.0.1:58722] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,302 | DEBUG | WriteChecker: 10001ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,316 | DEBUG | Running WriteCheck[tcp://127.0.0.1:35706] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,328 | DEBUG | WriteChecker: 10006ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,344 | DEBUG | WriteChecker: 10003ms elapsed since last
write check. | org.apache.activemq.transport.AbstractInactivityMonitor |
ActiveMQ InactivityMonitor WriteCheckTimer
2021-12-09 15:36:56,351 | DEBUG | Running WriteCheck[tcp://127.0.0.1:44245] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:56,344 | DEBUG | Running WriteCheck[tcp://127.0.0.1:48056] |
org.apache.activemq.transport.AbstractInactivityMonitor | ActiveMQ
InactivityMonitor Worker
2021-12-09 15:36:57,085 | DEBUG | Checkpoint started. |
org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint
Worker
2021-12-09 15:36:57,088 | DEBUG | Checkpoint done. |
org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint
Worker
2021-12-09 15:36:57,718 | INFO | Apache ActiveMQ 5.16.3 (localhost,
ID::1) is shutting down |
org.apache.activemq.broker.BrokerService | ActiveMQ ShutdownHook
2021-12-09 15:36:57,722 | DEBUG | Caught exception, must be shutting down. This
exception is ignored. | org.apache.activemq.broker.BrokerService | ActiveMQ
ShutdownHook
java.lang.IllegalStateException: Shutdown in progress
at
java.lang.ApplicationShutdownHooks.remove(ApplicationShutdownHooks.java:82)[:1.8.0_201]
at java.lang.Runtime.removeShutdownHook(Runtime.java:239)[:1.8.0_201]
at
org.apache.activemq.broker.BrokerService.removeShutdownHook(BrokerService.java:2576)[activemq-broker-5.16.3.jar:5.16.3]
at
org.apache.activemq.broker.BrokerService.stop(BrokerService.java:847)[activemq-broker-5.16.3.jar:5.16.3]
at
org.apache.activemq.xbean.XBeanBrokerService.stop(XBeanBrokerService.java:122)[activemq-spring-5.16.3.jar:5.16.3]
at
org.apache.activemq.broker.BrokerService.containerShutdown(BrokerService.java:2599)[activemq-broker-5.16.3.jar:5.16.3]
at
org.apache.activemq.broker.BrokerService$7.run(BrokerService.java:2566)[activemq-broker-5.16.3.jar:5.16.3]
2021-12-09 15:36:57,728 | DEBUG | Unregistering MBean
[jira] [Work logged] (ARTEMIS-3596) ServiceLoader.load causing issues in OSGi enviroments.
[ https://issues.apache.org/jira/browse/ARTEMIS-3596?focusedWorklogId=695097=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-695097 ] ASF GitHub Bot logged work on ARTEMIS-3596: --- Author: ASF GitHub Bot Created on: 13/Dec/21 14:31 Start Date: 13/Dec/21 14:31 Worklog Time Spent: 10m Work Description: ryeats commented on pull request #3869: URL: https://github.com/apache/activemq-artemis/pull/3869#issuecomment-992538111 Yes, I understand that is why it took me so long to respond initially. While I was trying to figure out what was going on I was seeing issues but possibly not the issues you saw because these didn't seem to be because of my changes. Then I rebased and my problem now is they are not failing anymore and I didn't do anything to fix it. When I debug through the code I changed with or without my change it returns the same class from ServiceLoad.load each time so i don't have a lot to go on. I was hoping you had an idea since i am going to be going back through recent commits to see which one fixed the issue we were seeing otherwise. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 695097) Time Spent: 2h 10m (was: 2h) > ServiceLoader.load causing issues in OSGi enviroments. > -- > > Key: ARTEMIS-3596 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3596 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: osgi >Affects Versions: 2.19.0 >Reporter: Ryan Yeats >Priority: Major > Time Spent: 2h 10m > Remaining Estimate: 0h > > Our system runs Artemis inside of Karaf as an OSGi bundle. Starting with > version 2.19.0 of Artemis, Artemis fails to start correctly due to an > exception during the bundle resolution process. The problems happens when the > artemis-server-osgi bundle is reloaded by the bundle resolution process. The > bundle starts correctly the first time, but during the resolution process, an > import Artemis uses is refreshed causing the bundle to be reloaded. > Consequently, the ServiceLoader.load method is called again by the static > initializer block in the SSLContextFactoryProvider class. The > ServiceLoader.load is passed in a class loader is obtained by calling > Thread.currentThread.getContextClassloader(). The first time the static > initializer block is executed, the classes DefaultSSLContextFactory and its > interface, SSLContextFactory, are loaded. However, on reload > Thread.currentThread.getContextClassloader() returns the original > DefaultSSLContextFactory which is no long the one corresponding to the class > loader of the bundle the second time it is started. Resulting in the > following error message: > org.apache.activemq.artemis.spi.core.remoting.ssl.SSLContextFactory: > org.apache.activemq.artemis.core.remoting.impl.ssl.DefaultSSLContextFactory > not a subtype > I believe the best way to fix this is to change > ServiceLoader.load(SSLContextFactory.class, > Thread.currentThread().getContextClassLoader()) > to > ServiceLoader.load(SSLContextFactory.class, > SSLContextFactoryProvider.class.getClassLoader()) > Which for any environment that doesn’t juggle class-loaders like OSGi would > evaluate to the same class-loader. > I also noticed several places that ServiceLoader.load(.class) was > called which should also be changed to pass in the class-loader of the class > since they would default to the thread context class-loader also. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (AMQ-8430) Log4j 1.2.17 is being used in activemq-all - 5.16.3 : [CVE-2021-44228] [log4j] [1.2.17]
[
https://issues.apache.org/jira/browse/AMQ-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458374#comment-17458374
]
David commented on AMQ-8430:
I found the following link :
[https://stackoverflow.com/questions/65617521/activemq-version-5-16-0-has-vulnerable-dependency-jar
|https://stackoverflow.com/questions/65617521/activemq-version-5-16-0-has-vulnerable-dependency-jar]
And on the configuration documentation page I found the information that slf4j
is used primarily and that log4j can be configured optionally.
[https://activemq.apache.org/how-do-i-change-the-logging]
I am just not sure if that is correct.
> Log4j 1.2.17 is being used in activemq-all - 5.16.3 : [CVE-2021-44228]
> [log4j] [1.2.17]
>
>
> Key: AMQ-8430
> URL: https://issues.apache.org/jira/browse/AMQ-8430
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.16.3
>Reporter: Aman Mishra
>Priority: Critical
>
> *Aqua Description :* Apache Log4j2 <=2.14.1 JNDI features used in
> configuration, log messages, and parameters do not protect against attacker
> controlled LDAP and other JNDI related endpoints. An attacker who can control
> log messages or log message parameters can execute arbitrary code loaded from
> LDAP servers when message lookup substitution is enabled. From log4j 2.15.0,
> this behavior has been disabled by default. In previous releases (>2.10) this
> behavior can be mitigated by setting system property
> "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class
> from the classpath (example: zip {-}q -d log4j-core{-}*.jar
> org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see
> [https://www.oracle.com/java/technologies/javase/8u121-relnotes.html])
> protects against remote code execution by defaulting
> "com.sun.jndi.rmi.object.trustURLCodebase" and
> "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3606) Broker does not discard absent replica instances
[
https://issues.apache.org/jira/browse/ARTEMIS-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Austermühle updated ARTEMIS-3606:
-
Description:
We have deployed ActiveMQ Artemis v2.19.0 in a HA+Cluster configuration, hosted
on Kubernetes (non-cloud) and use the JGroups {{KUBE_PING}} for the broker
discovery. During regular operations, we have 2 primaries and 2 replica brokers
and everything looks fine.
For testing, we now remove the replica instances (no Pods left) – and end up
with a weird cluster state: 2 primaries – and 1 zombie replica connected to
primary 1. The replica instances were shut down (scaling the corresponding
StatefulSet to zero), i.e., no hard kill.
Restarting the replicas brings the cluster back to a normal state – sometimes.
[According to the
docs|https://activemq.apache.org/components/artemis/documentation/latest/clusters.html#discovery-groups],
the missing broker instances should be removed:
{quote}If it has not received a broadcast from a particular server for a length
of time it will remove that server's entry from its list.
{quote}
The broker also includes the zombie replicas in its topology update to JMS
clients resulting in about >30 connection attempts per second in our case.
Since Kubernetes does not know the shutdown replica broker instances anymore,
the client’s name resolution ends with {{{}Cannot resolve host{}}}. This
finally leads to the client eating a whole CPU core on connection attempts and
logging the failure.
By the way, the JMS client should wait for some time after a {{Cannot resolve
host}} exception instead of retrying immediately. Looks like the pause
parameters retryInterval, retryIntervalMultiplier, maxRetryInterval, and
reconnectAttempts don’t have any effect.
[~brusdev] commented:
{quote}logs confirm no messages from replicas so the issue isn't caused by
jgroups, it could be due to a bug on propagating cluster topology updates. The
cluster topology updates are sent using ClusterTopologyChangeMessage.
{quote}
Please see [https://stackoverflow.com/q/70288344/6529100] for additional
information, logs, configuration.
Maybe it is worth mentioning that shutting down a primary (master) instance
works as expected.
was:
We have deployed ActiveMQ Artemis v2.19.0 in a HA+Cluster configuration, hosted
on Kubernetes (non-cloud) and use the JGroups {{KUBE_PING}} for the broker
discovery. During regular operations, we have 2 primaries and 2 replica brokers
and everything looks fine.
For testing, we now remove the replica instances (no Pods left) – and end up
with a weird cluster state: 2 primaries – and 1 zombie replica connected to
primary 1. The replica instances were shut down (scaling the corresponding
StatefulSet to zero), i.e., no hard kill.
Restarting the replicas brings the cluster back to a normal state – sometimes.
[According to the
docs|https://activemq.apache.org/components/artemis/documentation/latest/clusters.html#discovery-groups],
the missing broker instances should be removed:
{quote}If it has not received a broadcast from a particular server for a length
of time it will remove that server's entry from its list.
{quote}
The broker also includes the zombie replicas in its topology update to JMS
clients resulting in about >30 connection attempts per second in our case.
Since Kubernetes does not know the shutdown replica broker instances anymore,
the client’s name resolution ends with {{{}Cannot resolve host{}}}. This
finally leads to the client eating a whole CPU core on connection attempts and
logging the failure.
By the way, the JMS client should wait for some time after a {{Cannot resolve
host}} exception instead of retrying immediately. Looks like the pause
parameters retryInterval,
retryIntervalMultiplier, maxRetryInterval, and reconnectAttempts don’t have any
effect.
[~brusdev] commented:
{quote}logs confirm no messages from replicas so the issue isn't caused by
jgroups, it could be due to a bug on propagating cluster topology updates. The
cluster topology updates are sent using ClusterTopologyChangeMessage.
{quote}
Please see [https://stackoverflow.com/q/70288344/6529100] for additional
information, logs, configuration.
Maybe it is worth mentioning that shutting down a primary (master) instance
works as expected.
> Broker does not discard absent replica instances
>
>
> Key: ARTEMIS-3606
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3606
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.19.0
>Reporter: Stephan Austermühle
>Priority: Major
>
> We have deployed ActiveMQ Artemis v2.19.0 in a HA+Cluster configuration,
> hosted on Kubernetes (non-cloud) and use the JGroups {{KUBE_PING}} for the
> broker discovery. During regular
[jira] [Created] (ARTEMIS-3606) Broker does not discard absent replica instances
Stephan Austermühle created ARTEMIS-3606:
Summary: Broker does not discard absent replica instances
Key: ARTEMIS-3606
URL: https://issues.apache.org/jira/browse/ARTEMIS-3606
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.19.0
Reporter: Stephan Austermühle
We have deployed ActiveMQ Artemis v2.19.0 in a HA+Cluster configuration, hosted
on Kubernetes (non-cloud) and use the JGroups {{KUBE_PING}} for the broker
discovery. During regular operations, we have 2 primaries and 2 replica brokers
and everything looks fine.
For testing, we now remove the replica instances (no Pods left) – and end up
with a weird cluster state: 2 primaries – and 1 zombie replica connected to
primary 1. The replica instances were shut down (scaling the corresponding
StatefulSet to zero), i.e., no hard kill.
Restarting the replicas brings the cluster back to a normal state – sometimes.
[According to the
docs|https://activemq.apache.org/components/artemis/documentation/latest/clusters.html#discovery-groups],
the missing broker instances should be removed:
{quote}If it has not received a broadcast from a particular server for a length
of time it will remove that server's entry from its list.
{quote}
The broker also includes the zombie replicas in its topology update to JMS
clients resulting in about >30 connection attempts per second in our case.
Since Kubernetes does not know the shutdown replica broker instances anymore,
the client’s name resolution ends with {{{}Cannot resolve host{}}}. This
finally leads to the client eating a whole CPU core on connection attempts and
logging the failure.
By the way, the JMS client should wait for some time after a {{Cannot resolve
host}} exception instead of retrying immediately. Looks like the pause
parameters retryInterval,
retryIntervalMultiplier, maxRetryInterval, and reconnectAttempts don’t have any
effect.
[~brusdev] commented:
{quote}logs confirm no messages from replicas so the issue isn't caused by
jgroups, it could be due to a bug on propagating cluster topology updates. The
cluster topology updates are sent using ClusterTopologyChangeMessage.
{quote}
Please see [https://stackoverflow.com/q/70288344/6529100] for additional
information, logs, configuration.
Maybe it is worth mentioning that shutting down a primary (master) instance
works as expected.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (AMQ-8431) Log4j old version in use
MALOY KUMAR BAIN created AMQ-8431: - Summary: Log4j old version in use Key: AMQ-8431 URL: https://issues.apache.org/jira/browse/AMQ-8431 Project: ActiveMQ Issue Type: Bug Components: AMQP Affects Versions: 5.16.3 Reporter: MALOY KUMAR BAIN Fix For: 5.x Hi, with the declaration of log4j security vulnerability, I see that the latest verison of ActiveMqconnectionFactory still uses the old log4j packagae. please have this mitigatedd. I am in urgent need of the fixed version of ActiveMq. Thanks Maloy -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (AMQ-8430) Log4j 1.2.17 is being used in activemq-all - 5.16.3 : [CVE-2021-44228] [log4j] [1.2.17]
[
https://issues.apache.org/jira/browse/AMQ-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458358#comment-17458358
]
Aman Mishra commented on AMQ-8430:
--
I have found the occurrence of log4j 1.2.17 in
[https://repo1.maven.org/maven2/org/apache/activemq/activemq-all/5.16.3/activemq-all-5.16.3.pom]
So, anybody from activemq side can confirm that where we are upgrading this
complete occurrence of log4j1.2.17 ?
> Log4j 1.2.17 is being used in activemq-all - 5.16.3 : [CVE-2021-44228]
> [log4j] [1.2.17]
>
>
> Key: AMQ-8430
> URL: https://issues.apache.org/jira/browse/AMQ-8430
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.16.3
>Reporter: Aman Mishra
>Priority: Critical
>
> *Aqua Description :* Apache Log4j2 <=2.14.1 JNDI features used in
> configuration, log messages, and parameters do not protect against attacker
> controlled LDAP and other JNDI related endpoints. An attacker who can control
> log messages or log message parameters can execute arbitrary code loaded from
> LDAP servers when message lookup substitution is enabled. From log4j 2.15.0,
> this behavior has been disabled by default. In previous releases (>2.10) this
> behavior can be mitigated by setting system property
> "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class
> from the classpath (example: zip {-}q -d log4j-core{-}*.jar
> org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see
> [https://www.oracle.com/java/technologies/javase/8u121-relnotes.html])
> protects against remote code execution by defaulting
> "com.sun.jndi.rmi.object.trustURLCodebase" and
> "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (AMQ-8430) Log4j 1.2.17 is being used in activemq-all - 5.16.3 : [CVE-2021-44228] [log4j] [1.2.17]
[
https://issues.apache.org/jira/browse/AMQ-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aman Mishra updated AMQ-8430:
-
Summary: Log4j 1.2.17 is being used in activemq-all - 5.16.3 :
[CVE-2021-44228] [log4j] [1.2.17] (was: Log4j 1.2.17 is being used in
activemq-all : [CVE-2021-44228] [log4j] [1.2.17] )
> Log4j 1.2.17 is being used in activemq-all - 5.16.3 : [CVE-2021-44228]
> [log4j] [1.2.17]
>
>
> Key: AMQ-8430
> URL: https://issues.apache.org/jira/browse/AMQ-8430
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.16.3
>Reporter: Aman Mishra
>Priority: Critical
>
> *Aqua Description :* Apache Log4j2 <=2.14.1 JNDI features used in
> configuration, log messages, and parameters do not protect against attacker
> controlled LDAP and other JNDI related endpoints. An attacker who can control
> log messages or log message parameters can execute arbitrary code loaded from
> LDAP servers when message lookup substitution is enabled. From log4j 2.15.0,
> this behavior has been disabled by default. In previous releases (>2.10) this
> behavior can be mitigated by setting system property
> "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class
> from the classpath (example: zip {-}q -d log4j-core{-}*.jar
> org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see
> [https://www.oracle.com/java/technologies/javase/8u121-relnotes.html])
> protects against remote code execution by defaulting
> "com.sun.jndi.rmi.object.trustURLCodebase" and
> "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (AMQ-8430) Log4j 1.2.17 is being used in activemq-all : [CVE-2021-44228] [log4j] [1.2.17]
[
https://issues.apache.org/jira/browse/AMQ-8430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458336#comment-17458336
]
David commented on AMQ-8430:
log4j is only found under ./lib/optional. Per default it should use slf4j and
not log4j as far as I figured it out. Could anybody confirm that?
> Log4j 1.2.17 is being used in activemq-all : [CVE-2021-44228] [log4j]
> [1.2.17]
> ---
>
> Key: AMQ-8430
> URL: https://issues.apache.org/jira/browse/AMQ-8430
> Project: ActiveMQ
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 5.16.3
>Reporter: Aman Mishra
>Priority: Critical
>
> *Aqua Description :* Apache Log4j2 <=2.14.1 JNDI features used in
> configuration, log messages, and parameters do not protect against attacker
> controlled LDAP and other JNDI related endpoints. An attacker who can control
> log messages or log message parameters can execute arbitrary code loaded from
> LDAP servers when message lookup substitution is enabled. From log4j 2.15.0,
> this behavior has been disabled by default. In previous releases (>2.10) this
> behavior can be mitigated by setting system property
> "log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class
> from the classpath (example: zip {-}q -d log4j-core{-}*.jar
> org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see
> [https://www.oracle.com/java/technologies/javase/8u121-relnotes.html])
> protects against remote code execution by defaulting
> "com.sun.jndi.rmi.object.trustURLCodebase" and
> "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (ARTEMIS-3605) Upgrade jetty version to 9.4.44.v20210927
Domenico Francesco Bruscino created ARTEMIS-3605: Summary: Upgrade jetty version to 9.4.44.v20210927 Key: ARTEMIS-3605 URL: https://issues.apache.org/jira/browse/ARTEMIS-3605 Project: ActiveMQ Artemis Issue Type: Dependency upgrade Reporter: Domenico Francesco Bruscino -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3559) Update netty version to 4.1.70.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-3559?focusedWorklogId=694959=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-694959 ] ASF GitHub Bot logged work on ARTEMIS-3559: --- Author: ASF GitHub Bot Created on: 13/Dec/21 10:57 Start Date: 13/Dec/21 10:57 Worklog Time Spent: 10m Work Description: brusdev opened a new pull request #3878: URL: https://github.com/apache/activemq-artemis/pull/3878 The netty-transport-native-epoll transitive dependency version of zookeeper doesn't match the netty version defined and causes a distribution issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 694959) Time Spent: 0.5h (was: 20m) > Update netty version to 4.1.70.Final > > > Key: ARTEMIS-3559 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3559 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.20.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update netty version to 4.1.70.Final and netty-tcnative version to > 2.0.44.Final. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3557) ARTEMIS-1925 fix does not handle redistribution to "old" consumers
[ https://issues.apache.org/jira/browse/ARTEMIS-3557?focusedWorklogId=694925=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-694925 ] ASF GitHub Bot logged work on ARTEMIS-3557: --- Author: ASF GitHub Bot Created on: 13/Dec/21 09:31 Start Date: 13/Dec/21 09:31 Worklog Time Spent: 10m Work Description: AntonRoskvist commented on pull request #3858: URL: https://github.com/apache/activemq-artemis/pull/3858#issuecomment-992272021 I hope this addresses all concerns @gtully , if not just let me know. Br, Anton -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 694925) Time Spent: 4h 50m (was: 4h 40m) > ARTEMIS-1925 fix does not handle redistribution to "old" consumers > -- > > Key: ARTEMIS-3557 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3557 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Time Spent: 4h 50m > Remaining Estimate: 0h > > OFF_WITH_REDISTRIBUTION does not handle this scenario: > If a destination and consumer exist on one node in a cluster and a producer > shows up on another node messages will not get redistributed until the old > consumer disconnects and reconnects. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (AMQ-8430) Log4j 1.2.17 is being used in activemq-all : [CVE-2021-44228] [log4j] [1.2.17]
Aman Mishra created AMQ-8430:
Summary: Log4j 1.2.17 is being used in activemq-all :
[CVE-2021-44228] [log4j] [1.2.17]
Key: AMQ-8430
URL: https://issues.apache.org/jira/browse/AMQ-8430
Project: ActiveMQ
Issue Type: Bug
Components: AMQP
Affects Versions: 5.16.3
Reporter: Aman Mishra
*Aqua Description :* Apache Log4j2 <=2.14.1 JNDI features used in
configuration, log messages, and parameters do not protect against attacker
controlled LDAP and other JNDI related endpoints. An attacker who can control
log messages or log message parameters can execute arbitrary code loaded from
LDAP servers when message lookup substitution is enabled. From log4j 2.15.0,
this behavior has been disabled by default. In previous releases (>2.10) this
behavior can be mitigated by setting system property
"log4j2.formatMsgNoLookups" to “true” or by removing the JndiLookup class from
the classpath (example: zip {-}q -d log4j-core{-}*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see
[https://www.oracle.com/java/technologies/javase/8u121-relnotes.html]) protects
against remote code execution by defaulting
"com.sun.jndi.rmi.object.trustURLCodebase" and
"com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
