Skip to content

Comments

INTERNAL: make piped insert operations process synchronously#887

Merged
jhpark816 merged 1 commit intonaver:developfrom
oliviarla:pipe3
Aug 19, 2025
Merged

INTERNAL: make piped insert operations process synchronously#887
jhpark816 merged 1 commit intonaver:developfrom
oliviarla:pipe3

Conversation

@oliviarla
Copy link
Collaborator

@oliviarla oliviarla commented Mar 14, 2025

🔗 Related Issue

⌨️ What I did

  • ArcusClient 클래스
    • syncCollectionPipedInsert() / syncCollectionPipedUpdate() 메서드
      • 현재 수행중인 op 한 개가 complete된 후에 다음 op를 MemcachedNode가 처리할 수 있도록 등록한다.
  • PipedCollectionFuture
    • 초기에 생성된 모든 operation들을 List 필드에 담아두도록 한다.
    • 사용자로부터 cancel 요청 시, 기존에 cancel 되지 않은 상태라면 op를 순회하며 cancel을 시도한다.
    • 내부적으로 혹은 사용자로부터 온 cancel 요청이 성공하지 않았거나, cancel 요청이 아직 진행중인 경우 isCancelled()는 false를 반환한다.
    • 사용자의 cancel 요청(worker thread)과 내부 동작 중 cancel 요청(IO thread)이 동시에 발생할 수 있다.
      • BaseOperationImpl의 callbacked 변수로 인해 해당 값을 먼저 점유한 요청이 먼저 cancel을 시도하게 된다.
      • 이미 cancel된 후에는 다른 요청이 cancel을 할 수 없게 된다.
        • 사용자 요청이 실패했다면 Future에서 다음 op에 대해 cancel 요청을 보낼 것이다.
        • 내부 요청이 실패했다면 별다른 처리를 하지 않는다.

@oliviarla oliviarla marked this pull request as ready for review March 17, 2025 05:25
@oliviarla oliviarla requested review from jhpark816 and uhm0311 March 17, 2025 05:49
Copy link
Collaborator

@uhm0311 uhm0311 left a comment

Choose a reason for hiding this comment

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

우선 질문 위주입니다.

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.

1차 리뷰 의견입니다.

추가 리뷰를 바로 진행할겠습니다.

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.

추가 리뷰

Copy link
Collaborator Author

@oliviarla oliviarla left a comment

Choose a reason for hiding this comment

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

다른 리뷰 사항들은 반영해두었습니다.

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.

일부 리뷰

@oliviarla oliviarla force-pushed the pipe3 branch 3 times, most recently from a7063fa to 2939657 Compare March 27, 2025 07:16
@oliviarla
Copy link
Collaborator Author

@jhpark816 리뷰 반영하였습니다.

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.

리뷰 완료

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.

리뷰 완료

@jhpark816
Copy link
Collaborator

@uhm0311 리뷰 바랍니다.

Copy link
Collaborator

@uhm0311 uhm0311 left a comment

Choose a reason for hiding this comment

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

질문입니다.

@oliviarla oliviarla force-pushed the pipe3 branch 2 times, most recently from ac87315 to cf6c6fa Compare April 2, 2025 09:09
@oliviarla

This comment was marked as outdated.

@oliviarla oliviarla marked this pull request as draft May 2, 2025 00:46
@oliviarla oliviarla marked this pull request as ready for review June 10, 2025 07:49
@oliviarla oliviarla force-pushed the pipe3 branch 2 times, most recently from 6c6ba28 to ab39e1e Compare July 30, 2025 12:15
@oliviarla oliviarla marked this pull request as draft July 30, 2025 12:18
@oliviarla oliviarla marked this pull request as ready for review July 30, 2025 12:40
@oliviarla oliviarla requested a review from Copilot July 30, 2025 12:42

This comment was marked as resolved.

uhm0311
uhm0311 previously approved these changes Jul 31, 2025
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.

일부 리뷰

}
}
return false;
return cancelled.get();
Copy link
Collaborator

@jhpark816 jhpark816 Aug 13, 2025

Choose a reason for hiding this comment

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

future의 cancel(), isCancelled()가 자주 호출되는 메소드가 아니므로,
cancelled AtomicBoolean 값을 따로 두지 않아도 될 것 같은데요.
그리고, 단순 Boolean 값이어도 될 것 같습니다. 검토 바랍니다.
다른 쪽의 bulk 연산에서는 이러한 cancelled 값을 유지하는 지 궁금합니다.

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의 cancel(), isCancelled()가 자주 호출되는 메소드가 아니므로,
cancelled AtomicBoolean 값을 따로 두지 않아도 될 것 같은데요.

PipedCollectionFuture는 모든 op를 취소하는 것이 아니라 특정 op가 취소 가능하다면 취소시키고 바로 결과를 반환합니다. 그리고 이 과정에서 cancelled 플래그를 true로 두어, 다시 cancel 메서드가 호출되었을 때 더이상 op를 취소하지 않도록 합니다.

단순 Boolean 값이어도 될 것 같습니다.

대부분의 상황에서 cancel과 isCancelled를 하나의 스레드에서만 호출하기 때문에 boolean 타입을 사용해도 괜찮긴 한데, 여러 스레드에서 동시에 호출되는 케이스는 고려하지 않아도 되나요?

다른 쪽의 bulk 연산에서는 이러한 cancelled 값을 유지하는 지

다른쪽 bulk 연산은 비동기 방식이기 때문에 비교하기가 애매합니다.

public void complete() {
CollectionOperationStatus operationStatus = rv.getOperationStatus();
if (operationStatus != null && operationStatus.isSuccess()
&& !ops.get(opIdx).isCancelled()
Copy link
Collaborator

Choose a reason for hiding this comment

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

!ops.get(opIdx).isCancelled() 조건이 필요한 지 궁금합니다.
현재 연산이 cancel 되었으면, operatoinStatus.isSuccess() == false 상태이지 않는 지 ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

워커 스레드로부터 cancel이 호출되어 CANCELED 상태를 operationStatus에 저장하고 complete 메서드를 호출하는 도중에, IO 스레드에서 결과를 읽어들여 성공 상태로 덮어쓸 수 있습니다.

PipedCollectionFuture#setOperationStatus 메서드를 보시면 CANCELED 상태가 저장되어 있더라도 새로운 결과를 덮어쓰는 것을 확인할 수 있습니다.

@jhpark816
Copy link
Collaborator

@oliviarla 리뷰 코멘트 달았으니, 확인 바랍니다.

Copy link
Collaborator Author

@oliviarla oliviarla left a comment

Choose a reason for hiding this comment

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

나머지 코멘트에 대한 리뷰는 반영해두었습니다.

public void complete() {
CollectionOperationStatus operationStatus = rv.getOperationStatus();
if (operationStatus != null && operationStatus.isSuccess()
&& !ops.get(opIdx).isCancelled()
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

워커 스레드로부터 cancel이 호출되어 CANCELED 상태를 operationStatus에 저장하고 complete 메서드를 호출하는 도중에, IO 스레드에서 결과를 읽어들여 성공 상태로 덮어쓸 수 있습니다.

PipedCollectionFuture#setOperationStatus 메서드를 보시면 CANCELED 상태가 저장되어 있더라도 새로운 결과를 덮어쓰는 것을 확인할 수 있습니다.

}
}
return false;
return cancelled.get();
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의 cancel(), isCancelled()가 자주 호출되는 메소드가 아니므로,
cancelled AtomicBoolean 값을 따로 두지 않아도 될 것 같은데요.

PipedCollectionFuture는 모든 op를 취소하는 것이 아니라 특정 op가 취소 가능하다면 취소시키고 바로 결과를 반환합니다. 그리고 이 과정에서 cancelled 플래그를 true로 두어, 다시 cancel 메서드가 호출되었을 때 더이상 op를 취소하지 않도록 합니다.

단순 Boolean 값이어도 될 것 같습니다.

대부분의 상황에서 cancel과 isCancelled를 하나의 스레드에서만 호출하기 때문에 boolean 타입을 사용해도 괜찮긴 한데, 여러 스레드에서 동시에 호출되는 케이스는 고려하지 않아도 되나요?

다른 쪽의 bulk 연산에서는 이러한 cancelled 값을 유지하는 지

다른쪽 bulk 연산은 비동기 방식이기 때문에 비교하기가 애매합니다.

@jhpark816 jhpark816 merged commit e9c7897 into naver:develop Aug 19, 2025
2 checks passed
@oliviarla oliviarla deleted the pipe3 branch August 28, 2025 08:17
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