ENHANCE: Moved cache list change logic from IO thread to CacheManger thread.

[brido4125]

Motivation

현재 로직에서는 IO 쓰레드가 hash ring의 update로직을 수행한다. 이를 다른 CacheManager 데몬 쓰레드에게 이관하게 IO 쓰레드의 작업량을 감소시킨다.

관련 이슈

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

[uhm0311]

IO Thread에 의한 Read와 새로운 Thread에 의한 Write가 동시에 일어날 수 있습니다. 예를 들어, IO Thread가 제거되어야 할 Node를 가져와 연산을 보낼 수도 있습니다. 동시성 이슈는 어떻게 해결했나요?

[brido4125]

동시성 이슈는 어떻게 해결했나요?

ArcusKetamaNodeLocator 내부에 존재하는 Lock 인스턴스를 통해 allNodes 접근하는 경우 lock을 걸어 동시성 이슈를 해결하려 합니다.

이렇게 될 경우 IO Thread가 getAllNodes()를 호출할 때 Blocking이 될 가능성이 높은데 생각하시는 다른 방안이 있을까요?

[uhm0311]

다시 보니 기존에 걸려있는 Lock으로도 충분할 것 같습니다.

[brido4125]

HashRingUpdate Task의 작업 결과를 MemcachedConnection의 Future<Boolean> 필드로 가질 수 있게 하였습니다. 결론적으로 테스트 코드에서 getHashUpdateResult()를 호출해 Hash Ring update가 정상적으로 이루어졌는지 boolean 값을 통해 확인 할 수 있습니다.

[jhpark816]

@oliviarla 리뷰 바랍니다.

[oliviarla]

@jhpark816 알림을 놓쳤네요😢 다음주 초에 리뷰 완료하겠습니다.

[jhpark816]

@brido4125 rabase 바랍니다.

[brido4125]

@jhpark816 리뷰 부탁드리겠습니다.

[jhpark816]

@brido4125 @uhm0311 @oliviarla handleCacheNodesChange() 가 별도 스레드에 의해 수행되어야 할 것 같습니다. 어떤가요? handleCacheNodesChange() 메소드를 그대로 별도 스레드가 수행하면 되는 건지 아니면 메소드 로직에서 별도 스레드가 수행할 부분과 IO 스레드가 수행할 부분을 구분하여 처리해야 하는 지는 검토 바랍니다.

[uhm0311]

@jhpark816

cache_list의 변경분을 계산하는 것도 별도의 Thread에서 수행하는 방안이군요. Task에게 현재 cache_list와 변경된 cache_list를 주면 되겠네요. handleCacheNodesChange() 메소드의 로직 전체를 별도의 Thread에 위임해도 될 것 같습니다.

[brido4125]

@uhm0311 @oliviarla @jhpark816

handleCacheNodesChange 메서드 로직 전체를 별도의 스레드가 수행하도록 변경하였습니다.

[brido4125]

@uhm0311 @oliviarla 리뷰가 완료되신걸까요?

[uhm0311]

저는 아직입니다.