2주차 수요일 그룹 1

지찬우

• ExecutorService를 통해 멀티스레딩 처리 - 기본 사이즈 10 적용
• backlog는 default (java에서 50)
• try-with-resource를 최대한 활용
• Main에서 → 핸들러에게 소켓을 넘겨주면서 멀티스레딩이 시작됨 → 여기에서 HttpRequest, HttpRespones를 생성하여 요청을 파싱하고 응답을 넘겨주는 흐름임
• 리팩토링 해야 할 부분 → nio패키지를 사용하는 부분이 몇 개 있어서 수정해야 함
• 파일을 읽을때 이런 작업을 유틸 클래스에게 맞겨줄지, HttpRequest가 필드로 두어야 할지
  • 리뷰어: 전략 패턴 도입을 고려해보면 좋을 수도!
• java.net.http 폴더의 레퍼런스들을 많이 참고하면서 만들어감
  • 어떻게 활용해볼 수 있을지? (BodyPublishers 등)

이호석

• ThreadPoolExecutor에 대해 공부하고 정리함
• 스레드 개수를 초과하는 요청은 BlockingQueue에 적재되어 대기하게 됨 → 그래서 그냥 thread pool size 10 설정
• HTTP request, Response는 HTTP RFC 문서를 많이 참고하면서, 스펙에 맞춰서 구현하기 위해 노력했습니다
  • RequestLine or StatusLine, Headers, MessageBody
• MessageBodyData는 String으로 저장하고 추후에 다른 오브젝트로 갈아끼울 수 있게 준비해 놓음
• Http Header의 커스텀에 대한 제약이 따로 없는 부분을 어떻게 유연하게 끼울 수 있을지 고민하고 있습니다!

김규원

• Processor를 구현하여 request parsing과 response message 생성을 구현
• HttpResponse 객체 안에 HttpRequest 객체를 참조하고 있음 → HttpResponse에서 HttpRequest의 값을 사용할때가 있기때문에 편히 쓰게 하기 위해
• readStaticFile 을 테스트코드로 모킹하기위해 protected로 열어둠 → 테스트 자체가 불편해지는 문제가 생겨 readFile 부분을 주입하는 방식 (전략패턴) 을 고려하는 것이 좋을거 같다는 피드백을 받았는데 한번 적용해봐야될거 같습니다.
• ThreadPool 내부 구현체에 대한 공부가 필요한거 같습니다. 대기 큐 사이즈, keep-alive 까지 커스텀한 케이스를 보며 좀더 알아봐야될거 같습니다. 그리고 대기큐 기본구현체인 LinkedBlockingQueue 대신 ArrayBlockingQueue 를 권장하는 이유가 공식문서에 있다는데 찾아봐야될거 같습니다.
• 다른 분의 코드를 보면서 워커 쓰레드와 메인 쓰레드를 분리하여 메인 쓰레드는 항상 반환이 가능하도록 구현한 점이 인상깊었습니다. 메인 쓰레드는 항상 돌아가도록 냅두는 방식이 인상적이었습니다.

김현욱

• Fixed pool 대신 ThreadPoolExecutor를 직접적으로 구현
• LinkedBlockingQueue 대신 ArrayBlockingQueue를 사용
• Response header에 date가 고정이 되어있으면 테스트코드를 작성하기 매우 어려운 구조가 되기때문에 Timer 인터페이스를 추출하여 구현
• ResponseMessage를 조금 더 편하게 구현하기 위해 Builder 패턴을 이용하여 구현
• favicon과 같이 바이너리 파일들을 위해 body를 byte[] 로 구현
• 현재까지는 구조보단 기능 구현을 중점적으로 개발중

김수현

• 톰캣 구조 보고 비슷하게 설계함
• 웹 서버가 처리할 다양한 요청을 고려하여 별도의 인터페이스를 고민함
• 메인 스레드 막지 않고 acceptor 스레드가 따로 실행되면서 요청을 받음
  • 메인 스레드는 따로 초기화 작업 등 처리해야하는 것들이 있을 수 있어서 여유롭게 둠
• 워커 스레드 사이즈: 논리 프로세서수 * 2. io 작업으로 멈춘 스레드 있어도 CPU가 다른 스레드 처리할 수 있도록
• JioEndpoint 클래스 안에 Acceptor, SockeProcessor를 가지는데 static 하게 선언하지 않으면
  • 외부 클래스와 내부 클래스의 양방향 의존으로 인해서 GC 대상이 안될 수도 있으니 고치는게 좋을 것 같다.
• HttpProcessor를 풀로 관리하는 LinkedBlockingQueue를 ArrayBlockingQueue로 바꾸는게 좋겠다. → 고정된 수로 관리하기 때문에.

박혜성

• 구조보다는 기능 구현에 신경쓰면서 진행하였음.
  • 대부분의 값이 하드 코딩 되어있음
  • 추후에 예외 처리, 공통된 기능이 추가되면 추상화가 필요함.
• 핸들러 인터페이스를 두어서 정적 리소스 파일 처리와 별도의 요구사항 처리를 동일하게 핸들링할 수 있도록 고려함
  • 일단은 API 별로 핸들러 구현체가 늘어나는데 일단 성급한 추상화하지 않고 진행하다가 공통된 부분 추출해서 리팩토링 할 예정
• 빌드 후 리눅스에서 실행 시 정적 리소스를 찾아가지 못하는 문제를 수정해야 함.
  • 로그 찍어서 한 번 확인해보면 좋을 것임