Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENHANCE: Change asyncSetPipedExist method logic. #628
base: develop
Are you sure you want to change the base?
ENHANCE: Change asyncSetPipedExist method logic. #628
Changes from all commits
166686f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
아래 경우에 setOperationStatus 부분이 문제가 될 것 같습니다.
이 경우, 최종 OperationStatus는 NOT_FOUND가 됩니다.
맞는 동작인 지 검토 바랍니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#628 (comment)
위 코멘트대로, 여러 Op 중 하나라도
FAILED_END
라면,Future에서 반환하는 응답값은
FAILED_END
로 처리하는게 맞지 않나요?반대의 상황에서도
FAILED_END
는 유지가 됩니다.다만, PR 내의
failStatusCount
는 삭제해도 될 것 같습니다.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
바로 위의 코멘트 (https://github.com/naver/arcus-java-client/pull/628/files#r1530238965) 에 보인 예시에서는
FAILED_END
가 아닌NOT_FOUND
가 최종 OperationStatus로 되지 않나요?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
최종
OperationStatus
가실패 / 성공
의 여부에 대해 맞는 동작인지 검토하는것으로 이해했습니다.말씀하신 부분은 수정되어야 합니다.@jhpark816
Docs를 확인해보니 단순히
FAILED_END
가 아닌 구체적인 이유가 들어간OperationStatus
를 반환합니다.https://github.com/naver/arcus-java-client/blob/develop/docs/05-set-API.md#set-element-%EC%9D%BC%EA%B4%84-%EC%A1%B4%EC%9E%AC%EC%97%AC%EB%B6%80-%ED%99%95%EC%9D%B8
기존 동작으로 수행해야 하위 호환성 문제가 없을 것 같네요.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
현재 구현은 count를 통해서 해당 pipe Op의 모든 연산들이 동일한 원인인 경우,
구체적인 NOT_FOUND, TYPE_MISMATCH, UNREADABLE 을 리턴합니다.
만약 연산 중 일부는 성공 / 일부는 실패일 경우는
FAILED_END
를 리턴하네요.하지만
FAILED_END
라는 의미가 디버깅에도 별 도움이 되지 않기 때문에,하나라도 NOT_FOUND, TYPE_MISMATCH, UNREADABLE 중 설정 된다면
해당하는 Status를 리턴시켜 주는게 도움이 될 것 같습니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brido4125
코멘트에 있는 대로 처리하면 안 될 것 같습니다.
N개 pipe 연산에서 i번째 연산이 실패하면 그 뒤에 있는 모든 연산도 함께 실패 처리하는 것이 나을 것 같습니다.
이렇게 구현하는 것이 가능할까요?
@uhm0311 @oliviarla
위의 사항 검토 바랍니다.
위의 사항 때문에 기존에 piped 연산은 1개 연산으로만 제공했던 것은 아닌지 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
그러면 N개 pipe 연산을 보낼 때 1개를 보내고 응답을 받아서 실패하지 않았으면 다시 다음걸 보내는 방식으로 해야 합니다.
JDK 8에서는 CompletableFuture가 있으므로 1개 pipe 연산에 대한 CompletableFuture의 성공 Callback에 다음 pipe 연산을 보내는 식으로 구성하여 실패 시 다음 연산을 보내지 않도록 할 수 있습니다.
JDK 6에서는 ListenableFuture를 구현하지 않는 이상 비동기 방식은 불가능할 것으로 보입니다.
단, N개의 연산을 보낼 때 1개를 보내고 응답을 받아서 다음걸 보내는 방식은 N개 연산을 다 처리하는 데에는 지연 시간이 더 걸리게 되어 있으므로 Timeout 에러가 발생할 확률이 높아집니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
N개 pipe 연산을 보낼 때, 중간에 에러 발생 등으로 pipeline이 중단되는 경우가 아니면 마지막 N번째 연산을 보내기 전까지는 응답이 돌아오지 않을텐데요.
1개를 보내고 응답을 받은 뒤 다음 pipe 연산을 보낸다는 것의 의미가 제가 이해한 것과 다른 동작일까요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
500개의 연산을 1개의 pipe 연산으로 지칭한 것입니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jhpark816
exists 파이프만 1개 연산 지원이고, 다른 pipe는 초기 커밋부터 n개를 허용하였기에 그렇다고 보긴 힘들것 같네요