artemiscloud / activemq-artemis-broker-kubernetes-image Goto Github PK
View Code? Open in Web Editor NEWLicense: Apache License 2.0
License: Apache License 2.0
Enable github dependabot to verify which dependencies can be updated daily.
On this repo, currently only the github actions will be verified as the docker image is build using CEKit and the Container file is not available.
The release tags start with the prefix v
i.e. v1.0.0 while the container image tags have no prefix.
This mismatch cause confusion, could you create the release tags without prefix?
Is your feature request related to a problem? Please describe.
At the moment the the ./artemis create command is executed in the main container. As init container usage is being introduced it may be beneficial to more the creation of the broker instance into it's own init container that runs to completion prior to actually starting the broker.
Describe the solution you'd like
For such an 'activemq-artemis-broker-init-create' container the created instance could be shared from the init-container to the main container via an EmptyDir as per the original init container work.
Describe the bug
If the user using artemis cloud operator to config/deploy a broker that has redistribution-delay configured, the broker pod will not
be starting and result in CrashLoopBackOff state
To Reproduce
Steps to reproduce the behavior:
Platform (please complete the following information):
Expected behavior
Optional, use if not obvious. A clear and concise description of what you expected to happen.
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
The container image quay.io/artemiscloud/activemq-artemis-broker-kubernetes:1.0.19 for the arm64 doesn't include the aarch_64 netty-tcnative artifact.
Describe the bug
Enabling the AMQ_ENABLE_JOLOKIA_AGENT environment variable and disabling the CONFIG_BROKER environment variable, the broker container prints the following error:
Could not start Jolokia agent: java.lang.IllegalStateException: Cannot open keystore for https communication:
Exception FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f14179a8e91, pid=1, tid=26
#
# JRE version: OpenJDK Runtime Environment 21.9 (17.0.3+7) (build 17.0.3+7-LTS)
# Java VM: OpenJDK 64-Bit Server VM 21.9 (17.0.3+7-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C [libc.so.6+0x21e91] abort+0x203
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to /home/jboss/core.1)
#
# An error report file with more information is saved as:
# /home/jboss/hs_err_pid1.log
in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:491)
at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:503)
Caused by: java.lang.IllegalArgumentException: jolokia: Can not find configuration file /opt/jboss/container/jolokia/etc/jolokia.properties
at org.jolokia.jvmagent.JvmAgentConfig.readConfig(JvmAgentConfig.java:127)
at org.jolokia.jvmagent.JvmAgentConfig.getDefaultConfig(JvmAgentConfig.java:97)
at org.jolokia.jvmagent.JolokiaServerConfig.init(JolokiaServerConfig.java:103)
at org.jolokia.jvmagent.JvmAgentConfig.init(JvmAgentConfig.java:61)
at org.jolokia.jvmagent.JolokiaServerConfig.<init>(JolokiaServerConfig.java:94)
at org.jolokia.jvmagent.JvmAgentConfig.<init>(JvmAgentConfig.java:55)
at org.jolokia.jvmagent.JvmAgentConfig.<init>(JvmAgentConfig.java:46)
at org.jolokia.jvmagent.JvmAgent.premain(JvmAgent.java:72)
... 6 more
Caused by: java.io.FileNotFoundException: /opt/jboss/container/jolokia/etc/jolokia.properties (No such file or directory)
at java.base/java.io.FileInputStream.open0(Native Method)
at java.base/java.io.FileInputStream.open(FileInputStream.java:216)
at java.base/java.io.FileInputStream.<init>(FileInputStream.java:157)
at org.jolokia.jvmagent.JvmAgentConfig.readConfig(JvmAgentConfig.java:124)
... 13 more
*** java.lang.instrument ASSERTION FAILED ***: "result" with message agent load/premain call failed at src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 422
To Reproduce
docker run --name artemis --env AMQ_USER=admin --env AMQ_PASSWORD=admin --env AMQ_ENABLE_JOLOKIA_AGENT=true -e CONFIG_BROKER=false -e CONFIG_INSTANCE_DIR=... artemiscloud/activemq-artemis-broker-kubernetes:1.0.6
Describe the bug
The drain.sh in amq-launch-module should wait for the broker (which is running background) to finish
before exit. This is useful for broker to shutdown properly and for checking out broker status when scale
down fails.
To Reproduce
Steps to reproduce the behavior:
Platform (please complete the following information):
Expected behavior
Optional, use if not obvious. A clear and concise description of what you expected to happen.
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
$ curl --fail -L https://github.com/rh-messaging/artemis-prometheus-metrics-plugin/releases/download/v2.0.0/artemis-prometheus-metrics-plugin-2.0.0.jar
curl: (22) The requested URL returned error: 404
$ curl --fail -L https://github.com/rh-messaging/artemis-prometheus-metrics-plugin/releases/download/v2.0.0/artemis-prometheus-metrics-plugin-servlet-2.0.0.war
curl: (22) The requested URL returned error: 404
Describe the bug
During scaledown the drainer.sh uses its hostname in its connector for clusterconnection. However as the drainer pod is a standalone pod it's hostname (pod name) cannot be resolved by other broker pods. As a result when other broker pods try to use the hostname to establish a cluster connection to the drainer pod, "UnknownHostException" exception is thrown and as a result the broker keeps retrying (for 20 times as per current configure).
The simple fix is to just use pod's IP which is resolvable across the cluster.
To Reproduce
Steps to reproduce the behavior:
Platform (please complete the following information):
Expected behavior
Optional, use if not obvious. A clear and concise description of what you expected to happen.
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
Describe the bug
The upcoming artemis release 2.21 will be using jgroups 5.2 which is not compatible with current jgroups
configuration which based on JGroups 3.
To Reproduce
Steps to reproduce the behavior:
Platform (please complete the following information):
Expected behavior
Optional, use if not obvious. A clear and concise description of what you expected to happen.
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
Describe the bug
The operator uses JAVA_ARGS_APPEND to define some sys properties (for example logging)
However if a user configures broker using the same variable using ValueFrom
rather than
Value
its value will get overridden. To avoid the conflict the operator should use a
different env var and append the values to the JAVA_ARGS_APPEND before start up.
Broken fails to start when the broker.xml contains an acceptor with the OpenSSL provider:
ERROR
[org.apache.activemq.artemis.core.server] AMQ224097: Failed to start
server: java.lang.NoClassDefFoundError:
io/netty/internal/tcnative/SSLPrivateKeyMethod
at
io.netty.handler.ssl.SslContext.newServerContextInternal(SslContext.java:473)
...
The lib folder doesn't include the netty-tcnative classes.
Is your feature request related to a problem? Please describe.
Right now the script is using python2 which is very old.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
Optional. A clear and concise description of any alternative solutions or features you've considered.
Additional context
Optional. Add any other context or screenshots about the feature request here.
Describe the bug
Disabling the AMQ_ENABLE_MANAGEMENT_RBAC environment variable, the broker container doesn't not include the org.apache.activemq.artemis
domain into the allowlist.
To Reproduce
docker run --name artemis --env AMQ_USER=admin --env AMQ_PASSWORD=admin --env AMQ_ENABLE_MANAGEMENT_RBAC=false artemiscloud/activemq-artemis-broker-kubernetes:1.0.5
Build nightly images with the tag snapshot based on the latest ActiveMQ Artemis snapshot.
Describe the bug
The drain.sh script didn't check the response code from the scaledown call and if the scaledown fails the drainer pod
exits without error, this causes the operator to delete the PVC and may lose messages in it.
To Reproduce
Steps to reproduce the behavior:
Platform (please complete the following information):
Expected behavior
Optional, use if not obvious. A clear and concise description of what you expected to happen.
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
Is your feature request related to a problem? Please describe.
Currently the management console context path is hardcoded to /console, i can't really see way to update it besides manually change it in bootstrap.xml
Describe the solution you'd like
Additional parameter to update management console URL as part of image.yaml, can be something like AMQ_CONSOLE_CONTEXT, will be even better to have artemis-plugin, and activemq-branding to be customizable context path.
Describe alternatives you've considered
Optional. A clear and concise description of any alternative solutions or features you've considered.
Additional context
Optional. Add any other context or screenshots about the feature request here.
Is your feature request related to a problem? Please describe.
Add check on commit messages of PR to make sure each begin with a issue number
[#nnn] or [NO-ISSUE]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
Optional. A clear and concise description of any alternative solutions or features you've considered.
Additional context
Optional. Add any other context or screenshots about the feature request here.
Hello. I was browsing this project and since the repositories are based on the equivalents from RedHat AMQ Broker I was wondering if there is any reason why the Metrics plugin is still using the one published by RedHat instead of having its own "mirrored" one in artemiscloud just like other repositories? Generally I am asking if there are plans to create this plugin repository here.
Describe the bug
The drain.sh cannot correctly detect the type of queue in an address of both multicast and anycast routing types.
It treated a queue on that address as a temp queue which result in the message count of that queue being ignored.
To Reproduce
Steps to reproduce the behavior:
Platform (please complete the following information):
Expected behavior
Optional, use if not obvious. A clear and concise description of what you expected to happen.
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
v 1.6.2 suffers from jolokia/jolokia#569 which is resolved in v2.
The dependency is configured in https://github.com/artemiscloud/cct_module/blob/master/jboss/container/jolokia/bash/module.yaml#L35
The shading problem prevents the configuration of an authenticator via authClass that interacts with the jolokia core modules.
eg: authClass=org.apache.activemq.artemis.spi.core.security.jaas.HttpServerAuthenticator
This allows the jolokia agent to authenticate with the full set of artemis login modules.
Describe the bug
Disabling the AMQ_ENABLE_MANAGEMENT_RBAC environment variable, the broker container only enables access to org.apache.activemq.artemis
To Reproduce
docker run --name artemis --env AMQ_USER=admin --env AMQ_PASSWORD=admin --env AMQ_ENABLE_MANAGEMENT_RBAC=false artemiscloud/activemq-artemis-broker-kubernetes:1.0.8
Build container images for linux/amd64 and linux/arm64
The broker fails to load any of the netty tcnative libraries because the base image includes libssl.so.1.1 but it doesn't include libssl.so.10. Replacing netty-tcnative artifacts with netty-tcnative-boringssl-static artifacts should fix this issue:
java.lang.UnsatisfiedLinkError: failed to load the required native library
at io.netty.handler.ssl.OpenSsl.ensureAvailability(OpenSsl.java:601) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.ReferenceCountedOpenSslContext.<init>(ReferenceCountedOpenSslContext.java:215) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslContext.<init>(OpenSslContext.java:45) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:349) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:336) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContext.newServerContextInternal(SslContext.java:474) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:606) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport.createNettyContext(SSLSupport.java:240) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.ssl.DefaultOpenSSLContextFactory.getServerSslContext(DefaultOpenSSLContextFactory.java:60) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.loadSSLContext(NettyAcceptor.java:396) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.<init>(NettyAcceptor.java:348) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory.createAcceptor(NettyAcceptorFactory.java:43) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.createAcceptor(RemotingServiceImpl.java:273) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:216) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3447) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:78) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:708) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:605) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:129) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:212) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:162) ~[artemis-cli-2.28.0.jar:2.28.0]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:144) ~[artemis-boot.jar:2.28.0]
at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:61) ~[artemis-boot.jar:2.28.0]
Caused by: java.lang.IllegalArgumentException: Failed to load any of the given libraries: [netty_tcnative_linux_x86_64_fedora, netty_tcnative_linux_x86_64, netty_tcnative_x86_64, netty_tcnative]
at io.netty.util.internal.NativeLibraryLoader.loadFirstAvailable(NativeLibraryLoader.java:114) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.loadTcNative(OpenSsl.java:710) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:149) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
... 27 more
Suppressed: java.lang.UnsatisfiedLinkError: could not load a native library: netty_tcnative_linux_x86_64_fedora
at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:239) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.loadFirstAvailable(NativeLibraryLoader.java:105) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.loadTcNative(OpenSsl.java:710) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:149) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.ReferenceCountedOpenSslContext.<init>(ReferenceCountedOpenSslContext.java:215) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslContext.<init>(OpenSslContext.java:45) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:349) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:336) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContext.newServerContextInternal(SslContext.java:474) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:606) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport.createNettyContext(SSLSupport.java:240) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.ssl.DefaultOpenSSLContextFactory.getServerSslContext(DefaultOpenSSLContextFactory.java:60) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.loadSSLContext(NettyAcceptor.java:396) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.<init>(NettyAcceptor.java:348) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory.createAcceptor(NettyAcceptorFactory.java:43) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.createAcceptor(RemotingServiceImpl.java:273) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:216) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3447) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:78) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:708) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:605) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:129) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:212) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:162) ~[artemis-cli-2.28.0.jar:2.28.0]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:144) ~[artemis-boot.jar:2.28.0]
at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:61) ~[artemis-boot.jar:2.28.0]
Caused by: java.io.FileNotFoundException: META-INF/native/libnetty_tcnative_linux_x86_64_fedora.so
at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:186) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
... 30 more
Suppressed: java.lang.UnsatisfiedLinkError: no netty_tcnative_linux_x86_64_fedora in java.library.path: /opt/amq/bin/lib/linux-x86_64
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:2429) ~[?:?]
at java.lang.Runtime.loadLibrary0(Runtime.java:818) ~[?:?]
at java.lang.System.loadLibrary(System.java:1989) ~[?:?]
at io.netty.util.internal.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:38) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:391) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:161) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.loadFirstAvailable(NativeLibraryLoader.java:105) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.loadTcNative(OpenSsl.java:710) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:149) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.ReferenceCountedOpenSslContext.<init>(ReferenceCountedOpenSslContext.java:215) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslContext.<init>(OpenSslContext.java:45) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:349) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:336) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContext.newServerContextInternal(SslContext.java:474) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:606) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport.createNettyContext(SSLSupport.java:240) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.ssl.DefaultOpenSSLContextFactory.getServerSslContext(DefaultOpenSSLContextFactory.java:60) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.loadSSLContext(NettyAcceptor.java:396) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.<init>(NettyAcceptor.java:348) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory.createAcceptor(NettyAcceptorFactory.java:43) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.createAcceptor(RemotingServiceImpl.java:273) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:216) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3447) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:78) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:708) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:605) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:129) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:212) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:162) ~[artemis-cli-2.28.0.jar:2.28.0]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:144) ~[artemis-boot.jar:2.28.0]
at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:61) ~[artemis-boot.jar:2.28.0]
Suppressed: java.lang.UnsatisfiedLinkError: no netty_tcnative_linux_x86_64_fedora in java.library.path: /opt/amq/bin/lib/linux-x86_64
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:2429) ~[?:?]
at java.lang.Runtime.loadLibrary0(Runtime.java:818) ~[?:?]
at java.lang.System.loadLibrary(System.java:1989) ~[?:?]
at io.netty.util.internal.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:38) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at io.netty.util.internal.NativeLibraryLoader$1.run(NativeLibraryLoader.java:425) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at java.security.AccessController.doPrivileged(AccessController.java:318) ~[?:?]
at io.netty.util.internal.NativeLibraryLoader.loadLibraryByHelper(NativeLibraryLoader.java:417) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:383) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:161) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.loadFirstAvailable(NativeLibraryLoader.java:105) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.loadTcNative(OpenSsl.java:710) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:149) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.ReferenceCountedOpenSslContext.<init>(ReferenceCountedOpenSslContext.java:215) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslContext.<init>(OpenSslContext.java:45) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:349) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:336) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContext.newServerContextInternal(SslContext.java:474) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:606) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport.createNettyContext(SSLSupport.java:240) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.ssl.DefaultOpenSSLContextFactory.getServerSslContext(DefaultOpenSSLContextFactory.java:60) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.loadSSLContext(NettyAcceptor.java:396) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.<init>(NettyAcceptor.java:348) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory.createAcceptor(NettyAcceptorFactory.java:43) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.createAcceptor(RemotingServiceImpl.java:273) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:216) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3447) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:78) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:708) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:605) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:129) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:212) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:162) ~[artemis-cli-2.28.0.jar:2.28.0]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:144) ~[artemis-boot.jar:2.28.0]
at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:61) ~[artemis-boot.jar:2.28.0]
Suppressed: java.lang.UnsatisfiedLinkError: /home/jboss/amq-broker/tmp/libnetty_tcnative_linux_x86_641189559241779187359.so: libssl.so.10: cannot open shared object file: No such file or directory
at jdk.internal.loader.NativeLibraries.load(Native Method) ~[?:?]
at jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388) ~[?:?]
at jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232) ~[?:?]
at jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174) ~[?:?]
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:2389) ~[?:?]
at java.lang.Runtime.load0(Runtime.java:755) ~[?:?]
at java.lang.System.load(System.java:1953) ~[?:?]
at io.netty.util.internal.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:36) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:391) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:218) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.loadFirstAvailable(NativeLibraryLoader.java:105) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.loadTcNative(OpenSsl.java:710) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:149) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.ReferenceCountedOpenSslContext.<init>(ReferenceCountedOpenSslContext.java:215) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslContext.<init>(OpenSslContext.java:45) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:349) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:336) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContext.newServerContextInternal(SslContext.java:474) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:606) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport.createNettyContext(SSLSupport.java:240) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.ssl.DefaultOpenSSLContextFactory.getServerSslContext(DefaultOpenSSLContextFactory.java:60) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.loadSSLContext(NettyAcceptor.java:396) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.<init>(NettyAcceptor.java:348) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory.createAcceptor(NettyAcceptorFactory.java:43) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.createAcceptor(RemotingServiceImpl.java:273) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:216) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3447) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:78) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:708) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:605) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:129) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:212) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:162) ~[artemis-cli-2.28.0.jar:2.28.0]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:144) ~[artemis-boot.jar:2.28.0]
at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:61) ~[artemis-boot.jar:2.28.0]
Suppressed: java.lang.UnsatisfiedLinkError: /home/jboss/amq-broker/tmp/libnetty_tcnative_linux_x86_641189559241779187359.so: libssl.so.10: cannot open shared object file: No such file or directory
at jdk.internal.loader.NativeLibraries.load(Native Method) ~[?:?]
at jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388) ~[?:?]
at jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232) ~[?:?]
at jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174) ~[?:?]
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:2389) ~[?:?]
at java.lang.Runtime.load0(Runtime.java:755) ~[?:?]
at java.lang.System.load(System.java:1953) ~[?:?]
at io.netty.util.internal.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:36) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at io.netty.util.internal.NativeLibraryLoader$1.run(NativeLibraryLoader.java:425) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at java.security.AccessController.doPrivileged(AccessController.java:318) ~[?:?]
at io.netty.util.internal.NativeLibraryLoader.loadLibraryByHelper(NativeLibraryLoader.java:417) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:383) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:218) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.util.internal.NativeLibraryLoader.loadFirstAvailable(NativeLibraryLoader.java:105) ~[netty-common-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.loadTcNative(OpenSsl.java:710) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:149) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.ReferenceCountedOpenSslContext.<init>(ReferenceCountedOpenSslContext.java:215) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslContext.<init>(OpenSslContext.java:45) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:349) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:336) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContext.newServerContextInternal(SslContext.java:474) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:606) ~[netty-handler-4.1.86.Final.jar:4.1.86.Final]
at org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport.createNettyContext(SSLSupport.java:240) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.ssl.DefaultOpenSSLContextFactory.getServerSslContext(DefaultOpenSSLContextFactory.java:60) ~[artemis-core-client-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.loadSSLContext(NettyAcceptor.java:396) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor.<init>(NettyAcceptor.java:348) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory.createAcceptor(NettyAcceptorFactory.java:43) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.createAcceptor(RemotingServiceImpl.java:273) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:216) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:3447) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:78) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:708) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:605) ~[artemis-server-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.integration.FileBroker.start(FileBroker.java:66) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:129) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:212) ~[artemis-cli-2.28.0.jar:2.28.0]
at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:162) ~[artemis-cli-2.28.0.jar:2.28.0]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:144) ~[artemis-boot.jar:2.28.0]
at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:61) ~[artemis-boot.jar:2.28.0]
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
Platform (please complete the following information):
Expected behavior
Optional, use if not obvious. A clear and concise description of what you expected to happen.
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
Describe the bug
Enabling the AMQ_ENABLE_JOLOKIA_AGENT environment variable, the broker container prints the following error:
Could not start Jolokia agent: java.lang.IllegalStateException: Cannot open keystore for https communication: java.io.FileNotFoundException: No such CA cert /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt
To Reproduce
docker run --name artemis --env AMQ_USER=admin --env AMQ_PASSWORD=admin --env AMQ_ENABLE_JOLOKIA_AGENT=true artemiscloud/activemq-artemis-broker-kubernetes:1.0.5
Is your feature request related to a problem? Please describe.
Fuse console can't properly connect because of the limitations of the console Jolokia endpoint and the management RBAC.
Describe the solution you'd like
Enable the Jolokia JVM Agent and expose it.
Red Hat ActiveMQ Artemis builds already include metrics plugin artifacts.
Describe the bug
When scaledown returns failure the drain pod will be restarted repeatedly by kubernetes
if we can add some time delay to let the failing pod to live for sometime before restart
we can give the user a chance to login to the pod and inspect the logs etc to find out
clue about why it's failing.
To Reproduce
Steps to reproduce the behavior:
Platform (please complete the following information):
Expected behavior
Optional, use if not obvious. A clear and concise description of what you expected to happen.
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
Describe the bug
apt-get install is failing on github action workflow because the mirror list is not updated
To Reproduce
Execute ci or release workflow
Platform (please complete the following information):
N/A
Expected behavior
Have the workflow executed without errors
Screenshots
N/A
Additional context
apt-get install may fail if it is used directly without update the mirror list with apt-get update
Describe the bug
When a queue contains already messages that are part of a message group then only the first consumer will be assigned to all these message groups. ActiveMQ message groups are not rebalanced when new consumers are added to the broker. Even though group-rebalance=true
or resetAllGroups
is invoked via the management API. Only new message groups get assigned to newer clients.
To Reproduce
Steps to reproduce the behavior:
Platform (please complete the following information):
Expected behavior
The newer clients should also receive Messages with GroupIDs that were already in the queue before they were connected to the broker.
Additional context
Running on Kubernetes with an operator
Messages are created on the web console
Message groups are set at creation of messages via the Header "_AMQ_GROUP_ID"
Artemis documentation about message groups
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
Optional. A clear and concise description of any alternative solutions or features you've considered.
Additional context
Optional. Add any other context or screenshots about the feature request here.
The proxies and load balancers usually support X-Forwarded
headers to send information altered or lost when a proxy is involved in the path of the request.
Jetty supports the ForwardedRequestCustomizer customizer to handle X-Forwarded
headers. If these headers are present, then the Request object is updated so that the proxy is not seen as the other end point of the connection on which the request came.
Describe the bug
The command 'ps' is not installed by default. It is used in drain.sh for messages migration.
To Reproduce
Platform (please complete the following information):
Expected behavior
Optional, use if not obvious. A clear and concise description of what you expected to happen.
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
The container image quay.io/artemiscloud/activemq-artemis-broker-kubernetes:1.0.22 contains ActiveMQ Artemis 2.31.0 that is causing the regression of #44 because the default logging properties was changed by ARTEMIS-4428.
Add keycloak artifacts to the lib folder to support jaas keycloak login modules.
By enabling the metrics plugin the container fails to start. with environment variable AMQ_ENABLE_METRICS_PLUGIN: "true" to run the container
Caused by: java.lang.ClassNotFoundException: org.apache.activemq.artemis.core.server.metrics.plugins.ArtemisPrometheusMetricsPlugin
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
at org.apache.activemq.artemis.utils.ClassloadingUtil.newInstanceFromClassLoader(ClassloadingUtil.java:55)
it seems like
This issue was fixed by jolokia-jvm to 1.7.2.
Describe the bug
The problem is that when the scripts fetch an empty list from /proc/net/tcp
and since it doesn't get an exception it won't fetch /proc/net/tcp6
where the ports are really are. It then doesn't find any open ports.
The problem here is that the value-variable is not stripped before it is split. This results in all ports equals None
and then it will always continue - no matter whether the ports are listening or not.
The default Jetty SNI checks cause HTTP error 400: Invalid SNI if HTTPS is enabled and the server certificate doesn't include the hostname in the HTTP request. This check causes difficulties in a container behind a load balancer because the cerificate used by the container should contains also the load balancer hostname.
Describe the bug
Currently we always scaledown to pod 0 no matter whether the scaledown is successful or not.
It should in the fail case try a different pod (if available) until all are tried.
To Reproduce
Steps to reproduce the behavior:
Platform (please complete the following information):
Expected behavior
Optional, use if not obvious. A clear and concise description of what you expected to happen.
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
Is your feature request related to a problem? Please describe.
As a user I have a need to have more address settings configuration than currently provided.
Describe the solution you'd like
An init container runs to completion prior to the execution of the broker container in the same pod. One solution to the above problem is to use an init container to generate address settings configuration for the broker before the container runs and then utilize that when the broker container starts inside the same pod.
Describe alternatives you've considered
The CEKit build tool has modules that could be extended with more scripts to provide the functionality as required, however the init container method provides a kubernetes native way of accomplishing configuration tasks.
Describe the bug
The command artemis check queue print the following error before running: Could not start Jolokia agent: java.lang.IllegalStateException: Cannot open keystore for https communication: java.net.BindException: Address already in use
To Reproduce
docker run --name artemis --env AMQ_USER=admin --env AMQ_PASSWORD=admin --env AMQ_ENABLE_JOLOKIA_AGENT=true artemiscloud/activemq-artemis-broker-kubernetes:1.0.5
docker exec artemis -- /home/jboss/broker/bin/artemis check queue --name TEST --produce 1000 --browse 1000 --consume 1000 --user admin --password admin'
Describe the bug
Default log4j.properties file has the additivity = false
on audit logs and because of this if you enable the audit logging without changing the additivity to true, by default the audit messages are not logged in the console.
To Reproduce
Steps to reproduce the behavior:
Deploy a broker with a custom logging and set the audit logging as INFO
or higher level
Platform (please complete the following information):
N/A
Expected behavior
It is expected to have audit logging console.
Screenshots
N/A
Additional context
The need to also change the additivity = true
can confuse the users and additivity = false
can be removed from the file as additivity = true
is the default log4j2 behavior.
Describe the bug
Now when testing deployment of two statefulsets, with different APPLICATION_NAME's and thus ping service names, we see that the second can not start pods as they cannot find the correct credential secret.
Also the 'route name' in templates also hard-coded.
To Reproduce
Platform (please complete the following information):
Expected behavior
The multiple deployment described above should be all successful
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
Update repository documentation and templates
Describe the bug
Users used to enable metrics plugin using this env var directly on broker openshift image by modifying the statefulset while being deployed via broker operator. Now as we moved the configuration into init container, this method no longer works. In future we will add direct support for enabling metrics plugin from CR level with operator.
However existing users should be able to use the old method without breaking their existing apps.
To Reproduce
Steps to reproduce the behavior:
Platform (please complete the following information):
Expected behavior
Optional, use if not obvious. A clear and concise description of what you expected to happen.
Screenshots
Optional, add screenshots to help explain your problem.
Additional context
Optional. Add any other context about the problem here.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.