INTERNAL: Add operation status message to log when operation is not successful.

[uhm0311]

🔗 Related Issue

• Exception이 발생하진 않았으나 연산이 실패한 경우, OperationStatus를 확인하지 않으면 정확한 연산 실패 원인을 알 수 없다.

⌨️ What I did

• Exception이 발생하진 않았으나 연산이 실패한 경우, OperationStatus를 워닝 로그로 출력합니다.
• 로그 레벨은 임의로 우선 워닝으로 설정했으나 더 적합하다고 생각하는 로그 레벨이 있다면 의견 주세요.

[uhm0311]

OperationStatus의 StatusCode에 따라 로그 레벨을 다르게 출력하도록 수정했습니다.

[oliviarla]

@uhm0311 java client API의 add, delete, set, asyncGet, flush에서 각각 성공하지 않았을 때 발생하는 상태 코드를 간단히 정리해주실 수 있나요?

발생 가능한 상태 코드를 살펴보고 특정 조건일 때에만 로깅을 남기는 것이 어떤가요? 예를 들어 java client의 add 메서드는 StatusCode.ERR_NOT_STORED 외에 발생 가능한 상태 코드가 없어보이는데, 사용자가 putIfAbsent를 호출하였다면 의도를 충분히 이해하고 있을 것이고 따라서 logging 하지 않아도 되는 정보라는 생각이 듭니다.

다양한 케이스를 고려하다보니 현재 코드는 간단한 로깅 작업임에도 불구하고 한눈에 보고 이해하기 어렵습니다. 다만 하위 호환성으로 받아들이는 상태 코드가 버전마다 다르다면 어쩔 수 없이 이 형태로 구현해야 할 것 같긴 합니다.

[uhm0311]

서버 응답 모음

CLIENT_ERROR, SERVER_ERROR와 같은 에러는 없는 경우의 응답입니다.

get

키 존재 여부에 관계 없이 END, 성공

add

STORED, 값 저장 완료, 성공 NOT_STORED, 키가 이미 존재하는 경우, 실패

delete

DELETED, 값 제거 완료, 성공 NOT_FOUND, 키가 존재하지 않는 경우, 실패

flush

OK, Prefix가 존재하는 경우, 성공 NOT_FOUND, Prefix가 존재하지 않는 경우, 성공

무조건 로깅하는 이유

evict 실패 원인에 대한 문의가 있었기 때문에 로그를 통해 NOT_FOUND이면 캐시 키가 없다는 것을 알리기 위함입니다.

[jhpark816]

@oliviarla @brido4125 이 작업이 우선적으로 처리되어야 할 것 같습니다.

[uhm0311]

@brido4125

Mockito와 같은 라이브러리들의 버전 문제인지는 모르겠지만 TestLogger 클래스 없이는 로그 메세지를 검증할 좋은 방법이 없어서 로그 메세지를 출력하지 않고 메모리에 저장해두는 TestLogger 클래스를 추가했습니다.

[oliviarla]

저는 단순한 로깅 기능에 테스트코드까지 추가하는게 의미가 있는지 잘 모르겠는데, @uhm0311 님은 테스트코드가 필요하다고 보시나요?

[jhpark816]

@oliviarla 내 리뷰 의견을 보고 다른 의견이 있다면 알려주세요.

[uhm0311]

@jhpark816

반영했습니다.

[jhpark816]

@oliviarla @brido4125 리뷰 바랍니다.