[jira] [Updated] (ARTEMIS-4522) Slow-Consumer-Handling may get delayed significantly on occupied pool
[ https://issues.apache.org/jira/browse/ARTEMIS-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-4522: --- Description: Slack discussion with [~jbertram] see here: [https://the-asf.slack.com/archives/CFL910J30/p1699520764243169] h2. Initial Description consumers-window-size set to 0 and there some queues, that are heavily used and have consumers attached, that allow for a concurrency of 500 messages (larger than thread-pool-client-size). After some time - unclear what triggers it - the behavior becomes bad in the way that from those queues only 1-5 messages are fetched and immediately processed, but then there is a pause of 10 seconds before the next 1-5 messages are fetched. This continues. In the thread-dumps, several like the following can be seen: {noformat} "Thread-0 (ActiveMQ-client-global-threads)" #640 daemon prio=5 os_prio=0 cpu=899719.36ms elapsed=354425.44s tid=0x7f904c02e850 nid=0x150d29 runnable [0x7f8fdbae5000] java.lang.Thread.State: TIMED_WAITING (parking) at jdk.internal.misc.Unsafe.park(java.base@17.0.5/Native Method) - parking to wait for <0x0003f6c9d1d0> (a org.apache.activemq.artemis.utils.AbstractLatch$CountSync) at java.util.concurrent.locks.LockSupport.parkNanos(java.base@17.0.5/LockSupport.java:252) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.5/AbstractQueuedSynchronizer.java:717) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base@17.0.5/AbstractQueuedSynchronizer.java:1074) at org.apache.activemq.artemis.utils.AbstractLatch.await(AbstractLatch.java:115) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.startSlowConsumer(ClientConsumerImpl.java:869) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1025) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) 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:65) at org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$2008/0x0007ce20c000.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.5/ThreadPoolExecutor.java:1136) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.5/ThreadPoolExecutor.java:635) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) {noformat} which corresponds to code location with a 10 seconds sleep here: [https://github.com/apache/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientConsumerImpl.java#L854|https://github.com/seeburger-ag/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientConsumerImpl.java#L854] It seems it always needs to wait until the 10 seconds are reached, which is unexpected, since the latch should count-down before, after having sent the credit to the server. We could assume some bug, that maybe increments the latch, but misses to decrement, so it is not able to reach 0 ever again, but that's speculative. h2. Evaluation See slack for details, it boils down to the thread-pool in use being out of free threads, so the slow-consumer-handling is not able to run in good time. Affected versions: all since at least 2.22.0 up to current - probably since "ever", involved code derives from HornetQ. h2. Possible Solutions We experimented a bit and found a solution for us - or actually 2 variants. * No. 1 just uses an own single-threaded executor for flow-control, whose only job is to guarantee the credit was sent before continuing with other operations when starting/resetting slow-consumers. This looks simple and works perfectly in the test-case as well as in the real product in stress-tests [https://github.com/seeburger-ag/activemq-artemis/commit/5b94560fc55fabcc15f138fbec6b2f855508cc7e] * No. 2 has a similar idea, but goes the full way of adding an own thread-pool for flow-control and adding it like the others. This is more fitting into the style of the existing thread-pools and allows its configuration. [https://github.com/seeburger-ag/activemq-artemis/commit/b4d558c5fc90f3a442391ebcf4976e8d6ec7adb0] and [~jbertram] said: {quote}I think either one would be fine. Create a Jira and send a PR. {quote} So here is the Jira and I will push No. 2 as a pull-request: https://github.com/apache/activemq-artemis/pull/4699 was: Slack discussion with [~jbertram] see here: [http
[jira] [Updated] (ARTEMIS-4522) Slow-Consumer-Handling may get delayed significantly on occupied pool
[ https://issues.apache.org/jira/browse/ARTEMIS-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-4522: --- Description: Slack discussion with [~jbertram] see here: [https://the-asf.slack.com/archives/CFL910J30/p1699520764243169] h2. Initial Description consumers-window-size set to 0 and there some queues, that are heavily used and have consumers attached, that allow for a concurrency of 500 messages (larger than thread-pool-client-size). After some time - unclear what triggers it - the behavior becomes bad in the way that from those queues only 1-5 messages are fetched and immediately processed, but then there is a pause of 10 seconds before the next 1-5 messages are fetched. This continues. In the thread-dumps, several like the following can be seen: {noformat} "Thread-0 (ActiveMQ-client-global-threads)" #640 daemon prio=5 os_prio=0 cpu=899719.36ms elapsed=354425.44s tid=0x7f904c02e850 nid=0x150d29 runnable [0x7f8fdbae5000] java.lang.Thread.State: TIMED_WAITING (parking) at jdk.internal.misc.Unsafe.park(java.base@17.0.5/Native Method) - parking to wait for <0x0003f6c9d1d0> (a org.apache.activemq.artemis.utils.AbstractLatch$CountSync) at java.util.concurrent.locks.LockSupport.parkNanos(java.base@17.0.5/LockSupport.java:252) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.5/AbstractQueuedSynchronizer.java:717) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base@17.0.5/AbstractQueuedSynchronizer.java:1074) at org.apache.activemq.artemis.utils.AbstractLatch.await(AbstractLatch.java:115) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.startSlowConsumer(ClientConsumerImpl.java:869) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1025) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) 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:65) at org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$2008/0x0007ce20c000.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.5/ThreadPoolExecutor.java:1136) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.5/ThreadPoolExecutor.java:635) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) {noformat} which corresponds to code location with a 10 seconds sleep here: [https://github.com/seeburger-ag/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientConsumerImpl.java#L854] It seems it always needs to wait until the 10 seconds are reached, which is unexpected, since the latch should count-down before, after having sent the credit to the server. We could assume some bug, that maybe increments the latch, but misses to decrement, so it is not able to reach 0 ever again, but that's speculative. h2. Evaluation See slack for details, it boils down to the thread-pool in use being out of free threads, so the slow-consumer-handling is not able to run in good time. Affected versions: all since at least 2.22.0 up to current - probably since "ever", involved code derives from HornetQ. h2. Possible Solutions We experimented a bit and found a solution for us - or actually 2 variants. * No. 1 just uses an own single-threaded executor for flow-control, whose only job is to guarantee the credit was sent before continuing with other operations when starting/resetting slow-consumers. This looks simple and works perfectly in the test-case as well as in the real product in stress-tests [https://github.com/seeburger-ag/activemq-artemis/commit/5b94560fc55fabcc15f138fbec6b2f855508cc7e] * No. 2 has a similar idea, but goes the full way of adding an own thread-pool for flow-control and adding it like the others. This is more fitting into the style of the existing thread-pools and allows its configuration. [https://github.com/seeburger-ag/activemq-artemis/commit/b4d558c5fc90f3a442391ebcf4976e8d6ec7adb0] and [~jbertram] said: {quote}I think either one would be fine. Create a Jira and send a PR. {quote} So here is the Jira and I will push No. 2 as a pull-request and update here. was: Slack discussion with [~jbertram] see here: [https://the-asf.slack.com/archives/CFL910J30/p1699520764243169] h2. Initial Description consumers-window-size set to 0 and there some queues, that are heavily used and have consumers attached, that all
[jira] [Updated] (ARTEMIS-4522) Slow-Consumer-Handling may get delayed significantly on occupied pool
[ https://issues.apache.org/jira/browse/ARTEMIS-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-4522: --- Description: Slack discussion with [~jbertram] see here: [https://the-asf.slack.com/archives/CFL910J30/p1699520764243169] h2. Initial Description consumers-window-size set to 0 and there some queues, that are heavily used and have consumers attached, that allow for a concurrency of 500 messages (larger than thread-pool-client-size). After some time - unclear what triggers it - the behavior becomes bad in the way that from those queues only 1-5 messages are fetched and immediately processed, but then there is a pause of 10 seconds before the next 1-5 messages are fetched. This continues. In the thread-dumps, several like the following can be seen: {noformat} "Thread-0 (ActiveMQ-client-global-threads)" #640 daemon prio=5 os_prio=0 cpu=899719.36ms elapsed=354425.44s tid=0x7f904c02e850 nid=0x150d29 runnable [0x7f8fdbae5000] java.lang.Thread.State: TIMED_WAITING (parking) at jdk.internal.misc.Unsafe.park(java.base@17.0.5/Native Method) - parking to wait for <0x0003f6c9d1d0> (a org.apache.activemq.artemis.utils.AbstractLatch$CountSync) at java.util.concurrent.locks.LockSupport.parkNanos(java.base@17.0.5/LockSupport.java:252) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.5/AbstractQueuedSynchronizer.java:717) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base@17.0.5/AbstractQueuedSynchronizer.java:1074) at org.apache.activemq.artemis.utils.AbstractLatch.await(AbstractLatch.java:115) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.startSlowConsumer(ClientConsumerImpl.java:869) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1025) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) 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:65) at org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$2008/0x0007ce20c000.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.5/ThreadPoolExecutor.java:1136) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.5/ThreadPoolExecutor.java:635) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) {noformat} which corresponds to code location with a 10 seconds sleep here: [https://github.com/apache/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientConsumerImpl.java#L854|https://github.com/seeburger-ag/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientConsumerImpl.java#L854] It seems it always needs to wait until the 10 seconds are reached, which is unexpected, since the latch should count-down before, after having sent the credit to the server. We could assume some bug, that maybe increments the latch, but misses to decrement, so it is not able to reach 0 ever again, but that's speculative. h2. Evaluation See slack for details, it boils down to the thread-pool in use being out of free threads, so the slow-consumer-handling is not able to run in good time. Affected versions: all since at least 2.22.0 up to current - probably since "ever", involved code derives from HornetQ. h2. Possible Solutions We experimented a bit and found a solution for us - or actually 2 variants. * No. 1 just uses an own single-threaded executor for flow-control, whose only job is to guarantee the credit was sent before continuing with other operations when starting/resetting slow-consumers. This looks simple and works perfectly in the test-case as well as in the real product in stress-tests [https://github.com/seeburger-ag/activemq-artemis/commit/5b94560fc55fabcc15f138fbec6b2f855508cc7e] * No. 2 has a similar idea, but goes the full way of adding an own thread-pool for flow-control and adding it like the others. This is more fitting into the style of the existing thread-pools and allows its configuration. [https://github.com/seeburger-ag/activemq-artemis/commit/b4d558c5fc90f3a442391ebcf4976e8d6ec7adb0] and [~jbertram] said: {quote}I think either one would be fine. Create a Jira and send a PR. {quote} So here is the Jira and I will push No. 2 as a pull-request and update here. was: Slack discussion with [~jbertram] see here: [https://the-asf.slack.com/archives/CFL910J
[jira] [Created] (ARTEMIS-4522) Slow-Consumer-Handling may get delayed significantly on occupied pool
Rico Neubauer created ARTEMIS-4522: -- Summary: Slow-Consumer-Handling may get delayed significantly on occupied pool Key: ARTEMIS-4522 URL: https://issues.apache.org/jira/browse/ARTEMIS-4522 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Rico Neubauer Slack discussion with [~jbertram] see here: [https://the-asf.slack.com/archives/CFL910J30/p1699520764243169] h2. Initial Description consumers-window-size set to 0 and there some queues, that are heavily used and have consumers attached, that allow for a concurrency of 500 messages. After some time - unclear what triggers it - the behavior becomes bad in the way that from those queues only 1-5 orders are fetched and immediately processed, but then there is a pause of 10 seconds before the next 1-5 orders are fetched. This continues. In the thread-dumps, several like the following can be seen: {noformat} "Thread-0 (ActiveMQ-client-global-threads)" #640 daemon prio=5 os_prio=0 cpu=899719.36ms elapsed=354425.44s tid=0x7f904c02e850 nid=0x150d29 runnable [0x7f8fdbae5000] java.lang.Thread.State: TIMED_WAITING (parking) at jdk.internal.misc.Unsafe.park(java.base@17.0.5/Native Method) - parking to wait for <0x0003f6c9d1d0> (a org.apache.activemq.artemis.utils.AbstractLatch$CountSync) at java.util.concurrent.locks.LockSupport.parkNanos(java.base@17.0.5/LockSupport.java:252) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@17.0.5/AbstractQueuedSynchronizer.java:717) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base@17.0.5/AbstractQueuedSynchronizer.java:1074) at org.apache.activemq.artemis.utils.AbstractLatch.await(AbstractLatch.java:115) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.startSlowConsumer(ClientConsumerImpl.java:869) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1025) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) 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:65) at org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$2008/0x0007ce20c000.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.5/ThreadPoolExecutor.java:1136) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.5/ThreadPoolExecutor.java:635) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) {noformat} which corresponds to code location with a 10 seconds sleep here: [https://github.com/seeburger-ag/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientConsumerImpl.java#L854] It seems it always needs to wait until the 10 seconds are reached, which is unexpected, since the latch should count-down before, after having sent the credit to the server. We could assume some bug, that maybe increments the latch, but misses to decrement, so it is not able to reach 0 ever again, but that's speculative. h2. Evaluation See slack for details, it boils down to the thread-pool in use being out of free threads, so the slow-consumer-handling is not able to run in good time. Affected versions: all since at least 2.22.0 up to current - probably since "ever", involved code derives from HornetQ. h2. Possible Solutions We experimented a bit and found a solution for us - or actually 2 variants. * No. 1 just uses an own single-threaded executor for flow-control, whose only job is to guarantee the credit was sent before continuing with other operations when starting/resetting slow-consumers. This looks simple and works perfectly in the test-case as well as in the real product in stress-tests [https://github.com/seeburger-ag/activemq-artemis/commit/5b94560fc55fabcc15f138fbec6b2f855508cc7e] * No. 2 has a similar idea, but goes the full way of adding an own thread-pool for flow-control and adding it like the others. This is more fitting into the style of the existing thread-pools and allows its configuration. [https://github.com/seeburger-ag/activemq-artemis/commit/b4d558c5fc90f3a442391ebcf4976e8d6ec7adb0] and [~jbertram] said: {quote}I think either one would be fine. Create a Jira and send a PR. {quote} So here is the Jira and I will push No. 2 as a pull-request and update here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3922) Reducing contention on java.lang.Throwable#getOurStackTrace
[ https://issues.apache.org/jira/browse/ARTEMIS-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17575618#comment-17575618 ] Rico Neubauer commented on ARTEMIS-3922: PR https://github.com/apache/activemq-artemis/pull/4168 > Reducing contention on java.lang.Throwable#getOurStackTrace > --- > > Key: ARTEMIS-3922 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3922 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.24.0 >Reporter: Rico Neubauer >Priority: Major > Attachments: threads.txt > > Time Spent: 10m > Remaining Estimate: 0h > > This is a request for improvement rg. performance in a very specific case, > but easy to accomplish. > h2. Scenario > On certain contaier'ed Windows machines we have identified that > {{java.lang.Throwable#getOurStackTrace}} along with > {{java.lang.StackTraceElement#initStackTraceElements}} show up as a very > expensive operations. The reason behind this is still unclear, but since the > {{#getOurStackTrace}} is synchronized, it suffers even more when the native > method {{#initStackTraceElements}} takes an unexpected long time. > This shows in thread-dumps in 2 locations for Artemis, where > connection-creation is the more crucial one from my pov. > See attached threads.txt > h2. Remedy > Fortunately the location where this gets used via > {{Thread.currentThread().getStackTrace()}} is simple to replace, since the > information needed could just get passed by caller. > Please see attached patch for my proposal. > Also available [here as > commit|https://github.com/seeburger-ag/activemq-artemis/commit/7396b9356256706a886f35da3a27274084e5a973]. > Can create a pull request as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARTEMIS-3922) Reducing contention on java.lang.Throwable#getOurStackTrace
Rico Neubauer created ARTEMIS-3922: -- Summary: Reducing contention on java.lang.Throwable#getOurStackTrace Key: ARTEMIS-3922 URL: https://issues.apache.org/jira/browse/ARTEMIS-3922 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.24.0 Reporter: Rico Neubauer Attachments: threads.txt This is a request for improvement rg. performance in a very specific case, but easy to accomplish. h2. Scenario On certain contaier'ed Windows machines we have identified that {{java.lang.Throwable#getOurStackTrace}} along with {{java.lang.StackTraceElement#initStackTraceElements}} show up as a very expensive operations. The reason behind this is still unclear, but since the {{#getOurStackTrace}} is synchronized, it suffers even more when the native method {{#initStackTraceElements}} takes an unexpected long time. This shows in thread-dumps in 2 locations for Artemis, where connection-creation is the more crucial one from my pov. See attached threads.txt h2. Remedy Fortunately the location where this gets used via {{Thread.currentThread().getStackTrace()}} is simple to replace, since the information needed could just get passed by caller. Please see attached patch for my proposal. Also available [here as commit|https://github.com/seeburger-ag/activemq-artemis/commit/7396b9356256706a886f35da3a27274084e5a973]. Can create a pull request as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3583) Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause spurious AMQ224013 warnings to be emitted.
[ https://issues.apache.org/jira/browse/ARTEMIS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477232#comment-17477232 ] Rico Neubauer commented on ARTEMIS-3583: Sporadically getting error below, which to me seems related to this issue: {code:java} ERROR org.apache.activemq.artemis.core.server (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@69242555) [org.apache.activemq.artemis-server-osgi:2.20.0] AMQ224013: failed to expire messages for queue java.util.concurrent.TimeoutException: queueName at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl$ExpiryReaper.run(PostOfficeImpl.java:1861) ~[?:?] at org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.runForExecutor(ActiveMQScheduledComponent.java:313) ~[?:?] at org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.lambda$bookedRunForScheduler$2(ActiveMQScheduledComponent.java:320) ~[?:?] 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:65) ~[?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?] at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) ~[?:?]{code} ´´ > Race condition in QueueImpl#expireReferences(java.lang.Runnable) can cause > spurious AMQ224013 warnings to be emitted. > - > > Key: ARTEMIS-3583 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3583 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.18.0 > Environment: Large-core machines running embedded ActiveMQ broker. >Reporter: Anders Wallgren >Priority: Major > > A recent change - [https://github.com/apache/activemq-artemis/pull/3654] - > appears to introduce a race condition in QueueImpl#expireReferences(Runnable) > that can cause the Runnable "done" parameter to never be invoked. This > manifests itself as spurious "AMQ224013: failed to expire messages for queue" > messages. > The problem is this section of code and the non-atomic test-and-set on the > expiryScanner.scannerRunning AtomicInteger: > {code:java} > if (!queueDestroyed && expiryScanner.scannerRunning.get() == 0) { <--- "test" > if (expiryScanner.scannerRunning.incrementAndGet() == 1) { <--- "and-set" > expiryScanner.doneCallback = done; > } > getExecutor().execute(expiryScanner); > } else { > // expire is already happening on this queue, move on! > if (done != null) { > done.run(); > } > {code} > Consider the following sequence of events and see if you agree with my > analysis: > # Two threads, t1 and t2 > # t1 runs PostOfficeImpl.ExpiryReaper which calls > QueueImpl.expireReferences(latch::countDown) to drop a latch when expiration > is "done". It waits 10 seconds for the latch to drop. If the latch doesn't > drop within the timeout it issues a AMQ224013 warning. > # t2 calls QueueImpl.depage which calls QueueImpl.expireReferences(), which > in turn calls QueueImpl.expireReferences(null) > # t1 and t2 both see that expiryScanner.scannerRunning.get() == 0 so they > both enter that branch. <--- This is where things start to go wrong, as only > one of the two threads will successfully set expiryScanner.done; if the > thread that "loses" is the one that supplies a non-null "done" parameter then > that Runnable will never be invoked. > # t2 successfully increments expiryScanner.scannerRunning to 1 and sets > expiryScanner.doneCallback = null (since it passed null as the "done" > parameter) and then continues to run expiryScanner. > # t1 doesn't increment expiryScanner.scannerRunning and at this point the > "done" argument is lost and will never be invoked, guaranteeing the AMQ224013 > warning. t1 then also runs the expiryScanner (which has already been > submitted once by t2) > Because of the non-atomic test-and-set, the callback is not guaranteed to be > invoked and, also, more than one expiry run will execute simultaneously (this > seems to be undesirable based on why this change was made in the first place). > Should the code not be something like this (I'm not 100% familiar with the > semantics of scannerRunning being > 1, so this may not be the correct > solution): > > {code:java} > if (!queueDestroyed && expiryScanner.scannerRunning.compareAndSet(0,
[jira] [Commented] (ARTEMIS-2293) addPacket method in the org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl doesn't notify threads in case of an Exception
[ https://issues.apache.org/jira/browse/ARTEMIS-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17437582#comment-17437582 ] Rico Neubauer commented on ARTEMIS-2293: Thanks for reopening. Artemis 2.19.0 Experienced the same situation and will provide small patch to provoke the sit[^13035609_ARTEMIS-2293-Test.patch]uation (see below - including the #notifyAll already). An error on #addPacket results in the #waitCompletion method waiting until call–timeout (default=30 sec). Having several threads in this situation then leads to all of them waiting until timeout. Furthermore, it seems that at least while large messages are produced in parallel, this also has an impact on other client-consumers, that are not fed anymore - however this I could not reproduce reliable, so no hard evidence for that. My proposal is like [~pmolchanov2002] also suggested to add the #notifyAll in the exceptional case. > addPacket method in the > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl > doesn't notify threads in case of an Exception > --- > > Key: ARTEMIS-2293 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2293 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.19.0 >Reporter: Pavel Molchanov >Priority: Major > Fix For: 2.20.0 > > Attachments: 13035609_ARTEMIS-2293-Test.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Block that handles exceptions in the catch(Exception e) doesn't call > notifyAll(). That cause that other working threads are not released in the > waitCompletion method. > [https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/LargeMessageControllerImpl.java] > > addPacket method: > {code:java} > public void addPacket(byte[] chunk, int flowControlSize, boolean isContinues) > { > int flowControlCredit = 0; > > synchronized (this) { > packetAdded = true; > if (outStream != null) { > try { > if (!isContinues) { > streamEnded = true; > } > > if (fileCache != null) { > fileCache.cachePackage(chunk); > } > > outStream.write(chunk); > > flowControlCredit = flowControlSize; > > notifyAll(); > > if (streamEnded) { > outStream.close(); > } > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } else { > if (fileCache != null) { > try { > fileCache.cachePackage(chunk); > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } > > largeMessageData.offer(new LargeData(chunk, flowControlSize, > isContinues)); > } > }{code} > > waitCompletion method: > {code:java} > public synchronized boolean waitCompletion(final long timeWait) throws > ActiveMQException { > if (outStream == null) { > // There is no stream.. it will never achieve the end of streaming > return false; > } > > long timeOut; > > // If timeWait = 0, we will use the readTimeout > // And we will check if no packets have arrived within readTimeout > milliseconds > if (timeWait != 0) { > timeOut = System.currentTimeMillis() + timeWait; > } else { > timeOut = System.currentTimeMillis() + readTimeout; > } > > while (!streamEnded && handledException == null) { > try { > this.wait(timeWait == 0 ? readTimeout : timeWait); > } catch (InterruptedException e) { > throw new ActiveMQInterruptedException(e); > } > > if (!streamEnded && handledException == null) { > if (timeWait != 0 && System.currentTimeMillis() > timeOut) { > throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); > } else if (System.currentTimeMillis() > timeOut && !packetAdded) { > throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); > } > } > } > > checkException(); > > return streamEnded; > > }{code} > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2293) addPacket method in the org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl doesn't notify threads in case of an Exception
[ https://issues.apache.org/jira/browse/ARTEMIS-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2293: --- Attachment: 13035609_ARTEMIS-2293-Test.patch > addPacket method in the > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl > doesn't notify threads in case of an Exception > --- > > Key: ARTEMIS-2293 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2293 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.19.0 >Reporter: Pavel Molchanov >Priority: Major > Fix For: 2.20.0 > > Attachments: 13035609_ARTEMIS-2293-Test.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Block that handles exceptions in the catch(Exception e) doesn't call > notifyAll(). That cause that other working threads are not released in the > waitCompletion method. > [https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/LargeMessageControllerImpl.java] > > addPacket method: > {code:java} > public void addPacket(byte[] chunk, int flowControlSize, boolean isContinues) > { > int flowControlCredit = 0; > > synchronized (this) { > packetAdded = true; > if (outStream != null) { > try { > if (!isContinues) { > streamEnded = true; > } > > if (fileCache != null) { > fileCache.cachePackage(chunk); > } > > outStream.write(chunk); > > flowControlCredit = flowControlSize; > > notifyAll(); > > if (streamEnded) { > outStream.close(); > } > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } else { > if (fileCache != null) { > try { > fileCache.cachePackage(chunk); > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } > > largeMessageData.offer(new LargeData(chunk, flowControlSize, > isContinues)); > } > }{code} > > waitCompletion method: > {code:java} > public synchronized boolean waitCompletion(final long timeWait) throws > ActiveMQException { > if (outStream == null) { > // There is no stream.. it will never achieve the end of streaming > return false; > } > > long timeOut; > > // If timeWait = 0, we will use the readTimeout > // And we will check if no packets have arrived within readTimeout > milliseconds > if (timeWait != 0) { > timeOut = System.currentTimeMillis() + timeWait; > } else { > timeOut = System.currentTimeMillis() + readTimeout; > } > > while (!streamEnded && handledException == null) { > try { > this.wait(timeWait == 0 ? readTimeout : timeWait); > } catch (InterruptedException e) { > throw new ActiveMQInterruptedException(e); > } > > if (!streamEnded && handledException == null) { > if (timeWait != 0 && System.currentTimeMillis() > timeOut) { > throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); > } else if (System.currentTimeMillis() > timeOut && !packetAdded) { > throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); > } > } > } > > checkException(); > > return streamEnded; > > }{code} > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3551) CLONE - addPacket method in the org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl doesn't notify threads in case of an Exception
[ https://issues.apache.org/jira/browse/ARTEMIS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17437581#comment-17437581 ] Rico Neubauer commented on ARTEMIS-3551: [~jbertram] had no rights to reopen it - thanks for tackling it. > CLONE - addPacket method in the > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl > doesn't notify threads in case of an Exception > --- > > Key: ARTEMIS-3551 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3551 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.4 >Reporter: Rico Neubauer >Priority: Major > Attachments: ARTEMIS-2293-Test.patch > > > Hi, kindly asking to re-look into this issue. > Artemis 2.19.0 > Experienced the same situation and will provide small patch to provoke the > situation (see below - including the #notifyAll already). > An error on #addPacket results in the #waitCompletion method waiting until > call–timeout (default=30 sec). Having several threads in this situation then > leads to all of them waiting until timeout. > Furthermore, it seems that at least while large messages are produced in > parallel, this also has an impact on other client-consumers, that are not fed > anymore - however this I could not reproduce reliable, so no hard evidence > for that. > My proposal is like [~pmolchanov2002] also suggested to add the #notifyAll in > the exceptional case. > > [^ARTEMIS-2293-Test.patch] > > Following is the original description: > > Block that handles exceptions in the catch(Exception e) doesn't call > notifyAll(). That cause that other working threads are not released in the > waitCompletion method. > [https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/LargeMessageControllerImpl.java] > > addPacket method: > {code:java} > public void addPacket(byte[] chunk, int flowControlSize, boolean isContinues) > { > int flowControlCredit = 0; > > synchronized (this) { > packetAdded = true; > if (outStream != null) { > try { > if (!isContinues) { > streamEnded = true; > } > > if (fileCache != null) { > fileCache.cachePackage(chunk); > } > > outStream.write(chunk); > > flowControlCredit = flowControlSize; > > notifyAll(); > > if (streamEnded) { > outStream.close(); > } > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } else { > if (fileCache != null) { > try { > fileCache.cachePackage(chunk); > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } > > largeMessageData.offer(new LargeData(chunk, flowControlSize, > isContinues)); > } > }{code} > > waitCompletion method: > {code:java} > public synchronized boolean waitCompletion(final long timeWait) throws > ActiveMQException { > if (outStream == null) { > // There is no stream.. it will never achieve the end of streaming > return false; > } > > long timeOut; > > // If timeWait = 0, we will use the readTimeout > // And we will check if no packets have arrived within readTimeout > milliseconds > if (timeWait != 0) { > timeOut = System.currentTimeMillis() + timeWait; > } else { > timeOut = System.currentTimeMillis() + readTimeout; > } > > while (!streamEnded && handledException == null) { > try { > this.wait(timeWait == 0 ? readTimeout : timeWait); > } catch (InterruptedException e) { > throw new ActiveMQInterruptedException(e); > } > > if (!streamEnded && handledException == null) { > if (timeWait != 0 && System.currentTimeMillis() > timeOut) { > throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); > } else if (System.currentTimeMillis() > timeOut && !packetAdded) { > throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); > } > } > } > > checkException(); > > return streamEnded; > > }{code} > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (ARTEMIS-3551) CLONE - addPacket method in the org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl doesn't notify threads in case of an Exception
[ https://issues.apache.org/jira/browse/ARTEMIS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-3551: --- Comment: was deleted (was: Hi, kindly asking to re-look into this issue. Artemis 2.19.0 Experienced the same situation and will provide small patch to provoke the situation (see below - including the #notifyAll already). An error on #addPacket results in the #waitCompletion method waiting until call–timeout (default=30 sec). Having several threads in this situation then leads to all of them waiting until timeout. Furthermore, it seems that at least while large messages are produced in parallel, this also has an impact on other client-consumers, that are not fed anymore - however this I could not reproduce reliable, so no hard evidence for that. My proposal is like [~pmolchanov2002] also suggested to add the #notifyAll in the exceptional case. [^ARTEMIS-2293-Test.patch]) > CLONE - addPacket method in the > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl > doesn't notify threads in case of an Exception > --- > > Key: ARTEMIS-3551 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3551 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.4 >Reporter: Rico Neubauer >Priority: Major > Attachments: ARTEMIS-2293-Test.patch > > > Hi, kindly asking to re-look into this issue. > Artemis 2.19.0 > Experienced the same situation and will provide small patch to provoke the > situation (see below - including the #notifyAll already). > An error on #addPacket results in the #waitCompletion method waiting until > call–timeout (default=30 sec). Having several threads in this situation then > leads to all of them waiting until timeout. > Furthermore, it seems that at least while large messages are produced in > parallel, this also has an impact on other client-consumers, that are not fed > anymore - however this I could not reproduce reliable, so no hard evidence > for that. > My proposal is like [~pmolchanov2002] also suggested to add the #notifyAll in > the exceptional case. > > [^ARTEMIS-2293-Test.patch] > > Following is the original description: > > Block that handles exceptions in the catch(Exception e) doesn't call > notifyAll(). That cause that other working threads are not released in the > waitCompletion method. > [https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/LargeMessageControllerImpl.java] > > addPacket method: > {code:java} > public void addPacket(byte[] chunk, int flowControlSize, boolean isContinues) > { > int flowControlCredit = 0; > > synchronized (this) { > packetAdded = true; > if (outStream != null) { > try { > if (!isContinues) { > streamEnded = true; > } > > if (fileCache != null) { > fileCache.cachePackage(chunk); > } > > outStream.write(chunk); > > flowControlCredit = flowControlSize; > > notifyAll(); > > if (streamEnded) { > outStream.close(); > } > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } else { > if (fileCache != null) { > try { > fileCache.cachePackage(chunk); > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } > > largeMessageData.offer(new LargeData(chunk, flowControlSize, > isContinues)); > } > }{code} > > waitCompletion method: > {code:java} > public synchronized boolean waitCompletion(final long timeWait) throws > ActiveMQException { > if (outStream == null) { > // There is no stream.. it will never achieve the end of streaming > return false; > } > > long timeOut; > > // If timeWait = 0, we will use the readTimeout > // And we will check if no packets have arrived within readTimeout > milliseconds > if (timeWait != 0) { > timeOut = System.currentTimeMillis() + timeWait; > } else { > timeOut = System.currentTimeMillis() + readTimeout; > } > > while (!streamEnded && handledException == null) { > try { > this.wait(timeWait == 0 ? readTimeout : timeWait); > } catch (InterruptedException e) { > throw new ActiveMQInterruptedException(e); > } > > if (!streamEnded && handledException == null) { > if (timeWait != 0 && System.currentTimeMillis() > timeOut) { > throw ActiveMQClient
[jira] [Updated] (ARTEMIS-3551) CLONE - addPacket method in the org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl doesn't notify threads in case of an Exception
[ https://issues.apache.org/jira/browse/ARTEMIS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-3551: --- Description: Hi, kindly asking to re-look into this issue. Artemis 2.19.0 Experienced the same situation and will provide small patch to provoke the situation (see below - including the #notifyAll already). An error on #addPacket results in the #waitCompletion method waiting until call–timeout (default=30 sec). Having several threads in this situation then leads to all of them waiting until timeout. Furthermore, it seems that at least while large messages are produced in parallel, this also has an impact on other client-consumers, that are not fed anymore - however this I could not reproduce reliable, so no hard evidence for that. My proposal is like [~pmolchanov2002] also suggested to add the #notifyAll in the exceptional case. [^ARTEMIS-2293-Test.patch] Following is the original description: Block that handles exceptions in the catch(Exception e) doesn't call notifyAll(). That cause that other working threads are not released in the waitCompletion method. [https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/LargeMessageControllerImpl.java] addPacket method: {code:java} public void addPacket(byte[] chunk, int flowControlSize, boolean isContinues) { int flowControlCredit = 0; synchronized (this) { packetAdded = true; if (outStream != null) { try { if (!isContinues) { streamEnded = true; } if (fileCache != null) { fileCache.cachePackage(chunk); } outStream.write(chunk); flowControlCredit = flowControlSize; notifyAll(); if (streamEnded) { outStream.close(); } } catch (Exception e) { ActiveMQClientLogger.LOGGER.errorAddingPacket(e); handledException = e; } } else { if (fileCache != null) { try { fileCache.cachePackage(chunk); } catch (Exception e) { ActiveMQClientLogger.LOGGER.errorAddingPacket(e); handledException = e; } } largeMessageData.offer(new LargeData(chunk, flowControlSize, isContinues)); } }{code} waitCompletion method: {code:java} public synchronized boolean waitCompletion(final long timeWait) throws ActiveMQException { if (outStream == null) { // There is no stream.. it will never achieve the end of streaming return false; } long timeOut; // If timeWait = 0, we will use the readTimeout // And we will check if no packets have arrived within readTimeout milliseconds if (timeWait != 0) { timeOut = System.currentTimeMillis() + timeWait; } else { timeOut = System.currentTimeMillis() + readTimeout; } while (!streamEnded && handledException == null) { try { this.wait(timeWait == 0 ? readTimeout : timeWait); } catch (InterruptedException e) { throw new ActiveMQInterruptedException(e); } if (!streamEnded && handledException == null) { if (timeWait != 0 && System.currentTimeMillis() > timeOut) { throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); } else if (System.currentTimeMillis() > timeOut && !packetAdded) { throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); } } } checkException(); return streamEnded; }{code} was: Block that handles exceptions in the catch(Exception e) doesn't call notifyAll(). That cause that other working threads are not released in the waitCompletion method. [https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/LargeMessageControllerImpl.java] addPacket method: {code:java} public void addPacket(byte[] chunk, int flowControlSize, boolean isContinues) { int flowControlCredit = 0; synchronized (this) { packetAdded = true; if (outStream != null) { try { if (!isContinues) { streamEnded = true; } if (fileCache != null) { fileCache.cachePackage(chunk); } outStream.write(chunk); flowControlCredit = flowControlSize; notifyAll(); if (streamEnded) { outStream.close(); } } catch (Exception e) { ActiveMQClientLogger.LOGGER.errorAddingPacket(e); handledException = e; } } else { if (fileCache != null) {
[jira] [Comment Edited] (ARTEMIS-3551) CLONE - addPacket method in the org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl doesn't notify threads in case of an Exception
[ https://issues.apache.org/jira/browse/ARTEMIS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17437435#comment-17437435 ] Rico Neubauer edited comment on ARTEMIS-3551 at 11/2/21, 4:02 PM: -- Hi, kindly asking to re-look into this issue. Artemis 2.19.0 Experienced the same situation and will provide small patch to provoke the situation (see below - including the #notifyAll already). An error on #addPacket results in the #waitCompletion method waiting until call–timeout (default=30 sec). Having several threads in this situation then leads to all of them waiting until timeout. Furthermore, it seems that at least while large messages are produced in parallel, this also has an impact on other client-consumers, that are not fed anymore - however this I could not reproduce reliable, so no hard evidence for that. My proposal is like [~pmolchanov2002] also suggested to add the #notifyAll in the exceptional case. [^ARTEMIS-2293-Test.patch] was (Author: riconeubauer): Hi, kindly asking to re-look into this issue. Experienced the same situation and will provide small patch to provoke the situation (see below - including the #notifyAll already). An error on #addPacket results in the #waitCompletion method waiting until call–timeout (default=30 sec). Having several threads in this situation then leads to all of them waiting until timeout. Furthermore, it seems that at least while large messages are produced in parallel, this also has an impact on other client-consumers, that are not fed anymore - however this I could not reproduce reliable, so no hard evidence for that. My proposal is like [~pmolchanov2002] also suggested to add the #notifyAll in the exceptional case. [^ARTEMIS-2293-Test.patch] > CLONE - addPacket method in the > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl > doesn't notify threads in case of an Exception > --- > > Key: ARTEMIS-3551 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3551 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.4 >Reporter: Rico Neubauer >Priority: Major > Attachments: ARTEMIS-2293-Test.patch > > > Block that handles exceptions in the catch(Exception e) doesn't call > notifyAll(). That cause that other working threads are not released in the > waitCompletion method. > [https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/LargeMessageControllerImpl.java] > > addPacket method: > {code:java} > public void addPacket(byte[] chunk, int flowControlSize, boolean isContinues) > { > int flowControlCredit = 0; > > synchronized (this) { > packetAdded = true; > if (outStream != null) { > try { > if (!isContinues) { > streamEnded = true; > } > > if (fileCache != null) { > fileCache.cachePackage(chunk); > } > > outStream.write(chunk); > > flowControlCredit = flowControlSize; > > notifyAll(); > > if (streamEnded) { > outStream.close(); > } > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } else { > if (fileCache != null) { > try { > fileCache.cachePackage(chunk); > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } > > largeMessageData.offer(new LargeData(chunk, flowControlSize, > isContinues)); > } > }{code} > > waitCompletion method: > {code:java} > public synchronized boolean waitCompletion(final long timeWait) throws > ActiveMQException { > if (outStream == null) { > // There is no stream.. it will never achieve the end of streaming > return false; > } > > long timeOut; > > // If timeWait = 0, we will use the readTimeout > // And we will check if no packets have arrived within readTimeout > milliseconds > if (timeWait != 0) { > timeOut = System.currentTimeMillis() + timeWait; > } else { > timeOut = System.currentTimeMillis() + readTimeout; > } > > while (!streamEnded && handledException == null) { > try { > this.wait(timeWait == 0 ? readTimeout : timeWait); > } catch (InterruptedException e) { > throw new ActiveMQInterruptedException(e); > } > > if (!streamEnded && handledException == null) { > if (timeWait != 0 && System.currentTimeMillis() > timeOut) { > th
[jira] [Commented] (ARTEMIS-3551) CLONE - addPacket method in the org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl doesn't notify threads in case of an Exception
[ https://issues.apache.org/jira/browse/ARTEMIS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17437435#comment-17437435 ] Rico Neubauer commented on ARTEMIS-3551: Hi, kindly asking to re-look into this issue. Experienced the same situation and will provide small patch to provoke the situation (see below - including the #notifyAll already). An error on #addPacket results in the #waitCompletion method waiting until call–timeout (default=30 sec). Having several threads in this situation then leads to all of them waiting until timeout. Furthermore, it seems that at least while large messages are produced in parallel, this also has an impact on other client-consumers, that are not fed anymore - however this I could not reproduce reliable, so no hard evidence for that. My proposal is like [~pmolchanov2002] also suggested to add the #notifyAll in the exceptional case. [^ARTEMIS-2293-Test.patch] > CLONE - addPacket method in the > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl > doesn't notify threads in case of an Exception > --- > > Key: ARTEMIS-3551 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3551 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.4 >Reporter: Rico Neubauer >Priority: Major > Attachments: ARTEMIS-2293-Test.patch > > > Block that handles exceptions in the catch(Exception e) doesn't call > notifyAll(). That cause that other working threads are not released in the > waitCompletion method. > [https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/LargeMessageControllerImpl.java] > > addPacket method: > {code:java} > public void addPacket(byte[] chunk, int flowControlSize, boolean isContinues) > { > int flowControlCredit = 0; > > synchronized (this) { > packetAdded = true; > if (outStream != null) { > try { > if (!isContinues) { > streamEnded = true; > } > > if (fileCache != null) { > fileCache.cachePackage(chunk); > } > > outStream.write(chunk); > > flowControlCredit = flowControlSize; > > notifyAll(); > > if (streamEnded) { > outStream.close(); > } > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } else { > if (fileCache != null) { > try { > fileCache.cachePackage(chunk); > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } > > largeMessageData.offer(new LargeData(chunk, flowControlSize, > isContinues)); > } > }{code} > > waitCompletion method: > {code:java} > public synchronized boolean waitCompletion(final long timeWait) throws > ActiveMQException { > if (outStream == null) { > // There is no stream.. it will never achieve the end of streaming > return false; > } > > long timeOut; > > // If timeWait = 0, we will use the readTimeout > // And we will check if no packets have arrived within readTimeout > milliseconds > if (timeWait != 0) { > timeOut = System.currentTimeMillis() + timeWait; > } else { > timeOut = System.currentTimeMillis() + readTimeout; > } > > while (!streamEnded && handledException == null) { > try { > this.wait(timeWait == 0 ? readTimeout : timeWait); > } catch (InterruptedException e) { > throw new ActiveMQInterruptedException(e); > } > > if (!streamEnded && handledException == null) { > if (timeWait != 0 && System.currentTimeMillis() > timeOut) { > throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); > } else if (System.currentTimeMillis() > timeOut && !packetAdded) { > throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); > } > } > } > > checkException(); > > return streamEnded; > > }{code} > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3551) CLONE - addPacket method in the org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl doesn't notify threads in case of an Exception
[ https://issues.apache.org/jira/browse/ARTEMIS-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-3551: --- Attachment: ARTEMIS-2293-Test.patch > CLONE - addPacket method in the > org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl > doesn't notify threads in case of an Exception > --- > > Key: ARTEMIS-3551 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3551 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.4 >Reporter: Rico Neubauer >Priority: Major > Attachments: ARTEMIS-2293-Test.patch > > > Block that handles exceptions in the catch(Exception e) doesn't call > notifyAll(). That cause that other working threads are not released in the > waitCompletion method. > [https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/LargeMessageControllerImpl.java] > > addPacket method: > {code:java} > public void addPacket(byte[] chunk, int flowControlSize, boolean isContinues) > { > int flowControlCredit = 0; > > synchronized (this) { > packetAdded = true; > if (outStream != null) { > try { > if (!isContinues) { > streamEnded = true; > } > > if (fileCache != null) { > fileCache.cachePackage(chunk); > } > > outStream.write(chunk); > > flowControlCredit = flowControlSize; > > notifyAll(); > > if (streamEnded) { > outStream.close(); > } > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } else { > if (fileCache != null) { > try { > fileCache.cachePackage(chunk); > } catch (Exception e) { > ActiveMQClientLogger.LOGGER.errorAddingPacket(e); > handledException = e; > } > } > > largeMessageData.offer(new LargeData(chunk, flowControlSize, > isContinues)); > } > }{code} > > waitCompletion method: > {code:java} > public synchronized boolean waitCompletion(final long timeWait) throws > ActiveMQException { > if (outStream == null) { > // There is no stream.. it will never achieve the end of streaming > return false; > } > > long timeOut; > > // If timeWait = 0, we will use the readTimeout > // And we will check if no packets have arrived within readTimeout > milliseconds > if (timeWait != 0) { > timeOut = System.currentTimeMillis() + timeWait; > } else { > timeOut = System.currentTimeMillis() + readTimeout; > } > > while (!streamEnded && handledException == null) { > try { > this.wait(timeWait == 0 ? readTimeout : timeWait); > } catch (InterruptedException e) { > throw new ActiveMQInterruptedException(e); > } > > if (!streamEnded && handledException == null) { > if (timeWait != 0 && System.currentTimeMillis() > timeOut) { > throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); > } else if (System.currentTimeMillis() > timeOut && !packetAdded) { > throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); > } > } > } > > checkException(); > > return streamEnded; > > }{code} > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-3551) CLONE - addPacket method in the org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl doesn't notify threads in case of an Exception
Rico Neubauer created ARTEMIS-3551: -- Summary: CLONE - addPacket method in the org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl doesn't notify threads in case of an Exception Key: ARTEMIS-3551 URL: https://issues.apache.org/jira/browse/ARTEMIS-3551 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.6.4 Reporter: Rico Neubauer Block that handles exceptions in the catch(Exception e) doesn't call notifyAll(). That cause that other working threads are not released in the waitCompletion method. [https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/LargeMessageControllerImpl.java] addPacket method: {code:java} public void addPacket(byte[] chunk, int flowControlSize, boolean isContinues) { int flowControlCredit = 0; synchronized (this) { packetAdded = true; if (outStream != null) { try { if (!isContinues) { streamEnded = true; } if (fileCache != null) { fileCache.cachePackage(chunk); } outStream.write(chunk); flowControlCredit = flowControlSize; notifyAll(); if (streamEnded) { outStream.close(); } } catch (Exception e) { ActiveMQClientLogger.LOGGER.errorAddingPacket(e); handledException = e; } } else { if (fileCache != null) { try { fileCache.cachePackage(chunk); } catch (Exception e) { ActiveMQClientLogger.LOGGER.errorAddingPacket(e); handledException = e; } } largeMessageData.offer(new LargeData(chunk, flowControlSize, isContinues)); } }{code} waitCompletion method: {code:java} public synchronized boolean waitCompletion(final long timeWait) throws ActiveMQException { if (outStream == null) { // There is no stream.. it will never achieve the end of streaming return false; } long timeOut; // If timeWait = 0, we will use the readTimeout // And we will check if no packets have arrived within readTimeout milliseconds if (timeWait != 0) { timeOut = System.currentTimeMillis() + timeWait; } else { timeOut = System.currentTimeMillis() + readTimeout; } while (!streamEnded && handledException == null) { try { this.wait(timeWait == 0 ? readTimeout : timeWait); } catch (InterruptedException e) { throw new ActiveMQInterruptedException(e); } if (!streamEnded && handledException == null) { if (timeWait != 0 && System.currentTimeMillis() > timeOut) { throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); } else if (System.currentTimeMillis() > timeOut && !packetAdded) { throw ActiveMQClientMessageBundle.BUNDLE.timeoutOnLargeMessage(); } } } checkException(); return streamEnded; }{code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[ https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17431276#comment-17431276 ] Rico Neubauer commented on ARTEMIS-3433: Thanks [~gtully], this looks good to me and fixes the issue on shut-down. > AMQ224068 on stop due to No OpenSSLContextFactory registered > > > Key: ARTEMIS-3433 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3433 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.18.0 >Reporter: Rico Neubauer >Assignee: Gary Tully >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > ARTEMIS-3117 introduced code in 2.18.0 to invoke > _OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();_ > during stop of _RemotingServiceImpl_. See below for whole stacktrace. > This throws a NullPointerException for us running inside Karaf on stop due to > the OpenSSLContextFactory being null at that point in time. > > ARTEMIS-2791 was somewhat similar to this. > Requesting to not fail on the OpenSSLContextFactory being null during stop. > {code:java} > {code:java} > INFO org.apache.activemq.artemis.osgi FelixStartLevel > [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: > Required protocol OPENWIRE was removed for broker local. Stopping broker. > INFO org.apache.activemq.artemis.osgi FelixStartLevel > [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: > Required protocol OPENWIRE was removed for broker local. Stopping broker. > ERROR org.apache.activemq.artemis.core.server FelixStartLevel > [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: > Unable to stop component: > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: > null at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942) > ~[?:?] at > org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) > ~[?:?] at > org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) > ~[?:?] at > org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) > ~[?:?] at > org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) > ~[?:?] at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969) > ~[osgi.core-7.0.0.jar:?] at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871) > ~[osgi.core-7.0.0.jar:?] at > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > ~[osgi.core-7.0.0.jar:?] at > org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) > ~[osgi.core-7.0.0.jar:?] at > org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ~[?:?] at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:?] at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at > org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244) > ~[?:?] at > org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) > ~[?:?] at > org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685) > ~[?:?] at > org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) > ~[?:?] at > org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318) > ~[?:?] at > org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308) > ~[?:?] at > org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421) > ~[?:?] at > org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165) > ~[?:?] at > org.apache.felix.scr.impl.manager.AbstractComponentMa
[jira] [Comment Edited] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[ https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17429877#comment-17429877 ] Rico Neubauer edited comment on ARTEMIS-3433 at 10/18/21, 8:37 AM: --- Thanks for the change. Unfortunately the null-check seems not enough, since OpenSSLContextFactoryProvider also does a null-check in its static initializer and then throws an IllegalStateException. So infact OpenSSLContextFactoryProvider.getOpenSSLContextFactory() will not return null, but throw the IllegalStateException, so the null-check afterwards will not become effective. Also see the "caused by" part of initially reported stacktrace. was (Author: riconeubauer): Thanks for the change. Unfortunately the null-check seems not enough, since OpenSSLContextFactoryProvider also does a null-check in its static initializer and then throws a IllegalStateException. So infact OpenSSLContextFactoryProvider.getOpenSSLContextFactory() will not return null, but throw the exception, so the null-check afterwards will not become effective. Also see the "caused by" part of initially reported stacktrace. > AMQ224068 on stop due to No OpenSSLContextFactory registered > > > Key: ARTEMIS-3433 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3433 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.18.0 >Reporter: Rico Neubauer >Priority: Major > Fix For: 2.19.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > ARTEMIS-3117 introduced code in 2.18.0 to invoke > _OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();_ > during stop of _RemotingServiceImpl_. See below for whole stacktrace. > This throws a NullPointerException for us running inside Karaf on stop due to > the OpenSSLContextFactory being null at that point in time. > > ARTEMIS-2791 was somewhat similar to this. > Requesting to not fail on the OpenSSLContextFactory being null during stop. > {code:java} > {code:java} > INFO org.apache.activemq.artemis.osgi FelixStartLevel > [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: > Required protocol OPENWIRE was removed for broker local. Stopping broker. > INFO org.apache.activemq.artemis.osgi FelixStartLevel > [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: > Required protocol OPENWIRE was removed for broker local. Stopping broker. > ERROR org.apache.activemq.artemis.core.server FelixStartLevel > [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: > Unable to stop component: > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: > null at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942) > ~[?:?] at > org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) > ~[?:?] at > org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) > ~[?:?] at > org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) > ~[?:?] at > org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) > ~[?:?] at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969) > ~[osgi.core-7.0.0.jar:?] at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871) > ~[osgi.core-7.0.0.jar:?] at > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > ~[osgi.core-7.0.0.jar:?] at > org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) > ~[osgi.core-7.0.0.jar:?] at > org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ~[?:?] at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:?] at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at > org.apache.felix.s
[jira] [Reopened] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[ https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer reopened ARTEMIS-3433: Thanks for the change. Unfortunately the null-check seems not enough, since OpenSSLContextFactoryProvider also does a null-check in its static initializer and then throws a IllegalStateException. So infact OpenSSLContextFactoryProvider.getOpenSSLContextFactory() will not return null, but throw the exception, so the null-check afterwards will not become effective. Also see the "caused by" part of initially reported stacktrace. > AMQ224068 on stop due to No OpenSSLContextFactory registered > > > Key: ARTEMIS-3433 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3433 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.18.0 >Reporter: Rico Neubauer >Priority: Major > Fix For: 2.19.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > ARTEMIS-3117 introduced code in 2.18.0 to invoke > _OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();_ > during stop of _RemotingServiceImpl_. See below for whole stacktrace. > This throws a NullPointerException for us running inside Karaf on stop due to > the OpenSSLContextFactory being null at that point in time. > > ARTEMIS-2791 was somewhat similar to this. > Requesting to not fail on the OpenSSLContextFactory being null during stop. > {code:java} > {code:java} > INFO org.apache.activemq.artemis.osgi FelixStartLevel > [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: > Required protocol OPENWIRE was removed for broker local. Stopping broker. > INFO org.apache.activemq.artemis.osgi FelixStartLevel > [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: > Required protocol OPENWIRE was removed for broker local. Stopping broker. > ERROR org.apache.activemq.artemis.core.server FelixStartLevel > [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: > Unable to stop component: > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: > null at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948) > ~[?:?] at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942) > ~[?:?] at > org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) > ~[?:?] at > org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) > ~[?:?] at > org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) > ~[?:?] at > org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) > ~[?:?] at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969) > ~[osgi.core-7.0.0.jar:?] at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871) > ~[osgi.core-7.0.0.jar:?] at > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > ~[osgi.core-7.0.0.jar:?] at > org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) > ~[osgi.core-7.0.0.jar:?] at > org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ~[?:?] at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:?] at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at > org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244) > ~[?:?] at > org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) > ~[?:?] at > org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685) > ~[?:?] at > org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) > ~[?:?] at > org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318) > ~[?:?] at > org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308) > ~[?:?] at >
[jira] [Commented] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[ https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428059#comment-17428059 ] Rico Neubauer commented on ARTEMIS-2618: Will provide the PR in the way you suggested latest tomorrow - thanks! > Improve Handling of Shutdown on critical I/O Error > -- > > Key: ARTEMIS-2618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2618 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.11.0 >Reporter: Rico Neubauer >Priority: Major > Fix For: 2.20.0 > > Attachments: Improve-Handling-of-Shutdown-on-critic.patch > > > Would like to request an improvement in the handling of critical I/O errors > on opening journal files. > If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to > open a journal file, the whole server shuts down with {{@Message(id = 222010, > value = "Critical IO Error, shutting down the server. file=1, message=0"}}. > We have seen this in the wild, where a backup-software locked the file for a > short time while journal was about getting opened, resulting in the shutdown. > Proposed improvement would be to have a short-running retry for opening the > journal files and only fail fatally if error persists. > Will attach a proposal patch. Can also create a PR if you accept. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[ https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17427490#comment-17427490 ] Rico Neubauer commented on ARTEMIS-2618: Still an issue for us, this is why we adapted it in our fork (see above). Not able to provide a test-case. Agree, that it is too dangerous to persistently retry, but for a short amount of time, as described in initial post, it is a pragmatic approach to deal with virus-scanners, backup-software etc. > Improve Handling of Shutdown on critical I/O Error > -- > > Key: ARTEMIS-2618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2618 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.11.0 >Reporter: Rico Neubauer >Priority: Major > Attachments: Improve-Handling-of-Shutdown-on-critic.patch > > > Would like to request an improvement in the handling of critical I/O errors > on opening journal files. > If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to > open a journal file, the whole server shuts down with {{@Message(id = 222010, > value = "Critical IO Error, shutting down the server. file=1, message=0"}}. > We have seen this in the wild, where a backup-software locked the file for a > short time while journal was about getting opened, resulting in the shutdown. > Proposed improvement would be to have a short-running retry for opening the > journal files and only fail fatally if error persists. > Will attach a proposal patch. Can also create a PR if you accept. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[ https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-3433: --- Description: ARTEMIS-3117 introduced code in 2.18.0 to invoke _OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();_ during stop of _RemotingServiceImpl_. See below for whole stacktrace. This throws a NullPointerException for us running inside Karaf on stop due to the OpenSSLContextFactory being null at that point in time. ARTEMIS-2791 was somewhat similar to this. Requesting to not fail on the OpenSSLContextFactory being null during stop. {code:java} {code:java} INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. ERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: null at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942) ~[?:?] at org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) ~[?:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) ~[osgi.core-7.0.0.jar:?] at org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589) ~[?:?] at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718) ~[?:?] at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487) ~[?:?] at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:613) ~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:70) ~[?:?] at org.apache.felix.scr.impl.Activator$ScrExten
[jira] [Updated] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[ https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-3433: --- Description: ARTEMIS-3117 introduced code in 2.18.0 to invoke ´´OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();´´ during stop of ``RemotingServiceImpl``. See below for whole stacktrace. This throws a NullPointerException for us running inside Karaf on stop due to the OpenSSLContextFactory being null at that point in time. ARTEMIS-2791 was somewhat similar to this. Requesting to not fail on the OpenSSLContextFactory being null during stop. {code:java} {code:java} INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. ERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: null at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942) ~[?:?] at org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) ~[?:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) ~[osgi.core-7.0.0.jar:?] at org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589) ~[?:?] at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718) ~[?:?] at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487) ~[?:?] at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:613) ~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:70) ~[?:?] at org.apache.felix.scr.impl.Activator$Scr
[jira] [Updated] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[ https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-3433: --- Description: ARTEMIS-3117 introduced code in 2.18.0 to invoke ´´OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();´´ during stop of ``RemotingServiceImpl``. See below for whole stacktrace. This throws a NullPointerException for us running inside Karaf on stop due to the OpenSSLContextFactory being null at that point in time. ARTEMIS-2791 was somewhat similar to this. Requesting to not fail on the OpenSSLContextFactory being null during stop. \{code} INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. ERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: null at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942) ~[?:?] at org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) ~[?:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) ~[osgi.core-7.0.0.jar:?] at org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589) ~[?:?] at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718) ~[?:?] at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487) ~[?:?] at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:613) ~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:70) ~[?:?] at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:451) ~[?:?] at
[jira] [Updated] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[ https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-3433: --- Description: ARTEMIS-3117 introduced code in 2.18.0 to invoke ´´OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();´´ during stop of ``RemotingServiceImpl``. See below for whole stacktrace. This throws a NullPointerException for us running inside Karaf on stop due to the OpenSSLContextFactory being null at that point in time. ARTEMIS-2791 was somewhat similar to this. Requesting to not fail on the OpenSSLContextFactory being null during stop. {noformat} INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. 2021-08-18T19:23:30.876+0200 ERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: null at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942) ~[?:?] at org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) ~[?:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) ~[osgi.core-7.0.0.jar:?] at org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589) ~[?:?] at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718) ~[?:?] at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487) ~[?:?] at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:613) ~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:70) ~[?:?] at org.apache.felix.scr
[jira] [Updated] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
[ https://issues.apache.org/jira/browse/ARTEMIS-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-3433: --- Description: ARTEMIS-3117 introduced code in 2.18.0 to invoke ´´OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();´´ during stop of ``RemotingServiceImpl``. See below for whole stacktrace. This throws a NullPointerException for us running inside Karaf on stop due to the OpenSSLContextFactory being null at that point in time. ARTEMIS-2791 was somewhat similar to this. Requesting to not fail on the OpenSSLContextFactory being null during stop. {{INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. ERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: null at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942) ~[?:?] at org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) ~[?:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) ~[osgi.core-7.0.0.jar:?] at org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589) ~[?:?] at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718) ~[?:?] at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487) ~[?:?] at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:613) ~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:70) ~[?:?] at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:451) ~[?:?] at org.a
[jira] [Created] (ARTEMIS-3433) AMQ224068 on stop due to No OpenSSLContextFactory registered
Rico Neubauer created ARTEMIS-3433: -- Summary: AMQ224068 on stop due to No OpenSSLContextFactory registered Key: ARTEMIS-3433 URL: https://issues.apache.org/jira/browse/ARTEMIS-3433 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.18.0 Reporter: Rico Neubauer ARTEMIS-3117 introduced code in 2.18.0 to invoke ``OpenSSLContextFactoryProvider.getOpenSSLContextFactory().clearSslContexts();`` during stop of ``RemotingServiceImpl``. See below for whole stacktrace. This throws a NullPointerException for us running inside Karaf on stop due to the OpenSSLContextFactory being null at that point in time. ARTEMIS-2791 was somewhat similar to this. Requesting to not fail on the OpenSSLContextFactory being null during stop. {{INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. INFO org.apache.activemq.artemis.osgi FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ581002: Required protocol OPENWIRE was removed for broker local. Stopping broker. ERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.18.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: null at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:390) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1287) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:942) ~[?:?] at org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) ~[?:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:969) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:871) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) ~[osgi.core-7.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:380) ~[osgi.core-7.0.0.jar:?] at org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:244) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:685) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:529) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:318) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:308) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:853) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589) ~[?:?] at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:718) ~[?:?] at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:487) ~[?:?] at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:6
[jira] [Updated] (ARTEMIS-2938) Update to latest Apache ActiveMQ Client to resolve CVEs
[ https://issues.apache.org/jira/browse/ARTEMIS-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2938: --- Attachment: ARTEMIS-2938-Update-to-latest-Apache-ActiveMQ-Client-to-r.patch > Update to latest Apache ActiveMQ Client to resolve CVEs > --- > > Key: ARTEMIS-2938 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2938 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: OpenWire >Affects Versions: 2.15.0 >Reporter: Rico Neubauer >Priority: Major > Attachments: > ARTEMIS-2938-Update-to-latest-Apache-ActiveMQ-Client-to-r.patch > > > Hi, > artemis-openwire-protocol embeds dependency > org.apache.activemq:activemq-client. > Version is defined in main pom.xml and currently 5.14.5. > ([Link|https://github.com/apache/activemq-artemis/blob/master/pom.xml#L87]) > 5.14.5 has the following vulnerabilities: > {noformat} > CVE-2018-11775 (BDSA-2018-3183): (7.4) > > TLS hostname verification when using the Apache ActiveMQ Client before 5.15.6 > was missing which could make the client vulnerable to a MITM attack between a > Java application using the ActiveMQ client and the ActiveMQ server. This is > now enabled by default. > CVE-2019-0222 (BDSA-2019-0858): (7.5) > --- > In Apache ActiveMQ 5.0.0 - 5.15.8, unmarshalling corrupt MQTT frame can lead > to broker Out of Memory exception making it unresponsive. > {noformat} > I therefore kindly request to update the dependency to the latest version - > 5.16.0 at time of writing. > Ran a full verification build with 5.16.0, which was perfectly fine. > Previous similar issue: ARTEMIS-118 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2938) Update to latest Apache ActiveMQ Client to resolve CVEs
Rico Neubauer created ARTEMIS-2938: -- Summary: Update to latest Apache ActiveMQ Client to resolve CVEs Key: ARTEMIS-2938 URL: https://issues.apache.org/jira/browse/ARTEMIS-2938 Project: ActiveMQ Artemis Issue Type: Improvement Components: OpenWire Affects Versions: 2.15.0 Reporter: Rico Neubauer Attachments: ARTEMIS-2938-Update-to-latest-Apache-ActiveMQ-Client-to-r.patch Hi, artemis-openwire-protocol embeds dependency org.apache.activemq:activemq-client. Version is defined in main pom.xml and currently 5.14.5. ([Link|https://github.com/apache/activemq-artemis/blob/master/pom.xml#L87]) 5.14.5 has the following vulnerabilities: {noformat} CVE-2018-11775 (BDSA-2018-3183): (7.4) TLS hostname verification when using the Apache ActiveMQ Client before 5.15.6 was missing which could make the client vulnerable to a MITM attack between a Java application using the ActiveMQ client and the ActiveMQ server. This is now enabled by default. CVE-2019-0222 (BDSA-2019-0858): (7.5) --- In Apache ActiveMQ 5.0.0 - 5.15.8, unmarshalling corrupt MQTT frame can lead to broker Out of Memory exception making it unresponsive. {noformat} I therefore kindly request to update the dependency to the latest version - 5.16.0 at time of writing. Ran a full verification build with 5.16.0, which was perfectly fine. Previous similar issue: ARTEMIS-118 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2795) update to proton-j 0.33.5 and qpid-jms 0.52.0
[ https://issues.apache.org/jira/browse/ARTEMIS-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17166475#comment-17166475 ] Rico Neubauer commented on ARTEMIS-2795: [~robbie] sorry, my bad, I mixed up the files. The linked file *does* contain the right, updated versions. > update to proton-j 0.33.5 and qpid-jms 0.52.0 > - > > Key: ARTEMIS-2795 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2795 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.14.0 > > Time Spent: 20m > Remaining Estimate: 0h > > update to proton-j 0.33.5 and qpid-jms 0.52.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2795) update to proton-j 0.33.5 and qpid-jms 0.52.0
[ https://issues.apache.org/jira/browse/ARTEMIS-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17166438#comment-17166438 ] Rico Neubauer commented on ARTEMIS-2795: This change was not reflected in the features.xml, see https://search.maven.org/remotecontent?filepath=org/apache/activemq/artemis-features/2.14.0/artemis-features-2.14.0-features.xml Is this missing by accident? > update to proton-j 0.33.5 and qpid-jms 0.52.0 > - > > Key: ARTEMIS-2795 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2795 > Project: ActiveMQ Artemis > Issue Type: Task > Components: AMQP >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.14.0 > > Time Spent: 20m > Remaining Estimate: 0h > > update to proton-j 0.33.5 and qpid-jms 0.52.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2791) ArrayIndexOutOfBoundsException in SSLContextFactoryProvider
[ https://issues.apache.org/jira/browse/ARTEMIS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125886#comment-17125886 ] Rico Neubauer commented on ARTEMIS-2791: just fyi: workaround for us on shutdown: https://github.com/seeburger-ag/activemq-artemis/commit/43c99ed48fc99adef883cbecdac4c4697383d0fb will not resolve potetntial issues at other code locations calling SSLContextFactoryProvider. > ArrayIndexOutOfBoundsException in SSLContextFactoryProvider > --- > > Key: ARTEMIS-2791 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2791 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.13.0 > Environment: Artemis 2.13.0 running in Karaf 4.2.8 >Reporter: Rico Neubauer >Priority: Major > > Hi, > updated from 2.12.0 to 2.13.0 and new class > {{org.apache.activemq.artemis.spi.core.remoting.ssl.SSLContextFactoryProvider}} > introduced with ARTEMIS-2704 produces an {{ArrayIndexOutOfBoundsException}} > on shutdown: > {code} > ERROR org.apache.activemq.artemis.core.server FelixStartLevel > [org.apache.activemq.artemis-server-osgi:2.13.0.SEE1] >AMQ224068: Unable to stop component: > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl > java.lang.ExceptionInInitializerError: null > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:384) > ~[?:?] > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) > ~[?:?] > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1031) > ~[?:?] > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:876) > ~[?:?] > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:870) > ~[?:?] > at > org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) > ~[?:?] > at > org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) > ~[?:?] > at > org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) > ~[?:?] > at > org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) > ~[?:?] > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:967) > ~[osgi.core-6.0.0.jar:?] > at > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:870) > ~[osgi.core-6.0.0.jar:?] > at > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > ~[osgi.core-6.0.0.jar:?] > at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:377) > ~[osgi.core-6.0.0.jar:?] > at > org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ~[?:1.8.0_242] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:1.8.0_242] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:1.8.0_242] > at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_242] > at > org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:228) > ~[?:?] > at > org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) > ~[?:?] > at > org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:664) > ~[?:?] > at > org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:510) > ~[?:?] > at > org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317) > ~[?:?] > at > org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307) > ~[?:?] > at > org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:407) > ~[?:?] > at > org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:163) > ~[?:?] > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:831) > ~[?:?] > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:805) > ~[?:?] > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:584) > ~[?:?] > at > org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(Co
[jira] [Updated] (ARTEMIS-2791) ArrayIndexOutOfBoundsException in SSLContextFactoryProvider
[ https://issues.apache.org/jira/browse/ARTEMIS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2791: --- Description: Hi, updated from 2.12.0 to 2.13.0 and new class {{org.apache.activemq.artemis.spi.core.remoting.ssl.SSLContextFactoryProvider}} introduced with ARTEMIS-2704 produces an {{ArrayIndexOutOfBoundsException}} on shutdown: {code} ERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.13.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImplERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.13.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: null at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:384) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1031) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:876) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:870) ~[?:?] at org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) ~[?:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:967) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:870) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:377) ~[osgi.core-6.0.0.jar:?] at org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_242] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_242] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_242] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_242] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:228) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:664) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:510) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:407) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:163) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:831) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:805) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:584) ~[?:?] at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:716) ~[?:?] at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:510) ~[?:?] at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:429) ~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:49) ~[?:?] at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:292) ~[?:?] at org.apache.felix.scr.impl.AbstractExtender$1.run(AbstractExtender.java:216) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_242] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_242] at org.apache.felix.scr.impl.AbstractExtender.destroyExtension(AbstractExtender.java:238) ~[?:?] at org.apache.felix.scr.impl.AbstractExtender.bundleChanged(AbstractExtender.java:132) ~[?:?] at org.apache.felix.framework.EventDispatcher.
[jira] [Updated] (ARTEMIS-2791) ArrayIndexOutOfBoundsException in SSLContextFactoryProvider
[ https://issues.apache.org/jira/browse/ARTEMIS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2791: --- Description: Hi, updated from 2.12.0 to 2.13.0 and new class {{org.apache.activemq.artemis.spi.core.remoting.ssl.SSLContextFactoryProvider}} introduced with ARTEMIS-2704 produces an {{ArrayIndexOutOfBoundsException}} on shutdown: {code} ERRORorg.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.13.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl java.lang.ExceptionInInitializerError: null at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:384) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1031) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:876) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:870) ~[?:?] at org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) ~[?:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:967) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:870) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:377) ~[osgi.core-6.0.0.jar:?] at org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_242] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_242] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_242] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_242] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:228) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:664) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:510) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:407) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:163) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:831) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:805) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:584) ~[?:?] at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:716) ~[?:?] at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:510) ~[?:?] at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:429) ~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:49) ~[?:?] at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:292) ~[?:?] at org.apache.felix.scr.impl.AbstractExtender$1.run(AbstractExtender.java:216) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_242] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_242] at org.apache.felix.scr.impl.AbstractExtender.destroyExtension(AbstractExtender.java:238) ~[?:?] at org.apache.felix.scr.impl.Abstr
[jira] [Created] (ARTEMIS-2791) ArrayIndexOutOfBoundsException in SSLContextFactoryProvider
Rico Neubauer created ARTEMIS-2791: -- Summary: ArrayIndexOutOfBoundsException in SSLContextFactoryProvider Key: ARTEMIS-2791 URL: https://issues.apache.org/jira/browse/ARTEMIS-2791 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.13.0 Environment: Artemis 2.13.0 running in Karaf 4.2.8 Reporter: Rico Neubauer Hi, updated from 2.12.0 to 2.13.0 and new class {{org.apache.activemq.artemis.spi.core.remoting.ssl.SSLContextFactoryProvider}} produces an {{ArrayIndexOutOfBoundsException}} on shutdown: {noformat} ERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.13.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImplERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.13.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: null at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:384) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1031) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:876) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:870) ~[?:?] at org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) ~[?:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:967) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:870) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:377) ~[osgi.core-6.0.0.jar:?] at org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_242] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_242] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_242] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_242] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:228) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:664) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:510) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:407) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:163) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:831) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:805) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:584) ~[?:?] at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:716) ~[?:?] at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:510) ~[?:?] at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:429) ~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:49) ~[?:?] at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:292) ~[?:?] at org.apache.felix.scr.impl.AbstractExtender$1.run(AbstractExtender.java:216) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_242] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_242] at org.apache.felix.scr.impl.
[jira] [Updated] (ARTEMIS-2791) ArrayIndexOutOfBoundsException in SSLContextFactoryProvider
[ https://issues.apache.org/jira/browse/ARTEMIS-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2791: --- Description: Hi, updated from 2.12.0 to 2.13.0 and new class {{org.apache.activemq.artemis.spi.core.remoting.ssl.SSLContextFactoryProvider}} introduced with ARTEMIS-2704 produces an {{ArrayIndexOutOfBoundsException}} on shutdown: {noformat} ERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.13.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImplERROR org.apache.activemq.artemis.core.server FelixStartLevel [org.apache.activemq.artemis-server-osgi:2.13.0.SEE1] AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpljava.lang.ExceptionInInitializerError: null at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.stop(RemotingServiceImpl.java:384) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1153) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1031) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:876) ~[?:?] at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:870) ~[?:?] at org.apache.activemq.artemis.osgi.OsgiBroker$ServerTrackerCallBackImpl.stop(OsgiBroker.java:242) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.protocolRemoved(ProtocolTracker.java:122) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:94) ~[?:?] at org.apache.activemq.artemis.osgi.ProtocolTracker.removedService(ProtocolTracker.java:38) ~[?:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:967) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:870) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) ~[osgi.core-6.0.0.jar:?] at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:377) ~[osgi.core-6.0.0.jar:?] at org.apache.activemq.artemis.osgi.OsgiBroker.stop(OsgiBroker.java:147) ~[?:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_242] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_242] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_242] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_242] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:228) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:664) ~[?:?] at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:510) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317) ~[?:?] at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:407) ~[?:?] at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:163) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:831) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:805) ~[?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:584) ~[?:?] at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:716) ~[?:?] at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:510) ~[?:?] at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:429) ~[?:?] at org.apache.felix.scr.impl.Activator.access$300(Activator.java:49) ~[?:?] at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:292) ~[?:?] at org.apache.felix.scr.impl.AbstractExtender$1.run(AbstractExtender.java:216) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_242] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_242] at org.apache.felix.scr.impl.AbstractExtender.destroyExtension(AbstractExtender.java:238) ~[?:?] at org.apache.felix.scr.impl.AbstractExtender.bundleChanged(AbstractExtender.java:132) ~[?:?] at org.apache.felix.framework.EventDispatc
[jira] [Comment Edited] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[ https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099053#comment-17099053 ] Rico Neubauer edited comment on ARTEMIS-2618 at 5/4/20, 4:44 PM: - fyi: [Commit|https://github.com/seeburger-ag/activemq-artemis/commit/4e95dcec2714afe101d92f260451acfd37f824d4] was (Author: riconeubauer): fyi: https://github.com/seeburger-ag/activemq-artemis/commit/3867f09f1e20454aaafa43d564e1cacef9483354 > Improve Handling of Shutdown on critical I/O Error > -- > > Key: ARTEMIS-2618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2618 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.11.0 >Reporter: Rico Neubauer >Priority: Major > Attachments: Improve-Handling-of-Shutdown-on-critic.patch > > > Would like to request an improvement in the handling of critical I/O errors > on opening journal files. > If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to > open a journal file, the whole server shuts down with {{@Message(id = 222010, > value = "Critical IO Error, shutting down the server. file=1, message=0"}}. > We have seen this in the wild, where a backup-software locked the file for a > short time while journal was about getting opened, resulting in the shutdown. > Proposed improvement would be to have a short-running retry for opening the > journal files and only fail fatally if error persists. > Will attach a proposal patch. Can also create a PR if you accept. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[ https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099053#comment-17099053 ] Rico Neubauer commented on ARTEMIS-2618: fyi: https://github.com/seeburger-ag/activemq-artemis/commit/3867f09f1e20454aaafa43d564e1cacef9483354 > Improve Handling of Shutdown on critical I/O Error > -- > > Key: ARTEMIS-2618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2618 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.11.0 >Reporter: Rico Neubauer >Priority: Major > Attachments: Improve-Handling-of-Shutdown-on-critic.patch > > > Would like to request an improvement in the handling of critical I/O errors > on opening journal files. > If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to > open a journal file, the whole server shuts down with {{@Message(id = 222010, > value = "Critical IO Error, shutting down the server. file=1, message=0"}}. > We have seen this in the wild, where a backup-software locked the file for a > short time while journal was about getting opened, resulting in the shutdown. > Proposed improvement would be to have a short-running retry for opening the > journal files and only fail fatally if error persists. > Will attach a proposal patch. Can also create a PR if you accept. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[ https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033648#comment-17033648 ] Rico Neubauer commented on ARTEMIS-2618: [~clebertsuconic] in our case it was: * Running on Windows * A backup software accessing the journal files and creating a lock on them temporarily ** at the same time Artemis wanted to open one of the locked journal file --> error > Improve Handling of Shutdown on critical I/O Error > -- > > Key: ARTEMIS-2618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2618 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.11.0 >Reporter: Rico Neubauer >Priority: Major > Attachments: Improve-Handling-of-Shutdown-on-critic.patch > > > Would like to request an improvement in the handling of critical I/O errors > on opening journal files. > If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to > open a journal file, the whole server shuts down with {{@Message(id = 222010, > value = "Critical IO Error, shutting down the server. file=1, message=0"}}. > We have seen this in the wild, where a backup-software locked the file for a > short time while journal was about getting opened, resulting in the shutdown. > Proposed improvement would be to have a short-running retry for opening the > journal files and only fail fatally if error persists. > Will attach a proposal patch. Can also create a PR if you accept. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[ https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033589#comment-17033589 ] Rico Neubauer edited comment on ARTEMIS-2618 at 2/10/20 1:16 PM: - Ah, I see. Thanks for looking into this [~nigro@gmail.com]. Understand if refrain from implementing a retry then. Or would it be an option to only consider retries for Windows systems (where file locking is the actual initial problem)? We would probably implement it in our fork nevertheless, since considering the impact of a server shutdown too severe, compared to the risk of sth. else than locking causing the IOEx. on opening, especially since we always run with AsyncIO on Linux anyway. was (Author: riconeubauer): Ah, I see. Thanks for looking into this [~nigro@gmail.com]. Understand if refrain from implementing a retry then. Or would it be an option to only consider retries for Windows systems (where file locking is the actual initial problem)? We would probably implement it in our fork nevertheless, since considering the impact of a server shutdown too severe, compared to the risk of sth. else than locking causing the IOEx. on opening. > Improve Handling of Shutdown on critical I/O Error > -- > > Key: ARTEMIS-2618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2618 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.11.0 >Reporter: Rico Neubauer >Priority: Major > Attachments: Improve-Handling-of-Shutdown-on-critic.patch > > > Would like to request an improvement in the handling of critical I/O errors > on opening journal files. > If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to > open a journal file, the whole server shuts down with {{@Message(id = 222010, > value = "Critical IO Error, shutting down the server. file=1, message=0"}}. > We have seen this in the wild, where a backup-software locked the file for a > short time while journal was about getting opened, resulting in the shutdown. > Proposed improvement would be to have a short-running retry for opening the > journal files and only fail fatally if error persists. > Will attach a proposal patch. Can also create a PR if you accept. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[ https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033589#comment-17033589 ] Rico Neubauer commented on ARTEMIS-2618: Ah, I see. Thanks for looking into this [~nigro@gmail.com]. Understand if refrain from implementing a retry then. Or would it be an option to only consider retries for Windows systems (where file locking is the actual initial problem)? We would probably implement it in our fork nevertheless, since considering the impact of a server shutdown too severe, compared to the risk of sth. else than locking causing the IOEx. on opening. > Improve Handling of Shutdown on critical I/O Error > -- > > Key: ARTEMIS-2618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2618 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.11.0 >Reporter: Rico Neubauer >Priority: Major > Attachments: Improve-Handling-of-Shutdown-on-critic.patch > > > Would like to request an improvement in the handling of critical I/O errors > on opening journal files. > If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to > open a journal file, the whole server shuts down with {{@Message(id = 222010, > value = "Critical IO Error, shutting down the server. file=1, message=0"}}. > We have seen this in the wild, where a backup-software locked the file for a > short time while journal was about getting opened, resulting in the shutdown. > Proposed improvement would be to have a short-running retry for opening the > journal files and only fail fatally if error persists. > Will attach a proposal patch. Can also create a PR if you accept. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[ https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033540#comment-17033540 ] Rico Neubauer commented on ARTEMIS-2618: I agree [~nigro@gmail.com], retrying read/write operations is disputable. Note however, that I was only targeting the File#open, an operation which fails or succeeds, not altering the persistent state. > Improve Handling of Shutdown on critical I/O Error > -- > > Key: ARTEMIS-2618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2618 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.11.0 >Reporter: Rico Neubauer >Priority: Major > Attachments: Improve-Handling-of-Shutdown-on-critic.patch > > > Would like to request an improvement in the handling of critical I/O errors > on opening journal files. > If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to > open a journal file, the whole server shuts down with {{@Message(id = 222010, > value = "Critical IO Error, shutting down the server. file=1, message=0"}}. > We have seen this in the wild, where a backup-software locked the file for a > short time while journal was about getting opened, resulting in the shutdown. > Proposed improvement would be to have a short-running retry for opening the > journal files and only fail fatally if error persists. > Will attach a proposal patch. Can also create a PR if you accept. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[ https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2618: --- Description: Would like to request an improvement in the handling of critical I/O errors on opening journal files. If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to open a journal file, the whole server shuts down with {{@Message(id = 222010, value = "Critical IO Error, shutting down the server. file=1, message=0"}}. We have seen this in the wild, where a backup-software locked the file for a short time while journal was about getting opened, resulting in the shutdown. Proposed improvement would be to have a short-running retry for opening the journal files and only fail fatally if error persists. Will attach a proposal patch. Can also create a PR if you accept. was: Would like to request an improvement in the handling of critical I/O errors on opening journal files. If ´´org.apache.activemq.artemis.core.io.nio.NIOSequentialFile´´ fails to open a journal file, the whole server shuts down with ´´@Message(id = 222010, value = "Critical IO Error, shutting down the server. file=\{1}, message=\{0}"´´. We have seen this in the wild, where a backup-software locked the file for a short time while journal was about getting opened, resulting in the shutdown. Proposed improvement would be to have a short-running retry for opening the journal files and only fail fatally if error persists. Will attach a proposal patch. Can also create a PR if you accept. > Improve Handling of Shutdown on critical I/O Error > -- > > Key: ARTEMIS-2618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2618 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.11.0 >Reporter: Rico Neubauer >Priority: Major > Attachments: Improve-Handling-of-Shutdown-on-critic.patch > > > Would like to request an improvement in the handling of critical I/O errors > on opening journal files. > If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to > open a journal file, the whole server shuts down with {{@Message(id = 222010, > value = "Critical IO Error, shutting down the server. file=1, message=0"}}. > We have seen this in the wild, where a backup-software locked the file for a > short time while journal was about getting opened, resulting in the shutdown. > Proposed improvement would be to have a short-running retry for opening the > journal files and only fail fatally if error persists. > Will attach a proposal patch. Can also create a PR if you accept. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[ https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2618: --- Description: Would like to request an improvement in the handling of critical I/O errors on opening journal files. If ´´org.apache.activemq.artemis.core.io.nio.NIOSequentialFile´´ fails to open a journal file, the whole server shuts down with ´´@Message(id = 222010, value = "Critical IO Error, shutting down the server. file=\{1}, message=\{0}"´´. We have seen this in the wild, where a backup-software locked the file for a short time while journal was about getting opened, resulting in the shutdown. Proposed improvement would be to have a short-running retry for opening the journal files and only fail fatally if error persists. Will attach a proposal patch. Can also create a PR if you accept. was: Would like to request an improvement in the handling of critical I/O errors on opening journal files. If ``org.apache.activemq.artemis.core.io.nio.NIOSequentialFile`` fails to open a journal file, the whole server shuts down with ``@Message(id = 222010, value = "Critical IO Error, shutting down the server. file=\{1}, message=\{0}"``. We have seen this in the wild, where a backup-software locked the file for a short time while journal was about getting opened, resulting in the shutdown. Proposed improvement would be to have a short-running retry for opening the journal files and only fail fatally if error persists. Will attach a proposal patch. Can also create a PR if you accept. > Improve Handling of Shutdown on critical I/O Error > -- > > Key: ARTEMIS-2618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2618 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.11.0 >Reporter: Rico Neubauer >Priority: Major > Attachments: Improve-Handling-of-Shutdown-on-critic.patch > > > Would like to request an improvement in the handling of critical I/O errors > on opening journal files. > If ´´org.apache.activemq.artemis.core.io.nio.NIOSequentialFile´´ fails to > open a journal file, the whole server shuts down with ´´@Message(id = 222010, > value = "Critical IO Error, shutting down the server. file=\{1}, > message=\{0}"´´. > We have seen this in the wild, where a backup-software locked the file for a > short time while journal was about getting opened, resulting in the shutdown. > Proposed improvement would be to have a short-running retry for opening the > journal files and only fail fatally if error persists. > Will attach a proposal patch. Can also create a PR if you accept. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
Rico Neubauer created ARTEMIS-2618: -- Summary: Improve Handling of Shutdown on critical I/O Error Key: ARTEMIS-2618 URL: https://issues.apache.org/jira/browse/ARTEMIS-2618 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.11.0 Reporter: Rico Neubauer Attachments: Improve-Handling-of-Shutdown-on-critic.patch Would like to request an improvement in the handling of critical I/O errors on opening journal files. If ``org.apache.activemq.artemis.core.io.nio.NIOSequentialFile`` fails to open a journal file, the whole server shuts down with ``@Message(id = 222010, value = "Critical IO Error, shutting down the server. file=\{1}, message=\{0}"``. We have seen this in the wild, where a backup-software locked the file for a short time while journal was about getting opened, resulting in the shutdown. Proposed improvement would be to have a short-running retry for opening the journal files and only fail fatally if error persists. Will attach a proposal patch. Can also create a PR if you accept. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17010517#comment-17010517 ] Rico Neubauer commented on ARTEMIS-2586: [~jbertram] Thanks for your reply and your hints. No, we are not acknowledging the message before the send. I will set up a test which provokes the situation and check whether acknowledging resolves the situation (whereas this would actually not be the desired flow). About the AMQP - yes, it was because of the "AMQ" prefix - sorry for the confusion I caused here. Just removed it as component. > Inifinite Block in AMQ212054 after transient DB-error > - > > Key: ARTEMIS-2586 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2586 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.10.1 > Environment: This is Ubuntu 18.04 and Oracle DB, but don't think it's > that relevant for the issue. >Reporter: Rico Neubauer >Priority: Major > Attachments: 2019-11-28_threaddump_01.txt, > 2019-12-04_threaddump_01.txt, Message-Counts.png, artemis.xml, > initial-error.txt, log-extract.txt, writerIndex-Credits.PNG > > > Hi, > Would like to describe a quite severe situation which was expirienced in a > long-running test with 2 out of 3 instances/machines. > We are running Karaf with Artemis 2.10.1. > After some time (see screenshot), first one, then after a while a 2nd > instance came to a complete stop. > Looking into the logs and thread-dumps revealed the following (same for bith > instances): > # There was a temporary problem connecting to the DB ({{connection reset by > peer}}and {{Closed Connection }}) > # This resulted (due to handling on our side) in an > {{IllegalStateException}}/{{Error during two phase commit}} being thrown back > to Artemis. > # After this, there is no messaging possible anymore at all and the > following log repeats: > {noformat} > AMQ212054: Destination address=DLQ is blocked. If the system is configured to > block make sure you consume messages on this configuration.{noformat} > (system is not configured to block, see attached config) > which comes from threads like these, trying to obtain credits for sending: > > {noformat} > "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on > lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) > at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) > at > org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) > at > com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) > at > com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) > at > com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) > at > org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) > 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 > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown > Source) > at > java.util.c
[jira] [Updated] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2586: --- Component/s: (was: AMQP) > Inifinite Block in AMQ212054 after transient DB-error > - > > Key: ARTEMIS-2586 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2586 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.10.1 > Environment: This is Ubuntu 18.04 and Oracle DB, but don't think it's > that relevant for the issue. >Reporter: Rico Neubauer >Priority: Major > Attachments: 2019-11-28_threaddump_01.txt, > 2019-12-04_threaddump_01.txt, Message-Counts.png, artemis.xml, > initial-error.txt, log-extract.txt, writerIndex-Credits.PNG > > > Hi, > Would like to describe a quite severe situation which was expirienced in a > long-running test with 2 out of 3 instances/machines. > We are running Karaf with Artemis 2.10.1. > After some time (see screenshot), first one, then after a while a 2nd > instance came to a complete stop. > Looking into the logs and thread-dumps revealed the following (same for bith > instances): > # There was a temporary problem connecting to the DB ({{connection reset by > peer}}and {{Closed Connection }}) > # This resulted (due to handling on our side) in an > {{IllegalStateException}}/{{Error during two phase commit}} being thrown back > to Artemis. > # After this, there is no messaging possible anymore at all and the > following log repeats: > {noformat} > AMQ212054: Destination address=DLQ is blocked. If the system is configured to > block make sure you consume messages on this configuration.{noformat} > (system is not configured to block, see attached config) > which comes from threads like these, trying to obtain credits for sending: > > {noformat} > "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on > lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) > at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) > at > org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) > at > com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) > at > com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) > at > com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) > at > org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) > 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 > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown > Source) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > Locked synchronizers: count = 1 > - java.util.concurrent.ThreadPoolExecutor$Worker@bc49fcf > {noformat} > which will never succeed, since the credits seem to no suffi
[jira] [Commented] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17007974#comment-17007974 ] Rico Neubauer commented on ARTEMIS-2586: Config attached now - sorry, missed it. Just used "AMQP" as component since, the logged error has it in its name. You are right: we are using the core protocol. The exceptions thrown originate in the JDBC-driver's networ layer, while the MessageReceiverBase#onMessage tries to commit. This exception is handled by MessageReceiverBase and message is tried to be sent to DLQ, while looking at it, maybe this handling leads to the credit exhaustion, since the handling is still part of our #onMessage code, i.e. there is not yet a return/exception back to JMS-server done, when the blocking send is in progress: e.g. {noformat} "Thread-83 (ActiveMQ-client-global-threads)" Id=1727 in TIMED_WAITING on lock=java.util.concurrent.Semaphore$NonfairSync@85eb557 at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) at org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) at org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) at com.company.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) at com.company.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) at com.company.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387){noformat} > Inifinite Block in AMQ212054 after transient DB-error > - > > Key: ARTEMIS-2586 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2586 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.10.1 > Environment: This is Ubuntu 18.04 and Oracle DB, but don't think it's > that relevant for the issue. >Reporter: Rico Neubauer >Priority: Major > Attachments: 2019-11-28_threaddump_01.txt, > 2019-12-04_threaddump_01.txt, Message-Counts.png, artemis.xml, > initial-error.txt, log-extract.txt, writerIndex-Credits.PNG > > > Hi, > Would like to describe a quite severe situation which was expirienced in a > long-running test with 2 out of 3 instances/machines. > We are running Karaf with Artemis 2.10.1. > After some time (see screenshot), first one, then after a while a 2nd > instance came to a complete stop. > Looking into the logs and thread-dumps revealed the following (same for bith > instances): > # There was a temporary problem connecting to the DB ({{connection reset by > peer}}and {{Closed Connection }}) > # This resulted (due to handling on our side) in an > {{IllegalStateException}}/{{Error during two phase commit}} being thrown back > to Artemis. > # After this, there is no messaging possible anymore at all and the > following log repeats: > {noformat} > AMQ212054: Destination address=DLQ is blocked. If the system is configured to > block make sure you consume messages on this configuration.{noformat} > (system is not configured to block, see attached config) > which comes from threads like these, trying to obtain credits for sending: > > {noformat} > "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on > lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) > at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.ac
[jira] [Comment Edited] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17007974#comment-17007974 ] Rico Neubauer edited comment on ARTEMIS-2586 at 1/4/20 10:39 AM: - Config attached now - sorry, missed it. Just used "AMQP" as component since, the logged error has it in its name. You are right: we are using the core protocol. The exceptions thrown originate in the JDBC-driver's networ layer, while the MessageReceiverBase#onMessage tries to commit. This exception is handled by MessageReceiverBase and message is tried to be sent to DLQ. While looking at it now, maybe this handling leads to the credit exhaustion, since the handling is still part of our #onMessage code, i.e. there is not yet a return/exception back to JMS-server done, when the blocking send is in progress: e.g. {noformat} "Thread-83 (ActiveMQ-client-global-threads)" Id=1727 in TIMED_WAITING on lock=java.util.concurrent.Semaphore$NonfairSync@85eb557 at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) at org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) at org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) at com.company.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) at com.company.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) at com.company.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387){noformat} was (Author: riconeubauer): Config attached now - sorry, missed it. Just used "AMQP" as component since, the logged error has it in its name. You are right: we are using the core protocol. The exceptions thrown originate in the JDBC-driver's networ layer, while the MessageReceiverBase#onMessage tries to commit. This exception is handled by MessageReceiverBase and message is tried to be sent to DLQ, while looking at it, maybe this handling leads to the credit exhaustion, since the handling is still part of our #onMessage code, i.e. there is not yet a return/exception back to JMS-server done, when the blocking send is in progress: e.g. {noformat} "Thread-83 (ActiveMQ-client-global-threads)" Id=1727 in TIMED_WAITING on lock=java.util.concurrent.Semaphore$NonfairSync@85eb557 at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) at org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) at org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) at com.company.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) at com.company.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) at com.company.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387){noformat} > Inifinite Block in AMQ212054 after transient
[jira] [Updated] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2586: --- Attachment: artemis.xml > Inifinite Block in AMQ212054 after transient DB-error > - > > Key: ARTEMIS-2586 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2586 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.10.1 > Environment: This is Ubuntu 18.04 and Oracle DB, but don't think it's > that relevant for the issue. >Reporter: Rico Neubauer >Priority: Major > Attachments: 2019-11-28_threaddump_01.txt, > 2019-12-04_threaddump_01.txt, Message-Counts.png, artemis.xml, > initial-error.txt, log-extract.txt, writerIndex-Credits.PNG > > > Hi, > Would like to describe a quite severe situation which was expirienced in a > long-running test with 2 out of 3 instances/machines. > We are running Karaf with Artemis 2.10.1. > After some time (see screenshot), first one, then after a while a 2nd > instance came to a complete stop. > Looking into the logs and thread-dumps revealed the following (same for bith > instances): > # There was a temporary problem connecting to the DB ({{connection reset by > peer}}and {{Closed Connection }}) > # This resulted (due to handling on our side) in an > {{IllegalStateException}}/{{Error during two phase commit}} being thrown back > to Artemis. > # After this, there is no messaging possible anymore at all and the > following log repeats: > {noformat} > AMQ212054: Destination address=DLQ is blocked. If the system is configured to > block make sure you consume messages on this configuration.{noformat} > (system is not configured to block, see attached config) > which comes from threads like these, trying to obtain credits for sending: > > {noformat} > "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on > lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) > at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) > at > org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) > at > com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) > at > com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) > at > com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) > at > org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) > 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 > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown > Source) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > Locked synchronizers: count = 1 > - java.util.concurrent.ThreadPoolExecutor$Worker@bc49fcf > {noformat} > which will never succeed, since the c
[jira] [Updated] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2586: --- Description: Hi, Would like to describe a quite severe situation which was expirienced in a long-running test with 2 out of 3 instances/machines. We are running Karaf with Artemis 2.10.1. After some time (see screenshot), first one, then after a while a 2nd instance came to a complete stop. Looking into the logs and thread-dumps revealed the following (same for bith instances): # There was a temporary problem connecting to the DB ({{connection reset by peer}}and {{Closed Connection }}) # This resulted (due to handling on our side) in an {{IllegalStateException}}/{{Error during two phase commit}} being thrown back to Artemis. # After this, there is no messaging possible anymore at all and the following log repeats: {noformat} AMQ212054: Destination address=DLQ is blocked. If the system is configured to block make sure you consume messages on this configuration.{noformat} (system is not configured to block, see attached config) which comes from threads like these, trying to obtain credits for sending: {noformat} "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) at org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) at org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) at com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) at com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) at com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) at org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) 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 org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) Locked synchronizers: count = 1 - java.util.concurrent.ThreadPoolExecutor$Worker@bc49fcf {noformat} which will never succeed, since the credits seem to no suffice (see heap-dump screenshot) >From my point of view, the thrown IllegalStateException should not lead to the >system going in this non-recoverable state, what do you think, is there >something that can be enhanced? [Fastthread-Link|https://fastthread.io/my-thread-report.jsp?p=c2hhcmVkLzIwMjAvMDEvMy8tLTIwMTktMTItMDRfdGhyZWFkZHVtcF8wMS50eHQtLTEzLTM4LTE1OzstLTIwMTktMTEtMjhfdGhyZWFkZHVtcF8wMS50eHQtLTEzLTM4LTE1] In case it helps: The 2 instances are still in this state (since September) and I can fetch additional information or debug them on request. was: Hi, Would like to describe a quite severe situation which was expirienced in a long-running test with 2 out of 3 instances/machines. We are running Karaf with Artemis 2.10.1. After some time (see screenshot), first one, then after a while a 2nd instance came to a complete sto
[jira] [Updated] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2586: --- Description: Hi, Would like to describe a quite severe situation which was expirienced in a long-running test with 2 out of 3 instances/machines. We are running Karaf with Artemis 2.10.1. After some time (see screenshot), first one, then after a while a 2nd instance came to a complete stop. Looking into the logs and thread-dumps revealed the following (same for bith instances): # There was a temporary problem connecting to the DB ({{connection reset by peer}}and {{Closed Connection }}) # This resulted (due to handling on our side) in an {{IllegalStateException}}/{{Error during two phase commit}} being thrown back to Artemis. # After this, there is no messaging possible anymore at all and the following log repeats: {noformat} AMQ212054: Destination address=DLQ is blocked. If the system is configured to block make sure you consume messages on this configuration.{noformat} (system is not condifured to block, see attached config) which comes from threads like these, trying to obtain credits for sending: {noformat} "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) at org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) at org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) at com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) at com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) at com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) at org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) 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 org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) Locked synchronizers: count = 1 - java.util.concurrent.ThreadPoolExecutor$Worker@bc49fcf {noformat} which will never succeed, since the credits seem to no suffice (see heap-dump screenshot) >From my point of view, the thrown IllegalStateException should not lead to the >system going in this non-recoverable state, what do you think, is there >something that can be enhanced? [Fastthread-Link|https://fastthread.io/my-thread-report.jsp?p=c2hhcmVkLzIwMjAvMDEvMy8tLTIwMTktMTItMDRfdGhyZWFkZHVtcF8wMS50eHQtLTEzLTM4LTE1OzstLTIwMTktMTEtMjhfdGhyZWFkZHVtcF8wMS50eHQtLTEzLTM4LTE1] In case it helps: The 2 instances are still in this state (since September) and I can fetch additional information or debug them on request. was: Hi, Would like to describe a quite severe situation which was expirienced in a long-running test with 2 out of 3 instances/machines. We are running Karaf with Artemis 2.10.1. After some time (see screenshot), first one, then after a while a 2nd instance came to a complete stop
[jira] [Updated] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2586: --- Attachment: 2019-12-04_threaddump_01.txt > Inifinite Block in AMQ212054 after transient DB-error > - > > Key: ARTEMIS-2586 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2586 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.10.1 > Environment: This is Ubuntu 18.04 and Oracle DB, but don't think it's > that relevant for the issue. >Reporter: Rico Neubauer >Priority: Major > Attachments: 2019-11-28_threaddump_01.txt, > 2019-12-04_threaddump_01.txt, Message-Counts.png, initial-error.txt, > log-extract.txt, writerIndex-Credits.PNG > > > Hi, > Would like to describe a quite severe situation which was expirienced in a > long-running test with 2 out of 3 instances/machines. > We are running Karaf with Artemis 2.10.1. > After some time (see screenshot), first one, then after a while a 2nd > instance came to a complete stop. > Looking into the logs and thread-dumps revealed the following (same for bith > instances): > # There was a temporary problem connecting to the DB (\{{connection reset by > peer}}and \{{Closed Connection }}) > # This resulted (due to handling on our side) in an > \{{IllegalStateException}}/\{{Error during two phase commit}} being thrown > back to Artemis. > # After this, there is no messaging possible anymore at all and the > following log repeats: > {noformat} > AMQ212054: Destination address=DLQ is blocked. If the system is configured to > block make sure you consume messages on this configuration.{noformat} > which comes from threads like these, trying to obtain credits for sending: > > {noformat} > "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on > lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) > at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) > at > org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) > at > com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) > at > com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) > at > com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) > at > org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) > 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 > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown > Source) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > Locked synchronizers: count = 1 > - java.util.concurrent.ThreadPoolExecutor$Worker@bc49fcf > {noformat} > which will never succeed, since the credits seem to no suffice (see heap-dump > screensh
[jira] [Updated] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2586: --- Attachment: writerIndex-Credits.PNG > Inifinite Block in AMQ212054 after transient DB-error > - > > Key: ARTEMIS-2586 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2586 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.10.1 > Environment: This is Ubuntu 18.04 and Oracle DB, but don't think it's > that relevant for the issue. >Reporter: Rico Neubauer >Priority: Major > Attachments: 2019-11-28_threaddump_01.txt, > 2019-12-04_threaddump_01.txt, Message-Counts.png, initial-error.txt, > log-extract.txt, writerIndex-Credits.PNG > > > Hi, > Would like to describe a quite severe situation which was expirienced in a > long-running test with 2 out of 3 instances/machines. > We are running Karaf with Artemis 2.10.1. > After some time (see screenshot), first one, then after a while a 2nd > instance came to a complete stop. > Looking into the logs and thread-dumps revealed the following (same for bith > instances): > # There was a temporary problem connecting to the DB (\{{connection reset by > peer}}and \{{Closed Connection }}) > # This resulted (due to handling on our side) in an > \{{IllegalStateException}}/\{{Error during two phase commit}} being thrown > back to Artemis. > # After this, there is no messaging possible anymore at all and the > following log repeats: > {noformat} > AMQ212054: Destination address=DLQ is blocked. If the system is configured to > block make sure you consume messages on this configuration.{noformat} > which comes from threads like these, trying to obtain credits for sending: > > {noformat} > "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on > lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) > at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) > at > org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) > at > com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) > at > com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) > at > com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) > at > org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) > 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 > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown > Source) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > Locked synchronizers: count = 1 > - java.util.concurrent.ThreadPoolExecutor$Worker@bc49fcf > {noformat} > which will never succeed, since the credits seem to no suffice (see heap-dump > screenshot) >
[jira] [Updated] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2586: --- Attachment: Message-Counts.png > Inifinite Block in AMQ212054 after transient DB-error > - > > Key: ARTEMIS-2586 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2586 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.10.1 > Environment: This is Ubuntu 18.04 and Oracle DB, but don't think it's > that relevant for the issue. >Reporter: Rico Neubauer >Priority: Major > Attachments: 2019-11-28_threaddump_01.txt, > 2019-12-04_threaddump_01.txt, Message-Counts.png, initial-error.txt, > log-extract.txt, writerIndex-Credits.PNG > > > Hi, > Would like to describe a quite severe situation which was expirienced in a > long-running test with 2 out of 3 instances/machines. > We are running Karaf with Artemis 2.10.1. > After some time (see screenshot), first one, then after a while a 2nd > instance came to a complete stop. > Looking into the logs and thread-dumps revealed the following (same for bith > instances): > # There was a temporary problem connecting to the DB (\{{connection reset by > peer}}and \{{Closed Connection }}) > # This resulted (due to handling on our side) in an > \{{IllegalStateException}}/\{{Error during two phase commit}} being thrown > back to Artemis. > # After this, there is no messaging possible anymore at all and the > following log repeats: > {noformat} > AMQ212054: Destination address=DLQ is blocked. If the system is configured to > block make sure you consume messages on this configuration.{noformat} > which comes from threads like these, trying to obtain credits for sending: > > {noformat} > "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on > lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) > at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) > at > org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) > at > com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) > at > com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) > at > com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) > at > org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) > 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 > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown > Source) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > Locked synchronizers: count = 1 > - java.util.concurrent.ThreadPoolExecutor$Worker@bc49fcf > {noformat} > which will never succeed, since the credits seem to no suffice (see heap-dump > screenshot) > From
[jira] [Updated] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2586: --- Attachment: log-extract.txt > Inifinite Block in AMQ212054 after transient DB-error > - > > Key: ARTEMIS-2586 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2586 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.10.1 > Environment: This is Ubuntu 18.04 and Oracle DB, but don't think it's > that relevant for the issue. >Reporter: Rico Neubauer >Priority: Major > Attachments: 2019-11-28_threaddump_01.txt, > 2019-12-04_threaddump_01.txt, Message-Counts.png, initial-error.txt, > log-extract.txt, writerIndex-Credits.PNG > > > Hi, > Would like to describe a quite severe situation which was expirienced in a > long-running test with 2 out of 3 instances/machines. > We are running Karaf with Artemis 2.10.1. > After some time (see screenshot), first one, then after a while a 2nd > instance came to a complete stop. > Looking into the logs and thread-dumps revealed the following (same for bith > instances): > # There was a temporary problem connecting to the DB (\{{connection reset by > peer}}and \{{Closed Connection }}) > # This resulted (due to handling on our side) in an > \{{IllegalStateException}}/\{{Error during two phase commit}} being thrown > back to Artemis. > # After this, there is no messaging possible anymore at all and the > following log repeats: > {noformat} > AMQ212054: Destination address=DLQ is blocked. If the system is configured to > block make sure you consume messages on this configuration.{noformat} > which comes from threads like these, trying to obtain credits for sending: > > {noformat} > "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on > lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) > at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) > at > org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) > at > com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) > at > com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) > at > com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) > at > org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) > 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 > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown > Source) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > Locked synchronizers: count = 1 > - java.util.concurrent.ThreadPoolExecutor$Worker@bc49fcf > {noformat} > which will never succeed, since the credits seem to no suffice (see heap-dump > screenshot) > From my
[jira] [Updated] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2586: --- Attachment: 2019-11-28_threaddump_01.txt > Inifinite Block in AMQ212054 after transient DB-error > - > > Key: ARTEMIS-2586 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2586 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.10.1 > Environment: This is Ubuntu 18.04 and Oracle DB, but don't think it's > that relevant for the issue. >Reporter: Rico Neubauer >Priority: Major > Attachments: 2019-11-28_threaddump_01.txt, > 2019-12-04_threaddump_01.txt, Message-Counts.png, initial-error.txt, > log-extract.txt, writerIndex-Credits.PNG > > > Hi, > Would like to describe a quite severe situation which was expirienced in a > long-running test with 2 out of 3 instances/machines. > We are running Karaf with Artemis 2.10.1. > After some time (see screenshot), first one, then after a while a 2nd > instance came to a complete stop. > Looking into the logs and thread-dumps revealed the following (same for bith > instances): > # There was a temporary problem connecting to the DB (\{{connection reset by > peer}}and \{{Closed Connection }}) > # This resulted (due to handling on our side) in an > \{{IllegalStateException}}/\{{Error during two phase commit}} being thrown > back to Artemis. > # After this, there is no messaging possible anymore at all and the > following log repeats: > {noformat} > AMQ212054: Destination address=DLQ is blocked. If the system is configured to > block make sure you consume messages on this configuration.{noformat} > which comes from threads like these, trying to obtain credits for sending: > > {noformat} > "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on > lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) > at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) > at > org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) > at > com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) > at > com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) > at > com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) > at > org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) > 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 > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown > Source) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > Locked synchronizers: count = 1 > - java.util.concurrent.ThreadPoolExecutor$Worker@bc49fcf > {noformat} > which will never succeed, since the credits seem to no suffice (see heap-dump > screensh
[jira] [Created] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
Rico Neubauer created ARTEMIS-2586: -- Summary: Inifinite Block in AMQ212054 after transient DB-error Key: ARTEMIS-2586 URL: https://issues.apache.org/jira/browse/ARTEMIS-2586 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.10.1 Environment: This is Ubuntu 18.04 and Oracle DB, but don't think it's that relevant for the issue. Reporter: Rico Neubauer Attachments: initial-error.txt Hi, Would like to describe a quite severe situation which was expirienced in a long-running test with 2 out of 3 instances/machines. We are running Karaf with Artemis 2.10.1. After some time (see screenshot), first one, then after a while a 2nd instance came to a complete stop. Looking into the logs and thread-dumps revealed the following (same for bith instances): # There was a temporary problem connecting to the DB (\{{connection reset by peer}}and \{{Closed Connection }}) # This resulted (due to handling on our side) in an \{{IllegalStateException}}/\{{Error during two phase commit}} being thrown back to Artemis. # After this, there is no messaging possible anymore at all and the following log repeats: {noformat} AMQ212054: Destination address=DLQ is blocked. If the system is configured to block make sure you consume messages on this configuration.{noformat} which comes from threads like these, trying to obtain credits for sending: {noformat} "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) at org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) at org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) at org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) at org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) at com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) at com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) at com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) at org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) 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 org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) Locked synchronizers: count = 1 - java.util.concurrent.ThreadPoolExecutor$Worker@bc49fcf {noformat} which will never succeed, since the credits seem to no suffice (see heap-dump screenshot) >From my point of view, the thrown IllegalStateException should not lead to the >system going in this non-recoverable state, what do you think, is there >something that can be enhanced? [Fastthread-Link|https://fastthread.io/my-thread-report.jsp?p=c2hhcmVkLzIwMjAvMDEvMy8tLTIwMTktMTItMDRfdGhyZWFkZHVtcF8wMS50eHQtLTEzLTM4LTE1OzstLTIwMTktMTEtMjhfdGhyZWFkZHVtcF8wMS50eHQtLTEzLTM4LTE1] In case it helps: The 2 instances are still in this state (since September) and I can fetch additional information or debug them on reques
[jira] [Updated] (ARTEMIS-2586) Inifinite Block in AMQ212054 after transient DB-error
[ https://issues.apache.org/jira/browse/ARTEMIS-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2586: --- Attachment: initial-error.txt > Inifinite Block in AMQ212054 after transient DB-error > - > > Key: ARTEMIS-2586 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2586 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.10.1 > Environment: This is Ubuntu 18.04 and Oracle DB, but don't think it's > that relevant for the issue. >Reporter: Rico Neubauer >Priority: Major > Attachments: initial-error.txt > > > Hi, > Would like to describe a quite severe situation which was expirienced in a > long-running test with 2 out of 3 instances/machines. > We are running Karaf with Artemis 2.10.1. > After some time (see screenshot), first one, then after a while a 2nd > instance came to a complete stop. > Looking into the logs and thread-dumps revealed the following (same for bith > instances): > # There was a temporary problem connecting to the DB (\{{connection reset by > peer}}and \{{Closed Connection }}) > # This resulted (due to handling on our side) in an > \{{IllegalStateException}}/\{{Error during two phase commit}} being thrown > back to Artemis. > # After this, there is no messaging possible anymore at all and the > following log repeats: > {noformat} > AMQ212054: Destination address=DLQ is blocked. If the system is configured to > block make sure you consume messages on this configuration.{noformat} > which comes from threads like these, trying to obtain credits for sending: > > {noformat} > "Thread-93 (ActiveMQ-client-global-threads)" Id=2001 in TIMED_WAITING on > lock=java.util.concurrent.Semaphore$NonfairSync@1f9a57e0 > at sun.misc.Unsafe.park(Native Method) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1039) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1332) > at java.util.concurrent.Semaphore.tryAcquire(Semaphore.java:582) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl.actualAcquire(ClientProducerCreditsImpl.java:73) > at > org.apache.activemq.artemis.core.client.impl.AbstractProducerCreditsImpl.acquireCredits(AbstractProducerCreditsImpl.java:77) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:301) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:275) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:128) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:485) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:195) > at > com.seeburger.engine.jms.MessageReceiverBase.sendToDLQ(MessageReceiverBase.java:571) > at > com.seeburger.engine.jms.MessageReceiverBase.handleException(MessageReceiverBase.java:493) > at > com.seeburger.engine.jms.MessageReceiverBase.onMessage(MessageReceiverBase.java:387) > at > org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:110) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1031) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) > at > org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1154) > 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 > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$431/1769898766.run(Unknown > Source) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > Locked synchronizers: count = 1 > - java.util.concurrent.ThreadPoolExecutor$Worker@bc49fcf > {noformat} > which will never succeed, since the credits seem to no suffice (see heap-dump > screenshot) > From my point of view, the thrown IllegalStateException should not lead to > the system going in this non-recoverable state, what do
[jira] [Commented] (ARTEMIS-2426) Allow artemis-native loading Libraries from Bundle
[ https://issues.apache.org/jira/browse/ARTEMIS-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953499#comment-16953499 ] Rico Neubauer commented on ARTEMIS-2426: fyi: Resulting Manifest entry: {noformat} Bundle-NativeCode: lib/linux-i686/libartemis-native-32.so; osname=Linux; processor=x86, lib/linux-x86_64/libartemis-native-64.so; osname=Linux; processor=x86-64, *{noformat} > Allow artemis-native loading Libraries from Bundle > -- > > Key: ARTEMIS-2426 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2426 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: ActiveMQ-Artemis-Native >Affects Versions: native-1.0.0 >Reporter: Rico Neubauer >Assignee: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > artemis-native currently expects the native libraries to be in the native > library path on filesystem. The libraries are shipped in the bundle though > already. > There is header _Bundle-Native_ which can be used to declare the path inside > the bundle to look for the libraries. The way they get loaded > (System.loadLibrary) already matches to find them. > See section 3.10 in OSGi spec (4.3). > Will push a PR, which creates the header for x86 and x86-64, since those are > the 2 that are also shipped in the bundle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2426) Allow artemis-native loading Libraries from Bundle
[ https://issues.apache.org/jira/browse/ARTEMIS-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2426: --- External issue ID: 86989 > Allow artemis-native loading Libraries from Bundle > -- > > Key: ARTEMIS-2426 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2426 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: ActiveMQ-Artemis-Native >Affects Versions: native-1.0.0 >Reporter: Rico Neubauer >Assignee: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > artemis-native currently expects the native libraries to be in the native > library path on filesystem. The libraries are shipped in the bundle though > already. > There is header _Bundle-Native_ which can be used to declare the path inside > the bundle to look for the libraries. The way they get loaded > (System.loadLibrary) already matches to find them. > See section 3.10 in OSGi spec (4.3). > Will push a PR, which creates the header for x86 and x86-64, since those are > the 2 that are also shipped in the bundle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARTEMIS-2490) JournalStorageManager#parseLargeMessage may produce fatal issue when reading ORIG_ID
[ https://issues.apache.org/jira/browse/ARTEMIS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2490: --- Description: Preface: Found the issue initially with HornetQ and Stacktrace below is from HornetQ, but checked Artemis and issue there exists in the same manner. If there is a large-message in journal, this gets parsed on startup while doing initialization. While doing that property "__AMQ_ORIG_MESSAGE_ID_" (in HornetQ "HQ" instead of "AMQ") is always read, _for compatibility_ according to code. Problem with that: In case the property does not hold a number, but sth. like "_ID:c6e2e3..._", then a NumberFormatException is thrown, which falls thru the entire initialization mechanism and leads to a non-functioning server. I have no idea, who sets this, but seems internally, since we have no code doing this. Looks like a JMS-Message-ID to me. Mabye this whole compatibility code is not needed anymore - cannot say though. What I would like to request: # Move the retrieval of the property inside the compatibility-block in org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage - since it is not needed otherwise and already avoids the issue in the vast majority where no compatibility must be done. # -In addition, a check for the "ID:" prefix and removing it before parsing to Long.- Edit: Sorry that was wrong, but: Adding a try for parsing to Long and handling not-a-number gracefully, so server continues startup. See PR for first. Just fyi: the fix for HornetQ: [Github (containing wrong logic for parsing)|https://github.com/seeburger-ag/hornetq/commit/8ef99744f219b23d76803435201e4af33a53b3c5] Stacktrace (as said: based on HornetQ code, but class- and method-names are the same): {code:java} Failure in initialisation: java.lang.NumberFormatException: For input string: "ID:c6e2e367-d77e-11e9-9471-005056b7cdce" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Long.parseLong(Long.java:589) at java.lang.Long.parseLong(Long.java:631) at org.hornetq.utils.TypedProperties.getLongProperty(TypedProperties.java:330) at org.hornetq.core.message.impl.MessageImpl.getLongProperty(MessageImpl.java:762) at org.hornetq.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage(JournalStorageManager.java:1764) at org.hornetq.core.persistence.impl.journal.JournalStorageManager.loadMessageJournal(JournalStorageManager.java:953) at org.hornetq.core.server.impl.HornetQServerImpl.loadJournals(HornetQServerImpl.java:1603) at org.hornetq.core.server.impl.HornetQServerImpl.initialisePart2(HornetQServerImpl.java:1445) at org.hornetq.core.server.impl.HornetQServerImpl.access$1200(HornetQServerImpl.java:138) at org.hornetq.core.server.impl.HornetQServerImpl$SharedStoreLiveActivation.run(HornetQServerImpl.java:1919) at org.hornetq.core.server.impl.HornetQServerImpl.start(HornetQServerImpl.java:366) at org.hornetq.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:269) {code} was: Preface: Found the issue initially with HornetQ and Stacktrace below is from HornetQ, but checked Artemis and issue there exists in the same manner. If there is a large-message in journal, this gets parsed on startup while doing initialization. While doing that property "__AMQ_ORIG_MESSAGE_ID_" (in HornetQ "HQ" instead of "AMQ") is always read, _for compatibility_ according to code. Problem with that: In case the property does not hold a number, but sth. like "_ID:c6e2e3..._", then a NumberFormatException is thrown, which falls thru the entire initialization mechanism and leads to a non-functioning server. I have no idea, who sets this "ID:" prefix, but seems internally, since we have no code doing this. Mabye this whole compatibility code is not needed anymore - cannot say though. What I would like to request: # Move the retrieval of the property inside the compatibility-block in org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage - since it is not needed otherwise and already avoids the issue in the vast majority where no compatibility must be done. # In addition, a check for the "ID:" prefix and removing it before parsing to Long. See PR for first. Just fyi: the fix for HornetQ: [Github|https://github.com/seeburger-ag/hornetq/commit/8ef99744f219b23d76803435201e4af33a53b3c5] Stacktrace (as said: based on HornetQ code, but class- and method-names are the same): {code:java} Failure in initialisation: java.lang.NumberFormatException: For input string: "ID:c6e2e367-d77e-11e9-9471-005056b7cdce" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Long.parseLong(Long.java:589) at java.lang.Long.parseLong(Long.java:631) at org.hornetq.
[jira] [Updated] (ARTEMIS-2490) JournalStorageManager#parseLargeMessage may produce fatal issue when reading ORIG_ID
[ https://issues.apache.org/jira/browse/ARTEMIS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2490: --- Description: Preface: Found the issue initially with HornetQ and Stacktrace below is from HornetQ, but checked Artemis and issue there exists in the same manner. If there is a large-message in journal, this gets parsed on startup while doing initialization. While doing that property "__AMQ_ORIG_MESSAGE_ID_" (in HornetQ "HQ" instead of "AMQ") is always read, _for compatibility_ according to code. Problem with that: In case the property does not hold a number, but sth. like "_ID:c6e2e3..._", then a NumberFormatException is thrown, which falls thru the entire initialization mechanism and leads to a non-functioning server. I have no idea, who sets this "ID:" prefix, but seems internally, since we have no code doing this. Mabye this whole compatibility code is not needed anymore - cannot say though. What I would like to request: # Move the retrieval of the property inside the compatibility-block in org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage - since it is not needed otherwise and already avoids the issue in the vast majority where no compatibility must be done. # In addition, a check for the "ID:" prefix and removing it before parsing to Long. See PR for first. Just fyi: the fix for HornetQ: [Github|https://github.com/seeburger-ag/hornetq/commit/8ef99744f219b23d76803435201e4af33a53b3c5] Stacktrace (as said: based on HornetQ code, but class- and method-names are the same): {code:java} Failure in initialisation: java.lang.NumberFormatException: For input string: "ID:c6e2e367-d77e-11e9-9471-005056b7cdce" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Long.parseLong(Long.java:589) at java.lang.Long.parseLong(Long.java:631) at org.hornetq.utils.TypedProperties.getLongProperty(TypedProperties.java:330) at org.hornetq.core.message.impl.MessageImpl.getLongProperty(MessageImpl.java:762) at org.hornetq.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage(JournalStorageManager.java:1764) at org.hornetq.core.persistence.impl.journal.JournalStorageManager.loadMessageJournal(JournalStorageManager.java:953) at org.hornetq.core.server.impl.HornetQServerImpl.loadJournals(HornetQServerImpl.java:1603) at org.hornetq.core.server.impl.HornetQServerImpl.initialisePart2(HornetQServerImpl.java:1445) at org.hornetq.core.server.impl.HornetQServerImpl.access$1200(HornetQServerImpl.java:138) at org.hornetq.core.server.impl.HornetQServerImpl$SharedStoreLiveActivation.run(HornetQServerImpl.java:1919) at org.hornetq.core.server.impl.HornetQServerImpl.start(HornetQServerImpl.java:366) at org.hornetq.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:269) {code} was: Preface: Found the issue initially with HornetQ and Stacktrace below is from HornetQ, but checked Artemis and issue there exists in the same manner. If there is a large-message in journal, this gets parsed on startup while doing initialization. While doing that property "__AMQ_ORIG_MESSAGE_ID_" (in HornetQ "HQ" instead of "AMQ") is always read, _for compatibility_ according to code. Problem with that: In case the property does not hold a number, but sth. like "_ID:c6e2e3..._", then a NumberFormatException is thrown, which falls thru the entire initialization mechanism and leads to a non-functioning server. I have no idea, who sets this "ID:" prefix, but seems internally, since we have no code doing this. Mabye this whole compatibility code is not needed anymore - cannot say though. What I would like to request: # Move the retrieval of the property inside the compatibility-block in org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage - since it is not needed otherwise and already avoids the issue in the vast majority where no compatibility must be done. # In addition, a check for the "ID:" prefix and removing it before parsing to Long. See PR for both. Just fyi: the fix for HornetQ: [Github|https://github.com/seeburger-ag/hornetq/commit/8ef99744f219b23d76803435201e4af33a53b3c5] Stacktrace (as said: based on HornetQ code, but class- and method-names are the same): {code:java} Failure in initialisation: java.lang.NumberFormatException: For input string: "ID:c6e2e367-d77e-11e9-9471-005056b7cdce" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Long.parseLong(Long.java:589) at java.lang.Long.parseLong(Long.java:631) at org.hornetq.utils.TypedProperties.getLongProperty(TypedProperties.java:330) at org.hornetq.core.message.impl.MessageImpl.getLongProperty(MessageImpl.java:762) at org.hornetq.core.persistence.impl.jo
[jira] [Updated] (ARTEMIS-2490) JournalStorageManager#parseLargeMessage may produce fatal issue when reading ORIG_ID
[ https://issues.apache.org/jira/browse/ARTEMIS-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2490: --- Description: Preface: Found the issue initially with HornetQ and Stacktrace below is from HornetQ, but checked Artemis and issue there exists in the same manner. If there is a large-message in journal, this gets parsed on startup while doing initialization. While doing that property "__AMQ_ORIG_MESSAGE_ID_" (in HornetQ "HQ" instead of "AMQ") is always read, _for compatibility_ according to code. Problem with that: In case the property does not hold a number, but sth. like "_ID:c6e2e3..._", then a NumberFormatException is thrown, which falls thru the entire initialization mechanism and leads to a non-functioning server. I have no idea, who sets this "ID:" prefix, but seems internally, since we have no code doing this. Mabye this whole compatibility code is not needed anymore - cannot say though. What I would like to request: # Move the retrieval of the property inside the compatibility-block in org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage - since it is not needed otherwise and already avoids the issue in the vast majority where no compatibility must be done. # In addition, a check for the "ID:" prefix and removing it before parsing to Long. See PR for both. Just fyi: the fix for HornetQ: [Github|https://github.com/seeburger-ag/hornetq/commit/8ef99744f219b23d76803435201e4af33a53b3c5] Stacktrace (as said: based on HornetQ code, but class- and method-names are the same): {code:java} Failure in initialisation: java.lang.NumberFormatException: For input string: "ID:c6e2e367-d77e-11e9-9471-005056b7cdce" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Long.parseLong(Long.java:589) at java.lang.Long.parseLong(Long.java:631) at org.hornetq.utils.TypedProperties.getLongProperty(TypedProperties.java:330) at org.hornetq.core.message.impl.MessageImpl.getLongProperty(MessageImpl.java:762) at org.hornetq.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage(JournalStorageManager.java:1764) at org.hornetq.core.persistence.impl.journal.JournalStorageManager.loadMessageJournal(JournalStorageManager.java:953) at org.hornetq.core.server.impl.HornetQServerImpl.loadJournals(HornetQServerImpl.java:1603) at org.hornetq.core.server.impl.HornetQServerImpl.initialisePart2(HornetQServerImpl.java:1445) at org.hornetq.core.server.impl.HornetQServerImpl.access$1200(HornetQServerImpl.java:138) at org.hornetq.core.server.impl.HornetQServerImpl$SharedStoreLiveActivation.run(HornetQServerImpl.java:1919) at org.hornetq.core.server.impl.HornetQServerImpl.start(HornetQServerImpl.java:366) at org.hornetq.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:269) {code} was: Preface: Found the issue initially with HornetQ and Stacktrace below is from HornetQ, but checked Artemis and issue there exists in the same manner. If there is a large-message in journal, this gets parsed on startup while doing initialization. While doing that property "__AMQ_ORIG_MESSAGE_ID_" (in HornetQ "HQ" instead of "AMQ") is always read, _for compatibility_ according to code. Problem with that: In case the property does not hold a number, but sth. like "_ID:c6e2e3..._", then a NumberFormatException is thrown, which falls thru the entire initialization mechanism and leads to a non-functioning server. I have no idea, who sets this "ID:" prefix, but seems internally, since we have no code doing this. Mabye this whole compatibility code is not needed anymore - cannot say though. What I would like to request: # Move the retrieval of the property inside the compatibility-block in org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage - since it is not needed otherwise and already avoids the issue in the vast majority where no compatibility must be done. # In addition, a check for the "ID:" prefix and removing it before parsing to Long. See PR for both. Just fyi: the fix for HornetQ: [Github|https://github.com/seeburger-ag/hornetq/commit/8ef99744f219b23d76803435201e4af33a53b3c5] {noformat} Failure in initialisation: java.lang.NumberFormatException: For input string: "ID:c6e2e367-d77e-11e9-9471-005056b7cdce"Failure in initialisation: java.lang.NumberFormatException: For input string: "ID:c6e2e367-d77e-11e9-9471-005056b7cdce" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Long.parseLong(Long.java:589) at java.lang.Long.parseLong(Long.java:631) at org.hornetq.utils.TypedProperties.getLongProperty(TypedProperties.java:330) at org.hornetq.core.message.impl.MessageImpl.getLongProperty(MessageImpl.java:762) at org.hornetq.core.persistenc
[jira] [Created] (ARTEMIS-2490) JournalStorageManager#parseLargeMessage may produce fatal issue when reading ORIG_ID
Rico Neubauer created ARTEMIS-2490: -- Summary: JournalStorageManager#parseLargeMessage may produce fatal issue when reading ORIG_ID Key: ARTEMIS-2490 URL: https://issues.apache.org/jira/browse/ARTEMIS-2490 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.10.0 Reporter: Rico Neubauer Preface: Found the issue initially with HornetQ and Stacktrace below is from HornetQ, but checked Artemis and issue there exists in the same manner. If there is a large-message in journal, this gets parsed on startup while doing initialization. While doing that property "__AMQ_ORIG_MESSAGE_ID_" (in HornetQ "HQ" instead of "AMQ") is always read, _for compatibility_ according to code. Problem with that: In case the property does not hold a number, but sth. like "_ID:c6e2e3..._", then a NumberFormatException is thrown, which falls thru the entire initialization mechanism and leads to a non-functioning server. I have no idea, who sets this "ID:" prefix, but seems internally, since we have no code doing this. Mabye this whole compatibility code is not needed anymore - cannot say though. What I would like to request: # Move the retrieval of the property inside the compatibility-block in org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage - since it is not needed otherwise and already avoids the issue in the vast majority where no compatibility must be done. # In addition, a check for the "ID:" prefix and removing it before parsing to Long. See PR for both. Just fyi: the fix for HornetQ: [Github|https://github.com/seeburger-ag/hornetq/commit/8ef99744f219b23d76803435201e4af33a53b3c5] {noformat} Failure in initialisation: java.lang.NumberFormatException: For input string: "ID:c6e2e367-d77e-11e9-9471-005056b7cdce"Failure in initialisation: java.lang.NumberFormatException: For input string: "ID:c6e2e367-d77e-11e9-9471-005056b7cdce" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Long.parseLong(Long.java:589) at java.lang.Long.parseLong(Long.java:631) at org.hornetq.utils.TypedProperties.getLongProperty(TypedProperties.java:330) at org.hornetq.core.message.impl.MessageImpl.getLongProperty(MessageImpl.java:762) at org.hornetq.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage(JournalStorageManager.java:1764) at org.hornetq.core.persistence.impl.journal.JournalStorageManager.loadMessageJournal(JournalStorageManager.java:953) at org.hornetq.core.server.impl.HornetQServerImpl.loadJournals(HornetQServerImpl.java:1603) at org.hornetq.core.server.impl.HornetQServerImpl.initialisePart2(HornetQServerImpl.java:1445) at org.hornetq.core.server.impl.HornetQServerImpl.access$1200(HornetQServerImpl.java:138) at org.hornetq.core.server.impl.HornetQServerImpl$SharedStoreLiveActivation.run(HornetQServerImpl.java:1919) at org.hornetq.core.server.impl.HornetQServerImpl.start(HornetQServerImpl.java:366) at org.hornetq.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:269){noformat} -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (ARTEMIS-2487) artemis-server-osgi references not-existing jctools:2.2.0
[ https://issues.apache.org/jira/browse/ARTEMIS-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rico Neubauer updated ARTEMIS-2487: --- Fix Version/s: 2.11.0 > artemis-server-osgi references not-existing jctools:2.2.0 > - > > Key: ARTEMIS-2487 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2487 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: osgi >Affects Versions: 2.10.0 >Reporter: Rico Neubauer >Priority: Major > Fix For: 2.11.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Have a look in released org.apache.activemq:artemis-server-osgi:2.10.0 > ([https://search.maven.org/artifact/org.apache.activemq/artemis-server-osgi/2.10.0/bundle)] > There is an import towards > {noformat} > org.jctools.queues;version="[2.2,3)"{noformat} > > No such version exists. Latest version existing is 2.1.2 and in Artemis' > parent pom.xml version 2.1.1 is referenced. > https://search.maven.org/search?q=a:jctools-core > This obviously leads to being not deployable in an OSGi-container. > So far did not see where that ghost version could come from. > Error in Karaf: > > {noformat} > org.apache.felix.resolver.reason.ReasonException: Unable to resolve > org.apache.activemq.artemis-server-osgi/2.10.0: missing requirement > [org.apache.activemq.artemis-server-osgi/2.10.0] osgi.wiring.package; > filter:="(&(osgi.wiring.package=org.jctools.queues)(version>=2.2.0)(!(version>=3.0.0)))"{noformat} > > Dependency itself was introduced with ARTEMIS-2399. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (ARTEMIS-2487) artemis-server-osgi references not-existing jctools:2.2.0
[ https://issues.apache.org/jira/browse/ARTEMIS-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16930323#comment-16930323 ] Rico Neubauer commented on ARTEMIS-2487: Closed with [d13d28450b16b9c4dc31d9353e2a1b7c0d147683|https://github.com/apache/activemq-artemis/commit/d13d28450b16b9c4dc31d9353e2a1b7c0d147683] > artemis-server-osgi references not-existing jctools:2.2.0 > - > > Key: ARTEMIS-2487 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2487 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: osgi >Affects Versions: 2.10.0 >Reporter: Rico Neubauer >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Have a look in released org.apache.activemq:artemis-server-osgi:2.10.0 > ([https://search.maven.org/artifact/org.apache.activemq/artemis-server-osgi/2.10.0/bundle)] > There is an import towards > {noformat} > org.jctools.queues;version="[2.2,3)"{noformat} > > No such version exists. Latest version existing is 2.1.2 and in Artemis' > parent pom.xml version 2.1.1 is referenced. > https://search.maven.org/search?q=a:jctools-core > This obviously leads to being not deployable in an OSGi-container. > So far did not see where that ghost version could come from. > Error in Karaf: > > {noformat} > org.apache.felix.resolver.reason.ReasonException: Unable to resolve > org.apache.activemq.artemis-server-osgi/2.10.0: missing requirement > [org.apache.activemq.artemis-server-osgi/2.10.0] osgi.wiring.package; > filter:="(&(osgi.wiring.package=org.jctools.queues)(version>=2.2.0)(!(version>=3.0.0)))"{noformat} > > Dependency itself was introduced with ARTEMIS-2399. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (ARTEMIS-2487) artemis-server-osgi references not-existing jctools:2.2.0
[ https://issues.apache.org/jira/browse/ARTEMIS-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16929281#comment-16929281 ] Rico Neubauer edited comment on ARTEMIS-2487 at 9/13/19 3:54 PM: - OK, found it. maven-bundle-plugin takes the version from export declaration of dependency. jctools:2.1.1 had a bug, that it exported its packages as 2.2.0. See manifest of [jctools-core-2.1.1|https://search.maven.org/remotecontent?filepath=org/jctools/jctools-core/2.1.1/jctools-core-2.1.1.jar] This was fixed in 2.1.2 and it exports correctly as 2.1.2. Pragmatic approach therefore: Update to 2.1.2 as already discussed in ARTEMIS-2399. Pull-Request sent. Tested it locally and result is the correct import declaration: {noformat} org.jctools.queues;version="[2.1,3)"{noformat} was (Author: riconeubauer): OK, found it. maven-bundle-plugin takes the version from export declaration of dependency. jctools:2.1.1 had a bug, that it exported its packages as 2.2.0. See manifest of [https://search.maven.org/remotecontent?filepath=org/jctools/jctools-core/2.1.1/jctools-core-2.1.1.jar|jctools-core-2.1.1] This was fixed in 2.1.2 and it exports correctly as 2.1.2. Pragmatic approach therefore: Update to 2.1.2 as already discussed in ARTEMIS-2399. Pull-Request sent. Tested it locally and result is the correct import declaration: {noformat} org.jctools.queues;version="[2.1,3)"{noformat} > artemis-server-osgi references not-existing jctools:2.2.0 > - > > Key: ARTEMIS-2487 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2487 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: osgi >Affects Versions: 2.10.0 >Reporter: Rico Neubauer >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Have a look in released org.apache.activemq:artemis-server-osgi:2.10.0 > ([https://search.maven.org/artifact/org.apache.activemq/artemis-server-osgi/2.10.0/bundle)] > There is an import towards > {noformat} > org.jctools.queues;version="[2.2,3)"{noformat} > > No such version exists. Latest version existing is 2.1.2 and in Artemis' > parent pom.xml version 2.1.1 is referenced. > https://search.maven.org/search?q=a:jctools-core > This obviously leads to being not deployable in an OSGi-container. > So far did not see where that ghost version could come from. > Error in Karaf: > > {noformat} > org.apache.felix.resolver.reason.ReasonException: Unable to resolve > org.apache.activemq.artemis-server-osgi/2.10.0: missing requirement > [org.apache.activemq.artemis-server-osgi/2.10.0] osgi.wiring.package; > filter:="(&(osgi.wiring.package=org.jctools.queues)(version>=2.2.0)(!(version>=3.0.0)))"{noformat} > > Dependency itself was introduced with ARTEMIS-2399. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (ARTEMIS-2487) artemis-server-osgi references not-existing jctools:2.2.0
[ https://issues.apache.org/jira/browse/ARTEMIS-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16929281#comment-16929281 ] Rico Neubauer edited comment on ARTEMIS-2487 at 9/13/19 3:21 PM: - OK, found it. maven-bundle-plugin takes the version from export declaration of dependency. jctools:2.1.1 had a bug, that it exported its packages as 2.2.0. See manifest of [https://search.maven.org/remotecontent?filepath=org/jctools/jctools-core/2.1.1/jctools-core-2.1.1.jar|jctools-core-2.1.1] This was fixed in 2.1.2 and it exports correctly as 2.1.2. Pragmatic approach therefore: Update to 2.1.2 as already discussed in ARTEMIS-2399. Pull-Request sent. Tested it locally and result is the correct import declaration: {noformat} org.jctools.queues;version="[2.1,3)"{noformat} was (Author: riconeubauer): OK, found it. maven-bundle-plugin takes the version from export declaration of dependency. jctools:2.1.1 had a bug, that it exported its packages as 2.2.0. See manifest of [https://search.maven.org/remotecontent?filepath=org/jctools/jctools-core/2.1.1/jctools-core-2.1.1.jar|jctools-core-2.1.1] This was fixed in 2.1.2 and it exports correctly as 2.1.2. Pragmatic approach therefore: Update to 2.1.2 as already discussed in ARTEMIS-2399. Tested it locally and result is the correct import declaration: {noformat} org.jctools.queues;version="[2.1,3)"{noformat} > artemis-server-osgi references not-existing jctools:2.2.0 > - > > Key: ARTEMIS-2487 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2487 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: osgi >Affects Versions: 2.10.0 >Reporter: Rico Neubauer >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Have a look in released org.apache.activemq:artemis-server-osgi:2.10.0 > ([https://search.maven.org/artifact/org.apache.activemq/artemis-server-osgi/2.10.0/bundle)] > There is an import towards > {noformat} > org.jctools.queues;version="[2.2,3)"{noformat} > > No such version exists. Latest version existing is 2.1.2 and in Artemis' > parent pom.xml version 2.1.1 is referenced. > https://search.maven.org/search?q=a:jctools-core > This obviously leads to being not deployable in an OSGi-container. > So far did not see where that ghost version could come from. > Error in Karaf: > > {noformat} > org.apache.felix.resolver.reason.ReasonException: Unable to resolve > org.apache.activemq.artemis-server-osgi/2.10.0: missing requirement > [org.apache.activemq.artemis-server-osgi/2.10.0] osgi.wiring.package; > filter:="(&(osgi.wiring.package=org.jctools.queues)(version>=2.2.0)(!(version>=3.0.0)))"{noformat} > > Dependency itself was introduced with ARTEMIS-2399. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (ARTEMIS-2487) artemis-server-osgi references not-existing jctools:2.2.0
[ https://issues.apache.org/jira/browse/ARTEMIS-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16929281#comment-16929281 ] Rico Neubauer edited comment on ARTEMIS-2487 at 9/13/19 3:15 PM: - OK, found it. maven-bundle-plugin takes the version from export declaration of dependency. jctools:2.1.1 had a bug, that it exported its packages as 2.2.0. See manifest of [https://search.maven.org/remotecontent?filepath=org/jctools/jctools-core/2.1.1/jctools-core-2.1.1.jar|jctools-core-2.1.1] This was fixed in 2.1.2 and it exports correctly as 2.1.2. Pragmatic approach therefore: Update to 2.1.2 as already discussed in ARTEMIS-2399. Tested it locally and result is the correct import declaration: {noformat} org.jctools.queues;version="[2.1,3)"{noformat} was (Author: riconeubauer): OK, found it. maven-bundle-plugin takes the version from export declaration of dependency. jctools:2.1.1 had a bug, that it exported its packages as 2.2.0. See manifest of [https://search.maven.org/remotecontent?filepath=org/jctools/jctools-core/2.1.1/jctools-core-2.1.1.jar|jctools-core-2.1.1] This was fixed in 2.1.2 and it exports correctly as 2.1.2. Pragmatic approach therefore: Updated to 2.1.2 as already discussed in ARTEMIS-2399. Tested it locally and result is the correct import declaration: {noformat} org.jctools.queues;version="[2.1,3)"{noformat} > artemis-server-osgi references not-existing jctools:2.2.0 > - > > Key: ARTEMIS-2487 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2487 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: osgi >Affects Versions: 2.10.0 >Reporter: Rico Neubauer >Priority: Major > > Have a look in released org.apache.activemq:artemis-server-osgi:2.10.0 > ([https://search.maven.org/artifact/org.apache.activemq/artemis-server-osgi/2.10.0/bundle)] > There is an import towards > {noformat} > org.jctools.queues;version="[2.2,3)"{noformat} > > No such version exists. Latest version existing is 2.1.2 and in Artemis' > parent pom.xml version 2.1.1 is referenced. > https://search.maven.org/search?q=a:jctools-core > This obviously leads to being not deployable in an OSGi-container. > So far did not see where that ghost version could come from. > Error in Karaf: > > {noformat} > org.apache.felix.resolver.reason.ReasonException: Unable to resolve > org.apache.activemq.artemis-server-osgi/2.10.0: missing requirement > [org.apache.activemq.artemis-server-osgi/2.10.0] osgi.wiring.package; > filter:="(&(osgi.wiring.package=org.jctools.queues)(version>=2.2.0)(!(version>=3.0.0)))"{noformat} > > Dependency itself was introduced with ARTEMIS-2399. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (ARTEMIS-2487) artemis-server-osgi references not-existing jctools:2.2.0
[ https://issues.apache.org/jira/browse/ARTEMIS-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16929281#comment-16929281 ] Rico Neubauer commented on ARTEMIS-2487: OK, found it. maven-bundle-plugin takes the version from export declaration of dependency. jctools:2.1.1 had a bug, that it exported its packages as 2.2.0. See manifest of [https://search.maven.org/remotecontent?filepath=org/jctools/jctools-core/2.1.1/jctools-core-2.1.1.jar|jctools-core-2.1.1] This was fixed in 2.1.2 and it exports correctly as 2.1.2. Pragmatic approach therefore: Updated to 2.1.2 as already discussed in ARTEMIS-2399. Tested it locally and result is the correct import declaration: {noformat} org.jctools.queues;version="[2.1,3)"{noformat} > artemis-server-osgi references not-existing jctools:2.2.0 > - > > Key: ARTEMIS-2487 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2487 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: osgi >Affects Versions: 2.10.0 >Reporter: Rico Neubauer >Priority: Major > > Have a look in released org.apache.activemq:artemis-server-osgi:2.10.0 > ([https://search.maven.org/artifact/org.apache.activemq/artemis-server-osgi/2.10.0/bundle)] > There is an import towards > {noformat} > org.jctools.queues;version="[2.2,3)"{noformat} > > No such version exists. Latest version existing is 2.1.2 and in Artemis' > parent pom.xml version 2.1.1 is referenced. > https://search.maven.org/search?q=a:jctools-core > This obviously leads to being not deployable in an OSGi-container. > So far did not see where that ghost version could come from. > Error in Karaf: > > {noformat} > org.apache.felix.resolver.reason.ReasonException: Unable to resolve > org.apache.activemq.artemis-server-osgi/2.10.0: missing requirement > [org.apache.activemq.artemis-server-osgi/2.10.0] osgi.wiring.package; > filter:="(&(osgi.wiring.package=org.jctools.queues)(version>=2.2.0)(!(version>=3.0.0)))"{noformat} > > Dependency itself was introduced with ARTEMIS-2399. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (ARTEMIS-2487) artemis-server-osgi references not-existing jctools:2.2.0
[ https://issues.apache.org/jira/browse/ARTEMIS-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16929270#comment-16929270 ] Rico Neubauer commented on ARTEMIS-2487: An ugly workaround would be to add the following to artemis-server-osgi's maven-bundle-plugin configuration: {noformat} org.jctools*;version="[${jctools.version},3)]"{noformat} but could still not figure out where that version 2.2 comes from. > artemis-server-osgi references not-existing jctools:2.2.0 > - > > Key: ARTEMIS-2487 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2487 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: osgi >Affects Versions: 2.10.0 >Reporter: Rico Neubauer >Priority: Major > > Have a look in released org.apache.activemq:artemis-server-osgi:2.10.0 > ([https://search.maven.org/artifact/org.apache.activemq/artemis-server-osgi/2.10.0/bundle)] > There is an import towards > {noformat} > org.jctools.queues;version="[2.2,3)"{noformat} > > No such version exists. Latest version existing is 2.1.2 and in Artemis' > parent pom.xml version 2.1.1 is referenced. > https://search.maven.org/search?q=a:jctools-core > This obviously leads to being not deployable in an OSGi-container. > So far did not see where that ghost version could come from. > Error in Karaf: > > {noformat} > org.apache.felix.resolver.reason.ReasonException: Unable to resolve > org.apache.activemq.artemis-server-osgi/2.10.0: missing requirement > [org.apache.activemq.artemis-server-osgi/2.10.0] osgi.wiring.package; > filter:="(&(osgi.wiring.package=org.jctools.queues)(version>=2.2.0)(!(version>=3.0.0)))"{noformat} > > Dependency itself was introduced with ARTEMIS-2399. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (ARTEMIS-2487) artemis-server-osgi references not-existing jctools:2.2.0
Rico Neubauer created ARTEMIS-2487: -- Summary: artemis-server-osgi references not-existing jctools:2.2.0 Key: ARTEMIS-2487 URL: https://issues.apache.org/jira/browse/ARTEMIS-2487 Project: ActiveMQ Artemis Issue Type: Bug Components: osgi Affects Versions: 2.10.0 Reporter: Rico Neubauer Have a look in released org.apache.activemq:artemis-server-osgi:2.10.0 ([https://search.maven.org/artifact/org.apache.activemq/artemis-server-osgi/2.10.0/bundle)] There is an import towards {noformat} org.jctools.queues;version="[2.2,3)"{noformat} No such version exists. Latest version existing is 2.1.2 and in Artemis' parent pom.xml version 2.1.1 is referenced. https://search.maven.org/search?q=a:jctools-core This obviously leads to being not deployable in an OSGi-container. So far did not see where that ghost version could come from. Error in Karaf: {noformat} org.apache.felix.resolver.reason.ReasonException: Unable to resolve org.apache.activemq.artemis-server-osgi/2.10.0: missing requirement [org.apache.activemq.artemis-server-osgi/2.10.0] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.jctools.queues)(version>=2.2.0)(!(version>=3.0.0)))"{noformat} Dependency itself was introduced with ARTEMIS-2399. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (ARTEMIS-2399) Improve Paging performance when there are a lot of subscribers
[ https://issues.apache.org/jira/browse/ARTEMIS-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928648#comment-16928648 ] Rico Neubauer commented on ARTEMIS-2399: allrighty, thanks > Improve Paging performance when there are a lot of subscribers > -- > > Key: ARTEMIS-2399 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2399 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.9.0 > Environment: broker 2.9.0 > cpu: 4 cores, memory: 8G, disk: ssd 500G > broker.xml: > 60 > > 51Mb > 50Mb > 1 > PAGE > > -1 >Reporter: yangwei >Priority: Major > Fix For: 2.10.0 > > Time Spent: 18h 40m > Remaining Estimate: 0h > > We noticed that there was a significant drop in performance when entering > page mode in the case of multiple subscribers. > We created a topic and 100 queues bound to it. We ran our _GrinderRunner > test_ in our inner test infra cluster with 500 threads producing message and > 560 threads, each one picked a random queue to subscribe. The test showed > performance is bad: 13000 msg/s sent and 5000 msg/s received. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (ARTEMIS-2399) Improve Paging performance when there are a lot of subscribers
[ https://issues.apache.org/jira/browse/ARTEMIS-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928607#comment-16928607 ] Rico Neubauer commented on ARTEMIS-2399: Is there a reason not taking the recent version (2.1.2) of jtools? > Improve Paging performance when there are a lot of subscribers > -- > > Key: ARTEMIS-2399 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2399 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.9.0 > Environment: broker 2.9.0 > cpu: 4 cores, memory: 8G, disk: ssd 500G > broker.xml: > 60 > > 51Mb > 50Mb > 1 > PAGE > > -1 >Reporter: yangwei >Priority: Major > Fix For: 2.10.0 > > Time Spent: 18h 40m > Remaining Estimate: 0h > > We noticed that there was a significant drop in performance when entering > page mode in the case of multiple subscribers. > We created a topic and 100 queues bound to it. We ran our _GrinderRunner > test_ in our inner test infra cluster with 500 threads producing message and > 560 threads, each one picked a random queue to subscribe. The test showed > performance is bad: 13000 msg/s sent and 5000 msg/s received. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (ARTEMIS-2426) Allow artemis-native loading Libraries from Bundle
Rico Neubauer created ARTEMIS-2426: -- Summary: Allow artemis-native loading Libraries from Bundle Key: ARTEMIS-2426 URL: https://issues.apache.org/jira/browse/ARTEMIS-2426 Project: ActiveMQ Artemis Issue Type: New Feature Components: ActiveMQ-Artemis-Native Affects Versions: native-1.0.0 Reporter: Rico Neubauer Assignee: clebert suconic artemis-native currently expects the native libraries to be in the native library path on filesystem. The libraries are shipped in the bundle though already. There is header _Bundle-Native_ which can be used to declare the path inside the bundle to look for the libraries. The way they get loaded (System.loadLibrary) already matches to find them. See section 3.10 in OSGi spec (4.3). Will push a PR, which creates the header for x86 and x86-64, since those are the 2 that are also shipped in the bundle. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (ARTEMIS-2269) Karaf config should use predefined etc-dir instead of hard-coded etc
Rico Neubauer created ARTEMIS-2269: -- Summary: Karaf config should use predefined etc-dir instead of hard-coded etc Key: ARTEMIS-2269 URL: https://issues.apache.org/jira/browse/ARTEMIS-2269 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.6.4 Reporter: Rico Neubauer In Karaf configuration file /artemis-features/src/main/resources/org.apache.activemq.artemis.cfg the path to karaf.etc directory is hard-coded with "etc": {noformat} config=file:etc/artemis.xml{noformat} This represents an issue if KARAF_ETC is reconfigured to point to another directory than "etc". Fix is easy, just using the predefined "karaf.etc" instead: {noformat} config=file:${karaf.etc}/artemis.xml{noformat} Will push a pull-request. -- This message was sent by Atlassian JIRA (v7.6.3#76005)