INTERNAL: Change asyncGets return future type.

[brido4125]

변경 사항

• 오전에 오프라인으로 논의된 asyncGets API의 Future 리턴 타입을 OperationFuture -> GetFuture로 변경하였습니다.

• 아래의 코멘트의 Transcoder 문제 때문에 CASGetResult<T>를 사용해서 구현하였습니다.

  • INTERNAL: Remove transcoder service logic in bulkGet apis. #710 (comment)

• GetResult 인터페이스를 통해 아래 문제를 해결하였습니다.

• 이를 해결하기 위해 해당 PR은 생성자 내에서 super(null)을 사용하였습니다. 아래 코멘트는 다른 방안들입니다.

  • INTERNAL: Remove transcoder service logic in bulkGet apis. #710 (comment)

• @Deprecated를 사용하려면 asyncGetsNew() 와 같은 새로운 함수를 정의하고 기존asyncGets()에 @Deprecated을 붙여줘야합니다. 메서드의 리턴값만 다를 경우 오버로딩이 적용되지 않기 때문입니다. 우선은 로직에 대한 리뷰를 먼저 받기 위해 기존 메서드의 리턴값을 바로 변경하였습니다.

• GetResult 생성자에서 CachedData를 외부로부터 주입 받는 로직은 별도의 PR로 반영하겠습니다.

[brido4125]

PR 본문의 @Deprecated 관련 의견이 필요합니다.

1. 기존 API에서 곧바로 변경(현재 구현)
2. @Deprecated붙이고 새로운 asynGetsNew()와 같은 API 추가

1번의 경우 버전 업그레이드 후 컴파일 시 컴파일 에러가 발생하고,
2번의 경우 추후 @Deprecated된 API가 삭제될 경우, 함수명 변경을 진행해줘야합니다.
다만, 2번의 경우도 Warning을 에러 처리한 WAS인 경우 컴파일 에러가 발생합니다.

추가적인 다른 의견도 주시면 감사하겠습니다.

[jhpark816]

리뷰 완료

[uhm0311]

PR 본문의 @deprecated 관련 의견이 필요합니다.

저는 2번이 낫다고 봅니다.
그런데 의문이 하나 있습니다.
기존 API를 Deprecated 처리 한다고 해서 모든 응용이 기존 API를 사용하지 않는 것은 아닙니다.
그럼 기존 API는 여전히 IO Thread에 의해 디코딩 작업을 하도록 내버려 두나요?
아니면 기존 API도 응용의 Worker Thread가 디코딩 작업을 하도록 개선을 하긴 하나요?

[brido4125]

그럼 기존 API는 여전히 IO Thread에 의해 디코딩 작업을 하도록 내버려 두나요?
아니면 기존 API도 응용의 Worker Thread가 디코딩 작업을 하도록 개선을 하긴 하나요?

개선을 하려면 하위호환성에 영향을 미치지 않게 개선을해야하는데, 그럴 경우 CASValue를 활용한다거나 등의 새로운 변경이 발생합니다.
그리고 해당 변경은 추후에 기존 API를 삭제할 경우 롤백시켜야합니다.

그렇기 때문에 Deprecated 처리될 API는 여전히 IO 쓰레드가 작업을 하도록 놔두는게 맞는것 같습니다.

[jhpark816]

GetFuture가 OperationFuture를 inherit 하면 backward compatibility는 만족이 되나요?

[uhm0311]

GetFuture가 OperationFuture를 inherit 하면 backward compatibility는 만족이 되나요?

만족이 되기 때문에 새 API를 만들고 기존 API를 Deprecated 처리할 필요가 없어집니다.

[jhpark816]

그러면, 상속 관계를 이용하여 backward compatibility 이슈를 해결하는 것이 좋겠습니다.
CollectionGetFuture와 CollectionFuture도 상속 관계가 있는 것 같으니, 확인 바랍니다.

[jhpark816]

리뷰 완료

[jhpark816]

리뷰 완료

[jhpark816]

@brido4125
수정 완료된 상태이면, noti 주세요.

[oliviarla]

리뷰 완료입니다.

[oliviarla]

@jhpark816 @uhm0311 @brido4125
FrontCacheGetFuture가 GetFuture를 상속받으면서 동시에 GetFuture 필드를 갖고 있는 것이 좋은 형태는 아닌 것 같습니다. 일단은 지금 형태로 머지하되, 나중에는 FrontCacheGetFuture가 GetFuture를 상속하지 않도록 전체적인 구조를 변경하거나 GetFuture필드를 제거할 방안을 고민해보는 게 어떨까 싶습니다.

[jhpark816]

리뷰 완료

[jhpark816]

set()과 setOperation()을 override 하지 않아도 되는 이유는 무엇인가요?

[brido4125]

아래 시퀀스로 parent에 op와 opertaionStatus가 설정됩니다.

1.setOperation() -> asyncGet() 에서 호출 (콜백 X)
2.set -> receivedStatus() 에서 호출 (콜백)

FrontCacheFuture는 parent의 op와 operationStatus를 리턴하면 됩니다.

결론적으로 parent에 설정된 operation과 operationStatus를
사용하도록 메서드를 오버라이딩해서입니다.