如何禁用Spring Boot中Hazelcast默认关闭钩子并解决用户状态更新问题

Hey there, let's work through this issue together—this kind of cluster state sync problem comes up pretty often when combining WebSockets with distributed caches like Hazelcast. Here's what I'd try based on past experience:

When your app instance is shutting down or restarting, the JVM and Hazelcast member/client are already in an unstable state by the time afterConnectionClosed fires. That's probably why your remote operations are getting truncated. First, add a check to make sure Hazelcast is still active before trying any state updates:

• Grab your HazelcastInstance reference
• Validate it's running with hazelcastInstance.getLifecycleService().isRunning()
• If it's not active, skip the local update—we'll handle this with a pre-shutdown hook instead (more on that next)

Instead of waiting for individual connection close events (which fire too late during shutdown), handle all local users' states in one go when the instance starts shutting down. This avoids the race condition where the JVM cuts off your Hazelcast calls mid-operation:

// Register this listener when your app starts up
HazelcastInstance hazelcastInstance = Hazelcast.newHazelcastInstance();
hazelcastInstance.getLifecycleService().addLifecycleListener(new LifecycleListener() {
    @Override
    public void stateChanged(LifecycleEvent event) {
        if (LifecycleState.SHUTTING_DOWN.equals(event.getState())) {
            // Get all user IDs connected to this local instance
            Collection<String> localConnectedUsers = fetchLocalWebSocketUsers();
            if (localConnectedUsers.isEmpty()) return;

            // Bulk remove/update their status in Hazelcast's distributed map
            IMap<String, UserStatus> userStatusMap = hazelcastInstance.getMap("online-user-status");
            userStatusMap.removeAll(localConnectedUsers);
            // Or if you need to mark them as offline instead of removing:
            // userStatusMap.putAll(localConnectedUsers.stream()
            //     .collect(Collectors.toMap(id -> id, id -> UserStatus.OFFLINE)));
        }
    }
});

This way, you're cleaning up all local user states while the Hazelcast instance is still fully operational, before any shutdown processes start cutting resources.

If you still need to handle individual connection closures (for normal user disconnects, not just instance shutdown), beef up the method with error handling and retries:

@Override
protected void afterConnectionClosed(WebSocketSession session, CloseStatus status) throws Exception {
    super.afterConnectionClosed(session, status);
    String userId = extractUserIdFromSession(session);
    if (userId == null) return;

    HazelcastInstance hazelcastInstance = getHazelcastInstance();
    // Skip if Hazelcast is already shutting down
    if (!hazelcastInstance.getLifecycleService().isRunning()) {
        log.info("Skipping status update for user {}—node is shutting down", userId);
        return;
    }

    IMap<String, UserStatus> userStatusMap = hazelcastInstance.getMap("online-user-status");
    try {
        // Use atomic operation to ensure we only update status tied to this node
        userStatusMap.executeOnKey(userId, entry -> {
            if (entry != null && entry.getValue().getNodeId().equals(getLocalNodeId())) {
                entry.setValue(UserStatus.OFFLINE);
            }
            return null;
        });
    } catch (HazelcastInstanceNotActiveException | IOException e) {
        // If the operation fails, queue it for another node to handle
        log.warn("Failed to update status for user {}—queuing for retry", userId, e);
        IQueue<String> pendingUpdates = hazelcastInstance.getQueue("pending-status-updates");
        pendingUpdates.offer(userId);
    }
}

Then, set up a small background task on each cluster node to process the pending updates queue—this ensures that even if one node fails to update a user's status, another node will pick it up.

Make sure your user status entries include the node ID of the instance they're connected to. This lets you:

• Quickly identify which entries belong to a shutting-down node for bulk cleanup
• Avoid race conditions where multiple nodes try to update the same user's status incorrectly

内容的提问来源于stack exchange，提问作者Nisheeth Shah