[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:
[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
[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:
[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=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=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, 1)) {
> <---
[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=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=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
[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=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) {
> throw
[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=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=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
>
[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=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
>
[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=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=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
[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
[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
[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
[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
[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=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=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=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
>
[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
[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
[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
[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
[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=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=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=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=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=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=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=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
>
[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
[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=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
>
[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=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 DB-error
>
[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
[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
[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
[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)
>
[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
>
[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
>
[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
[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
[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
[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=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
[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
[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
[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=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=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=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=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=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=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=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=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)
