-
Notifications
You must be signed in to change notification settings - Fork 47
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
FIX: change cancel method logic in OperationFuture. #639
Conversation
public boolean cancel(boolean ign) { | ||
assert op != null : "No operation"; | ||
if (op.getState().equals(OperationState.COMPLETE)) { |
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.
enum이니까 == 연산으로 비교해도 됩니다.
public boolean isDone() { | ||
assert op != null : "No operation"; | ||
return latch.getCount() == 0 || | ||
op.isCancelled() || op.getState() == OperationState.COMPLETE; |
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.
두 메소드에 변경 사항이 없어 보입니다. 원래 있던 위치에 놓아주세요.
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.
생성자 -> 오버라이드된 메서드 -> 인스턴스 메서드 순으로
다른 Future에서도 메서드 정렬 방식을 가져가고 있어서 유지하려고 합니다.
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.
그 변경사항은 현재 커밋 메세지에 어울리지 않으니, 다른 PR로 반영하도록 합시다.
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.
변경 완료하였습니다.
5ec258a
to
4875ae7
Compare
4875ae7
to
a47fa4f
Compare
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.
리뷰 완료
// This isn't exactly correct, but it's close enough. If we're in | ||
// a writing state, we *probably* haven't started. | ||
return op.getState() == OperationState.WRITE_QUEUED; | ||
return op.getState() != OperationState.COMPLETE; |
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.
return true;
해도 될 것 같은 데, getState() 다시 확인하는 이유가 있나요?
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.
return true
로 변경하는게 더 이해하기 쉬울것 같습니다.
별 다른 이유는 없었습니다.
a47fa4f
to
3628823
Compare
관련 이슈
https://github.com/jam2in/arcus-works/issues/419
Motivation
기존의 단일 Op를 가지는 Future의 cancel 로직은 아래와 같은 문제가 있다.
아래의 세가지 경우를 고려하지 않고
모든 case에 대해 op.cancel()을 호출시킨다.
그리고
OperationState.WRITE_QUEUED
를 기준으로cancel()의 성공 및 실패 여부를 알려준다.
만약 op가 완료 된 후, cancel() 요청이 들어올 경우
응답값은 false로 정상적으로 돌려준다.
하지만 cancel() 요청 후, get() 메서드를 호출할 경우엔
ExecutionException
을 발생시킨다.즉, 작업의 완료로 인해 cancel이 실패하였음에도
cancel에 의한 예외가 발생한다.
정상 동작은 예외가 발생하지 않고 완료된 결과를 리턴해줘야한다.
변경 후 로직
OperationState.WRITE_QUEUED
OperationState.READING
,OperationState.WRITING
OperationState.COMPLETE
참고로 single Op만을 가지는
Future
들은 모두OperationFuture
의cancel()
구현을 사용합니다.