[
https://issues.apache.org/jira/browse/ARTEMIS-4305?focusedWorklogId=931242&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-931242
]
ASF GitHub Bot logged work on ARTEMIS-4305:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 21/Aug/24 21:02
Start Date: 21/Aug/24 21:02
Worklog Time Spent: 10m
Work Description: iiliev2 commented on PR #4899:
URL:
https://github.com/apache/activemq-artemis/pull/4899#issuecomment-2303007461
> For example, if your use-case required messages to survive a broker
restart then setting persistence-enabled to false would be technically
possible, but it would not be valid.
Yes, however that (may) be a recovarable situation - to just fix our
configuration. In this case however, there is no recovering(unless we resort to
hacks), no matter which configuration we use.
Running inside k8s is not the only use case we want to support. We also
deploy in other modes, where nodes do keep identities between restarts. There
can be all kinds of variations to the deployment. We need a single
configuration that works in all cases, not multiple different ones, each of
which is prone to various bugs(as history has proven). We would never get
anything resolved that way.
We have communicated before we even started to work on this fix. The
approach via the `Ping` packets has been validated with you.
There are plenty of tests to guarantee the robustness of these changes.
Why would effectively 2 additional longs in one kind of (management) message
be that big of a performance hit(if that is your concern here)? How can we
profile this?
Issue Time Tracking
-------------------
Worklog Id: (was: 931242)
Time Spent: 2h 50m (was: 2h 40m)
> 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: 2h 50m
> 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
