-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Aim 58 impl udp server #26
base: develop
Are you sure you want to change the base?
Conversation
src/main/java/com/example/pitching/call/handler/CallWebSocketHandler.java
Outdated
Show resolved
Hide resolved
src/main/java/com/example/pitching/call/operation/request/InitRequest.java
Outdated
Show resolved
Hide resolved
} | ||
|
||
private Mono<Sinks.Many<DatagramPacket>> getChannelSink(String channelId) { | ||
// TODO: get 에서 에러가 발생하면 서버가 끊김 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
해당 TODO
의 해결방식이 명시되지 않은 것 같습니다. TODO는 문제를 명시하기보다 해야할 일을 명시해주면 좋을 것 같아요!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UDP 관련된 부분은 이번 티켓에서 다루지 않을 예정이기도 하고, 해당 문제도 테스트 후 정확한 진단이 필요해서 다음 티켓에서 정확히 분석 후 진행하겠습니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
아니요. UDP와 관련한 작업은 이후에 작업해주시면 되는 부분인 것 같고요.
TODO 주석은 이후 어떤 작업을 해야될지 나타내야하는 주석이라고 생각을 해요. develop 브랜치에 merge 되는 부분은 문제 없는 부분들이 merge 되야한다고 생각하는데, 해당 주석은 merge 되기에는 맞지 않다고 생각해서 이번 pr에서 수정해주셨으면 좋겠습니다.
.wiretap(true) | ||
.doOnChannelInit((observer, channel, remote) -> | ||
channel.pipeline().addFirst(new LoggingHandler("reactor.netty.examples"))) | ||
.option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
해당 5000이라는 값은 옆에 MILLIS를 보고나서야 5초라는 것을 알 수 있는 값 인 것 같아요. 의미있는 변수명을 통해 명시해주는 게 보다 좋을 것 같습니다! 또한, 유지보수 측면에서도 yml에서 값을 설정하는 것이 좋아보여요!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UDP 관련된 부분은 이번 티켓에서 다루지 않을 예정이기도 하고, 다음 티켓에서 정리해서 반영해도 될까요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
위에 적은 TODO와 같은 맥락이라고 생각합니다. 이번 브랜치에서 수정해주셨으면 좋겠습니다. 만약, 이후 브랜치에서 수정하지 않을거라면 TODO 처리해주시면 좋을 것 같아요
|
||
public void initializeCallSink(ChannelEnterResponse channelEnterResponse) { | ||
// Create clientSink | ||
if (!clientSinkMap.containsKey(channelEnterResponse.userId())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
여러 스레드가 동시에 containsKey를 통과할 때, 동시성 문제가 발생하는 상황은 없을까요??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UDP 관련된 부분은 이번 티켓에서 다루지 않을 예정이기도 하고, 다음 티켓에서 정리해서 반영해도 될까요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
좋습니다. TODO 작성해주세요!
|
||
private NettyOutbound handleVoiceData(UdpInbound in, UdpOutbound out) { | ||
return out.sendObject( | ||
// TODO: 자신이 송출한 데이터는 되돌려 받지 않기 때문에 Void를 반환하는데, UDP 연결이 안끊기고 있음 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO는 문제를 명시하기 보다는 해야할 일
을 작성하는 것이 보다 좋아보여요! 아래처럼 작성해주시면, 어떠한 작업이 필요하다는 것을 보다 명확하게 이해할 수 있을 것 같습니다.
// 변경 전
// TODO: 자신이 송출한 데이터는 되돌려 받지 않기 때문에 Void를 반환하는데, UDP 연결이 안끊기고 있음
// 변경 후
// TODO: UDP 연결 자원을 명시적으로 해제하는 dispose() 메서드 구현 필요
// 또는
// TODO: UDP 소켓 연결 종료 후 리소스 정리하는 cleanup 로직 추가
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UDP 관련된 부분은 이번 티켓에서 다루지 않을 예정이기도 하고, 다음 티켓에서 정리해서 반영해도 될까요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
해당 주석은 정확히 해야할 일을 이번 PR에서 명시해주시면 감사하겠습니다.
public Mono<Boolean> removeActiveUser(String userId) { | ||
return valueOperations.delete(getActiveUserRedisKey(userId)); | ||
public Mono<String> removeUserActiveFromRedis(String userId) { | ||
return valueOperations.getAndDelete(getActiveUserRedisKey(userId)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
단일 책임 원칙에 어긋나는 것 같아요. get과 delete 2개의 책임을 지고 있기 때문입니다. 또한, delete의 경우 void를 반환하는 것이 관행이라고 생각하는 데 String 값이 반환되는 이유가 있을까요??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
해당 메서드는 제가 정의한 메서드가 아니고, 제공되는 메서드 입니다.
기존의 있던 값을 get으로 가져오고 delete 하는 메서드입니다!
보통 삭제되기 전의 값이 필요한 경우 사용합니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
찾아보니까 SRP보다는 원자성 보장을 위해서 제공하는 메서드인 것 같네요! 좋습니다~
.flatMap(pastServerId -> validateServerDestination(serverId, pastServerId)); | ||
.map(pastServerId -> validateServerDestination(serverId, pastServerId)) | ||
.doOnSuccess(isChanged -> { | ||
if (isChanged) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
조건문을 filter
로 대체할 수 있을 것 같은데, if문을 사용하신 이유가 있을까요??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
filter를 하면 말그대로 필터링이되어서, false 라는 값이 뒤에 전달이 안되기 때문에 doOnSuccess를 사용했습니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return valueOperations.getAndSet(getActiveUserRedisKey(userId), serverId)
.flatMap(pastServerId -> validateServerDestination(serverId, pastServerId))
.filter(isChanged -> isChanged) // true인 경우만 다음 로직 실행
.doOnNext(ignored -> log.info("ALREADY ACTIVE BUT NOT SAME SERVER ID"))
.flatMap(ignored -> setSubscriptionRequired(userId, true))
.defaultIfEmpty(false); // false인 경우 기본값 처리
클로드는 위처럼 작성하면 된다고 하던데, 문제가 되는 부분이 있을까요??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
오!
이 방법이 더 깔끔한거 같네요. 감사합니다.
disposable.dispose(); | ||
log.info("Unregister server stream: {}", serverId); | ||
return Flux.defer(() -> { | ||
synchronized (this) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
synchronized는 webflux의 non-blocking 방식과 충돌이 있을 것 같은데, 사용하신 이유가 있을까요??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
동기화를 사용하면 논블로킹 방식에서 이점을 얻을 수 없지만, 해당 부분은 속도보다는 정합성을 우선시하는게 맞다고 생각하여 사용했습니다. (사용하지 않으면 프론트에서 Strict mode에 의해 엄청 짧은 시간에 반복 요청을 보내는 경우 2번 수행이 되는 이슈가 있었습니다.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
클로드는 synchronized와 비교해봤을 때 더 좋은 대안으로 computeIfAbsent
를 추천하더라고요! 혹시 알아보셨을까요??!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
computeIfAbsent 메서드는 단순히 값을 확인하고 새로운 값을 넣는 두 동작의 원자성만을 보장해주기 때문에 해당 객체의 접근 자체를 동기화시켜주지는 못하기 때문에 사용하지 않았습니다.
2fbfcbe
to
c662d3b
Compare
- Change using Spring Security to using first socket message for authorization
c662d3b
to
917d4f4
Compare
☝️Issue Number
🔎 Key Changes
💌 To Reviewers