[jira] [Comment Edited] (AMQ-9257) Disabled expire message checking when pauseDispatch=true
[ https://issues.apache.org/jira/browse/AMQ-9257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722950#comment-17722950 ] Matt Pavlovich edited comment on AMQ-9257 at 5/16/23 1:15 AM: -- [~cshannon] Yes, the queue can deadlock if you do administrative work on the queue while pauseDispatch = true and the expiry task executes to scan for expired messages. Also, _exipreMessages_ policyEntry setting is one of the config options that _cannot_ be updated at runtime. was (Author: mattrpav): [~cshannon] Yes, the queue can deadlock if you do administrative work on the queue while pauseDispatch = true and the expiry task executes to scan for expired messages. Also, exipreMessages is one of the config options that _cannot_ be updated at runtime. > Disabled expire message checking when pauseDispatch=true > > > Key: AMQ-9257 > URL: https://issues.apache.org/jira/browse/AMQ-9257 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 5.19.0, 5.17.5, 5.18.2 > > Time Spent: 10m > Remaining Estimate: 0h > > If pauseDispatch is set, the expiry checking should be ignored as well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (AMQ-9257) Disabled expire message checking when pauseDispatch=true
[ https://issues.apache.org/jira/browse/AMQ-9257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722950#comment-17722950 ] Matt Pavlovich edited comment on AMQ-9257 at 5/16/23 1:14 AM: -- [~cshannon] Yes, the queue can deadlock if you do administrative work on the queue while pauseDispatch = true and the expiry task executes to scan for expired messages. Also, exipreMessages is one of the config options that _cannot_ be updated at runtime. was (Author: mattrpav): [~cshannon] Yes, the queue can deadlock if you do administrative work on the queue while pauseDispatch = true and the expiry task executes to scan for expired messages. > Disabled expire message checking when pauseDispatch=true > > > Key: AMQ-9257 > URL: https://issues.apache.org/jira/browse/AMQ-9257 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 5.19.0, 5.17.5, 5.18.2 > > Time Spent: 10m > Remaining Estimate: 0h > > If pauseDispatch is set, the expiry checking should be ignored as well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (AMQ-9257) Disabled expire message checking when pauseDispatch=true
[ https://issues.apache.org/jira/browse/AMQ-9257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AMQ-9257 started by Matt Pavlovich. --- > Disabled expire message checking when pauseDispatch=true > > > Key: AMQ-9257 > URL: https://issues.apache.org/jira/browse/AMQ-9257 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 5.19.0, 5.17.5, 5.18.2 > > Time Spent: 10m > Remaining Estimate: 0h > > If pauseDispatch is set, the expiry checking should be ignored as well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9257) Disabled expire message checking when pauseDispatch=true
[ https://issues.apache.org/jira/browse/AMQ-9257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722950#comment-17722950 ] Matt Pavlovich commented on AMQ-9257: - [~cshannon] Yes, the queue can deadlock if you do administrative work on the queue while pauseDispatch = true and the expiry task executes to scan for expired messages. > Disabled expire message checking when pauseDispatch=true > > > Key: AMQ-9257 > URL: https://issues.apache.org/jira/browse/AMQ-9257 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 5.19.0, 5.17.5, 5.18.2 > > Time Spent: 10m > Remaining Estimate: 0h > > If pauseDispatch is set, the expiry checking should be ignored as well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (AMQ-9257) Disabled expire message checking when pauseDispatch=true
[ https://issues.apache.org/jira/browse/AMQ-9257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722937#comment-17722937 ] Christopher L. Shannon commented on AMQ-9257: - What is the background here? This ticket needs a lot more detail. Why does message expiration need to be paused as well? Was there a bug seen? > Disabled expire message checking when pauseDispatch=true > > > Key: AMQ-9257 > URL: https://issues.apache.org/jira/browse/AMQ-9257 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Matt Pavlovich >Assignee: Matt Pavlovich >Priority: Minor > Fix For: 5.19.0, 5.17.5, 5.18.2 > > Time Spent: 10m > Remaining Estimate: 0h > > If pauseDispatch is set, the expiry checking should be ignored as well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-3809) LargeMessageControllerImpl hangs the message consume
[
https://issues.apache.org/jira/browse/ARTEMIS-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722932#comment-17722932
]
ASF subversion and git services commented on ARTEMIS-3809:
--
Commit 1d4139f27844c9ca4cc9b5cbdc4576806b778cea in activemq-artemis's branch
refs/heads/main from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=1d4139f278 ]
ARTEMIS-3809 Fixing LargeMessageController timeout
Say packets stopped flowing, and you are calling receive(0);
The Controller should check if packets didn't arrive and throw a proper
exception
> LargeMessageControllerImpl hangs the message consume
>
>
> Key: ARTEMIS-3809
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3809
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.21.0
> Environment: OS: Windows Server 2019
> JVM: OpenJDK 64-Bit Server VM Temurin-17.0.1+12
> Max Memory (-Xmx): 6GB
> Allocated to JVM: 4.168GB
> Currently in use: 3.398GB (heap 3.391GB, non-heap 0.123GB)
>Reporter: David Bennion
>Priority: Major
> Labels: test-stability
> Attachments: image-2022-05-03-10-51-46-872.png
>
>
> I wondered if this might be a recurrence of issue ARTEMIS-2293 but this
> happens on 2.21.0 and I can see the code change in
> LargeMessageControllerImpl.
> Using the default min-large-message-size of 100K. (defaults)
> Many messages are passing through the broker when this happens. I would
> anticipate that most of the messages are smaller than 100K, but clearly some
> of them must exceed. After some number of messages, a particular consumer
> ceases to consume messages.
> After the system became "hung" I was able to get a stack trace and I was able
> to identify that the system is stuck in an Object.wait() for a notify that
> appears to never come.
> Here is the trace I was able to capture:
> {code:java}
> Thread-2 (ActiveMQ-client-global-threads) id=78 state=TIMED_WAITING
> - waiting on <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> - locked <0x43523a75> (a
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
> at java.base@17.0.1/java.lang.Object.wait(Native Method)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:294)
> at
> org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:268)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:157)
> at
> org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:89)
> at mypackage.MessageListener.handleMessage(MessageListener.java:46)
> {code}
>
> The app can run either as a single node using the InVM transporter or as a
> cluster using the TCP. To my knowledge, I have only seen this issue occur on
> the InVM.
> I am not expert in this code, but I can tell from the call stack that 0 must
> be the value of timeWait passed into waitCompletion(). But from what I can
> discern of the code changes in 2.21.0, it should be adjusting the
> readTimeout to the timeout of the message (I think?) such that it causes the
> read to eventually give up rather than remaining blocked forever.
> We have persistenceEnabled = false, which leads me to believe that the only
> disk activity for messages should be related to large messages(?).
> On a machine and context where this was consistently happening, I adjusted
> the min-large-message-size upwards and the problem went away. This makes
> sense for my application, but ultimately if a message goes across the
> threshold to become large it appears to hang the consumer indefinitely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (ARTEMIS-4280) Kubernetes JaaS LoginModule extract role info from review groups
Gary Tully created ARTEMIS-4280: --- Summary: Kubernetes JaaS LoginModule extract role info from review groups Key: ARTEMIS-4280 URL: https://issues.apache.org/jira/browse/ARTEMIS-4280 Project: ActiveMQ Artemis Issue Type: Improvement Components: JAAS Affects Versions: 2.28.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 2.29.0 The role mapping is via a properties file, which cold be achieved via the properties login module, however the roles also map nicely from the review users groups. Making the role file optional and using the group info as roles by default is more intuitive. Adding an optional ignoreTokenReviewRoles to disable the role association from the group information gives full flexibility. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4199) PageCounter leaving record out of Transaction
[ https://issues.apache.org/jira/browse/ARTEMIS-4199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722793#comment-17722793 ] ASF subversion and git services commented on ARTEMIS-4199: -- Commit f082b9c5d167157e9cb63e630e797722819da70c in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=f082b9c5d1 ] ARTEMIS-4199 Adding test for open transaction on reset call > PageCounter leaving record out of Transaction > - > > Key: ARTEMIS-4199 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4199 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.29.0 > > > this was causing an annoyance in logging. the TX.delete(keepZero) was keeping > a record without a commit in the journal. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4275) _AMQ_ConsumerName is missing from Consumer Created/Closed notifications
[ https://issues.apache.org/jira/browse/ARTEMIS-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722663#comment-17722663 ] Liviu Citu commented on ARTEMIS-4275: - Hi Bertram, I saw your commit regarding _AMQ_ConsumerName and I have added a comment to it. Please have a look, Thanks https://github.com/apache/activemq-artemis/commit/7da9bdf0a9b0d416ab4fa53c421ace27f3a44d0b#diff-96cdf8c4ff8d61ac9690fd5bfe2baefb4207074fc2bcd8a86d9122cb2f1ee1c2 > _AMQ_ConsumerName is missing from Consumer Created/Closed notifications > --- > > Key: ARTEMIS-4275 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4275 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.28.0 >Reporter: Liviu Citu >Priority: Major > > Hi, > *_AMQ_ConsumerName* property is missing from *CONSUMER_CREATED / > CONSUMER_CLOSED* notification messages. This property is necessary to > identify the *ConsumerId.* In a subscription model functionality the server > needs to know when a certain subscription (consumer) gets created or closed. > I have tried to use *_AMQ_RoutingName* but it seems it is for different > purposes (sometimes it is simply equal with *_AMQ_Address).* > *_AMQ_ConsumerName* was available in the Advisory Message but it does not > seem to be part of the Notification Message. Therefore this is a regression > compared to Classic ActiveMQ. > Regards > Liviu -- This message was sent by Atlassian Jira (v8.20.10#820010)
