Page History

Remote 는, 기존 작성했던 액터를 그대로 재활용하여 , 액터설계의 코드변경없이

원격지에서 사용이 가능합니다. 이것은 아주 큰장점입니다. 대부분의 비동기처리에 있어서

로컬에서도 휼륭한 역활을 하지만 , 원격에 배치를 하여 메시지처리를 휼륭하게 합니다.

액터가 리모터 기능을 가지게 되더라도, 액터의 코드변경은 없으며 ,이것이 Actor를 굳이 RemoteActor라고 부르지 않는 이유입니다.

이전에 학습한 Router를 참조하여, 3대정도의 서비스를 뛰워 원격 라운드로빈 처리가 가능한지

샘플 코드작성을 해보는것을 추천합니다. 그리고 이것은 액터설계에 아무런 변경이 없다란 장점을 알게될것입니다.

만약 리모트 역활을 위해 

우리는 EchoActor를 통해 자신이한 인사가 되돌아오는것을 확인하였습니다.

하지만 이러한 가정을 해봅시다. EchoActor1가 EcshoActor2 에게 인사를 합니다.

어떠한 상황이 펼쳐질까요? 메시지간 무한반복이 됩니다. 인사를하고 인사를 받고 또하고 받고하는

끝나지 않는 상황이 됩니다. 응답시간이 0 이라고 가정해봅시다.

이것은 무한대의 메시지 처리가 될것입니다. 마치 거울두개를 맞되어 무한의 이미지가 투영되는것으로

슈퍼컴퓨터도 이것을 처리할수 없습니다. 보통 메모리가 풀에 다다른 이후 GC에의한 CPU 100% 가 예상됩니다.

가끔 이것을 컴퓨터가 얼마나 버티냐? 호기심에 부하테스트를 하기도합니다.

네트워크상황이 더 좋을수록 이것은 보통 더 빨리 크래쉬가 납니다.

이러한 실수를 방지하려면 보통 네이밍 기법으로 해결합니다.

Hello ==> HellowReq , HelloRes 이렇게 요청과/응답을 분리를 합니다.

인사의 속성을 살펴보면, 같은 안녕이지만 처음 인사는 인사의 응답을 받는 숨은 의미가 있습니다.

그래서 HellowReq (Request) 입니다. 인사에 대응하는 안녕은 응답을 해주고, 다음에 그어떤 기대가

숨어있지 않습니다. 그래서 HellowRes(Response) 입니다.

하지만 이방식은 일반적인 방식은 아니며 , 전통적인 패킷설계방식을 적용한것입니다.

액터는 메시지 네이밍에 관여하지 않고, 처리지정된 메시지패턴만 가지고 처리하려고 하기때문에

이것은 응용개발자가 더 좋은 방법으로 설계를 할수가 있을것입니다.

추가적으로 액터메시지는, 전송이후 메시지를 변조하는것을(메시지는 전송이후 불변이여야한다의 원칙)

일반적으로 금지하고 있습니다.(어떠한 전략에의해 복사/변경할수 있는 전략을 쓰기도 하지만 일반적이진 않습니다.)두 액터간 메시지를 주고 받을때, 인사(Hello)에 항상 반응 하는 두 액터가 있다고 가정해봅시다.

두 액터중 아무나 먼저 상대 액터에게 인사를 시작하면 두액터는 무한대로 인사를 주고 받을것입니다.

네트워크에서 발생할수 있는 무한루프이며, 네트워크 지연이없을수록 하드웨어 자원(CPU,메모리)를 빠르게 고갈시킬것입니다.

이러한 실수를 방지하기위해 전통적인 방법으로는 전송 오브젝트에대해 요청(Req)과 응답(Res)을 분리하여 네이밍을 할수 있습니다.