[
https://issues.apache.org/jira/browse/ARTEMIS-4305?focusedWorklogId=930936&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-930936
]
ASF GitHub Bot logged work on ARTEMIS-4305:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 20/Aug/24 09:17
Start Date: 20/Aug/24 09:17
Worklog Time Spent: 10m
Work Description: iiliev2 commented on PR #4899:
URL:
https://github.com/apache/activemq-artemis/pull/4899#issuecomment-2298378613
>java.lang.NullPointerException: Cannot invoke
"java.util.concurrent.ScheduledExecutorService.scheduleAtFixedRate(java.lang.Runnable,
long, long, java.util.concurrent.TimeUnit)" because "this.s" is null
I had to update the test to work with JUnit 5(I didn't notice on my last
rebase that Artemis upgraded from an earlier JUnit).
>Also, I put together a proof-of-concept fix
I am having trouble running the multicast discovery tests on my mac. I setup
my routes as described in https://issues.apache.org/jira/browse/ARTEMIS-2341
(like last time and that was sufficient to make multicast discovery work).
I also added `-Djava.net.preferIPv4Stack=true` to the broker stratup
commands, but still I am getting `Can't assign requested address` error(even in
other tests like `DiscoveryTest`).
So as it stands I am unable to verify if your fix works. I was only able to
look at the code, and as far as I can tell, my concerns remain same as I
mentioned
[earlier](https://github.com/apache/activemq-artemis/pull/4899#issuecomment-2078890094).
However, if your fix works reliably, I have no objections.
Could you please pull the latest version of test
`ZeroPersistenceSymmetricalClusterTest` and run it against your fix?
Issue Time Tracking
-------------------
Worklog Id: (was: 930936)
Time Spent: 1h 50m (was: 1h 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: 1h 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
