INTERNAL: read while END/PIPE_ERROR received in the pipe operation

[oliviarla]

🔗 Related Issue

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

⌨️ What I did

• 본 PR에서는 두 가지 사항을 처리합니다.
  • proxy 서버에서 하나의 pipe operation에서 여러 error가 발생할 때를 대비하여 operation의 예외 필드를 List로 변경합니다.
  • pipe operation에서 예외가 하나라도 발생했을 때 곧바로 커넥션을 끊는 대신 END|PIPE_ERROR 까지 읽고 예외를 모아 저장해둡니다. 이를 통해 사용자는 get() 메서드 호출 시 발생했던 모든 예외를 CompositeException을 통해 조회해볼 수 있습니다.
• 만약 모든 response를 읽은 후에 END|PIPE_ERROR 를 읽지 못했다면 버퍼로부터 다음 Line을 읽는 시점에 OperationException을 던져 커넥션을 끊도록 합니다.

[jhpark816]

@uhm0311 먼저 리뷰하면 됩니다.

[uhm0311]

1차 질문입니다.

[uhm0311]

2차, 리뷰 의견과 질문입니다.

[uhm0311]

3차 리뷰 의견입니다.

[jhpark816]

@oliviarla @uhm0311
CompositeException의 printCallStack() 관련 PR은 merge 되었습니다.

[oliviarla]

@uhm0311 @jhpark816
현재 END/PIPE_ERROR가 오지 않아 예외가 발생한다면 아래와 같이 로깅이 되는데요, 이 때 어떤 에러가 어떤 연산에서 났는지 확인하기 어렵다는 단점이 있긴 합니다만, 별다른 해결 방안은 없는 것 같습니다. (pipe operation에서 내부적으로 사용하고 있는 index 정보를 같이 로깅하면 어떨까 생각해보았는데, 메서드 인자 등을 로그로 알기 어려우므로 index를 알더라도 쓸모없는 정보가 될 것 같습니다.)

OperationException: SERVER: Multiple exceptions (3) reported: SERVER_ERROR out of memory @ testnode 0.0.0.0/0.0.0.0:11211, CLIENT_ERROR too large value @ testnode 0.0.0.0/0.0.0.0:11211, END|PIPE_ERROR not received

[uhm0311]

4차 리뷰 의견입니다.

[oliviarla]

@jhpark816 리뷰 부탁드립니다.

[jhpark816]

@oliviarla 리뷰 진행 중입니다.

[jhpark816]

일부 리뷰

[jhpark816]

리뷰 완료,
복잡한 이슈네요.

[oliviarla]

@jhpark816 @uhm0311
현재 상황에서 수정할 부분을 대략 정리해봤습니다. 코드로 작성하기 전에 검토 먼저 부탁드립니다.

• OperationImpl#readFromBuffer의 로직 변경
  • isPipeOperation()가 true이고 첫 번째 응답이 RESPONSE <count> 라면, 이후에는 classifyError()를 거치지 않고 handleLine()에서
  • CLIENT_ERROR, SERVER_ERROR, ERROR를 읽고 gotStatus 콜백 메서드에 넘긴다.
• handleLine(String line)의 로직 변경
  • END가 왔을 때에는 Operation COMPLETE 상태로 변경
  • PIPE_ERROR가 왔을 때에는 Operation COMPLETE 상태로 변경하고, operation에 예외를 추가해 reconnect되도록 하고, hasErrored가 true를 반환하도록 한다.
• getFailedResult() 메서드를 pipe 관련 Future에 추가
  • 에러와 상관없이 failedResult 결과를 조회할 수 있도록 한다.

[jhpark816]

@oliviarla

isPipeOperation()가 true이면 classifyError()를 거치지 않고 handleLine()에서 CLIENT_ERROR, SERVER_ERROR, ERROR를 gotStatus 콜백 메서드에 넘긴다.

• pipe 요청에 대해 ERROR 등이 바로 나올 수 있으며, 이 경우는 classifyError()를 수행해야 합니다.
• pipe 요청에 대해 RESPONSE <count>\r\n 응답이 온 이후에는 classifyError()를 거치지 않아야 합니다.

END가 오면 리다이렉트한 후 Operation COMPLETE 상태로 변경
PIPE_ERROR가 오면 리다이렉트한 후 Operation COMPLETE 상태로 변경

리다이렉트한다는 것이 어떤 의미인가요?

future.get()의 로직 변경
hasErrored 일 때에는 exception을 던지지 않는다.

result가 있는 지에 따라 판단해야 할 지 ? 정도의 느낌이 듭니다.

[oliviarla]

@jhpark816
윗 코멘트를 수정했습니다.

[jhpark816]

hasErrored로 인한 exception은 던지지 않는다. cancel에 대한 exception은 던진다. (이 때에는 어디까지 처리되었는지 여부는 알 수 없다.)

• exception, cancel, timeout 관련 처리는 동일해야 할 것 같습니다.
• future.get() 동작을 아래와 같이 수정하는 방안이 있습니다. (backward compatibility 이슈 발생)
  • error, cancel, timeout 시에 exception throw 하지 않는 방식이 있습니다.
  • 이 경우, error, cacncel, timeout을 OperationStatus로 리턴해야 합니다.
• future.get() 동작을 그대로 유지하는 대신, getSome() 같은 별도의 메소드를 두는 방식이 있습니다.
  • getSome()은 error, cacncel, timeout을 OperationStatus로 리턴합니다.
  • getSome()은 getBulk에서 제공하는 메소드이고, storeBulk에 맞는 용어의 메소드(getFailed())이어야 합니다.

[uhm0311]

END가 왔을 때에는 Operation COMPLETE 상태로 변경

현재와 동일한 동작이란 거죠?

getFailedResult() 메서드를 pipe 관련 Future에 추가

해당 메소드의 리턴 타입은 어떻게 되나요?