[jira] [Commented] (AMQ-9483) Non Daemon Connection Keeping JVM alive when combined with optimizedAckScheduledAckInterval
[ https://issues.apache.org/jira/browse/AMQ-9483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841283#comment-17841283 ] Matthew Washburn commented on AMQ-9483: --- Some unit tests need to be updated with the new constructor arg. If you are good with the approach for detecting if we should be daemon I will update them. > Non Daemon Connection Keeping JVM alive when combined with > optimizedAckScheduledAckInterval > --- > > Key: AMQ-9483 > URL: https://issues.apache.org/jira/browse/AMQ-9483 > Project: ActiveMQ Classic > Issue Type: Bug > Components: JMS client >Affects Versions: 5.18.4 >Reporter: Matthew Washburn >Priority: Major > Attachments: > 0001-make-sure-the-executor-service-for-deliveryingAcknow.patch, 796.patch > > > The thread used to send ack unacked messages when using the > optimizedAckScheduledAckInterval is not daemon even if the connection is set > to daemon. This is probably advantageous as you would not want a queue or > durable topic consumer to shutdown before it has finished acking a message > causing it to be redelivered on restart. On the other hand, it means that if > the optimized ack scheduler ever kicks in on a daemon connection the JVM will > never exit. Also the thread isn't uniquely named so it's hard to track down. > > I'm not sure how to get in the situation where there are unacked messages > that are acked by the timer so I'm not sure how to create a simple repo > script but the attached patch fixes my application. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?focusedWorklogId=916653=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-916653 ] ASF GitHub Bot logged work on ARTEMIS-4745: --- Author: ASF GitHub Bot Created on: 26/Apr/24 15:29 Start Date: 26/Apr/24 15:29 Worklog Time Spent: 10m Work Description: gemmellr merged PR #4907: URL: https://github.com/apache/activemq-artemis/pull/4907 Issue Time Tracking --- Worklog Id: (was: 916653) Time Spent: 0.5h (was: 20m) > Allow configuration of AMQP federation pull consumer batch size > > > Key: ARTEMIS-4745 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4745 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.34.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When Queue federation receiver links are configured to only pull messages > from the remote when local capacity allows it they grant a fixed credit > window amount of link credits currently. In some cases control over this > batch size value is beneficial. We can add an additional configuration > property to convey this limit to the federation configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841273#comment-17841273 ] ASF subversion and git services commented on ARTEMIS-4745: -- Commit 659b17c3a933a7d80f9148836d7b9bbd4275932f in activemq-artemis's branch refs/heads/main from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=659b17c3a9 ] ARTEMIS-4745 Allow configuration of the pull consumer batch size Allow for configuration of the batch size granted to the remote when an AMQP federation queue receiver is pulling messages only when there is local capacity to handle them. Some code housekeeping is done here to make adding future properties a bit simpler and require fewer changes. > Allow configuration of AMQP federation pull consumer batch size > > > Key: ARTEMIS-4745 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4745 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.34.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When Queue federation receiver links are configured to only pull messages > from the remote when local capacity allows it they grant a fixed credit > window amount of link credits currently. In some cases control over this > batch size value is beneficial. We can add an additional configuration > property to convey this limit to the federation configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved ARTEMIS-4745. - Resolution: Fixed > Allow configuration of AMQP federation pull consumer batch size > > > Key: ARTEMIS-4745 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4745 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.34.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When Queue federation receiver links are configured to only pull messages > from the remote when local capacity allows it they grant a fixed credit > window amount of link credits currently. In some cases control over this > batch size value is beneficial. We can add an additional configuration > property to convey this limit to the federation configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?focusedWorklogId=916646=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-916646 ] ASF GitHub Bot logged work on ARTEMIS-4745: --- Author: ASF GitHub Bot Created on: 26/Apr/24 15:04 Start Date: 26/Apr/24 15:04 Worklog Time Spent: 10m Work Description: tabish121 commented on PR #4907: URL: https://github.com/apache/activemq-artemis/pull/4907#issuecomment-2079572871 I've run the full test suite with these changes Issue Time Tracking --- Worklog Id: (was: 916646) Time Spent: 20m (was: 10m) > Allow configuration of AMQP federation pull consumer batch size > > > Key: ARTEMIS-4745 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4745 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.34.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When Queue federation receiver links are configured to only pull messages > from the remote when local capacity allows it they grant a fixed credit > window amount of link credits currently. In some cases control over this > batch size value is beneficial. We can add an additional configuration > property to convey this limit to the federation configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4745) Allow configuration of AMQP federation pull consumer batch size
[ https://issues.apache.org/jira/browse/ARTEMIS-4745?focusedWorklogId=916645=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-916645 ] ASF GitHub Bot logged work on ARTEMIS-4745: --- Author: ASF GitHub Bot Created on: 26/Apr/24 15:04 Start Date: 26/Apr/24 15:04 Worklog Time Spent: 10m Work Description: tabish121 opened a new pull request, #4907: URL: https://github.com/apache/activemq-artemis/pull/4907 Allow for configuration of the batch size granted to the remote when an AMQP federation queue receiver is pulling messages only when there is local capacity to handle them. Some code housekeeping is done here to make adding future properties a bit simpler and require fewer changes. Issue Time Tracking --- Worklog Id: (was: 916645) Remaining Estimate: 0h Time Spent: 10m > Allow configuration of AMQP federation pull consumer batch size > > > Key: ARTEMIS-4745 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4745 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: AMQP >Affects Versions: 2.33.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: 2.34.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When Queue federation receiver links are configured to only pull messages > from the remote when local capacity allows it they grant a fixed credit > window amount of link credits currently. In some cases control over this > batch size value is beneficial. We can add an additional configuration > property to convey this limit to the federation configuration -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (ARTEMIS-4305) Zero persistence does not work in kubernetes
[
https://issues.apache.org/jira/browse/ARTEMIS-4305?focusedWorklogId=916585=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-916585
]
ASF GitHub Bot logged work on ARTEMIS-4305:
---
Author: ASF GitHub Bot
Created on: 26/Apr/24 08:24
Start Date: 26/Apr/24 08:24
Worklog Time Spent: 10m
Work Description: iiliev2 commented on PR #4899:
URL:
https://github.com/apache/activemq-artemis/pull/4899#issuecomment-2078890094
Initially I attempted what you suggest about lazy initializing the node id
like that, precicely because I wanted to keep the code changes to a minimum.
However, that ended up being much more complicated(rather than simplified),
because of the way `ClientSessionFactoryImpl` creates a new connection object
on re-connects. It is very hard to reason about both when reading the code and
when needing to debug it at runtime. So instead of this, I had to fill the
missing gaps to use the data that is already there anyway, just wasn't being
propagated deep enough.
IMO from a functional standpoint, adding the `TransportConfiguration` to the
connector(and connection) is the right thing to do here anyway. I assume due to
historical reasons, those classes were working with a subset of the data, and
no one had a good reason to fix this until now. For example
`NettyConnection#getConnectorConfig` was creating a bogus transport
configuration, even though when it was created there was a configuration which
was not being passed to it.
`Ping` is already the only `Packet` that is being modified. Why do you want
to use a raw `byte[]` rather than `UUID`? IMO that will be more confusing - it
suggests that there could be other kind of data that can be contained.
Issue Time Tracking
---
Worklog Id: (was: 916585)
Time Spent: 0.5h (was: 20m)
> Zero persistence does not work in kubernetes
>
>
> Key: ARTEMIS-4305
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4305
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Ivan Iliev
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In a cluster deployed in kubernetes, when a node is destroyed it terminates
> the process and shuts down the network before the process has a chance to
> close connections. Then a new node might be brought up, reusing the old
> node’s ip. If this happens before the connection ttl, from artemis’ point of
> view, it looks like as if the connection came back. Yet it is actually not
> the same, the peer has a new node id, etc. This messes things up with the
> cluster, the old message flow record is invalid.
> One way to fix it could be if the {{Ping}} messages which are typically used
> to detect dead connections could use some sort of connection id to match that
> the other side is really the one which it is supposed to be.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
