Hi Hailey, Thanks for confirming this reproduces independently of AMQ-5568, and for the pointer on the keepAlive-heartbeat idea.
> My suggestion for upstream fix would be to have the keepAlive emit some sort of heartbeat and treat timeouts on that heartbeat as a lock loss. > Also, something to note that lockKeepAlivePeriod defaults to 0, meaning a default shared-store config will still be susceptible to this issue even > after the fix, unless that default changes too. Good catch - that default would need to change alongside any fix, or the heartbeat never fires for anyone running defaults. On our side, we ended up building a stop-gap while waiting on an upstream fix: a custom Locker that wraps lock()/keepAlive()/unlock() in a timed executor and calls Runtime.halt() on timeout, since a hard-mounted NFS hang leaves the affected thread in D-state and unresponsive to normal shutdown or even SIGKILL. It's not something we'd propose as *the* fix - more a symptom of how deep this problem sits, and evidence that a timeout-based approach at the locker level is workable in practice. It's only been tested in our own reproduction setup so far, not reviewed by a colleague yet. Happy to push it to a public branch if that's useful as a reference. Would a JIRA ticket be the right place to attach something like that, or is this still better kept at the discussion stage for now? Best, Axel
