INTERNAL: make lop piped operations process synchronously #795

oliviarla · 2024-08-19T06:37:39Z

🔗 Related Issue

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

⌨️ What I did

500개 아이템 단위로 Operation 객체를 나누어 비동기로 요청을 보내던 것을 동기 방식으로 보내어 Arcus 서버에 과도한 부하가 들어가는 것을 방지하고, 실패 시 다음 Operation을 수행하지 않도록 합니다.
- 만약 CLIENT_ERROR, SERVER_ERROR 실패가 발생하면 그 즉시 latch.countdown을 호출해 더이상 로직을 수행하지 않습니다.
- OVERFLOWED, OUT_OF_RANGE 같은 실패가 발생하면 이후의 item에 대해 CANCELLED 오류를 반환하도록 합니다.
기존에 asyncLopPipedInsert에서 입력받은 valueList 순서대로 저장하지 않는 문제가 있었고 이를 순서대로 저장하도록 변경했습니다.
시범적으로 Lop Piped Insert에만 적용합니다.
future를 통한 비동기 수행이 되기 때문에 메서드명은 그대로 두고자 합니다.

src/main/java/net/spy/memcached/ArcusClient.java

src/main/java/net/spy/memcached/internal/PipedCollectionFuture.java

src/main/java/net/spy/memcached/ArcusClient.java

jhpark816

일부 리뷰

src/main/java/net/spy/memcached/ArcusClient.java

jhpark816 · 2024-08-28T03:59:54Z

src/main/java/net/spy/memcached/ArcusClient.java

+                || rv.getOperationStatus().getResponse() == CollectionResponse.CANCELED) {
+          // countdown if this is last op
+          latch.countDown();
+        } else if (!rv.getOperationStatus().isSuccess()) {


rv.getOperationStatus().isSuccess() 조건으로 next 연산 수행 여부를 판단하기 어렵습니다.
이 부분에 대해 offline 논의해야 할 것 같습니다.

관련 사항을 좀 더 자세하게 적으면 다음과 같습니다.

PIPE_ERROR 응답이 온 경우

현재의 piped 연산에서 PIPE_ERROR로 인해 아예 수행되지 item 연산이 있을 수 있습니다.

이 경우, 현재 failed Result에 결과를 담지 않고 있으므로, 이를 추가해야 합니다.

PIPE_END 응답이 온 경우

개별 연산에 대해 NOT_FOUND, ELEMENT_EXISTS, OVERFLOWED, OUT_OF_RANGE, TYPE_MISMATCH, BKEY_MISMATCH 오류가 발생할 수 있습니다.

B+Tree collection에 대해 BKEY_MISMATCH 오류가 발생한 경우, 주어진 element만 insert 실패하고 나머진 성공할 수 있습니다. 이 경우, next 연산을 수행하는 것이 맞지 않는 지 ? ELEMENT_EXISTS 오류도 비슷해 보입니다.

그 외의 오류인 경우는 캐시 서버에서 수행을 중지하고, PIPE_ERROR 리턴해야 하지 않나 생각합니다.

결국, 캐시 서버 동작 부분도 함께 고려되어야 하지 않나 생각합니다.

END 응답이 왔고 btree일 때 BKEY_MISMATCH, map, set일 때 ELEMENT_EXISTS만 발생했다면 다음 Operation 보내는 것에는 동의합니다.

PIPE_ERROR가 CLIENT_ERROR, SERVER_ERROR 로 인해 발생했다면 예외가 발생해 failed result를 조회할 수 없습니다. PIPE_ERROR가 command/memory overflow 로 인해 발생했다면 에러를 무시하고 모든 응답을 기준으로 전체 성공/실패 여부만 판별합니다. 따라서 "PIPE_ERROR" 라는 응답이 왔는지 future에서는 확인할 수 없으며, failed result에 결과를 넣을 필요도 없습니다.

arcus-java-client/src/main/java/net/spy/memcached/protocol/ascii/CollectionPipedInsertOperationImpl.java

Lines 139 to 148 in f60ed48

if (line.startsWith("END") || line.startsWith("PIPE_ERROR ")) {

/* ENABLE_MIGRATION if */

if (needRedirect()) {

transitionState(OperationState.REDIRECT);

return;

}

/* ENABLE_MIGRATION end */

cb.receivedStatus((successAll) ? END : FAILED_END);

transitionState(OperationState.COMPLETE);

} else if (line.startsWith("RESPONSE ")) {

@oliviarla

기존 pipe 처리에도 일부 문제가 있는 것 같습니다.

CLIENT_ERROR, SERVER_ERROR 등의 오류가 있는 경우, java client는 PIPE_ERROR 응답까지 읽지 않는다.
그러면, 다음 연산에서 응답을 읽을 시에 PIPE_ERROR 응답을 보게 되는 문제가 있습니다.
대략 확인한 사항이라, 이 부분에 관한 코드는 직접 확인해 보기 바랍니다.

아래 2가지 PIPE_ERROR에 대해 "END" 응답을 받은 경우와 동일하게 처리합니다.
즉, 처리하지 못한 연산이 존재하더라도 처리가 완료된 것으로 판단하고 있습니다.

PIPE_ERROR command overflow

PIPE_ERROR memory overflow

이러한 pipe 처리 오류는 본 PR과는 별도로 처리해야 하죠?
검토 바랍니다.

CLIENT_ERROR, SERVER_ERROR 등의 오류가 있는 경우, 바로 OperationException이 throw 됩니다.
이 예외를 MemcachedConnection에서 catch하여 연결을 끊기 때문에 다음 연산이 응답을 읽을 수 없을 것으로 보입니다.

arcus-java-client/src/main/java/net/spy/memcached/MemcachedConnection.java

Lines 948 to 952 in 45720de

} catch (OperationException e) {

qa.setupForAuth("operation exception"); // noop if !shouldAuth

getLogger().warn("Reconnection due to exception " +

"handling a memcached exception on %s.", qa, e);

lostConnection(qa, ReconnDelay.IMMEDIATE, "operation exception");

PIPE_ERROR command/memory overflow 오류 시, 처리되지 못한 연산에 대해
본 PR 처럼 CANCELED CollectionOperationStatus 설정하는 것이 좋겠습니다.

PIPE_ERROR command/memory overflow 오류 시, 처리되지 못한 연산에 대해
본 PR 처럼 CANCELED CollectionOperationStatus 설정하는 것이 좋겠습니다.

위 사항을 구현하기 위해
아래 로직에서 cb.receivedStatus() 호출 시의 인자 값이 수정되어야 할 것 같습니다.

if (line.startsWith("END") || line.startsWith("PIPE_ERROR ")) { /* ENABLE_MIGRATION if */ if (needRedirect()) { transitionState(OperationState.REDIRECT); return; } /* ENABLE_MIGRATION end */ cb.receivedStatus((successAll) ? END : FAILED_END); transitionState(OperationState.COMPLETE); } else if (line.startsWith("RESPONSE ")) {

아래와 같이 호출해야 할 것 같습니다.

cb.receivedStatus((index == count && successAll) ? END : FAILED_END);

또한, 아래 경우에 CENCEL 상태를 추가하는 로직도 수정되어야 합니다.

if (!rv.getOperationStatus().isSuccess()) { rv.addEachResult(index + (idx * CollectionPipedInsert.MAX_PIPED_ITEM_COUNT), new CollectionOperationStatus(false, "CANCELED", CollectionResponse.CANCELED)); latch.countDown(); }

위와 같이 변경되면,
complete() 로직에서의 검사 순서도 변경되어야 합니다.
아래 조건이 가장 먼저 검사되어야 할 것입니다.

if (!rv.getOperationStatus().isSuccess())

jhpark816

리뷰 완료

src/main/java/net/spy/memcached/ArcusClient.java

oliviarla · 2024-09-06T10:22:28Z

@jhpark816 리뷰 반영했습니다.

jhpark816 · 2024-09-09T02:50:54Z

@uhm0311 리뷰 바랍니다.

uhm0311 · 2024-09-23T03:34:28Z

@oliviarla

컨플릭트 확인해주세요.

src/main/java/net/spy/memcached/ArcusClient.java

oliviarla · 2024-09-26T06:21:25Z

src/main/java/net/spy/memcached/protocol/ascii/CollectionPipedInsertOperationImpl.java

@@ -145,6 +145,10 @@ assert getState() == OperationState.READING
      /* ENABLE_MIGRATION end */
      cb.receivedStatus((successAll) ? END : FAILED_END);
      transitionState(OperationState.COMPLETE);
+    } else if (line.startsWith("PIPE_ERROR ")) {
+      // command flow / memory flow


@namsic @uhm0311
제 생각에는 PIPE_ERROR memory overflow일 경우에만 redirect 처리하도록 변경하면 될 것 같은데, 어떻게 생각하시나요?

PIPE_ERROR 종류가 무엇인가요?

PIPE_ERROR는 다음과 같은 종류가 있습니다.

PIPE_ERROR bad error : SERVER_ERROR / CLIENT_ERROR 발생하여 예외가 반환된 상황이며, 해당 두 케이스는 현재 처리중에 exception이 throw되므로 이 코드에 도달하지 않습니다.

PIPE_ERROR command overflow : pipelining 가능한 command의 최대 개수를 넘어선 요청이 들어와 예외가 반환된 상황

PIPE_ERROR memory overflow : pipelining 처리를 위한 메모리 공간이 부족하게 되어 파이프라인 수행을 멈추고 예외가 반환된 상황

command overflow와 memory overflow일 때 Redirect를 하지 않는 이유와 하는 이유는 무엇인가요?

command overflow일 때는 해당 operation으로 생성되는 pipe 명령어의 개수가 동일하기 때문에 redirect하여 똑같은 명령을 보내면 실패하므로 redirect할 필요성이 없어보입니다.
memory overflow일 때는 해당 캐시 노드에 memory 용량이 부족했던 것이기 때문에, 다른 노드로 redirect되었을 때 성공할 가능성이 있으므로 redirect 처리하면 될 것으로 보입니다.

참고 사항으로, 현재 서버 구현 기준

single key pipe에서 NOT_MY_KEY와 PIPE_ERROR를 함께 응답하는 경우는 없을 것입니다.

multi key pipe에서는 NOT_MY_KEY와 PIPE_ERROR가 함께 발생할 수 있습니다.

다만 migration 관련 구현은 아직 완전히 정리된 상태는 아니어서 추후 변경될 가능성은 있어 보입니다.

single key pipe에서 NOT_MY_KEY와 PIPE_ERROR를 함께 응답하는 경우는 없을 것입니다.

왜 그런지 간단히 설명해 주시죠.

왜 그런지 간단히 설명해 주시죠.

코드를 확인해 보니, NOT_MY_KEY 발생 이후 invalid command 수신하는 경우에는
NOT_MY_KEY + CLIENT_ERROR + PIPE_ERROR bad error 응답이 가능해 보입니다.

그 외에 정상적인 명령으로 구성된 single key pipe에서는 아래와 같이 동작합니다.

https://github.com/jam2in/arcus-memcached-EE/wiki/Response-format

pipe 처리 중 NOT_MY_KEY 발생하면 response buffer에 NOT_MY_KEY 응답을 추가합니다.

만약 이 응답을 추가하는 과정에서 문제가 생기면, NOT_MY_KEY 응답 대신
PIPE_ERROR 응답이 추가되며 pipe 종료하고 클라이언트에게 응답을 돌려줄 것입니다.

single key pipe 명령에서 직전 명령이 NOT_MY_KEY 발생했으면 현재 명령은 swallow(skip) 처리합니다.

수행하더라도 NOT_MY_KEY 발생할 것이기 때문입니다.

NOT_MY_KEY 1회 발생 이후 모든 명령이 swallow 처리되므로
PIPE_ERROR가 발생하는 상황(cmd_ovfl, mem_ovfl, ERROR)이 없고,
마지막 명령까지 swallow 처리된 후 END와 함께 클라이언트에게 응답 반환합니다.

CLIENT_ERROR 이더라도 PIPE_ERROR까지 읽도록 수정한다면,
PIPE_ERROR이더라도 redirect 수행해야 할 것입니다.
따라서, CLIENT_ERROR 이더라도 PIPE_ERROR까지 읽게 하는 작업을 먼저 진행하는 것이 좋겠습니다.

command overflow일 때는 해당 operation으로 생성되는 pipe 명령어의 개수가 동일하기 때문에 redirect하여 똑같은 명령을 보내면 실패하므로 redirect할 필요성이 없어보입니다.
memory overflow일 때는 해당 캐시 노드에 memory 용량이 부족했던 것이기 때문에, 다른 노드로 redirect되었을 때 성공할 가능성이 있으므로 redirect 처리하면 될 것으로 보입니다.

위의 내용에 대한 코멘트입니다.

command overflow에서 redirect하면, 처리되지 않은 연산만 보내므로 해당 연산들은 성공할 수 있습니다.

memory overflow에서 rediret하는 이유는 일부 연산이 처리되기 전에 해당 key가 다른 node로 이전했기 때문이며, 처리되지 못한 연산만을 이전된 node로 보내어 처리해야 하기 때문입니다.

클라이언트가 정상적으로 동작한다면 command overflow가 발생하지 않을 것입니다. 제 생각에는 command overflow가 발생하면 redirect하지 않고 예외를 발생시켜 문제가 있는 상황임을 알리는 것이 좋을 것 같습니다.

memory overflow에 대해서는 말씀하신 사항에 동의합니다.

jhpark816

리뷰 완료

src/main/java/net/spy/memcached/ArcusClient.java

jhpark816 · 2024-10-07T08:50:12Z

src/main/java/net/spy/memcached/ArcusClient.java

+          latch.countDown();
+        } else if (!rv.getOperationStatus().isSuccess()) {
+          // If this operation failed, remaining subsequent operation
+          // should not be added and should be marked as cancelled.


complete() 로직을 완벽하게 만들려면,
PIPE_ERROR이더라도 모든 응답을 읽어내는 기능이 먼저 구현되어야 할 것 같습니다.
이를 이슈로 올리고 작업을 시작하면 좋겠습니다.

jhpark816 · 2024-10-07T08:59:27Z

src/main/java/net/spy/memcached/ArcusClient.java

+                || rv.getOperationStatus().getResponse() == CollectionResponse.CANCELED) {
+          // countdown if this is last op
+          latch.countDown();
+        } else if (!rv.getOperationStatus().isSuccess()) {


PIPE_ERROR command/memory overflow 오류 시, 처리되지 못한 연산에 대해
본 PR 처럼 CANCELED CollectionOperationStatus 설정하는 것이 좋겠습니다.

위 사항을 구현하기 위해
아래 로직에서 cb.receivedStatus() 호출 시의 인자 값이 수정되어야 할 것 같습니다.

if (line.startsWith("END") || line.startsWith("PIPE_ERROR ")) { /* ENABLE_MIGRATION if */ if (needRedirect()) { transitionState(OperationState.REDIRECT); return; } /* ENABLE_MIGRATION end */ cb.receivedStatus((successAll) ? END : FAILED_END); transitionState(OperationState.COMPLETE); } else if (line.startsWith("RESPONSE ")) {

아래와 같이 호출해야 할 것 같습니다.

cb.receivedStatus((index == count && successAll) ? END : FAILED_END);

또한, 아래 경우에 CENCEL 상태를 추가하는 로직도 수정되어야 합니다.

if (!rv.getOperationStatus().isSuccess()) { rv.addEachResult(index + (idx * CollectionPipedInsert.MAX_PIPED_ITEM_COUNT), new CollectionOperationStatus(false, "CANCELED", CollectionResponse.CANCELED)); latch.countDown(); }

위와 같이 변경되면,
complete() 로직에서의 검사 순서도 변경되어야 합니다.
아래 조건이 가장 먼저 검사되어야 할 것입니다.

if (!rv.getOperationStatus().isSuccess())

jhpark816 · 2024-10-07T09:12:08Z

src/main/java/net/spy/memcached/internal/PipedCollectionFuture.java

-      }
-    }
-    return false;
+    return operationStatus.get().getResponse() == CollectionResponse.CANCELED;


마지막 op에 대해 isCancelled() 호출해야 하지 않나요?

return ops.get(ops.size() - 1).isCancelled();

사용자가 future.cancel을 호출하거나 내부적으로 op.cancel이 호출되면 BaseOperationImpl의 cancel 메서드가 호출됩니다.
해당 cancel 메서드 내부에서는 wasCancelled 메서드를 호출하게 되는데, 이는 자식 클래스인CollectionPipedInsertOperationImpl에 구현되어 있고, receivedStatus에 의해 future의 상태에 쓰이게 됩니다.
따라서 operationStatus만으로도 cancel 여부를 확인 가능합니다.

arcus-java-client/src/main/java/net/spy/memcached/protocol/BaseOperationImpl.java

Lines 95 to 107 in f60ed48

public final boolean cancel(String cause) {

if (callbacked.compareAndSet(false, true)) {

cancelled = true;

if (handlingNode != null) {

cause += " @ " + handlingNode.getNodeName();

}

cancelCause = "Cancelled (" + cause + ")";

wasCancelled();

callback.complete();

return true;

}

return false;

}

arcus-java-client/src/main/java/net/spy/memcached/protocol/ascii/CollectionPipedInsertOperationImpl.java

Lines 182 to 185 in f60ed48

@Override

protected void wasCancelled() {

getCallback().receivedStatus(STORE_CANCELED);

}

jhpark816 · 2024-10-07T09:54:05Z

src/main/java/net/spy/memcached/protocol/ascii/CollectionPipedInsertOperationImpl.java

@@ -145,6 +145,10 @@ assert getState() == OperationState.READING
      /* ENABLE_MIGRATION end */
      cb.receivedStatus((successAll) ? END : FAILED_END);
      transitionState(OperationState.COMPLETE);
+    } else if (line.startsWith("PIPE_ERROR ")) {
+      // command flow / memory flow


CLIENT_ERROR 이더라도 PIPE_ERROR까지 읽도록 수정한다면,
PIPE_ERROR이더라도 redirect 수행해야 할 것입니다.
따라서, CLIENT_ERROR 이더라도 PIPE_ERROR까지 읽게 하는 작업을 먼저 진행하는 것이 좋겠습니다.

command overflow일 때는 해당 operation으로 생성되는 pipe 명령어의 개수가 동일하기 때문에 redirect하여 똑같은 명령을 보내면 실패하므로 redirect할 필요성이 없어보입니다.
memory overflow일 때는 해당 캐시 노드에 memory 용량이 부족했던 것이기 때문에, 다른 노드로 redirect되었을 때 성공할 가능성이 있으므로 redirect 처리하면 될 것으로 보입니다.

위의 내용에 대한 코멘트입니다.

command overflow에서 redirect하면, 처리되지 않은 연산만 보내므로 해당 연산들은 성공할 수 있습니다.

memory overflow에서 rediret하는 이유는 일부 연산이 처리되기 전에 해당 key가 다른 node로 이전했기 때문이며, 처리되지 못한 연산만을 이전된 node로 보내어 처리해야 하기 때문입니다.

jhpark816 · 2024-10-07T10:00:04Z

src/main/java/net/spy/memcached/internal/PipedCollectionFuture.java

-        throw new CheckedOperationTimeoutException(duration, unit, elapsed, timedOutOps);
-      }
+    Operation lastOp = ops.get(ops.size() - 1);
+    if (!latch.await(duration, unit) && lastOp.getState() != OperationState.COMPLETE) {


latch.await() 호출 전에 lastOp 객체를 미리 구해두는 것이 이상합니다.
latch.await() 동안에도 새로운 op가 생성되어 등록될 수 있기 때문입니다.

그리고, lastOp가 실제 future에 등록된 마지막 op가 아니라
실제 요청해야 할 마지막 op이어야 하지 않는가요?

그리고, lastOp가 실제 future에 등록된 마지막 op가 아니라
실제 요청해야 할 마지막 op이어야 하지 않는가요?

여러 Op 객체 연산 수행 중 하나의 Op에서 예외나 잘못된 응답이 발생하면 future에 다음 Op를 넣지 않고 latch를 countdown시킵니다.
따라서 future에서는 실제 요청해야 할 마지막 Op를 확인할 필요 없이 실행되었던 가장 마지막 Op만 확인하는 것입니다.

oliviarla requested review from jhpark816 and uhm0311 August 19, 2024 06:37

oliviarla referenced this pull request in oliviarla/arcus-java-client Aug 19, 2024

INTERNAL: lop pipe version2

2f92cfc

jhpark816 removed their request for review August 19, 2024 06:42

oliviarla requested review from jhpark816 and removed request for jhpark816 August 19, 2024 06:43

oliviarla self-assigned this Aug 19, 2024

uhm0311 reviewed Aug 19, 2024

View reviewed changes

src/main/java/net/spy/memcached/ArcusClient.java Outdated Show resolved Hide resolved

src/main/java/net/spy/memcached/ArcusClient.java Outdated Show resolved Hide resolved

oliviarla force-pushed the pipe2 branch from 09b5b09 to 7e9b0f9 Compare August 19, 2024 08:38

uhm0311 reviewed Aug 21, 2024

View reviewed changes

src/main/java/net/spy/memcached/ArcusClient.java Outdated Show resolved Hide resolved

src/main/java/net/spy/memcached/internal/PipedCollectionFuture.java Show resolved Hide resolved

src/main/java/net/spy/memcached/internal/PipedCollectionFuture.java Show resolved Hide resolved

oliviarla force-pushed the pipe2 branch 3 times, most recently from 9eb5496 to 076d02b Compare August 23, 2024 11:35

uhm0311 reviewed Aug 26, 2024

View reviewed changes

src/main/java/net/spy/memcached/ArcusClient.java Outdated Show resolved Hide resolved

src/main/java/net/spy/memcached/ArcusClient.java Outdated Show resolved Hide resolved

oliviarla force-pushed the pipe2 branch from 076d02b to b89e895 Compare August 27, 2024 02:18

uhm0311 previously approved these changes Aug 27, 2024

View reviewed changes

oliviarla requested a review from jhpark816 August 28, 2024 02:43

jhpark816 reviewed Aug 28, 2024

View reviewed changes

oliviarla dismissed uhm0311’s stale review via 90a7ee5 August 28, 2024 06:22

oliviarla force-pushed the pipe2 branch 2 times, most recently from 90a7ee5 to df233d9 Compare September 2, 2024 03:29

jhpark816 reviewed Sep 6, 2024

View reviewed changes

src/main/java/net/spy/memcached/ArcusClient.java Outdated Show resolved Hide resolved

src/main/java/net/spy/memcached/ArcusClient.java Outdated Show resolved Hide resolved

oliviarla force-pushed the pipe2 branch 4 times, most recently from 600f2b2 to d232a01 Compare September 6, 2024 09:15

oliviarla added the prototype label Sep 10, 2024

oliviarla force-pushed the pipe2 branch 2 times, most recently from 237a9b6 to f4aabe9 Compare September 23, 2024 04:06

uhm0311 reviewed Sep 23, 2024

View reviewed changes

src/main/java/net/spy/memcached/ArcusClient.java Outdated Show resolved Hide resolved

uhm0311 previously approved these changes Sep 23, 2024

View reviewed changes

oliviarla force-pushed the pipe2 branch from f4aabe9 to dd84b6e Compare September 26, 2024 02:35

oliviarla commented Sep 26, 2024

View reviewed changes

jhpark816 reviewed Oct 7, 2024

View reviewed changes

oliviarla dismissed uhm0311’s stale review via db4f08a October 14, 2024 02:56

oliviarla force-pushed the pipe2 branch from dd84b6e to db4f08a Compare October 14, 2024 02:56

INTERNAL: make lop piped operations process synchronously

e5edceb

oliviarla force-pushed the pipe2 branch from db4f08a to e5edceb Compare October 14, 2024 02:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

INTERNAL: make lop piped operations process synchronously #795

INTERNAL: make lop piped operations process synchronously #795

oliviarla commented Aug 19, 2024

jhpark816 left a comment

jhpark816 Aug 28, 2024

jhpark816 Aug 28, 2024

oliviarla Aug 28, 2024

jhpark816 Sep 6, 2024

oliviarla Sep 6, 2024

jhpark816 Sep 6, 2024

jhpark816 Oct 7, 2024

jhpark816 left a comment

oliviarla commented Sep 6, 2024

jhpark816 commented Sep 9, 2024

uhm0311 commented Sep 23, 2024

oliviarla Sep 26, 2024

uhm0311 Sep 26, 2024

oliviarla Sep 26, 2024

uhm0311 Sep 26, 2024

oliviarla Sep 26, 2024

namsic Sep 26, 2024

jhpark816 Sep 26, 2024

namsic Sep 26, 2024

jhpark816 Oct 7, 2024

oliviarla Oct 14, 2024

jhpark816 left a comment

jhpark816 Oct 7, 2024

jhpark816 Oct 7, 2024

jhpark816 Oct 7, 2024

oliviarla Oct 14, 2024

jhpark816 Oct 7, 2024

jhpark816 Oct 7, 2024

oliviarla Oct 14, 2024

	if (line.startsWith("END") \|\| line.startsWith("PIPE_ERROR ")) {
	/* ENABLE_MIGRATION if */
	if (needRedirect()) {
	transitionState(OperationState.REDIRECT);
	return;
	}
	/* ENABLE_MIGRATION end */
	cb.receivedStatus((successAll) ? END : FAILED_END);
	transitionState(OperationState.COMPLETE);
	} else if (line.startsWith("RESPONSE ")) {

	} catch (OperationException e) {
	qa.setupForAuth("operation exception"); // noop if !shouldAuth
	getLogger().warn("Reconnection due to exception " +
	"handling a memcached exception on %s.", qa, e);
	lostConnection(qa, ReconnDelay.IMMEDIATE, "operation exception");

	public final boolean cancel(String cause) {
	if (callbacked.compareAndSet(false, true)) {
	cancelled = true;
	if (handlingNode != null) {
	cause += " @ " + handlingNode.getNodeName();
	}
	cancelCause = "Cancelled (" + cause + ")";
	wasCancelled();
	callback.complete();
	return true;
	}
	return false;
	}

	@Override
	protected void wasCancelled() {
	getCallback().receivedStatus(STORE_CANCELED);
	}

INTERNAL: make lop piped operations process synchronously #795

Are you sure you want to change the base?

INTERNAL: make lop piped operations process synchronously #795

Conversation

oliviarla commented Aug 19, 2024

🔗 Related Issue

⌨️ What I did

jhpark816 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jhpark816 left a comment

Choose a reason for hiding this comment

oliviarla commented Sep 6, 2024

jhpark816 commented Sep 9, 2024

uhm0311 commented Sep 23, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jhpark816 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment