> If so does it mean the ack failed thus the message is not acked and will
be delivered to the consumer again in the new session?
Yes.
> Attached is the full log
Looks like the attached log didn't make it through the list filters. Maybe
try pasting it somewhere (e.g. here [1]) and providing a li
First of all, thank you very much Andy for your hard work! Compared to other
brokers, like for example RabbitMQ or RocketMQ, or any pub/sub type cloud based
implementation, Artemis management UI is lacking so ANY movement in that
direction is much appreciated.
Nevertheless, I think part of the
Thank you for your response.
Suggestion regarding switching to persistent queues looks interesting. I'm
wondering what is the performance penalty of having
auto-delete-queues/auto-delete-addresses enabled on a broker with tens of
thousands of queues versus using temporary queues? Currently we h
+ 1 to all that Justin said. Just to add a little more, Jolokia polls all
the JMX beans regularly and this does not currently scale, once you hit a
certain number of addresses the console just hangs, most of this is just
for the JMX tree and isnt needed for the non JMX view. I am currently
working
Sorry, but I must come back to this.
Does setting security settings on temporary queues supposed to work this way?
Or is the namespace only supported for standard address settings, like metrics,
etc.?
temp
I'm asking, because it looks like my assumptions previously were wrong and we
get
Hi Justin,
Yes, we are getting exception in broker log
(javax.net.ssl.SSLHandshakeException: Empty server certificate chain) and we
are looking for more information along with just client IP.
If JDK handles these handshakes as part of heap or native memory? Our brokers
are running in K8s (6 GB
> ...any article or whitepaper from community on how to handle (D)DoS
attack on Artemis broker?
I'm not aware of any such whitepaper.
That said, I think the first line of defense would actually be in the
network exposure rather than in the broker configuration. In other words,
only expose your br
Hello,
We recently got this error from one of our artemis broker (2.31.2):
ERROR [org.apache.activemq.artemis.core.server] AMQ224016: Caught exception
org.apache.activemq.artemis.api.core.ActiveMQIllegalStateException:
AMQ229028: Consumer 0 doesn't exist on the server
I am not sure if this is d
Understood. So one probable performance penalty would be due to queues sitting
on disk. Another penalty I suppose is queue scanning every
"address-queue-scan-period"? If we have thousands of queues and the scan needs
to check every queue for messages and consumer count I suppose this is also
re
> I just defined sslProvider=openssl...
You should be using this as noted in the documentation [1]:
sslProvider=OPENSSL
> Is there any log or other indication that now SSL process has moved from
JDK to OPENSSL?
I couldn't find anything that logs which sslProvider is in use for an
acceptor.
Hello Vilius,
I tried to use a temporary queue namespace to define security settings, and
it definitely doesn't work this way. If an application tries to use a
temporary address with a random name, it needs permissions for all
addresses.
Recently we solved a problem in the JMSToolBox application
Affected versions:
- Apache ActiveMQ Artemis 1.5.1 before 2.40.0
Description:
Insertion of Sensitive Information into Log File vulnerability in Apache
ActiveMQ Artemis. All the values of the broker properties are logged when the
org.apache.activemq.artemis.core.config.impl.ConfigurationImpl lo
Hi Justin,
While moving from JDK to OPENSSL, I just defined sslProvider=openssl on the
acceptor and broker seems to start fine. Is there any log or other indication
that now SSL process has moved from JDK to OPENSSL? Unfortunately, I could not
find any article on using OPENSSL with Artemis. Any
Hello Justin.
I did see the console while it was still a standalone product, and I somehow
thought that it was a very early attempt to integrate a new HawtIO version, and
that the development will continue towards the previous experience. It's a user
interface after all, and users who are not d
14 matches
Mail list logo
