[jira] [Commented] (ARTEMIS-2780) Artemis Jar Files are automatically removed after abnormal system shutdown
[
https://issues.apache.org/jira/browse/ARTEMIS-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17138109#comment-17138109
]
Domenico Bruscino commented on ARTEMIS-2780:
I can't reproduce this issue on windows using Artemis 2.11. Could you track the
file deletions of the lib folder using
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon or enabling
Audit Object Access?
> Artemis Jar Files are automatically removed after abnormal system shutdown
> --
>
> Key: ARTEMIS-2780
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2780
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.11.0
> Environment: Artemis is configured to always use a personally built
> OPEN JRE java (not using the default one)
> * Artemis 2.11.0.
> * Windows 10
> * OpenJDK 1.8.0_66 (OPEN_JRE - C: \ work \ open-jre \)
> * Oracle JDK 1.9.0_191 (Environment variable JAVA_HOME - C: \ Program Files
> \ Java \ jdk1.8.0_191
>
>Reporter: Stefan Buzoianu
>Priority: Critical
> Attachments: ARTEMIS-2780.png, artemis-service.xml, artemis.cmd
>
>
> If you kill the server without invoking a normal shutdown, the contents of
> the lib folder (ArtemisRootDir/lib) are removed. This makes Artemis Brokers
> unable to start.
> My suspicion is that there is a certain incompatibility between my local
> Windows resources and the way ActiveMQ Artemis is configured. Can you check
> the attached files please?
>
> I found this
> [https://github.com/apache/activemq-artemis/blob/a68381904f658dfb3765710ae63f7c79e038b1ed/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/SpawnedVMSupport.java#L192]
> Which apparently makes the java path to be set to java_home
> {code:java}
> final String javaPath = Paths.get(System.getProperty("java.home"), "bin",
> "java").toAbsolutePath().toString();{code}
> But in my case, I actually start the application using Open Jre. (Please
> check Environment details)
>
>
> I found some similarities in these issues
> https://issues.apache.org/jira/browse/ARTEMIS-2596
> https://issues.apache.org/jira/browse/ARTEMIS-1058
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2792) Wrong default network pinger command for linux
Domenico Bruscino created ARTEMIS-2792: -- Summary: Wrong default network pinger command for linux Key: ARTEMIS-2792 URL: https://issues.apache.org/jira/browse/ARTEMIS-2792 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino The network pinger uses a network timeout as an argument for -t in the ping command. The linux man page for ping says -t sets TTL, which is "The TTL value of an IP packet represents the maximum number of IP routers that the packet can go through before being thrown away. In current practice you can expect each router in the Internet to decrement the TTL field by exactly one." It looks like the intent was to use -w timeout, in seconds, before ping exits regardless of how many packets have been sent or received. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2790) No examples documentation in the bin archive
Domenico Bruscino created ARTEMIS-2790: -- Summary: No examples documentation in the bin archive Key: ARTEMIS-2790 URL: https://issues.apache.org/jira/browse/ARTEMIS-2790 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino The documentation of the examples is generated during release but it isn't copied in the bin archive during release because of the build order. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2778) AcceptorControl returns only transport parameters
Domenico Bruscino created ARTEMIS-2778: -- Summary: AcceptorControl returns only transport parameters Key: ARTEMIS-2778 URL: https://issues.apache.org/jira/browse/ARTEMIS-2778 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino The AcceptorControl returns only transport parameters and it doesn't return the protocol parameters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2770) Update diverts using the management API
[ https://issues.apache.org/jira/browse/ARTEMIS-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2770: --- Summary: Update diverts using the management API (was: Update diverts by ) > Update diverts using the management API > --- > > Key: ARTEMIS-2770 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2770 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Domenico Bruscino >Priority: Major > > The diverts can already be created and destroyed using the management API but > there isn't a way to reconfigure a non-exclusive divert without duplicating > or losing messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2770) Update diverts by
[ https://issues.apache.org/jira/browse/ARTEMIS-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2770: --- Summary: Update diverts by (was: Update diverts) > Update diverts by > -- > > Key: ARTEMIS-2770 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2770 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Domenico Bruscino >Priority: Major > > The diverts can already be created and destroyed using the management API but > there isn't a way to reconfigure a non-exclusive divert without duplicating > or losing messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2770) Update diverts
[ https://issues.apache.org/jira/browse/ARTEMIS-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2770: --- Summary: Update diverts (was: Update diverts atomically) > Update diverts > -- > > Key: ARTEMIS-2770 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2770 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Domenico Bruscino >Priority: Major > > The diverts can already be created and destroyed using the management API but > there isn't a way to reconfigure a non-exclusive divert without duplicating > or losing messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2774) Remove the divert transformer on divert destroying
Domenico Bruscino created ARTEMIS-2774: -- Summary: Remove the divert transformer on divert destroying Key: ARTEMIS-2774 URL: https://issues.apache.org/jira/browse/ARTEMIS-2774 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino The divert's transformer is added automatically when the divert is created but it is not removed when the divert is destroyed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2770) Update diverts atomically
Domenico Bruscino created ARTEMIS-2770: -- Summary: Update diverts atomically Key: ARTEMIS-2770 URL: https://issues.apache.org/jira/browse/ARTEMIS-2770 Project: ActiveMQ Artemis Issue Type: New Feature Reporter: Domenico Bruscino The diverts can already be created and destroyed using the management API but there isn't a way to reconfigure a non-exclusive divert without duplicating or losing messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2760) Filter AddressQueueReaper misleading error messages
[ https://issues.apache.org/jira/browse/ARTEMIS-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2760: --- Summary: Filter AddressQueueReaper misleading error messages (was: Filter AddressQueueReaper misleading error messages in log) > Filter AddressQueueReaper misleading error messages > --- > > Key: ARTEMIS-2760 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2760 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Bruscino >Priority: Major > > The address and queue reaper is asynchronous so it could try to remove and > address already removed or try to remove an address during the broker > shutdown. In these situations, the broker should not log an error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2760) Filter AddressQueueReaper misleading error messages in log
Domenico Bruscino created ARTEMIS-2760: -- Summary: Filter AddressQueueReaper misleading error messages in log Key: ARTEMIS-2760 URL: https://issues.apache.org/jira/browse/ARTEMIS-2760 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino The address and queue reaper is asynchronous so it could try to remove and address already removed or try to remove an address during the broker shutdown. In these situations, the broker should not log an error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2755) Improve SoakPagingTest stability
Domenico Bruscino created ARTEMIS-2755: -- Summary: Improve SoakPagingTest stability Key: ARTEMIS-2755 URL: https://issues.apache.org/jira/browse/ARTEMIS-2755 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino The SoakPagingTest intermittently fails and the RetryRule only partially fixes it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2744) Fix karaf mvn repositories for ArtemisFeatureTest
Domenico Bruscino created ARTEMIS-2744: -- Summary: Fix karaf mvn repositories for ArtemisFeatureTest Key: ARTEMIS-2744 URL: https://issues.apache.org/jira/browse/ARTEMIS-2744 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2742) Warn complete XA transaction on the wrong session
Domenico Bruscino created ARTEMIS-2742: -- Summary: Warn complete XA transaction on the wrong session Key: ARTEMIS-2742 URL: https://issues.apache.org/jira/browse/ARTEMIS-2742 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino The broker allows starting a XA transaction on a session and completing the same XA transaction on another session. This is helpful to solve recovery situations and adding some warnings would make them easy to investigate. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2739) Artemis health check tool
Domenico Bruscino created ARTEMIS-2739: -- Summary: Artemis health check tool Key: ARTEMIS-2739 URL: https://issues.apache.org/jira/browse/ARTEMIS-2739 Project: ActiveMQ Artemis Issue Type: New Feature Reporter: Domenico Bruscino Artemis health check tool determines the broker's health state, testing whether an aspect of the broker is operating as expected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2737) Update apache commons-text version to 1.8
Domenico Bruscino created ARTEMIS-2737: -- Summary: Update apache commons-text version to 1.8 Key: ARTEMIS-2737 URL: https://issues.apache.org/jira/browse/ARTEMIS-2737 Project: ActiveMQ Artemis Issue Type: Task Reporter: Domenico Bruscino -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2727) Update netty version to 4.1.48.Final
Domenico Bruscino created ARTEMIS-2727: -- Summary: Update netty version to 4.1.48.Final Key: ARTEMIS-2727 URL: https://issues.apache.org/jira/browse/ARTEMIS-2727 Project: ActiveMQ Artemis Issue Type: Task Reporter: Domenico Bruscino Update netty version to 4.1.48.Final and netty-tcnative version to 2.0.29.Final. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2724) The setting auto-delete-created-queues doesn't work
Domenico Bruscino created ARTEMIS-2724: -- Summary: The setting auto-delete-created-queues doesn't work Key: ARTEMIS-2724 URL: https://issues.apache.org/jira/browse/ARTEMIS-2724 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino The broker doesn't automatically delete created queues with auto-delete-created-queues enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2723) Read the default CLI connector from the related broker
Domenico Bruscino created ARTEMIS-2723: -- Summary: Read the default CLI connector from the related broker Key: ARTEMIS-2723 URL: https://issues.apache.org/jira/browse/ARTEMIS-2723 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino Artemis CLI accesses to the port of the broker through core protocol for many commands. However, when several brokers are installed on a single machine, all the installed `artemis` command for each broker operate only one broker that have `tcp://localhost:61616` by default. This behavior is difficult to understand and could lead to incorrect operations for the different broker. The default connector could be read from the broker where you are related. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2703) Update commons-configuration2 version to 2.7
Domenico Bruscino created ARTEMIS-2703: -- Summary: Update commons-configuration2 version to 2.7 Key: ARTEMIS-2703 URL: https://issues.apache.org/jira/browse/ARTEMIS-2703 Project: ActiveMQ Artemis Issue Type: Task Reporter: Domenico Bruscino -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2699) Warn if queue stats are limited by default maxRows
[ https://issues.apache.org/jira/browse/ARTEMIS-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2699: --- Summary: Warn if queue stats are limited by default maxRows (was: Warn when queue stats are limited by default maxRows) > Warn if queue stats are limited by default maxRows > -- > > Key: ARTEMIS-2699 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2699 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Domenico Bruscino >Priority: Major > > The command "queue stat" have the option --maxRows that limits the number of > queue displayed, by default the value is 50. > There is no way, for the user, to understand if the list of the queues > displayed has been limited or not. > Please let the user to be aware if the limit has been reached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2699) Warn when queue stats are limited by default maxRows
[ https://issues.apache.org/jira/browse/ARTEMIS-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2699: --- Summary: Warn when queue stats are limited by default maxRows (was: CLI "queue stat" : warn user when maxRows has been reached) > Warn when queue stats are limited by default maxRows > > > Key: ARTEMIS-2699 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2699 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Domenico Bruscino >Priority: Major > > The command "queue stat" have the option --maxRows that limits the number of > queue displayed, by default the value is 50. > There is no way, for the user, to understand if the list of the queues > displayed has been limited or not. > Please let the user to be aware if the limit has been reached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2699) CLI "queue stat" : warn user when maxRows has been reached
Domenico Bruscino created ARTEMIS-2699: -- Summary: CLI "queue stat" : warn user when maxRows has been reached Key: ARTEMIS-2699 URL: https://issues.apache.org/jira/browse/ARTEMIS-2699 Project: ActiveMQ Artemis Issue Type: Improvement Components: Broker Reporter: Domenico Bruscino The command "queue stat" have the option --maxRows that limits the number of queue displayed, by default the value is 50. There is no way, for the user, to understand if the list of the queues displayed has been limited or not. Please let the user to be aware if the limit has been reached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2698) Expose queue group attributes
Domenico Bruscino created ARTEMIS-2698: -- Summary: Expose queue group attributes Key: ARTEMIS-2698 URL: https://issues.apache.org/jira/browse/ARTEMIS-2698 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino Expose the queue group attributes through the `ActiveMQServerControl` and the `QueueControl` interface. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2694) Document NO-JIRA use cases
Domenico Bruscino created ARTEMIS-2694: -- Summary: Document NO-JIRA use cases Key: ARTEMIS-2694 URL: https://issues.apache.org/jira/browse/ARTEMIS-2694 Project: ActiveMQ Artemis Issue Type: Task Reporter: Domenico Bruscino -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2693) Improve log of starting acceptor errors
Domenico Bruscino created ARTEMIS-2693: -- Summary: Improve log of starting acceptor errors Key: ARTEMIS-2693 URL: https://issues.apache.org/jira/browse/ARTEMIS-2693 Project: ActiveMQ Artemis Issue Type: Improvement Components: Broker Reporter: Domenico Bruscino Add the log of starting acceptor errors to simplify the detection of the failing acceptor in case of multiple acceptors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2691) Improve critical analyzer LOG policy
[ https://issues.apache.org/jira/browse/ARTEMIS-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2691: --- Component/s: Broker > Improve critical analyzer LOG policy > > > Key: ARTEMIS-2691 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2691 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Domenico Bruscino >Priority: Major > > The critical-analyzer only fires once but if the > is set to LOG, it would make more sense to repeat the LOG action. This would > help when doing log analysis after the issue was encountered. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2691) Improve critical analyzer LOG policy
Domenico Bruscino created ARTEMIS-2691: -- Summary: Improve critical analyzer LOG policy Key: ARTEMIS-2691 URL: https://issues.apache.org/jira/browse/ARTEMIS-2691 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino The critical-analyzer only fires once but if the is set to LOG, it would make more sense to repeat the LOG action. This would help when doing log analysis after the issue was encountered. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2686) Fix MQTT connect message rejection
Domenico Bruscino created ARTEMIS-2686: -- Summary: Fix MQTT connect message rejection Key: ARTEMIS-2686 URL: https://issues.apache.org/jira/browse/ARTEMIS-2686 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker, MQTT Affects Versions: 2.11.0 Reporter: Domenico Bruscino When an incoming MQTT interceptor rejects a MqttConnectMessage the connection doesn't close and the client gets stuck. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2684) NullPointer exception when slave tries to scale down
Domenico Bruscino created ARTEMIS-2684:
--
Summary: NullPointer exception when slave tries to scale down
Key: ARTEMIS-2684
URL: https://issues.apache.org/jira/browse/ARTEMIS-2684
Project: ActiveMQ Artemis
Issue Type: Bug
Components: Broker
Affects Versions: 2.11.0
Reporter: Domenico Bruscino
Using the following configuration on the slave where master1-connector points
to another broker in the broker cluster.
{code:xml}
true
true
master1-connector
{code}
I am getting the following NullPointerException when the slave tries to
activate.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2670) Deadlock when running in cluster mode
[ https://issues.apache.org/jira/browse/ARTEMIS-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063693#comment-17063693 ] Domenico Bruscino commented on ARTEMIS-2670: I can't reproduce this issue against Artemis 2.11.0 because this issue was already fixed by Clebert with ARTEMIS-2592. Before the fix, the QueueImpl.removeConsumer locks the queue until the deleting of auto-create queue. The deleting of a queue calls ManagementServiceImpl.unregisterQueue that is synchronized and this can cause the deadlock. After the fix, QueueManagerImpl has an executor so the deleting of auto-create queue isn't executed in the same thread of QueueImpl.removeConsumer and this prevents the deadlock. > Deadlock when running in cluster mode > - > > Key: ARTEMIS-2670 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2670 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.9.0 >Reporter: Luis Miguel De Bello >Priority: Major > Attachments: Deadlock1, Deadlock2 > > > We are running Artemis 2.9.0 in production (AWS) with 4 instances creating a > cluster (Jgroup) it usually works ok and was working fine but last week one > of the > instances got unhealthy, when login into the instance we noticed there was a > deadlock and lot of connection in CLOSE_WAIT state. I am assuming the > connection in CLOSE_WAIT are generated by this deadlock. > I was checking the releases note for 2.10.0 - 2.10.1 - 2.11.0 and I read > about two deadlock fixes but I don't think it is the same case. > Our clients connect to the broker using Secure Web Socket (Mutual TLS). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2664) The prefetch size is exceeded after delivered acks
Domenico Bruscino created ARTEMIS-2664: -- Summary: The prefetch size is exceeded after delivered acks Key: ARTEMIS-2664 URL: https://issues.apache.org/jira/browse/ARTEMIS-2664 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino In an environment using OpenWire clients, after the consumer send delivered acks, we see that messages get prefetched out to the consumer beyond its limit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2663) Add customizer support for the embedded web server
Domenico Bruscino created ARTEMIS-2663: -- Summary: Add customizer support for the embedded web server Key: ARTEMIS-2663 URL: https://issues.apache.org/jira/browse/ARTEMIS-2663 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino In many cases it could be useful to have hooks for request to be processed by the embedded web server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2652) Fix PageCursorProviderImplTest on IBM JVM
Domenico Bruscino created ARTEMIS-2652:
--
Summary: Fix PageCursorProviderImplTest on IBM JVM
Key: ARTEMIS-2652
URL: https://issues.apache.org/jira/browse/ARTEMIS-2652
Project: ActiveMQ Artemis
Issue Type: Task
Reporter: Domenico Bruscino
During the execution of
org.apache.activemq.artemis.core.paging.cursor.impl.PageCursorProviderImplTest
using IBM JDK I got an exception:
{code:java}
Underlying exception : org.mockito.exceptions.base.MockitoException: Could not
modify all classes [interface java.lang.Comparable, class
org.apache.activemq.artemis.core.paging.impl.Page, class java.lang.Object]
at
org.apache.activemq.artemis.core.paging.cursor.impl.PageCursorProviderImplTest.shouldAllowConcurrentPageReads(PageCursorProviderImplTest.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
Caused by: org.mockito.exceptions.base.MockitoException: Could not modify all
classes [interface java.lang.Comparable, class
org.apache.activemq.artemis.core.paging.impl.Page, class java.lang.Object]
at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:152)
at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:365)
at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:174)
at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:376)
... 10 more
Caused by: java.lang.instrument.UnmodifiableClassException
at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)
at
sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:163)
at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:174)
at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:153)
at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator$1.call(TypeCachingBytecodeGenerator.java:37)
at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator$1.call(TypeCachingBytecodeGenerator.java:34)
at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:152)
at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:365)
at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:174)
at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:376)
at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:32)
at
org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.createMockType(InlineByteBuddyMockMaker.java:197)
at
org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.createMock(InlineByteBuddyMockMaker.java:178)
at org.mockito.internal.util.MockUtil.createMock(MockUtil.java:35)
at org.mockito.internal.MockitoCore.mock(MockitoCore.java:62)
at org.mockito.Mockito.mock(Mockito.java:1907)
at org.mockito.Mockito.mock(Mockito.java:1816)
... 10 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2650) The delivering count is wrong after reconnecting an openwire client
Domenico Bruscino created ARTEMIS-2650: -- Summary: The delivering count is wrong after reconnecting an openwire client Key: ARTEMIS-2650 URL: https://issues.apache.org/jira/browse/ARTEMIS-2650 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino In an environment using OpenWire clients and messages sent by a CORE producer, we see that messages get prefetched out to the consumer up to its prefetch limit. However, after the client reconnects the delivering count is displayed as prefetch+1. After the consumer reconnection, the broker receives a message ack for a message dispatched before the disconnection. This ack causes an invalid acquiring of credits and a wrong message dispatching. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2644) Include client id into non durable subscriber queue name
Domenico Bruscino created ARTEMIS-2644: -- Summary: Include client id into non durable subscriber queue name Key: ARTEMIS-2644 URL: https://issues.apache.org/jira/browse/ARTEMIS-2644 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino In many cases, we have users who can start up a java web start based user interface, to receive notifications about events that may require manual intervention. For these, we typically use non-durable, non shared subscriptions. These are identified in the broker only with a computed UID, ie a non durable subscriber queue name: 4bd56221-3920-47e9-b5c1-f12015174d4d Sometimes, these consumers can stop consuming, possibly through the user not exiting cleanly, or perhaps with the virtualised desktop environment pausing the UI. We can look to killl these connections / queues from the broker side, but since there is no hostname / application / user visible in the queue name, it makes it hard to identify impacted business users. This is a request to allow consuming applications to provide their own string as part of the queue name, to assist with troubleshooting. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2641) Openwire client runs out of credits after reconnection
[
https://issues.apache.org/jira/browse/ARTEMIS-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2641:
---
Summary: Openwire client runs out of credits after reconnection (was:
Openwire client runs out of credits after restoring)
> Openwire client runs out of credits after reconnection
> --
>
> Key: ARTEMIS-2641
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2641
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Major
>
> In an environment using OpenWire NMS clients, after the consumer
> reconnection, we see that messages get prefetched out to the consumer up to
> its default limit (1000); however, after the client acks all the messages
> (and the broker shows 1000 messages acked), the broker still reports the
> consumer is waiting on credits and reports current credits as NULL:
> {code}
> DEBUG [org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl]
> ServerConsumerImpl [id=0, filter=null, binding=LocalQueueBinding
> [address=, queue=QueueImpl[name=, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=], temp=false], filter=null,
> name=, clusterName=]] is busy for the lack of credits. Current
> credits = null Can't receive reference
> Reference[45099938419]:RELIABLE:CoreMessage...
> {code}
> Looking at a heap from the affected broker, the currentWindow for the
> consumer is "0" though there are no message references in deliveringRefs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2641) Openwire client runs out of credits after restoring
Domenico Bruscino created ARTEMIS-2641:
--
Summary: Openwire client runs out of credits after restoring
Key: ARTEMIS-2641
URL: https://issues.apache.org/jira/browse/ARTEMIS-2641
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Domenico Bruscino
In an environment using OpenWire NMS clients, after the consumer reconnection,
we see that messages get prefetched out to the consumer up to its default limit
(1000); however, after the client acks all the messages (and the broker shows
1000 messages acked), the broker still reports the consumer is waiting on
credits and reports current credits as NULL:
{code}
DEBUG [org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl]
ServerConsumerImpl [id=0, filter=null, binding=LocalQueueBinding [address=,
queue=QueueImpl[name=, postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=], temp=false], filter=null,
name=, clusterName=]] is busy for the lack of credits. Current credits
= null Can't receive reference Reference[45099938419]:RELIABLE:CoreMessage...
{code}
Looking at a heap from the affected broker, the currentWindow for the consumer
is "0" though there are no message references in deliveringRefs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2627) simpleSecureServer failing on IBM Java 8 JVM
[
https://issues.apache.org/jira/browse/ARTEMIS-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2627:
---
Summary: simpleSecureServer failing on IBM Java 8 JVM (was:
simpleSecureServer failing on IBM JDK 8)
> simpleSecureServer failing on IBM Java 8 JVM
>
>
> Key: ARTEMIS-2627
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2627
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> org.apache.activemq.cli.test.WebServerComponentTest.simpleSecureServer is
> failing on IBM JDK 8.
> The error enabling `-Djavax.net.debug=all:
> {code}
> No available cipher suite for TLSv1
> qtp-1739620824-37, fatal error: 80: problem unwrapping net record
> javax.net.ssl.SSLHandshakeException: No appropriate protocol, may be no
> appropriate cipher suite specified or protocols are deactivated
> qtp-1739620824-37, SEND TLSv1.2 ALERT: fatal, description = internal_error
> qtp-1739620824-37, WRITE: TLSv1.2 Alert, length = 2
> qtp-1739620824-37, called closeOutbound()
> qtp-1739620824-37, closeOutboundInternal()
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2627) simpleSecureServer failing on IBM Java 8 JVM
[
https://issues.apache.org/jira/browse/ARTEMIS-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2627:
---
Description:
org.apache.activemq.cli.test.WebServerComponentTest.simpleSecureServer is
failing on IBM Java 8 JVM.
The error enabling `-Djavax.net.debug=all:
{code}
No available cipher suite for TLSv1
qtp-1739620824-37, fatal error: 80: problem unwrapping net record
javax.net.ssl.SSLHandshakeException: No appropriate protocol, may be no
appropriate cipher suite specified or protocols are deactivated
qtp-1739620824-37, SEND TLSv1.2 ALERT: fatal, description = internal_error
qtp-1739620824-37, WRITE: TLSv1.2 Alert, length = 2
qtp-1739620824-37, called closeOutbound()
qtp-1739620824-37, closeOutboundInternal()
{code}
was:
org.apache.activemq.cli.test.WebServerComponentTest.simpleSecureServer is
failing on IBM JDK 8.
The error enabling `-Djavax.net.debug=all:
{code}
No available cipher suite for TLSv1
qtp-1739620824-37, fatal error: 80: problem unwrapping net record
javax.net.ssl.SSLHandshakeException: No appropriate protocol, may be no
appropriate cipher suite specified or protocols are deactivated
qtp-1739620824-37, SEND TLSv1.2 ALERT: fatal, description = internal_error
qtp-1739620824-37, WRITE: TLSv1.2 Alert, length = 2
qtp-1739620824-37, called closeOutbound()
qtp-1739620824-37, closeOutboundInternal()
{code}
> simpleSecureServer failing on IBM Java 8 JVM
>
>
> Key: ARTEMIS-2627
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2627
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> org.apache.activemq.cli.test.WebServerComponentTest.simpleSecureServer is
> failing on IBM Java 8 JVM.
> The error enabling `-Djavax.net.debug=all:
> {code}
> No available cipher suite for TLSv1
> qtp-1739620824-37, fatal error: 80: problem unwrapping net record
> javax.net.ssl.SSLHandshakeException: No appropriate protocol, may be no
> appropriate cipher suite specified or protocols are deactivated
> qtp-1739620824-37, SEND TLSv1.2 ALERT: fatal, description = internal_error
> qtp-1739620824-37, WRITE: TLSv1.2 Alert, length = 2
> qtp-1739620824-37, called closeOutbound()
> qtp-1739620824-37, closeOutboundInternal()
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2627) simpleSecureServer failing on IBM JDK 8
Domenico Bruscino created ARTEMIS-2627:
--
Summary: simpleSecureServer failing on IBM JDK 8
Key: ARTEMIS-2627
URL: https://issues.apache.org/jira/browse/ARTEMIS-2627
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Domenico Bruscino
org.apache.activemq.cli.test.WebServerComponentTest.simpleSecureServer is
failing on IBM JDK 8.
The error enabling `-Djavax.net.debug=all:
{code}
No available cipher suite for TLSv1
qtp-1739620824-37, fatal error: 80: problem unwrapping net record
javax.net.ssl.SSLHandshakeException: No appropriate protocol, may be no
appropriate cipher suite specified or protocols are deactivated
qtp-1739620824-37, SEND TLSv1.2 ALERT: fatal, description = internal_error
qtp-1739620824-37, WRITE: TLSv1.2 Alert, length = 2
qtp-1739620824-37, called closeOutbound()
qtp-1739620824-37, closeOutboundInternal()
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2625) testListConsumers failing on IBM JDK 8
[
https://issues.apache.org/jira/browse/ARTEMIS-2625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2625:
---
Description:
org.apache.activemq.artemis.tests.smoke.jmx2.JmxServerControlTest.testListConsumers
is failing on IBM JDK 8, with the following error:
{code}number of consumers returned from query expected:<1> but was:<0>{code}
was:
org.apache.activemq.artemis.tests.smoke.jmx2.JmxServerControlTest.testListConsumers
is failing on IBM JDK 8, eith the following error:
{code}number of consumers returned from query expected:<1> but was:<0>{code}
> testListConsumers failing on IBM JDK 8
> --
>
> Key: ARTEMIS-2625
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2625
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Minor
>
> org.apache.activemq.artemis.tests.smoke.jmx2.JmxServerControlTest.testListConsumers
> is failing on IBM JDK 8, with the following error:
> {code}number of consumers returned from query expected:<1> but was:<0>{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2625) testListConsumers failing on IBM JDK 8
[
https://issues.apache.org/jira/browse/ARTEMIS-2625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2625:
---
Summary: testListConsumers failing on IBM JDK 8 (was: JmxServerControlTest
- testListConsumers failing on IBM JDK 8)
> testListConsumers failing on IBM JDK 8
> --
>
> Key: ARTEMIS-2625
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2625
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Minor
>
> org.apache.activemq.artemis.tests.smoke.jmx2.JmxServerControlTest.testListConsumers
> is failing on IBM JDK 8, eith the following error:
> {code}number of consumers returned from query expected:<1> but was:<0>{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2625) JmxServerControlTest - testListConsumers failing on IBM JDK 8
Domenico Bruscino created ARTEMIS-2625:
--
Summary: JmxServerControlTest - testListConsumers failing on IBM
JDK 8
Key: ARTEMIS-2625
URL: https://issues.apache.org/jira/browse/ARTEMIS-2625
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Domenico Bruscino
org.apache.activemq.artemis.tests.smoke.jmx2.JmxServerControlTest.testListConsumers
is failing on IBM JDK 8, eith the following error:
{code}number of consumers returned from query expected:<1> but was:<0>{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2615) Update netty version to 4.1.45.Final
Domenico Bruscino created ARTEMIS-2615: -- Summary: Update netty version to 4.1.45.Final Key: ARTEMIS-2615 URL: https://issues.apache.org/jira/browse/ARTEMIS-2615 Project: ActiveMQ Artemis Issue Type: Task Reporter: Domenico Bruscino Update netty version to 4.1.45.Final and netty-tcnative version to 2.0.28.Final. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (ARTEMIS-2600) Update mqtt-client version to 1.16
[ https://issues.apache.org/jira/browse/ARTEMIS-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino reopened ARTEMIS-2600: I reopened the issue because tests/activemq5-unit-tests/pom.xml uses the mqtt-client 1.10. > Update mqtt-client version to 1.16 > -- > > Key: ARTEMIS-2600 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2600 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Domenico Bruscino >Priority: Major > Fix For: 2.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2601) Update jetty version to 9.4.26.v20200117
[ https://issues.apache.org/jira/browse/ARTEMIS-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2601: --- Summary: Update jetty version to 9.4.26.v20200117 (was: Update jetty version to 9.4.26.v20200115) > Update jetty version to 9.4.26.v20200117 > > > Key: ARTEMIS-2601 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2601 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Domenico Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2601) Update jetty version to 9.4.26.v20200115
Domenico Bruscino created ARTEMIS-2601: -- Summary: Update jetty version to 9.4.26.v20200115 Key: ARTEMIS-2601 URL: https://issues.apache.org/jira/browse/ARTEMIS-2601 Project: ActiveMQ Artemis Issue Type: Task Reporter: Domenico Bruscino -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2600) Update mqtt-client version to 1.16
Domenico Bruscino created ARTEMIS-2600: -- Summary: Update mqtt-client version to 1.16 Key: ARTEMIS-2600 URL: https://issues.apache.org/jira/browse/ARTEMIS-2600 Project: ActiveMQ Artemis Issue Type: Task Reporter: Domenico Bruscino -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2598) Update netty version to 4.1.43.Final
Domenico Bruscino created ARTEMIS-2598: -- Summary: Update netty version to 4.1.43.Final Key: ARTEMIS-2598 URL: https://issues.apache.org/jira/browse/ARTEMIS-2598 Project: ActiveMQ Artemis Issue Type: Task Reporter: Domenico Bruscino Update netty version to 4.1.43.Final and netty-tcnative version to 2.0.26.Final. Netty 4.1.43.Final requires access to two more files: * /etc/os-release * /usr/lib/os-release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2597) Memory Leak when closing AMQP Consumers in the context
[ https://issues.apache.org/jira/browse/ARTEMIS-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2597: --- Summary: Memory Leak when closing AMQP Consumers in the context (was: Memory Leak when Opening and Closing AMQP Consumers in the Same Session / Context) > Memory Leak when closing AMQP Consumers in the context > -- > > Key: ARTEMIS-2597 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2597 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Domenico Bruscino >Priority: Major > > I found that if I open a JMSContext from a qpid JmsConnectionFactory, then > open and close consumers in a loop within the context, I can trigger a leak > of > org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext, > org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl and related > objects that seem to persist even after the client is killed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2597) Memory Leak when Opening and Closing AMQP Consumers in the Same Session / Context
Domenico Bruscino created ARTEMIS-2597: -- Summary: Memory Leak when Opening and Closing AMQP Consumers in the Same Session / Context Key: ARTEMIS-2597 URL: https://issues.apache.org/jira/browse/ARTEMIS-2597 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino I found that if I open a JMSContext from a qpid JmsConnectionFactory, then open and close consumers in a loop within the context, I can trigger a leak of org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext, org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl and related objects that seem to persist even after the client is killed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2593) Thread leak test failure with OpenJ9 JVM
[
https://issues.apache.org/jira/browse/ARTEMIS-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2593:
---
Description:
The test suite checks thread leak after each test, checking all the running
threads at the end of the test and if any of the thread is not in the expected
set, the test will fail.
The expected set is a set of thread names that can be ignored when checking
thread leak. With OpenJ9 JVM, the broker will cause a daemon thread called
"MemoryMXBean" to be started by the VM. This thread is not controlled by the
broker and should be put to the expected set. Otherwise tests will report false
thread leak error.
{code}
LEAKING THREADS
=
Thread Thread[MemoryMXBean notification dispatcher,6,main] is still alive with
the following stackTrace:
jdk.management/com.ibm.lang.management.internal.MemoryNotificationThread.processNotificationLoop(Native
Method)
jdk.management/com.ibm.lang.management.internal.MemoryNotificationThread.run(MemoryNotificationThread.java:183)
*
[main] 01:01:21,829 INFO
[org.apache.activemq.artemis.utils.ThreadLeakCheckRule] #test forceGC
[main] 01:01:21,877 INFO
[org.apache.activemq.artemis.utils.ThreadLeakCheckRule] #test forceGC Done
*
{code}
was:
The test suite checks thread leak after each test, checking all the running
threads at the end of the test and if any of the thread is not in the expected
set, the test will fail.
The expected set is a set of thread names that can be ignored when checking
thread leak. With IBM jre, the broker will cause a daemon thread called
"MemoryMXBean" to be started by the VM. This thread is not controlled by the
broker and should be put to the expected set. Otherwise tests will report false
thread leak error.
{code}
LEAKING THREADS
=
Thread Thread[MemoryMXBean notification dispatcher,6,main] is still alive with
the following stackTrace:
com.ibm.lang.management.internal.MemoryNotificationThread.processNotificationLoop(Native
Method)
com.ibm.lang.management.internal.MemoryNotificationThread.run(MemoryNotificationThread.java:183)
*
[main] 18:10:19,675 INFO
[org.apache.activemq.artemis.utils.ThreadLeakCheckRule] #test forceGC
[main] 18:10:19,777 INFO
[org.apache.activemq.artemis.utils.ThreadLeakCheckRule] #test forceGC Done
*
{code}
> Thread leak test failure with OpenJ9 JVM
>
>
> Key: ARTEMIS-2593
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2593
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Major
> Fix For: 2.11.0
>
>
> The test suite checks thread leak after each test, checking all the running
> threads at the end of the test and if any of the thread is not in the
> expected set, the test will fail.
> The expected set is a set of thread names that can be ignored when checking
> thread leak. With OpenJ9 JVM, the broker will cause a daemon thread called
> "MemoryMXBean" to be started by the VM. This thread is not controlled by the
> broker and should be put to the expected set. Otherwise tests will report
> false thread leak error.
> {code}
> LEAKING THREADS
> =
> Thread Thread[MemoryMXBean notification dispatcher,6,main] is still alive
> with the following stackTrace:
> jdk.management/com.ibm.lang.management.internal.MemoryNotificationThread.processNotificationLoop(Native
> Method)
> jdk.management/com.ibm.lang.management.internal.MemoryNotificationThread.run(MemoryNotificationThread.java:183)
> *
> [main] 01:01:21,829 INFO
> [org.apache.activemq.artemis.utils.ThreadLeakCheckRule] #test forceGC
> [main] 01:01:21,877 INFO
> [org.apache.activemq.artemis.utils.ThreadLeakCheckRule] #test forceGC Done
> *
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2593) Thread leak test failure with OpenJ9 JVM
Domenico Bruscino created ARTEMIS-2593:
--
Summary: Thread leak test failure with OpenJ9 JVM
Key: ARTEMIS-2593
URL: https://issues.apache.org/jira/browse/ARTEMIS-2593
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Domenico Bruscino
Fix For: 2.11.0
The test suite checks thread leak after each test, checking all the running
threads at the end of the test and if any of the thread is not in the expected
set, the test will fail.
The expected set is a set of thread names that can be ignored when checking
thread leak. With IBM jre, the broker will cause a daemon thread called
"MemoryMXBean" to be started by the VM. This thread is not controlled by the
broker and should be put to the expected set. Otherwise tests will report false
thread leak error.
{code}
LEAKING THREADS
=
Thread Thread[MemoryMXBean notification dispatcher,6,main] is still alive with
the following stackTrace:
com.ibm.lang.management.internal.MemoryNotificationThread.processNotificationLoop(Native
Method)
com.ibm.lang.management.internal.MemoryNotificationThread.run(MemoryNotificationThread.java:183)
*
[main] 18:10:19,675 INFO
[org.apache.activemq.artemis.utils.ThreadLeakCheckRule] #test forceGC
[main] 18:10:19,777 INFO
[org.apache.activemq.artemis.utils.ThreadLeakCheckRule] #test forceGC Done
*
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2585) Remove nested quotes from artemis.profile
Domenico Bruscino created ARTEMIS-2585:
--
Summary: Remove nested quotes from artemis.profile
Key: ARTEMIS-2585
URL: https://issues.apache.org/jira/browse/ARTEMIS-2585
Project: ActiveMQ Artemis
Issue Type: Improvement
Reporter: Domenico Bruscino
The JAVA_ARGS line in the generated artemis.profile contains nested quotes
around the hawtio.offline value:
{code}
JAVA_ARGS=" -XX:+PrintClassHistogram -XX:+UseG1GC -Xms512M -Xmx2G
-Dhawtio.realm=activemq -Dhawtio.offline="true" -Dhawtio.role=amq
-Dhawtio.rolePrincipalClasses=org.apache.activemq.artemis.spi.core.security.jaas.RolePrincipal
-Djolokia.policyLocation=${ARTEMIS_INSTANCE_ETC_URI}jolokia-access.xml
-Djon.id=amq"
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2579) [DOC] How to use custom logging handlers
Domenico Bruscino created ARTEMIS-2579: -- Summary: [DOC] How to use custom logging handlers Key: ARTEMIS-2579 URL: https://issues.apache.org/jira/browse/ARTEMIS-2579 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino Add the documentation to use custom logging handlers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2577) Thread leak test failure with IBM JRE
Domenico Bruscino created ARTEMIS-2577:
--
Summary: Thread leak test failure with IBM JRE
Key: ARTEMIS-2577
URL: https://issues.apache.org/jira/browse/ARTEMIS-2577
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Domenico Bruscino
The test suite checks thread leak after each test, checking all the running
threads at the end of the test and if any of the thread is not in the expected
set, the test will fail.
The expected set is a set of thread names that can be ignored when checking
thread leak. With IBM jre, the broker will cause a daemon thread called
"MemoryMXBean" to be started by the VM. This thread is not controlled by the
broker and should be put to the expected set. Otherwise tests will report false
thread leak error.
{code}
LEAKING THREADS
=
Thread Thread[MemoryMXBean notification dispatcher,6,main] is still alive with
the following stackTrace:
com.ibm.lang.management.internal.MemoryNotificationThread.processNotificationLoop(Native
Method)
com.ibm.lang.management.internal.MemoryNotificationThread.run(MemoryNotificationThread.java:183)
*
[main] 18:10:19,675 INFO
[org.apache.activemq.artemis.utils.ThreadLeakCheckRule] #test forceGC
[main] 18:10:19,777 INFO
[org.apache.activemq.artemis.utils.ThreadLeakCheckRule] #test forceGC Done
*
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2572) The retryMessages remove all paged messages
[ https://issues.apache.org/jira/browse/ARTEMIS-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2572: --- Summary: The retryMessages remove all paged messages (was: The retryMessages remove the paged messages without original annotations) > The retryMessages remove all paged messages > --- > > Key: ARTEMIS-2572 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2572 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Domenico Bruscino >Priority: Major > > The queue operation retryMessages remove the paged messages without the > original address and queue annotations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2572) The retryMessages remove the paged messages without original annotations
Domenico Bruscino created ARTEMIS-2572: -- Summary: The retryMessages remove the paged messages without original annotations Key: ARTEMIS-2572 URL: https://issues.apache.org/jira/browse/ARTEMIS-2572 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino The queue operation retryMessages remove the paged messages without the original address and queue annotations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2558) Add the commented out args to dump the java heap on OOME
Domenico Bruscino created ARTEMIS-2558: -- Summary: Add the commented out args to dump the java heap on OOME Key: ARTEMIS-2558 URL: https://issues.apache.org/jira/browse/ARTEMIS-2558 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino Would it be possible to add -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=... to the broker jvm args (as commented out). When a broker hits an out of memory exception, the heap dump is required to investigate. It would be useful to have it generated on the first occurrence rather than setting the arg and waiting for a second occurrence. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2538) Removing all messages from a huge queue causes OOM
[ https://issues.apache.org/jira/browse/ARTEMIS-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2538: --- Summary: Removing all messages from a huge queue causes OOM (was: Removing all messages from a huge queue cause OOM) > Removing all messages from a huge queue causes OOM > -- > > Key: ARTEMIS-2538 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2538 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Domenico Bruscino >Priority: Major > > On a queue that contains 4,000, 000 messages the JMX operation > "removeAllMessages()" eventually results in an OOM exception on the broker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2538) Removing all messages from a huge queue cause OOM
[ https://issues.apache.org/jira/browse/ARTEMIS-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2538: --- Description: On a queue that contains 4,000, 000 messages the JMX operation "removeAllMessages()" eventually results in an OOM exception on the broker. (was: n a queue that contains 4,000, 000 messages the JMX operation "removeAllMessages()" eventually results in an OOM exception on the broker.) > Removing all messages from a huge queue cause OOM > - > > Key: ARTEMIS-2538 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2538 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Domenico Bruscino >Priority: Major > > On a queue that contains 4,000, 000 messages the JMX operation > "removeAllMessages()" eventually results in an OOM exception on the broker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2538) Removing all messages from a huge queue cause OOM
Domenico Bruscino created ARTEMIS-2538: -- Summary: Removing all messages from a huge queue cause OOM Key: ARTEMIS-2538 URL: https://issues.apache.org/jira/browse/ARTEMIS-2538 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker Reporter: Domenico Bruscino n a queue that contains 4,000, 000 messages the JMX operation "removeAllMessages()" eventually results in an OOM exception on the broker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2534) Deleting addresses auto created on configuration reload
[ https://issues.apache.org/jira/browse/ARTEMIS-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2534: --- Summary: Deleting addresses auto created on configuration reload (was: Deleting addresses and queues auto created on configuration reload) > Deleting addresses auto created on configuration reload > --- > > Key: ARTEMIS-2534 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2534 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Domenico Bruscino >Priority: Major > > If the auto-created queues are associated with an auto-created address and > `config-delete-addresses=FORCE`, when the configuration file is reloaded they > are deleted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2534) Deleting addresses and queues auto created on configuration reload
Domenico Bruscino created ARTEMIS-2534: -- Summary: Deleting addresses and queues auto created on configuration reload Key: ARTEMIS-2534 URL: https://issues.apache.org/jira/browse/ARTEMIS-2534 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino If the auto-created queues are associated with an auto-created address and `config-delete-addresses=FORCE`, when the configuration file is reloaded they are deleted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2523) Deprecate the parameter failoverOnInitialConnection
Domenico Bruscino created ARTEMIS-2523: -- Summary: Deprecate the parameter failoverOnInitialConnection Key: ARTEMIS-2523 URL: https://issues.apache.org/jira/browse/ARTEMIS-2523 Project: ActiveMQ Artemis Issue Type: Task Reporter: Domenico Bruscino The parameter failoverOnInitialConnection wouldn't seem to be used and I can't understand the sense of this parameter because the failover will not occur if the client fails to make an initial connection to the live server ([https://activemq.apache.org/components/artemis/documentation/latest/ha.html#failing-over-on-the-initial-connection]). So I think the parameter could be deprecated from the API. The topic is discussed at [https://activemq.markmail.org/thread/ryf32vhjrwc4e7yf] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (ARTEMIS-2520) Consumer.receive return null if server is stopped
[
https://issues.apache.org/jira/browse/ARTEMIS-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino closed ARTEMIS-2520.
--
Resolution: Not A Bug
> Consumer.receive return null if server is stopped
> -
>
> Key: ARTEMIS-2520
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2520
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Minor
>
> ActiveMQMessageConsumer.receive(timeout) returns null, if the server is
> stopped during the call.
> Test to reproduce:
> {code:java}
> ConnectionFactory factorySend = new ActiveMQConnectionFactory();
> Connection connection = factorySend.createConnection();
> try (Session session = connection.createSession()) {
>javax.jms.Queue queue = session.createQueue("queueStop");
>MessageProducer producer = session.createProducer(queue);
>producer.send(session.createTextMessage("text"));
>connection.start();
>MessageConsumer consumer = session.createConsumer(queue);
>assertNotNull(consumer.receive(1000));
>final CountDownLatch stoppingLatch = new CountDownLatch(1);
>(new Thread(new Runnable() {
> @Override
> public void run() {
> try {
> stoppingLatch.countDown();
> Thread.sleep(1000);
> server.stop();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
>})).start();
>try {
> stoppingLatch.await();
> consumer.receive(5000);
> Assert.fail("didn't get expected exception!");
>} catch (Exception e) {
> e.printStackTrace();
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2520) Consumer.receive return null if server is stopped
[
https://issues.apache.org/jira/browse/ARTEMIS-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952660#comment-16952660
]
Domenico Bruscino commented on ARTEMIS-2520:
[~robbie] Thanks for your comments. I'm going to close the issue because I
agree with you _*the spec basically doesn't explicitly define exactly what
should occur*_ and changing the receive behavior could be a danger.
> Consumer.receive return null if server is stopped
> -
>
> Key: ARTEMIS-2520
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2520
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Minor
>
> ActiveMQMessageConsumer.receive(timeout) returns null, if the server is
> stopped during the call.
> Test to reproduce:
> {code:java}
> ConnectionFactory factorySend = new ActiveMQConnectionFactory();
> Connection connection = factorySend.createConnection();
> try (Session session = connection.createSession()) {
>javax.jms.Queue queue = session.createQueue("queueStop");
>MessageProducer producer = session.createProducer(queue);
>producer.send(session.createTextMessage("text"));
>connection.start();
>MessageConsumer consumer = session.createConsumer(queue);
>assertNotNull(consumer.receive(1000));
>final CountDownLatch stoppingLatch = new CountDownLatch(1);
>(new Thread(new Runnable() {
> @Override
> public void run() {
> try {
> stoppingLatch.countDown();
> Thread.sleep(1000);
> server.stop();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
>})).start();
>try {
> stoppingLatch.await();
> consumer.receive(5000);
> Assert.fail("didn't get expected exception!");
>} catch (Exception e) {
> e.printStackTrace();
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2520) Consumer.receive return null if server is stopped
[
https://issues.apache.org/jira/browse/ARTEMIS-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2520:
---
Issue Type: Improvement (was: Bug)
> Consumer.receive return null if server is stopped
> -
>
> Key: ARTEMIS-2520
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2520
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>
> ActiveMQMessageConsumer.receive(timeout) returns null, if the server is
> stopped during the call.
> Test to reproduce:
> {code:java}
> ConnectionFactory factorySend = new ActiveMQConnectionFactory();
> Connection connection = factorySend.createConnection();
> try (Session session = connection.createSession()) {
>javax.jms.Queue queue = session.createQueue("queueStop");
>MessageProducer producer = session.createProducer(queue);
>producer.send(session.createTextMessage("text"));
>connection.start();
>MessageConsumer consumer = session.createConsumer(queue);
>assertNotNull(consumer.receive(1000));
>final CountDownLatch stoppingLatch = new CountDownLatch(1);
>(new Thread(new Runnable() {
> @Override
> public void run() {
> try {
> stoppingLatch.countDown();
> Thread.sleep(1000);
> server.stop();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
>})).start();
>try {
> stoppingLatch.await();
> consumer.receive(5000);
> Assert.fail("didn't get expected exception!");
>} catch (Exception e) {
> e.printStackTrace();
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2520) Consumer.receive return null if server is stopped
[
https://issues.apache.org/jira/browse/ARTEMIS-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951037#comment-16951037
]
Domenico Bruscino commented on ARTEMIS-2520:
[~robbie] I see your point but {code:java}consumer.receive(5000);{code} throws
an exception when {code:java}ConnectionFactory factorySend = new
JmsConnectionFactory("amqp://localhost:61616");{code} or
{code:java}ConnectionFactory factorySend = new
org.apache.activemq.ActiveMQConnectionFactory("tcp://localhost:61616");{code}
What is the expected behavior?
> Consumer.receive return null if server is stopped
> -
>
> Key: ARTEMIS-2520
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2520
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Major
>
> ActiveMQMessageConsumer.receive(timeout) returns null, if the server is
> stopped during the call.
> Test to reproduce:
> {code:java}
> ConnectionFactory factorySend = new ActiveMQConnectionFactory();
> Connection connection = factorySend.createConnection();
> try (Session session = connection.createSession()) {
>javax.jms.Queue queue = session.createQueue("queueStop");
>MessageProducer producer = session.createProducer(queue);
>producer.send(session.createTextMessage("text"));
>connection.start();
>MessageConsumer consumer = session.createConsumer(queue);
>assertNotNull(consumer.receive(1000));
>final CountDownLatch stoppingLatch = new CountDownLatch(1);
>(new Thread(new Runnable() {
> @Override
> public void run() {
> try {
> stoppingLatch.countDown();
> Thread.sleep(1000);
> server.stop();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
>})).start();
>try {
> stoppingLatch.await();
> consumer.receive(5000);
> Assert.fail("didn't get expected exception!");
>} catch (Exception e) {
> e.printStackTrace();
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2520) Consumer.receive return null if server is stopped
Domenico Bruscino created ARTEMIS-2520:
--
Summary: Consumer.receive return null if server is stopped
Key: ARTEMIS-2520
URL: https://issues.apache.org/jira/browse/ARTEMIS-2520
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Domenico Bruscino
ActiveMQMessageConsumer.receive(timeout) returns null, if the server is stopped
during the call.
Test to reproduce:
{code:java}
ConnectionFactory factorySend = new ActiveMQConnectionFactory();
Connection connection = factorySend.createConnection();
try (Session session = connection.createSession()) {
javax.jms.Queue queue = session.createQueue("queueStop");
MessageProducer producer = session.createProducer(queue);
producer.send(session.createTextMessage("text"));
connection.start();
MessageConsumer consumer = session.createConsumer(queue);
assertNotNull(consumer.receive(1000));
final CountDownLatch stoppingLatch = new CountDownLatch(1);
(new Thread(new Runnable() {
@Override
public void run() {
try {
stoppingLatch.countDown();
Thread.sleep(1000);
server.stop();
} catch (Exception e) {
e.printStackTrace();
}
}
})).start();
try {
stoppingLatch.await();
consumer.receive(5000);
Assert.fail("didn't get expected exception!");
} catch (Exception e) {
e.printStackTrace();
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2512) Move the LocalMonitor tick log
[
https://issues.apache.org/jira/browse/ARTEMIS-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2512:
---
Summary: Move the LocalMonitor tick log (was: Split the LocalMonitor tick
log into its own logger)
> Move the LocalMonitor tick log
> --
>
> Key: ARTEMIS-2512
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2512
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Reporter: Domenico Bruscino
>Priority: Major
>
> Can we please move the logging below to its own logger. This is very useful
> logging to establish a "heartbeat" log statement (logging consistently every
> 5 seconds) when investigating potential CPU starvation or "pause" issues.
> {noformat}
> ...TRACE [org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl]
> Tick from store...
> {noformat}
> Right now, it is TRACE on the PagingManager logger. That includes other log
> statements that is too verbose to leave activated indefinitely in production.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2512) Split the LocalMonitor tick log into its own logger
Domenico Bruscino created ARTEMIS-2512:
--
Summary: Split the LocalMonitor tick log into its own logger
Key: ARTEMIS-2512
URL: https://issues.apache.org/jira/browse/ARTEMIS-2512
Project: ActiveMQ Artemis
Issue Type: Improvement
Components: Broker
Reporter: Domenico Bruscino
Can we please move the logging below to its own logger. This is very useful
logging to establish a "heartbeat" log statement (logging consistently every 5
seconds) when investigating potential CPU starvation or "pause" issues.
{noformat}
...TRACE [org.apache.activemq.artemis.core.paging.impl.PagingManagerImpl] Tick
from store...
{noformat}
Right now, it is TRACE on the PagingManager logger. That includes other log
statements that is too verbose to leave activated indefinitely in production.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2508) Crititical analyser trigger shutdown if removeAllMessages
[
https://issues.apache.org/jira/browse/ARTEMIS-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2508:
---
Summary: Crititical analyser trigger shutdown if removeAllMessages (was:
Crititical analyser trigger shutdown if removeAllMessages with a huge queue)
> Crititical analyser trigger shutdown if removeAllMessages
> -
>
> Key: ARTEMIS-2508
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2508
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Bruscino
>Priority: Major
>
> The crititical analyser trigger the broker shutdown if try to
> removeAllMessages with a huge queue.
> {code:java}
> WARN [org.apache.activemq.artemis.utils.critical.CriticalMeasure] Component
> org.apache.activemq.artemis.core.server.impl.QueueImpl is expired on path 3
> ERROR [org.apache.activemq.artemis.core.server] AMQ224079: The process for
> the virtual machine will be killed, as component QueueImpl[name=TEST,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=ba803379-cfa8-11e9-8c2b-0c4de9ce8296],
> temp=false]@3cf3f5cb is not responsive
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2508) Crititical analyser trigger shutdown if removeAllMessages with a huge queue
Domenico Bruscino created ARTEMIS-2508:
--
Summary: Crititical analyser trigger shutdown if removeAllMessages
with a huge queue
Key: ARTEMIS-2508
URL: https://issues.apache.org/jira/browse/ARTEMIS-2508
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Domenico Bruscino
The crititical analyser trigger the broker shutdown if try to removeAllMessages
with a huge queue.
{code:java}
WARN [org.apache.activemq.artemis.utils.critical.CriticalMeasure] Component
org.apache.activemq.artemis.core.server.impl.QueueImpl is expired on path 3
ERROR [org.apache.activemq.artemis.core.server] AMQ224079: The process for the
virtual machine will be killed, as component QueueImpl[name=TEST,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=ba803379-cfa8-11e9-8c2b-0c4de9ce8296],
temp=false]@3cf3f5cb is not responsive
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2503) Improve wildcards for the roles access match
[
https://issues.apache.org/jira/browse/ARTEMIS-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2503:
---
Summary: Improve wildcards for the roles access match (was: Improve the
use of wildcards in the key attribute of roles access )
> Improve wildcards for the roles access match
>
>
> Key: ARTEMIS-2503
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Domenico Bruscino
>Priority: Major
>
> Please improve wildcard support for the key element in the roles access
> element.
> ATM you can NOT apply a restriction across a set of queue instances starting
> with the same prefix (like below):
> {code:java}
>
>
>
>...
> {code}
> If queues are created dynamically and only a queue name "prefix" is known in
> advance; JMX RBAC cannot be used to restrict access in this case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2503) Improve the use of wildcards in the key attribute of roles access
Domenico Bruscino created ARTEMIS-2503:
--
Summary: Improve the use of wildcards in the key attribute of
roles access
Key: ARTEMIS-2503
URL: https://issues.apache.org/jira/browse/ARTEMIS-2503
Project: ActiveMQ Artemis
Issue Type: Improvement
Reporter: Domenico Bruscino
Please improve wildcard support for the key element in the roles access
element.
ATM you can NOT apply a restriction across a set of queue instances starting
with the same prefix (like below):
{code:java}
...
{code}
If queues are created dynamically and only a queue name "prefix" is known in
advance; JMX RBAC cannot be used to restrict access in this case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ARTEMIS-2415) JDBCJournal miss pending tasks during shutdown
Domenico Bruscino created ARTEMIS-2415: -- Summary: JDBCJournal miss pending tasks during shutdown Key: ARTEMIS-2415 URL: https://issues.apache.org/jira/browse/ARTEMIS-2415 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino Attachments: downstream_run_16.filtered_testRegularMessagePersistenceDelayedConsumer.log If server stops while having pending tasks in OperationContextImpl for JDBCJournal, server omits this tasks and prints a bunch of exceptions in the log, not exiting cleanly. Log of the situation from the test run is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2408) Too many opened FDs after server stops
Domenico Bruscino created ARTEMIS-2408: -- Summary: Too many opened FDs after server stops Key: ARTEMIS-2408 URL: https://issues.apache.org/jira/browse/ARTEMIS-2408 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Domenico Bruscino The number of opened FDs after stop the server on the testsuite is much higher than the number before the server is started, when default netty configuration is used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2394) Improve scheduling synchronization for AMQPConnectionContext
Domenico Bruscino created ARTEMIS-2394: -- Summary: Improve scheduling synchronization for AMQPConnectionContext Key: ARTEMIS-2394 URL: https://issues.apache.org/jira/browse/ARTEMIS-2394 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino Locks in connection stuff, artemis was built on the premise of being nonblocking. As time goes on more and more blocking locks are being added to core code paths. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2392) Enable remove on cancel policy for scheduled pool
Domenico Bruscino created ARTEMIS-2392: -- Summary: Enable remove on cancel policy for scheduled pool Key: ARTEMIS-2392 URL: https://issues.apache.org/jira/browse/ARTEMIS-2392 Project: ActiveMQ Artemis Issue Type: Improvement Components: Broker Affects Versions: 2.9.0 Reporter: Domenico Bruscino When a submitted task is cancelled before it is run, execution is suppressed. By default, such a cancelled task is not automatically removed from the work queue until its delay elapses. While this enables further inspection and monitoring, it may also cause unbounded retention of cancelled tasks. To avoid this, set remove on cancel policy to true, which causes tasks to be immediately removed from the work queue at time of cancellation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2385) Log header for rejecting message with too large header
Domenico Bruscino created ARTEMIS-2385: -- Summary: Log header for rejecting message with too large header Key: ARTEMIS-2385 URL: https://issues.apache.org/jira/browse/ARTEMIS-2385 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Domenico Bruscino The usage scenario I am thinking about; broker admins see many of these rejections but no way to trace it back to the application that is sending the offending message(s) to the broker. I have seen this scenario a few times, where broker admins had issues identifying which applications were responsible for these messages; so any data to help identify the offending message would be very useful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2359) Upgrade to Guava 24.1
[ https://issues.apache.org/jira/browse/ARTEMIS-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2359: --- Description: Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory allocation in the AtomicDoubleArray class (when serialized with Java serialization) and Compound Ordering class (when serialized with GWT serialization). An attacker could exploit applications that use Guava and deserialize untrusted data to cause a denial of service. Could you upgrade guava to version 24.1 or above? [https://github.com/google/guava/wiki/CVE-2018-10237] was: Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory allocation in the AtomicDoubleArray class (when serialized with Java serialization) and Compound Ordering class (when serialized with GWT serialization). An attacker could exploit applications that use Guava and deserialize untrusted data to cause a denial of service. Could you upgrade guava to version 24.1.1 or above? [https://github.com/google/guava/wiki/CVE-2018-10237] > Upgrade to Guava 24.1 > - > > Key: ARTEMIS-2359 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2359 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker >Affects Versions: 2.8.1 >Reporter: Domenico Bruscino >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory > allocation in the AtomicDoubleArray class (when serialized with Java > serialization) and Compound Ordering class (when serialized with GWT > serialization). An attacker could exploit applications that use Guava and > deserialize untrusted data to cause a denial of service. Could you upgrade > guava to version 24.1 > or above? > [https://github.com/google/guava/wiki/CVE-2018-10237] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2383) Upgrade to Guava 24.1.1
Domenico Bruscino created ARTEMIS-2383: -- Summary: Upgrade to Guava 24.1.1 Key: ARTEMIS-2383 URL: https://issues.apache.org/jira/browse/ARTEMIS-2383 Project: ActiveMQ Artemis Issue Type: Task Components: Broker Affects Versions: 2.9.0 Reporter: Domenico Bruscino -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2359) Upgrade to Guava 24.1
[ https://issues.apache.org/jira/browse/ARTEMIS-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2359: --- Summary: Upgrade to Guava 24.1 (was: Upgrade to Guava 24.1.1) > Upgrade to Guava 24.1 > - > > Key: ARTEMIS-2359 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2359 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker >Affects Versions: 2.8.1 >Reporter: Domenico Bruscino >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory > allocation in the AtomicDoubleArray class (when serialized with Java > serialization) and Compound Ordering class (when serialized with GWT > serialization). An attacker could exploit applications that use Guava and > deserialize untrusted data to cause a denial of service. Could you upgrade > guava to version 24.1.1 or above? > [https://github.com/google/guava/wiki/CVE-2018-10237] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2359) Upgrade to Guava 24.1
[ https://issues.apache.org/jira/browse/ARTEMIS-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2359: --- Description: Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory allocation in the AtomicDoubleArray class (when serialized with Java serialization) and Compound Ordering class (when serialized with GWT serialization). An attacker could exploit applications that use Guava and deserialize untrusted data to cause a denial of service. Could you upgrade guava to version 24.1.1 or above? [https://github.com/google/guava/wiki/CVE-2018-10237] was: Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory allocation in the AtomicDoubleArray class (when serialized with Java serialization) and Compound Ordering class (when serialized with GWT serialization). An attacker could exploit applications that use Guava and deserialize untrusted data to cause a denial of service. Could you upgrade guava to version 24.1 or above? [https://github.com/google/guava/wiki/CVE-2018-10237] > Upgrade to Guava 24.1 > - > > Key: ARTEMIS-2359 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2359 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker >Affects Versions: 2.8.1 >Reporter: Domenico Bruscino >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory > allocation in the AtomicDoubleArray class (when serialized with Java > serialization) and Compound Ordering class (when serialized with GWT > serialization). An attacker could exploit applications that use Guava and > deserialize untrusted data to cause a denial of service. Could you upgrade > guava to version 24.1.1 or above? > [https://github.com/google/guava/wiki/CVE-2018-10237] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2359) Upgrade to Guava 24.1.1
[ https://issues.apache.org/jira/browse/ARTEMIS-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Bruscino updated ARTEMIS-2359: --- Summary: Upgrade to Guava 24.1.1 (was: Upgrade to Guava 24.1) > Upgrade to Guava 24.1.1 > --- > > Key: ARTEMIS-2359 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2359 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker >Affects Versions: 2.8.1 >Reporter: Domenico Bruscino >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory > allocation in the AtomicDoubleArray class (when serialized with Java > serialization) and Compound Ordering class (when serialized with GWT > serialization). An attacker could exploit applications that use Guava and > deserialize untrusted data to cause a denial of service. Could you upgrade > guava to version 24.1.1 or above? > [https://github.com/google/guava/wiki/CVE-2018-10237] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2371) AMQP: message with very large header shuts broker down
Domenico Bruscino created ARTEMIS-2371:
--
Summary: AMQP: message with very large header shuts broker down
Key: ARTEMIS-2371
URL: https://issues.apache.org/jira/browse/ARTEMIS-2371
Project: ActiveMQ Artemis
Issue Type: Bug
Components: AMQP, Broker
Affects Versions: 2.9.0
Reporter: Domenico Bruscino
When there is one really large header sent with the message, the broker does
not have room for it and shuts down. Using an AMQP client send a message with
an extremely large header (>60 bytes) and broker default configuration this
will trigger the following exception:
{code:java}
[Thread-0
(ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$7@6bbe85a8)]
11:01:00,087 WARN [org.apache.activemq.artemis.core.server] AMQ222010:
Critical IO Error, shutting down the server.
file=AIOSequentialFile:/home/dbruscin/Workspace/activemq-artemis/tests/integration-tests/./target/tmp/junit9074908614954602801/journal0-L5672/activemq-data-1.amq,
message=Can't write records (size=2097454) bigger than the bufferSize(501760)
on the journal: java.lang.IllegalStateException: Can't write records
(size=2097454) bigger than the bufferSize(501760) on the journal
at
org.apache.activemq.artemis.core.io.buffer.TimedBuffer.checkSize(TimedBuffer.java:247)
[:]
at
org.apache.activemq.artemis.core.io.AbstractSequentialFile.fits(AbstractSequentialFile.java:180)
[:]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.switchFileIfNecessary(JournalImpl.java:3065)
[:]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.appendRecord(JournalImpl.java:2796)
[:]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl.access$100(JournalImpl.java:91)
[:]
at
org.apache.activemq.artemis.core.journal.impl.JournalImpl$1.run(JournalImpl.java:852)
[:]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
[:]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
[:]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
[:]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[rt.jar:1.8.0_212]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[rt.jar:1.8.0_212]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
[:]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARTEMIS-2359) Upgrade to Guava 24.1
Domenico Bruscino created ARTEMIS-2359: -- Summary: Upgrade to Guava 24.1 Key: ARTEMIS-2359 URL: https://issues.apache.org/jira/browse/ARTEMIS-2359 Project: ActiveMQ Artemis Issue Type: Task Components: Broker Affects Versions: 2.8.1 Reporter: Domenico Bruscino Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory allocation in the AtomicDoubleArray class (when serialized with Java serialization) and Compound Ordering class (when serialized with GWT serialization). An attacker could exploit applications that use Guava and deserialize untrusted data to cause a denial of service. Could you upgrade guava to version 24.1 or above? [https://github.com/google/guava/wiki/CVE-2018-10237] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (ARTEMIS-2344) [AMQP] Broker does not send security errors for unauthorized anonymous sasl
[
https://issues.apache.org/jira/browse/ARTEMIS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2344:
---
Comment: was deleted
(was: links to)
> [AMQP] Broker does not send security errors for unauthorized anonymous sasl
> ---
>
> Key: ARTEMIS-2344
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2344
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.9.0
>Reporter: Domenico Bruscino
>Priority: Major
>
> When user attempts unauthorized anonymous sasl, using AMQP protocol, the
> broker can return an internal error ("amqp:internal-error") instead of the
> security error ("amqp:unauthorized-access") that is expected in these cases.
>
> Source code to reproduce the issue using test
> testNoUserOrPasswordWithoutSaslRestrictions:
> https://github.com/brusdev/activemq-artemis/blob/amqp_security_error/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/JMSConnectionWithSecurityTest.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2344) [AMQP] Broker does not send security errors for unauthorized anonymous sasl
[
https://issues.apache.org/jira/browse/ARTEMIS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841941#comment-16841941
]
Domenico Bruscino commented on ARTEMIS-2344:
links to
> [AMQP] Broker does not send security errors for unauthorized anonymous sasl
> ---
>
> Key: ARTEMIS-2344
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2344
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.9.0
>Reporter: Domenico Bruscino
>Priority: Major
>
> When user attempts unauthorized anonymous sasl, using AMQP protocol, the
> broker can return an internal error ("amqp:internal-error") instead of the
> security error ("amqp:unauthorized-access") that is expected in these cases.
>
> Source code to reproduce the issue using test
> testNoUserOrPasswordWithoutSaslRestrictions:
> https://github.com/brusdev/activemq-artemis/blob/amqp_security_error/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/JMSConnectionWithSecurityTest.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2344) [AMQP] Broker does not send security errors for unauthorized anonymous sasl
[
https://issues.apache.org/jira/browse/ARTEMIS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2344:
---
External issue URL: (was:
https://github.com/apache/activemq-artemis/pull/2671)
> [AMQP] Broker does not send security errors for unauthorized anonymous sasl
> ---
>
> Key: ARTEMIS-2344
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2344
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.9.0
>Reporter: Domenico Bruscino
>Priority: Major
>
> When user attempts unauthorized anonymous sasl, using AMQP protocol, the
> broker can return an internal error ("amqp:internal-error") instead of the
> security error ("amqp:unauthorized-access") that is expected in these cases.
>
> Source code to reproduce the issue using test
> testNoUserOrPasswordWithoutSaslRestrictions:
> https://github.com/brusdev/activemq-artemis/blob/amqp_security_error/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/JMSConnectionWithSecurityTest.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2344) [AMQP] Broker does not send security errors for unauthorized anonymous sasl
[
https://issues.apache.org/jira/browse/ARTEMIS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Domenico Bruscino updated ARTEMIS-2344:
---
External issue URL: https://github.com/apache/activemq-artemis/pull/2671
> [AMQP] Broker does not send security errors for unauthorized anonymous sasl
> ---
>
> Key: ARTEMIS-2344
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2344
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.9.0
>Reporter: Domenico Bruscino
>Priority: Major
>
> When user attempts unauthorized anonymous sasl, using AMQP protocol, the
> broker can return an internal error ("amqp:internal-error") instead of the
> security error ("amqp:unauthorized-access") that is expected in these cases.
>
> Source code to reproduce the issue using test
> testNoUserOrPasswordWithoutSaslRestrictions:
> https://github.com/brusdev/activemq-artemis/blob/amqp_security_error/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/JMSConnectionWithSecurityTest.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARTEMIS-2344) [AMQP] Broker does not send security errors for unauthorized anonymous sasl
Domenico Bruscino created ARTEMIS-2344:
--
Summary: [AMQP] Broker does not send security errors for
unauthorized anonymous sasl
Key: ARTEMIS-2344
URL: https://issues.apache.org/jira/browse/ARTEMIS-2344
Project: ActiveMQ Artemis
Issue Type: Bug
Components: AMQP
Affects Versions: 2.9.0
Reporter: Domenico Bruscino
When user attempts unauthorized anonymous sasl, using AMQP protocol, the broker
can return an internal error ("amqp:internal-error") instead of the security
error ("amqp:unauthorized-access") that is expected in these cases.
Source code to reproduce the issue using test
testNoUserOrPasswordWithoutSaslRestrictions:
https://github.com/brusdev/activemq-artemis/blob/amqp_security_error/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/JMSConnectionWithSecurityTest.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
