[jira] [Commented] (ARTEMIS-4285) Disable Redelivery Persistence for new broker installations.
[ https://issues.apache.org/jira/browse/ARTEMIS-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724410#comment-17724410 ] ASF subversion and git services commented on ARTEMIS-4285: -- Commit e719622de5488f859f70beda926afaa51d5b0ff9 in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e719622de5 ] ARTEMIS-4285 Limit number of redelivery records > Disable Redelivery Persistence for new broker installations. > > > Key: ARTEMIS-4285 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4285 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We should allow disabling persisted redelivery on messages. > Every time a message is redelivery, and scheduled redelivery is used, an > update record is stored in the broker. > This may add a big burden in the journal or jdbc journal. > We will keep this as true by default (in java) however new broker.xml > configuration will have this as false, so we will keep current users' > expectation while setting this to false for any new broker installation. > This is a borderline between bug and improvement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4285) Disable Redelivery Persistence for new broker installations.
[ https://issues.apache.org/jira/browse/ARTEMIS-4285?focusedWorklogId=861837=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861837 ] ASF GitHub Bot logged work on ARTEMIS-4285: --- Author: ASF GitHub Bot Created on: 19/May/23 20:59 Start Date: 19/May/23 20:59 Worklog Time Spent: 10m Work Description: clebertsuconic merged PR #4484: URL: https://github.com/apache/activemq-artemis/pull/4484 Issue Time Tracking --- Worklog Id: (was: 861837) Remaining Estimate: 0h Time Spent: 10m > Disable Redelivery Persistence for new broker installations. > > > Key: ARTEMIS-4285 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4285 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We should allow disabling persisted redelivery on messages. > Every time a message is redelivery, and scheduled redelivery is used, an > update record is stored in the broker. > This may add a big burden in the journal or jdbc journal. > We will keep this as true by default (in java) however new broker.xml > configuration will have this as false, so we will keep current users' > expectation while setting this to false for any new broker installation. > This is a borderline between bug and improvement. -- 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=17724404#comment-17724404 ] ASF subversion and git services commented on ARTEMIS-4275: -- Commit a57c48ec556158a9f28c8fc9c318a81b7295b24e in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=a57c48ec55 ] ARTEMIS-4275 add ID to consumer notifications > _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)
[jira] [Commented] (ARTEMIS-2824) _AMQ_Client_ID on SESSION_CLOSED notification is always null
[ https://issues.apache.org/jira/browse/ARTEMIS-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724403#comment-17724403 ] ASF subversion and git services commented on ARTEMIS-2824: -- Commit 3a48258f7d816f28968e581a65df994b442d01d0 in activemq-artemis's branch refs/heads/main from Justin Bertram [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3a48258f7d ] ARTEMIS-2824 clientID not set on some notifications > _AMQ_Client_ID on SESSION_CLOSED notification is always null > > > Key: ARTEMIS-2824 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2824 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.11.0 >Reporter: Tim Daly >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a JMS client with a clientId set closes the session a notification > (_AMQ_NotifType=SESSION_CLOSED) is sent by the broker but the _AMQ_Client_ID > is always set to null. The JMS Client Id has been verified as being set via > the web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4283) Fail fast CORE client connect on closing
[ https://issues.apache.org/jira/browse/ARTEMIS-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724323#comment-17724323 ] ASF subversion and git services commented on ARTEMIS-4283: -- Commit c47d15c12a9e26d7e8ce1f977c286562c15396e9 in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=c47d15c12a ] ARTEMIS-4283 Fail fast CORE client connect on closing ServerLocatorImpl waits for topology after connecting a new session factory. It should interrupt waiting for topology when it is closed to fail fast. > Fail fast CORE client connect on closing > > > Key: ARTEMIS-4283 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4283 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > > ServerLocatorImpl waits for topology after connecting a new session factory. > It should interrupt waiting for topology when it is closed to fail fast. -- 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=17724271#comment-17724271 ] ASF subversion and git services commented on AMQ-9257: -- Commit 9a5b61f6a28184cfe832871302ece16069ebb71d in activemq's branch refs/heads/main from Matt Pavlovich [ https://gitbox.apache.org/repos/asf?p=activemq.git;h=9a5b61f6a2 ] [AMQ-9257] Disabled expire message checking when pauseDispatch=true (#1005) > 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] [Updated] (ARTEMIS-4284) Openwire prefetched messages can be out of order for a single consumer
[ https://issues.apache.org/jira/browse/ARTEMIS-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated ARTEMIS-4284: Description: It is an anti pattern, but a new consumer per message loop can fail with openwire. the remove is non blocking, so a new consumer can co exist with the async cancel/add sorted of the previpous consumer. This breaks ordering that is required for the delivery count logic around unconsumed prefetched messages. the workaround is to use prefetch=1 but the underlying problem is real, in 5.x the cancel/add_sorted is done in the same thread as remove. In artemis, the storage manager handles this async. A fix is to wait for the operation context complete on handling the removeConsumer command. was: It is an anti pattern, but a new consumer per message loop can fail with openwire. the remove is non blocking, so a new consumer can co exist with the async cancel/add sorted of the previpous consumer. This breaks ordering that is required for the delivery count logic around unconsumed prefetched messages. the workaround is to use prefetch=1 but the underlying problem is real, in 5.x the cancel/add_sorted is done in the same thread as remove. In artemis, the storage manager handles this async. A potential fix is to wait for the operation context complete on handling the removeConsumer command. > Openwire prefetched messages can be out of order for a single consumer > -- > > Key: ARTEMIS-4284 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4284 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: OpenWire >Affects Versions: 2.28.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.29.0 > > > It is an anti pattern, but a new consumer per message loop can fail with > openwire. the remove is non blocking, so a new consumer can co exist with the > async cancel/add sorted of the previpous consumer. This breaks ordering that > is required for the delivery count logic around unconsumed prefetched > messages. > the workaround is to use prefetch=1 but the underlying problem is real, in > 5.x the cancel/add_sorted is done in the same thread as remove. In artemis, > the storage manager handles this async. > A fix is to wait for the operation context complete on handling the > removeConsumer command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4285) Disable Redelivery Persistence for new broker installations.
[ https://issues.apache.org/jira/browse/ARTEMIS-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724202#comment-17724202 ] Gary Tully commented on ARTEMIS-4285: - It may make sense to do this just on the increment from 0->1 to support a persistent redelivery flag. That is what we did in 5.x to avoid too much overhead but still be usefull. see: https://issues.apache.org/jira/browse/AMQ-5068?focusedCommentId=13947821=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13947821 > Disable Redelivery Persistence for new broker installations. > > > Key: ARTEMIS-4285 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4285 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > > We should allow disabling persisted redelivery on messages. > Every time a message is redelivery, and scheduled redelivery is used, an > update record is stored in the broker. > This may add a big burden in the journal or jdbc journal. > We will keep this as true by default (in java) however new broker.xml > configuration will have this as false, so we will keep current users' > expectation while setting this to false for any new broker installation. > This is a borderline between bug and improvement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
