REFACTOR: Change cacheListUpdate parsing logic.
https://github.com/jam2in/arcus-works/issues/379
- 위 이슈 기반의 PR입니다.
변경 사항
기존에는 String 타입으로 cacheListChange 및 alterListChange를 관리한다.
이러한 경우에는 ArcusClientPool 내에 있는 모든 ArcusClient들이
String -> List<InetSocketAddress>로의 변환을 반복한다.
만약 cacheListChange를 String으로 변환하지 않고
List<InetSocketAddress>로 변환하면 위와 같은 반복을 제거할 수 있다.
@uhm0311 리뷰 꼭 바랍니다. @oliviarla 시간 되면, 리뷰 바랍니다.
@brido4125
develop 브랜치 기준으로 PR 보내야 합니다.
- develop 브랜치 기준으로 새로운 커밋 반영하였습니다.
- 내부
mvn clean test결과 이상 없었습니다.
@brido4125 develop 브랜치의 최신 코드 기준으로 rebase 바랍니다.
리뷰 및 머지 여부 확인 부탁드립니다. 제 계정에서는 Merge 가능으로 확인됩니다.
merge 가능으로 보입니다.
- finally문을 통해 일부 InetSocketAddress 만 들어가는 로직 수정했습니다.
@uhm0311 @oliviarla 이제 리뷰 바랍니다.
@brido4125 하나만 더 확인 바랍니다. 기존 메소드에서 아래 메소드 호출하도록 변경하면, 리턴 방식이 일부 변경(exception => emtpy list)될 것입니다. 따라서 아래 메소드를 호출하여 사용하는 코드에서는 이러한 변경이 있어도 문제가 없는 지를 검토 바랍니다.
List<InetSocketAddress> getAddresses(List<String> addressList)
해당 함수를 호출하는 곳을 조사해본 결과, 리턴 value인 List<InetSocketAddress>를 for loop를 통해 순회하거나 migration 대상 노드의 Sockeaddress에 대해 contain 또는 remove 용도로만 사용이 됩니다.
기존의 InetSocketAddress 일부만 들어가 있는 상태의 리스트가 반환 되는 경우보다 all or nothing으로 처리하는게 더 효율적이라 생각합니다.(기존코드에서는 말씀하신 exception이 try 블럭에서 발생해도 catch 블럭 아래의 로직이 실행되기에 일부만 들어간 리스트가 반환됩니다)
또한 리스트 크기가 0이므로 리스트 사용 시 NPE을 발생시키지 않기에 문제가 없을 것이라고 생각됩니다.
@brido4125 본 PR은 진행해야 하는 내용인 것으로 보이는 데, 진행해야 한다면, 최신 코드 기준으로 rebase하고 문제 없는 코드인지 자체 확인해 주세요.
@uhm0311 앞서 올린 리뷰 의견을 함께 검토해 보는 것이 좋겠습니다.
@uhm0311 @oliviarla
젤 위의 PR 설명 참고하셔서 리뷰 한번 부탁드립니다.
@oliviarla 리뷰 바랍니다.