INTERNAL: make piped insert operations process synchronously#887
INTERNAL: make piped insert operations process synchronously#887jhpark816 merged 1 commit intonaver:developfrom
Conversation
src/main/java/net/spy/memcached/internal/PipedCollectionFuture.java
Outdated
Show resolved
Hide resolved
src/main/java/net/spy/memcached/protocol/ascii/SingleKeyPipeOperationImpl.java
Outdated
Show resolved
Hide resolved
src/test/manual/net/spy/memcached/bulkoperation/BopPipeUpdateTest.java
Outdated
Show resolved
Hide resolved
jhpark816
left a comment
There was a problem hiding this comment.
1차 리뷰 의견입니다.
추가 리뷰를 바로 진행할겠습니다.
src/main/java/net/spy/memcached/internal/PipedCollectionFuture.java
Outdated
Show resolved
Hide resolved
src/main/java/net/spy/memcached/internal/PipedCollectionFuture.java
Outdated
Show resolved
Hide resolved
src/main/java/net/spy/memcached/internal/PipedCollectionFuture.java
Outdated
Show resolved
Hide resolved
oliviarla
left a comment
There was a problem hiding this comment.
다른 리뷰 사항들은 반영해두었습니다.
src/main/java/net/spy/memcached/internal/PipedCollectionFuture.java
Outdated
Show resolved
Hide resolved
a7063fa to
2939657
Compare
|
@jhpark816 리뷰 반영하였습니다. |
src/main/java/net/spy/memcached/internal/PipedCollectionFuture.java
Outdated
Show resolved
Hide resolved
src/main/java/net/spy/memcached/protocol/ascii/PipeOperationImpl.java
Outdated
Show resolved
Hide resolved
src/main/java/net/spy/memcached/protocol/ascii/PipeOperationImpl.java
Outdated
Show resolved
Hide resolved
src/main/java/net/spy/memcached/protocol/ascii/PipeOperationImpl.java
Outdated
Show resolved
Hide resolved
src/main/java/net/spy/memcached/protocol/ascii/PipeOperationImpl.java
Outdated
Show resolved
Hide resolved
|
@uhm0311 리뷰 바랍니다. |
src/test/manual/net/spy/memcached/bulkoperation/PipeInsertTest.java
Outdated
Show resolved
Hide resolved
ac87315 to
cf6c6fa
Compare
This comment was marked as outdated.
This comment was marked as outdated.
src/test/manual/net/spy/memcached/bulkoperation/BopPipeUpdateTest.java
Outdated
Show resolved
Hide resolved
src/main/java/net/spy/memcached/protocol/ascii/PipeOperationImpl.java
Outdated
Show resolved
Hide resolved
6c6ba28 to
ab39e1e
Compare
src/test/manual/net/spy/memcached/bulkoperation/LopInsertBulkMultipleValueTest.java
Show resolved
Hide resolved
src/main/java/net/spy/memcached/protocol/ascii/PipeOperationImpl.java
Outdated
Show resolved
Hide resolved
src/main/java/net/spy/memcached/protocol/ascii/PipeOperationImpl.java
Outdated
Show resolved
Hide resolved
| } | ||
| } | ||
| return false; | ||
| return cancelled.get(); |
There was a problem hiding this comment.
future의 cancel(), isCancelled()가 자주 호출되는 메소드가 아니므로,
cancelled AtomicBoolean 값을 따로 두지 않아도 될 것 같은데요.
그리고, 단순 Boolean 값이어도 될 것 같습니다. 검토 바랍니다.
다른 쪽의 bulk 연산에서는 이러한 cancelled 값을 유지하는 지 궁금합니다.
There was a problem hiding this comment.
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() |
There was a problem hiding this comment.
!ops.get(opIdx).isCancelled() 조건이 필요한 지 궁금합니다.
현재 연산이 cancel 되었으면, operatoinStatus.isSuccess() == false 상태이지 않는 지 ?
There was a problem hiding this comment.
워커 스레드로부터 cancel이 호출되어 CANCELED 상태를 operationStatus에 저장하고 complete 메서드를 호출하는 도중에, IO 스레드에서 결과를 읽어들여 성공 상태로 덮어쓸 수 있습니다.
PipedCollectionFuture#setOperationStatus 메서드를 보시면 CANCELED 상태가 저장되어 있더라도 새로운 결과를 덮어쓰는 것을 확인할 수 있습니다.
|
@oliviarla 리뷰 코멘트 달았으니, 확인 바랍니다. |
oliviarla
left a comment
There was a problem hiding this comment.
나머지 코멘트에 대한 리뷰는 반영해두었습니다.
| public void complete() { | ||
| CollectionOperationStatus operationStatus = rv.getOperationStatus(); | ||
| if (operationStatus != null && operationStatus.isSuccess() | ||
| && !ops.get(opIdx).isCancelled() |
There was a problem hiding this comment.
워커 스레드로부터 cancel이 호출되어 CANCELED 상태를 operationStatus에 저장하고 complete 메서드를 호출하는 도중에, IO 스레드에서 결과를 읽어들여 성공 상태로 덮어쓸 수 있습니다.
PipedCollectionFuture#setOperationStatus 메서드를 보시면 CANCELED 상태가 저장되어 있더라도 새로운 결과를 덮어쓰는 것을 확인할 수 있습니다.
| } | ||
| } | ||
| return false; | ||
| return cancelled.get(); |
There was a problem hiding this comment.
future의 cancel(), isCancelled()가 자주 호출되는 메소드가 아니므로,
cancelled AtomicBoolean 값을 따로 두지 않아도 될 것 같은데요.
PipedCollectionFuture는 모든 op를 취소하는 것이 아니라 특정 op가 취소 가능하다면 취소시키고 바로 결과를 반환합니다. 그리고 이 과정에서 cancelled 플래그를 true로 두어, 다시 cancel 메서드가 호출되었을 때 더이상 op를 취소하지 않도록 합니다.
단순 Boolean 값이어도 될 것 같습니다.
대부분의 상황에서 cancel과 isCancelled를 하나의 스레드에서만 호출하기 때문에 boolean 타입을 사용해도 괜찮긴 한데, 여러 스레드에서 동시에 호출되는 케이스는 고려하지 않아도 되나요?
다른 쪽의 bulk 연산에서는 이러한 cancelled 값을 유지하는 지
다른쪽 bulk 연산은 비동기 방식이기 때문에 비교하기가 애매합니다.
🔗 Related Issue
⌨️ What I did
syncCollectionPipedInsert() / syncCollectionPipedUpdate()메서드