INTERNAL: Not to cancel operations when node is removed from ZK but still alive.

[uhm0311]

🔗 Related Issue

• https://github.com/jam2in/arcus-works/issues/535

⌨️ What I did

• NodeLocator에서 노드를 제거할 때, 해당 노드와의 소켓 연결이 해제되지 않았고 Operation Queue가 비어 있지 않으면 소켓 연결을 해제와 연산 캔슬을 수행하지 않고 DelayedClosingNodes로 분류합니다.
• IO Thread가 DelayedClosingNodes로 분류된 노드들을 순회하며 다음의 로직을 수행합니다.
  • 소켓 연결이 끊어진 노드가 있다면 연산을 모두 캔슬하고 DelayedClosingNodes에서 제거합니다.
  • Operation Queue가 비어 있는 노드가 있다면 소켓 연결을 해제하고 DelayedClosingNodes에서 제거합니다.

[oliviarla]

handleNodesToRemove 메서드가 복제와 마이그레이션에서도 사용되는데, 해당 부분에는 영향이 없나요?

[uhm0311]

EE여도 cache_list znode가 제거되었을 때 동작은 CE와 동일합니다.
alter_list znode가 제거되었을 때는 NodeLocator에서 소켓 연결을 해제하므로 영향이 없습니다.

[uhm0311]

첫번째 코멘트에 커밋 수정사항을 업데이트 했습니다.

[jhpark816]

@oliviarla @brido4125 먼저 리뷰 하시죠.

[brido4125]

https://github.com/jam2in/arcus-works/issues/549

현재 PR에서는 locator의 update와 handleDelayedClosingNodes 모두 IO 쓰레드에서 순차적으로 수행합니다.

만약, 현재 진행중인 이슈처럼 locator에 대한 update 수행을 다른 스레드가 수행할 경우
해당 구현도 변경이 필요할 수도 있습니다.

추후 참고할 목적으로 해당 코멘트 남깁니다.

[oliviarla]

메서드명을 removeDelayedClosedNodes 로 변경하면 어떤가요?

[brido4125]

delete 대상인 노드들을 Locator 단에서 구분하고
delayedClosingNodes 또한 Locator가 관리합니다.

근데 Locator의 클래스 의미를 생각한다면
한가지 책임을 추가하는게 좋은 설계는 아니라고 생각됩니다.

차라리 MemcachedConnection 쪽에서 update 또는 updateRepl을
호출 할 때 delete 대상이 되는 Collection을 넘기니
그쪽에서 처리하는건 어떤가요?

[uhm0311]

@brido4125

소켓 연결에 대한 해제를 수행하는 메소드 호출(node.closeChannel())이 대부분 NodeLocator 내에 있어서 그렇게 분리하기는 힘들 것 같습니다.
PR의 의도는 소켓 연결을 해제하기 전에 정말 해제할 필요가 있는지를 확인하는 것이므로 소켓 연결 해제 로직과 결합되어야 합니다.