[jira] [Work logged] (ARTEMIS-2901) Support namespace for temporary queues
[
https://issues.apache.org/jira/browse/ARTEMIS-2901?focusedWorklogId=484247=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484247
]
ASF GitHub Bot logged work on ARTEMIS-2901:
---
Author: ASF GitHub Bot
Created on: 14/Sep/20 23:58
Start Date: 14/Sep/20 23:58
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request #3260:
URL: https://github.com/apache/activemq-artemis/pull/3260
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 484247)
Remaining Estimate: 0h
Time Spent: 10m
> Support namespace for temporary queues
> --
>
> Key: ARTEMIS-2901
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2901
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For some protocols & APIs in order to have address settings applied to
> temporary queues only the default match everything filter {{#}} can be used.
> We need a special name space for temporary queues that specific address
> settings can be applied only to them and not any others.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (AMQNET-565) Dotnet core port
[ https://issues.apache.org/jira/browse/AMQNET-565?focusedWorklogId=484218=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484218 ] ASF GitHub Bot logged work on AMQNET-565: - Author: ASF GitHub Bot Created on: 14/Sep/20 21:46 Start Date: 14/Sep/20 21:46 Worklog Time Spent: 10m Work Description: bthharper commented on pull request #9: URL: https://github.com/apache/activemq-nms-openwire/pull/9#issuecomment-692331304 @Havret / @michaelandrepearce - any news on when 1.8.0 will be released? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 484218) Time Spent: 14h 40m (was: 14.5h) > Dotnet core port > - > > Key: AMQNET-565 > URL: https://issues.apache.org/jira/browse/AMQNET-565 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: ActiveMQ >Reporter: Wojtek Kulma >Priority: Major > Time Spent: 14h 40m > Remaining Estimate: 0h > > Apache.NMS.ActiveMQ should be ported for dotnet core. > For now the following error is rises: > D:\RiderProjects\syncro [master ≡ +1 ~1 -1 !]> dotnet add package > Apache.NMS.ActiveMQ > Microsoft (R) Build Engine version 15.1.1012.6693 > Copyright (C) Microsoft Corporation. All rights reserved. > Writing C:\Users\wkulma\AppData\Local\Temp\tmp9A2E.tmp > info : Adding PackageReference for package 'Apache.NMS.ActiveMQ' into project > 'D:\RiderProjects\syncro\syncro.fsproj'. > log : Restoring packages for D:\RiderProjects\syncro\syncro.fsproj... > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json > info : CACHE https://api.nuget.org/v3-flatcontainer/fsharp.core/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.core/4.1.17/fsharp.core.4.1.17.nupkg > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/index.json > info : CACHE > https://api.nuget.org/v3-flatcontainer/fsharp.net.sdk/1.0.5/fsharp.net.sdk.1.0.5.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/index.json 611ms > info : GET > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > info : OK > https://api.nuget.org/v3-flatcontainer/apache.nms.activemq/1.7.2/apache.nms.activemq.1.7.2.nupkg > 481ms > error: Package Apache.NMS.ActiveMQ 1.7.2 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS.ActiveMQ 1.7.2 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: Package Apache.NMS 1.7.1 is not compatible with netcoreapp1.1 > (.NETCoreApp,Version=v1.1). Package Apache.NMS 1.7.1 supports: > error: - net20 (.NETFramework,Version=v2.0) > error: - net20-cf (.NETFramework,Version=v2.0,Profile=CompactFramework) > error: - net35 (.NETFramework,Version=v3.5) > error: - net40 (.NETFramework,Version=v4.0) > error: One or more packages are incompatible with .NETCoreApp,Version=v1.1. > error: Package 'Apache.NMS.ActiveMQ' is incompatible with 'all' frameworks in > project 'D:\RiderProjects\syncro\syncro.fsproj'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2900) Expose whole wire size on Large Messages
[ https://issues.apache.org/jira/browse/ARTEMIS-2900?focusedWorklogId=484187=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484187 ] ASF GitHub Bot logged work on ARTEMIS-2900: --- Author: ASF GitHub Bot Created on: 14/Sep/20 19:36 Start Date: 14/Sep/20 19:36 Worklog Time Spent: 10m Work Description: asfgit closed pull request #3259: URL: https://github.com/apache/activemq-artemis/pull/3259 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 484187) Time Spent: 20m (was: 10m) > Expose whole wire size on Large Messages > > > Key: ARTEMIS-2900 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2900 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.15.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.16.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When intercepting large messages, users need to know the exact size of the > message including the whole body. > > For that I should expose a new property named getWholeMessageSize() that will > be available on large messages and regular messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2886) Optimize security auth
[
https://issues.apache.org/jira/browse/ARTEMIS-2886?focusedWorklogId=484186=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484186
]
ASF GitHub Bot logged work on ARTEMIS-2886:
---
Author: ASF GitHub Bot
Created on: 14/Sep/20 19:35
Start Date: 14/Sep/20 19:35
Worklog Time Spent: 10m
Work Description: asfgit closed pull request #3254:
URL: https://github.com/apache/activemq-artemis/pull/3254
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 484186)
Time Spent: 2h 40m (was: 2.5h)
> Optimize security auth
> --
>
> Key: ARTEMIS-2886
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2886
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.16.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Both authentication and authorization will hit the underlying security
> repository (e.g. files, LDAP, etc.). For example, creating a JMS connection
> and a consumer will result in 2 hits with the *same* authentication request.
> This can cause unwanted (and unnecessary) resource utilization, especially in
> the case of networked configuration like LDAP.
> There is a rudimentary cache for authorization, but it is cleared *totally*
> every 10 seconds by default (controlled via the
> {{security-invalidation-interval setting}}), and it must be populated
> initially which still results in duplicate auth requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2886) Optimize security auth
[
https://issues.apache.org/jira/browse/ARTEMIS-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195709#comment-17195709
]
ASF subversion and git services commented on ARTEMIS-2886:
--
Commit cf92c163394069fdbcd48055920866a22103a29c in activemq-artemis's branch
refs/heads/master from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=cf92c16 ]
ARTEMIS-2886 put address/FQQN into new security manager interface
The default JAAS security manager doesn't need the address/FQQN for
authorization, but I'm putting it back into the interface because there
are other use cases which *do* need it.
> Optimize security auth
> --
>
> Key: ARTEMIS-2886
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2886
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.16.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Both authentication and authorization will hit the underlying security
> repository (e.g. files, LDAP, etc.). For example, creating a JMS connection
> and a consumer will result in 2 hits with the *same* authentication request.
> This can cause unwanted (and unnecessary) resource utilization, especially in
> the case of networked configuration like LDAP.
> There is a rudimentary cache for authorization, but it is cleared *totally*
> every 10 seconds by default (controlled via the
> {{security-invalidation-interval setting}}), and it must be populated
> initially which still results in duplicate auth requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2900) Expose whole wire size on Large Messages
[ https://issues.apache.org/jira/browse/ARTEMIS-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195710#comment-17195710 ] ASF subversion and git services commented on ARTEMIS-2900: -- Commit 7cf5289efa011493a3a69a96d1293609204018d6 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=7cf5289 ] ARTEMIS-2900 Expose property (getWholeMessageSize) so users can intercept size of messages and large messages > Expose whole wire size on Large Messages > > > Key: ARTEMIS-2900 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2900 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.15.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.16.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When intercepting large messages, users need to know the exact size of the > message including the whole body. > > For that I should expose a new property named getWholeMessageSize() that will > be available on large messages and regular messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2838) Migrate Console to use Hawtio 2
[ https://issues.apache.org/jira/browse/ARTEMIS-2838?focusedWorklogId=484183=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484183 ] ASF GitHub Bot logged work on ARTEMIS-2838: --- Author: ASF GitHub Bot Created on: 14/Sep/20 19:27 Start Date: 14/Sep/20 19:27 Worklog Time Spent: 10m Work Description: jbertram commented on pull request #3257: URL: https://github.com/apache/activemq-artemis/pull/3257#issuecomment-692264679 I think I see what the "issue" was when clicking on anything...I was expecting to see the attributes of the object when I clicked on it. However, that information is on the "Attributes" tab. The default tab (i.e. the "Status" tab) continues to display when clicking on anything in the tree. Fair enough. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 484183) Time Spent: 1h 50m (was: 1h 40m) > Migrate Console to use Hawtio 2 > --- > > Key: ARTEMIS-2838 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2838 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Andy Taylor >Assignee: Andy Taylor >Priority: Major > Fix For: 2.16.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > The main concern here is upgrading HawtIO as version 1 is no longer > maintained and we need to reduce the chance of CVE's going forward. > > I've basically re written the console JavaScript using the new API's making > them as much as possible the same as the original. There are a few minor > changes but nothing that would warrant a loss is functionality. This also > has a new look and feel. Ive aslo improved some features, these include: > > # A new landing page that shows some basic broker state, uptime, cluster > status, address memory used. > # A HawtIO security mbean, this means that hawtIO will check at call time > whether or not the attribute or operation can be called, so rather than see > an error in the attributes stab when access isnt authorised it is handled > gracefully. This is also used to control whether a tab is available, so if a > user does not have access to the createqueue jmx method then the create queue > tab will not be available. > # Added a help button to most of the tabs > # A search facility for mbeans in the JMX tree -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2838) Migrate Console to use Hawtio 2
[ https://issues.apache.org/jira/browse/ARTEMIS-2838?focusedWorklogId=484179=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484179 ] ASF GitHub Bot logged work on ARTEMIS-2838: --- Author: ASF GitHub Bot Created on: 14/Sep/20 19:18 Start Date: 14/Sep/20 19:18 Worklog Time Spent: 10m Work Description: jbertram commented on pull request #3257: URL: https://github.com/apache/activemq-artemis/pull/3257#issuecomment-692259926 I just built the branch and tested it out. When I created my broker is used `--allow-anonymous` and when I "logged in" to the console it just put in a dummy username and password. The console loaded fine, but whenever I clicked on anything in the tree (e.g. addresses, acceptors, etc.) the panel on the right would just flash something quickly and return to the normal status screen with the address size, etc. I figured this was related to security so I stopped the broker and changed my `etc/management.xml` to be: ```xml http://activemq.org/schema;> ``` When I restarted the broker and tried to log back in I got this NPE in the log: ``` 2020-09-14 14:11:59,952 ERROR [io.hawt.system.RBACMBeanInvoker] Error while invoking JMXSecurity MBean: javax.management.RuntimeMBeanException: java.lang.NullPointerException: com.google.common.util.concurrent.UncheckedExecutionException: javax.management.RuntimeMBeanException: java.lang.NullPointerException at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2052) [guava-24.1.1-jre.jar:] at com.google.common.cache.LocalCache.get(LocalCache.java:3943) [guava-24.1.1-jre.jar:] at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3967) [guava-24.1.1-jre.jar:] at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4952) [guava-24.1.1-jre.jar:] at io.hawt.system.RBACMBeanInvoker.canInvoke(RBACMBeanInvoker.java:215) [hawtio-system-2.10.2.jar:2.10.2] at io.hawt.system.RBACRestrictor.isOperationAllowed(RBACRestrictor.java:70) [hawtio-system-2.10.2.jar:2.10.2] at org.jolokia.handler.ExecHandler.checkForRestriction(ExecHandler.java:63) [jolokia-core-1.6.2.jar:] at org.jolokia.handler.ExecHandler.checkForRestriction(ExecHandler.java:40) [jolokia-core-1.6.2.jar:] at org.jolokia.handler.JsonRequestHandler.handleRequest(JsonRequestHandler.java:87) [jolokia-core-1.6.2.jar:] at org.jolokia.backend.MBeanServerExecutorLocal.handleRequest(MBeanServerExecutorLocal.java:109) [jolokia-core-1.6.2.jar:] at org.jolokia.backend.MBeanServerHandler.dispatchRequest(MBeanServerHandler.java:161) [jolokia-core-1.6.2.jar:] at org.jolokia.backend.LocalRequestDispatcher.dispatchRequest(LocalRequestDispatcher.java:99) [jolokia-core-1.6.2.jar:] at org.jolokia.backend.BackendManager.callRequestDispatcher(BackendManager.java:429) [jolokia-core-1.6.2.jar:] at org.jolokia.backend.BackendManager.handleRequest(BackendManager.java:158) [jolokia-core-1.6.2.jar:] at org.jolokia.http.HttpRequestHandler.executeRequest(HttpRequestHandler.java:197) [jolokia-core-1.6.2.jar:] at org.jolokia.http.HttpRequestHandler.handlePostRequest(HttpRequestHandler.java:137) [jolokia-core-1.6.2.jar:] at org.jolokia.http.AgentServlet$3.handleRequest(AgentServlet.java:460) [jolokia-core-1.6.2.jar:] at org.jolokia.http.AgentServlet.handleSecurely(AgentServlet.java:350) [jolokia-core-1.6.2.jar:] at org.jolokia.http.AgentServlet.handle(AgentServlet.java:321) [jolokia-core-1.6.2.jar:] at org.jolokia.http.AgentServlet.doPost(AgentServlet.java:284) [jolokia-core-1.6.2.jar:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jetty-all-9.4.27.v20200227-uber.jar:9.4.27.v20200227] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jetty-all-9.4.27.v20200227-uber.jar:9.4.27.v20200227] at org.eclipse.jetty.servlet.ServletHolder$NotAsyncServlet.service(ServletHolder.java:1395) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:755) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617) at io.hawt.web.auth.LoginRedirectFilter.doFilter(LoginRedirectFilter.java:57) [hawtio-system-2.10.2.jar:2.10.2] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604) at io.hawt.web.auth.AuthenticationFilter.lambda$executeAs$1(AuthenticationFilter.java:106) [hawtio-system-2.10.2.jar:2.10.2] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_151] at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_151] at io.hawt.web.auth.AuthenticationFilter.executeAs(AuthenticationFilter.java:105)
[jira] [Created] (ARTEMIS-2901) Support namespace for temporary queues
Justin Bertram created ARTEMIS-2901:
---
Summary: Support namespace for temporary queues
Key: ARTEMIS-2901
URL: https://issues.apache.org/jira/browse/ARTEMIS-2901
Project: ActiveMQ Artemis
Issue Type: New Feature
Reporter: Justin Bertram
Assignee: Justin Bertram
For some protocols & APIs in order to have address settings applied to
temporary queues only the default match everything filter {{#}} can be used. We
need a special name space for temporary queues that specific address settings
can be applied only to them and not any others.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=484056=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484056 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 14/Sep/20 15:11 Start Date: 14/Sep/20 15:11 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-692122818 @uomik That's the PR: https://github.com/uomik/activemq-artemis/pull/1 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 484056) Time Spent: 4h 10m (was: 4h) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 4h 10m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=484050=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484050 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 14/Sep/20 15:06 Start Date: 14/Sep/20 15:06 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-692118618 @uomik I will try to send a PR so you can accept/merge it and push force the new version, do you need me to help more? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 484050) Time Spent: 3h 50m (was: 3h 40m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=484051=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484051 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 14/Sep/20 15:06 Start Date: 14/Sep/20 15:06 Worklog Time Spent: 10m Work Description: franz1981 edited a comment on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-692118618 @uomik I will try to send a PR to your repository so you can accept/merge it and push force the new version, do you need me to help more? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 484051) Time Spent: 4h (was: 3h 50m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 4h > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=484047=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484047 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 14/Sep/20 15:01 Start Date: 14/Sep/20 15:01 Worklog Time Spent: 10m Work Description: uomik edited a comment on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-692112982 > @uomik any news on the changes I've proposed on [#3204 (comment)](https://github.com/apache/activemq-artemis/pull/3204#issuecomment-690766208)? Sorry. I'm burden under work currently. Had a quick look on changes (that seem to be ok and on point) and did the rebase, but was little confused about the outcome (I'm no means a git expert), and have had absolutely no time to dig into it. The unit tests did go through though. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 484047) Time Spent: 3h 40m (was: 3.5h) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 3h 40m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=484039=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484039 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 14/Sep/20 14:57 Start Date: 14/Sep/20 14:57 Worklog Time Spent: 10m Work Description: uomik commented on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-692112982 > @uomik any news on the changes I've proposed on [#3204 (comment)](https://github.com/apache/activemq-artemis/pull/3204#issuecomment-690766208)? Sorry. I'm burden under work currently. Had a quick look on changes (that seem to ok and be on point) and did the rebase, but was little confused about the outcome (I'm no means a git expert), and have had absolutely no time to dig into it. The unit tests did go through though. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 484039) Time Spent: 3.5h (was: 3h 20m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
[ https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=484029=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484029 ] ASF GitHub Bot logged work on ARTEMIS-2823: --- Author: ASF GitHub Bot Created on: 14/Sep/20 14:36 Start Date: 14/Sep/20 14:36 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3204: URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-692100125 @uomik any news on the changes I've proposed on https://github.com/apache/activemq-artemis/pull/3204#issuecomment-690766208? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 484029) Time Spent: 3h 20m (was: 3h 10m) > Improve JDBC connection management > -- > > Key: ARTEMIS-2823 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2823 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Mikko >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > > I have a case where the whole clustering reliability and HA must rely on HA > capabilities of clustered database, and running on top of application server > is not an option. > The current JDBC store implementation is rather bare bones on the connection > management side. JDBC driver is used directly with no management layer. At > startup, the broker just opens couple of direct connections to database and > expects them to be available forever. This is something that cannot be > expected in HA production environment. So, similarly to the discussion linked > below, in our case we lose the db connection after one hour, and all the > brokers need to be restared to get new connections: > [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html] > > This is something that could be resolved by simply using JDBC4 isValid > checks, but proper connection handling and pooling through datasource would > be preferrable. > I have implemented a solution for this by using DBCP2 datasource. Our test > cluster has been successfully running this forked version since the release > of Artemis 2.13.0. I will prepare of pull request if this is seen to be > something that can be useful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-2900) Expose whole wire size on Large Messages
[ https://issues.apache.org/jira/browse/ARTEMIS-2900?focusedWorklogId=484017=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-484017 ] ASF GitHub Bot logged work on ARTEMIS-2900: --- Author: ASF GitHub Bot Created on: 14/Sep/20 14:08 Start Date: 14/Sep/20 14:08 Worklog Time Spent: 10m Work Description: clebertsuconic opened a new pull request #3259: URL: https://github.com/apache/activemq-artemis/pull/3259 …cept size of messages and large messages 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 484017) Remaining Estimate: 0h Time Spent: 10m > Expose whole wire size on Large Messages > > > Key: ARTEMIS-2900 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2900 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.15.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.16.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When intercepting large messages, users need to know the exact size of the > message including the whole body. > > For that I should expose a new property named getWholeMessageSize() that will > be available on large messages and regular messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2900) Expose whole wire size on Large Messages
Clebert Suconic created ARTEMIS-2900: Summary: Expose whole wire size on Large Messages Key: ARTEMIS-2900 URL: https://issues.apache.org/jira/browse/ARTEMIS-2900 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.15.0 Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.16.0 When intercepting large messages, users need to know the exact size of the message including the whole body. For that I should expose a new property named getWholeMessageSize() that will be available on large messages and regular messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2852) Huge performance decrease between versions 2.2.0 and 2.13.0
[
https://issues.apache.org/jira/browse/ARTEMIS-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195467#comment-17195467
]
Francesco Nigro commented on ARTEMIS-2852:
--
[~kkondzielski] Any news about the performance of the latest Artemis release?
If using the old benchmark is fine, so we can close this...
Any help related a new/different benchmark could be addressed in a separate
issue too (y)
> Huge performance decrease between versions 2.2.0 and 2.13.0
> ---
>
> Key: ARTEMIS-2852
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2852
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Kasper Kondzielski
>Priority: Major
> Attachments: Selection_433.png, Selection_434.png, Selection_440.png,
> Selection_441.png, Selection_451.png
>
>
> Hi,
> Recently, we started to prepare a new revision of our blog-post in which we
> test various implementations of replicated queues. Previous version can be
> found here: [https://softwaremill.com/mqperf/]
> We updated artemis binary to 2.13.0, regenerated configuration file and
> applied all the performance tricks you told us last time. In particular these
> were:
> * the {{Xmx}} java parameter bumped to {{16G (now bumped to 48G)}}
> * in {{broker.xml}}, the {{global-max-size}} setting changed to {{8G (this
> one we forgot to set, but we suspect that it is not the issue)}}
> * {{journal-type}} set to {{MAPPED}}
> * {{journal-datasync}}, {{journal-sync-non-transactional}} and
> {{journal-sync-transactional}} all set to false
> Apart from that we changed machines' type we use to r5.2xlarge ( 8 cores, 64
> GIB memory, Network bandwidth Up to 10 Gbps, Storage bandwidth Up to 4,750
> Mbps) and we decided to always run twice as much receivers as senders.
> From our tests it looks like version 2.13.0 is not scaling as well, with the
> increase of senders and receivers, as version 2.2.0 (previously tested).
> Basically is not scaling at all as the throughput stays almost at the same
> level, while previously it used to grow linearly.
> Here you can find our tests results for both versions:
> [https://docs.google.com/spreadsheets/d/1kr9fzSNLD8bOhMkP7K_4axBQiKel1aJtpxsBCOy9ugU/edit?usp=sharing]
> We are aware that now there is a dedicated page in documentation about
> performance tuning, but we are surprised that same settings as before
> performs much worse.
> Maybe there is an obvious property which we overlooked which should be turned
> on?
> All changes between those versions together with the final configuration can
> be found on this merged PR:
> [https://github.com/softwaremill/mqperf/commit/6bfae489e11a250dc9e6ef59719782f839e8874a]
>
> Charts showing machines' usage in attachments. Memory consumed by artemis
> process didn't exceed ~ 16 GB. Bandwidht and cpu weren't also a bottlenecks.
> p.s. I wanted to ask this question on mailing list/nabble forum first but it
> seems that I don't have permissions to do so even though I registered &
> subscribed. Is that intentional?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2895) Support authentication over anonymous connection context in LDAPLoginModule
[ https://issues.apache.org/jira/browse/ARTEMIS-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-2895: Fix Version/s: (was: 2.15.0) 2.16.0 > Support authentication over anonymous connection context in LDAPLoginModule > --- > > Key: ARTEMIS-2895 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2895 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.14.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.16.0 > > > if the ldap provider supports anonymous binds, and the ldap login module is > configured to make use of those, it should still be possible to verify bind > credentials from client connections and revert to anonymous for further > mapping work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-8035) Support authentication over anonymous connection context in LDAPLoginModule
[ https://issues.apache.org/jira/browse/AMQ-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195289#comment-17195289 ] Jean-Baptiste Onofré commented on AMQ-8035: --- No problem, I will tackle that. Thanks. > Support authentication over anonymous connection context in LDAPLoginModule > --- > > Key: AMQ-8035 > URL: https://issues.apache.org/jira/browse/AMQ-8035 > Project: ActiveMQ > Issue Type: Bug > Components: Security/JAAS >Affects Versions: 5.16.0 >Reporter: Gary Tully >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.17.0, 5.16.1, 5.15.14 > > > if the ldap provider supports anonymous binds, and the ldap login module is > configured to make use of those, it should still be possible to verify bind > credentials from client connections and revert to anonymous for further > mapping work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (AMQ-8035) Support authentication over anonymous connection context in LDAPLoginModule
[ https://issues.apache.org/jira/browse/AMQ-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reopened AMQ-8035: -- Assignee: Jean-Baptiste Onofré (was: Gary Tully) @assignee Please cherry-pick [~gtully] 's fix back to 5.16.x + 5.15.x. > Support authentication over anonymous connection context in LDAPLoginModule > --- > > Key: AMQ-8035 > URL: https://issues.apache.org/jira/browse/AMQ-8035 > Project: ActiveMQ > Issue Type: Bug > Components: Security/JAAS >Affects Versions: 5.16.0 >Reporter: Gary Tully >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.17.0, 5.16.1, 5.15.14 > > > if the ldap provider supports anonymous binds, and the ldap login module is > configured to make use of those, it should still be possible to verify bind > credentials from client connections and revert to anonymous for further > mapping work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-8035) Support authentication over anonymous connection context in LDAPLoginModule
[ https://issues.apache.org/jira/browse/AMQ-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195286#comment-17195286 ] Colm O hEigeartaigh edited comment on AMQ-8035 at 9/14/20, 8:34 AM: [~jbonofre] Please cherry-pick [~gtully] 's fix back to 5.16.x + 5.15.x. was (Author: coheigea): @assignee Please cherry-pick [~gtully] 's fix back to 5.16.x + 5.15.x. > Support authentication over anonymous connection context in LDAPLoginModule > --- > > Key: AMQ-8035 > URL: https://issues.apache.org/jira/browse/AMQ-8035 > Project: ActiveMQ > Issue Type: Bug > Components: Security/JAAS >Affects Versions: 5.16.0 >Reporter: Gary Tully >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 5.17.0, 5.16.1, 5.15.14 > > > if the ldap provider supports anonymous binds, and the ldap login module is > configured to make use of those, it should still be possible to verify bind > credentials from client connections and revert to anonymous for further > mapping work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (AMQ-8035) Support authentication over anonymous connection context in LDAPLoginModule
[ https://issues.apache.org/jira/browse/AMQ-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated AMQ-8035: - Fix Version/s: 5.15.14 5.16.1 > Support authentication over anonymous connection context in LDAPLoginModule > --- > > Key: AMQ-8035 > URL: https://issues.apache.org/jira/browse/AMQ-8035 > Project: ActiveMQ > Issue Type: Bug > Components: Security/JAAS >Affects Versions: 5.16.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.17.0, 5.16.1, 5.15.14 > > > if the ldap provider supports anonymous binds, and the ldap login module is > configured to make use of those, it should still be possible to verify bind > credentials from client connections and revert to anonymous for further > mapping work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-8041) Cannot install activemq on karaf 4.2.9
[ https://issues.apache.org/jira/browse/AMQ-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195283#comment-17195283 ] Terrien Jean-Yves commented on AMQ-8041: I tried version 5.16.0 with the same result > Cannot install activemq on karaf 4.2.9 > -- > > Key: AMQ-8041 > URL: https://issues.apache.org/jira/browse/AMQ-8041 > Project: ActiveMQ > Issue Type: Bug > Components: OSGi/Karaf >Affects Versions: 5.15.13 > Environment: Windows 10 > Java 1.8.0_202 > I've added Camel 3.4.3 and deployed camel-activemq. > I saw that camel-activemq installs > 2020-09-14T09:50:44,547 | INFO | features-3-thread-1 | FeaturesServiceImpl | > 11 - org.apache.karaf.features.core - 4.2.9 | > *wrap:mvn:org.apache.activemq/activemq-osgi/5.15.13*$overwrite=merge=org.springframework.*;resolution:=optional;version="[5,6)",*;resolution:=optional > > That's why I chose version 5.15.13 >Reporter: Terrien Jean-Yves >Priority: Blocker > > Multiple problems on activemq-broker deployment. > >repo-add activemq 5.15.13 > >feature:install activemq-broker > 1) 2020-09-14T09:52:28,802 | WARN | features-3-thread-1 | Activator > | 205 - org.ops4j.pax.web.pax-web-extender-war - 7.2.16 | Error > while creating extension for bundle org.apache.activemq.activemq-web-console > [143] > java.lang.NoClassDefFoundError: com/sun/istack/Pool > after install > >install -s mvn:com.sun.istack/istack-commons-runtime/3.0.11 > 2) 2020-09-14T09:53:11,244 | ERROR | CM Configuration Updater > (ManagedServiceFactory Update: factoryPid=[org.apache.activemq.server]) | > configadmin | 9 - org.apache.felix.configadmin - 1.9.16 > | [org.osgi.service.cm.ManagedServiceFactory, id=401, > bundle=14/wrap:mvn:org.apache.activemq/activemq-osgi/5.15.13$overwrite=merge=org.springframework.*;resolution:=optional;version="[5,6)",*;resolution:=optional]: > Updating configuration > org.apache.activemq.server.4fb03afb-a88e-4ae5-9290-fb63275f3228 caused a > problem: Cannot start the broker > org.osgi.service.cm.ConfigurationException: null : Cannot start the broker > at > org.apache.activemq.osgi.ActiveMQServiceFactory.updated(ActiveMQServiceFactory.java:147) > ~[!/:5.15.13] > at > org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159) > ~[!/:?] > at > org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93) > [!/:?] > at > org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.provide(ConfigurationManager.java:1253) > [!/:?] > at > org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.run(ConfigurationManager.java:1197) > [!/:?] > at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:138) > [!/:?] > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:105) > [!/:?] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_202] > Caused by: > org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line > 24 in XML document from URL > [file:/H:/Karaf-distribution/apache-karaf-4.2.9/etc/activemq.xml] is invalid; > nested exception is org.xml.sax.SAXParseException; lineNumber: 24; > columnNumber: 101; cvc-elt.1 : Déclaration de l'élément 'beans' introuvable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-8035) Support authentication over anonymous connection context in LDAPLoginModule
[ https://issues.apache.org/jira/browse/AMQ-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195282#comment-17195282 ] Gary Tully commented on AMQ-8035: - [~coheigea] unfortunately I don't have the bandwidth to merge/monitor the .x branches at this time. > Support authentication over anonymous connection context in LDAPLoginModule > --- > > Key: AMQ-8035 > URL: https://issues.apache.org/jira/browse/AMQ-8035 > Project: ActiveMQ > Issue Type: Bug > Components: Security/JAAS >Affects Versions: 5.16.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.17.0 > > > if the ldap provider supports anonymous binds, and the ldap login module is > configured to make use of those, it should still be possible to verify bind > credentials from client connections and revert to anonymous for further > mapping work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (AMQ-8041) Cannot install activemq on karaf 4.2.9
Terrien Jean-Yves created AMQ-8041: -- Summary: Cannot install activemq on karaf 4.2.9 Key: AMQ-8041 URL: https://issues.apache.org/jira/browse/AMQ-8041 Project: ActiveMQ Issue Type: Bug Components: OSGi/Karaf Affects Versions: 5.15.13 Environment: Windows 10 Java 1.8.0_202 I've added Camel 3.4.3 and deployed camel-activemq. I saw that camel-activemq installs 2020-09-14T09:50:44,547 | INFO | features-3-thread-1 | FeaturesServiceImpl | 11 - org.apache.karaf.features.core - 4.2.9 | *wrap:mvn:org.apache.activemq/activemq-osgi/5.15.13*$overwrite=merge=org.springframework.*;resolution:=optional;version="[5,6)",*;resolution:=optional That's why I chose version 5.15.13 Reporter: Terrien Jean-Yves Multiple problems on activemq-broker deployment. >repo-add activemq 5.15.13 >feature:install activemq-broker 1) 2020-09-14T09:52:28,802 | WARN | features-3-thread-1 | Activator | 205 - org.ops4j.pax.web.pax-web-extender-war - 7.2.16 | Error while creating extension for bundle org.apache.activemq.activemq-web-console [143] java.lang.NoClassDefFoundError: com/sun/istack/Pool after install >install -s mvn:com.sun.istack/istack-commons-runtime/3.0.11 2) 2020-09-14T09:53:11,244 | ERROR | CM Configuration Updater (ManagedServiceFactory Update: factoryPid=[org.apache.activemq.server]) | configadmin | 9 - org.apache.felix.configadmin - 1.9.16 | [org.osgi.service.cm.ManagedServiceFactory, id=401, bundle=14/wrap:mvn:org.apache.activemq/activemq-osgi/5.15.13$overwrite=merge=org.springframework.*;resolution:=optional;version="[5,6)",*;resolution:=optional]: Updating configuration org.apache.activemq.server.4fb03afb-a88e-4ae5-9290-fb63275f3228 caused a problem: Cannot start the broker org.osgi.service.cm.ConfigurationException: null : Cannot start the broker at org.apache.activemq.osgi.ActiveMQServiceFactory.updated(ActiveMQServiceFactory.java:147) ~[!/:5.15.13] at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159) ~[!/:?] at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93) [!/:?] at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.provide(ConfigurationManager.java:1253) [!/:?] at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.run(ConfigurationManager.java:1197) [!/:?] at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:138) [!/:?] at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:105) [!/:?] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_202] Caused by: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 24 in XML document from URL [file:/H:/Karaf-distribution/apache-karaf-4.2.9/etc/activemq.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 24; columnNumber: 101; cvc-elt.1 : Déclaration de l'élément 'beans' introuvable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
