Skip to content
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

Merged
merged 1 commit into from
Jul 17, 2023

Conversation

brido4125
Copy link
Collaborator

@brido4125 brido4125 commented Jul 14, 2023

관련 이슈

https://github.com/jam2in/arcus-works/issues/419

Motivation

기존의 단일 Op를 가지는 Future의 cancel 로직은 아래와 같은 문제가 있다.

아래의 세가지 경우를 고려하지 않고
모든 case에 대해 op.cancel()을 호출시킨다.
그리고 OperationState.WRITE_QUEUED를 기준으로
cancel()의 성공 및 실패 여부를 알려준다.

  • op 진행 전 cancel() 요청
  • op 진행 중 cancel() 요청
  • op 완료 후 cancel() 요청

만약 op가 완료 된 후, cancel() 요청이 들어올 경우
응답값은 false로 정상적으로 돌려준다.
하지만 cancel() 요청 후, get() 메서드를 호출할 경우엔
ExecutionException을 발생시킨다.
즉, 작업의 완료로 인해 cancel이 실패하였음에도
cancel에 의한 예외가 발생한다.

정상 동작은 예외가 발생하지 않고 완료된 결과를 리턴해줘야한다.

변경 후 로직

  • op 진행 전 cancel() 요청 : return True, ExecutionException 발생
    • op의 state : OperationState.WRITE_QUEUED
  • op 진행 중 cancel() 요청 : return True, ExecutionException 발생
    • op의 state : OperationState.READING , OperationState.WRITING
  • op 완료 후 cancel() 요청 : return False, Future의 get() 호출 시 정상 응답
    • op의 state : OperationState.COMPLETE

참고로 single Op만을 가지는 Future들은 모두 OperationFuturecancel() 구현을 사용합니다.

@brido4125 brido4125 self-assigned this Jul 14, 2023
public boolean cancel(boolean ign) {
assert op != null : "No operation";
if (op.getState().equals(OperationState.COMPLETE)) {
Copy link
Collaborator

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;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

두 메소드에 변경 사항이 없어 보입니다. 원래 있던 위치에 놓아주세요.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

생성자 -> 오버라이드된 메서드 -> 인스턴스 메서드 순으로
다른 Future에서도 메서드 정렬 방식을 가져가고 있어서 유지하려고 합니다.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

그 변경사항은 현재 커밋 메세지에 어울리지 않으니, 다른 PR로 반영하도록 합시다.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

변경 완료하였습니다.

@brido4125 brido4125 requested a review from jhpark816 July 17, 2023 09:45
Copy link
Collaborator

@jhpark816 jhpark816 left a 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;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return true; 해도 될 것 같은 데, getState() 다시 확인하는 이유가 있나요?

Copy link
Collaborator Author

@brido4125 brido4125 Jul 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return true로 변경하는게 더 이해하기 쉬울것 같습니다.
별 다른 이유는 없었습니다.

@jhpark816 jhpark816 merged commit 4b8252b into naver:develop Jul 17, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants