INTERNAL: Refactor bopBulkGet API logic.

[brido4125]

Motivation

btreeGetBulk API의 내부 패턴이 다른 API들과 통일 되도록 변경한다.
기존에는 rv를 생성하지 않고 return문에서 Future를 생성하여 리턴하는 패턴이다.

[jhpark816]

구현 패턴 논의가 먼저 결정되어야 할 것 같습니다.

[brido4125]

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

위 코멘트에서 논의된 아래와 같은 패턴을 사용하지 않나요?

void asyncSomeApi(//...){
	SomeFuture<Result> rv = new SomeFuture<Result>(//Parameters need to rv);
	Operation op = opFact.someOp(
		new SomeCallback(){
			@Override
			public void recevivedStatus(OperationStatus status){
				//...
			}

			// implementaion other abstract method ...
		}
	)
	rv.setOperation(op);
	addOp(k, op); //Allocation op to MemcachedNode by Key.
	return rv;
}

[jhpark816]

@brido4125 @uhm0311 PR 리뷰 및 처리 바랍니다.

[jhpark816]

@brido4125
기존 구현 패턴이 읽기 나은 것 같습니다.

@oliviarla @uhm0311
구현 패턴에 대해 의견이 어떤가요?

[uhm0311]

@jhpark816

기존 구현 패턴으로 유지한다고 하면 어느 한 쪽으로 통일하지 않고 원래 패턴과 현재 PR의 패턴이 혼용된 상태로 API들이 존재하게 되는 것인가요?

[jhpark816]

@uhm0311
현재까지 괜찮다고 정리된 구현 패턴은 2가지가 있으며,
2가지를 모두 유지할 지 아니면 1가지로 통일할 지는 검토할 대상입니다.
대표 연산에 대해 구현 패턴의 가능성, 장단점을 살펴보면 되지 않나 생각합니다.

참고로, bopBulkGet과 bopSortMergeGet에서
latch, ops, result, timeout 인자로 future 생성하여 리턴하는 패턴은
result 생성에서 futue 연관성이 없어 읽기가 쉽습니다.

[oliviarla]

@jhpark816
현재까지 괜찮다고 정리된 구현 패턴은 2가지를 어디에서 확인할 수 있나요?

[jhpark816]

@oliviarla
아래 이슈를 참고하면 되는 데, 지금 보니 현재 정리 및 논의 중인 것 같습니다.
https://github.com/jam2in/arcus-works/issues/428

@brido4125
위의 이슈를 확인하고, 추가 정리할 부분이 있다면 정리 바랍니다.

[jhpark816]

latch, ops, result로 Future 객체를 만들어 리턴하는 패턴을 그대로 유지하기로 했습니다.