クイズ: プールとタイムアウト

DB 가 느려지자 요청 처리 스레드 200개가 전부 커넥션 대기에 들어가 헬스체크까지 실패했다. 근본 원인은?

• maxThreads 가 200 으로 너무 작다
• 커넥션 대기에 상한(maxWaitMillis)이 없어 스레드가 돌아오지 않는다
• acceptCount 가 기본값이라 OS 대기열이 넘쳤다
• GC 정지가 커넥션 반환을 막았다

Tomcat HTTP 커넥터 문서에서 acceptCount 의 뜻은?

• 동시에 처리할 수 있는 요청의 최대 수(기본 200)
• 항상 살려 두는 처리 스레드의 최소 수(기본 10)
• maxConnections 에 닿았을 때 OS 가 쌓아 두는 연결 요청 대기열 길이(기본 100)
• 연결을 받은 뒤 요청 줄을 기다리는 밀리초(기본 60000)

connectionTimeout 에 대해 문서가 적은 기본값 관계는?

• 문서 기본 60000, 배포판 server.xml 은 20000
• 문서 기본 20000, 배포판 server.xml 은 60000
• 둘 다 -1(무한)
• 문서 기본 5000, 배포판은 값을 두지 않는다

DBCP 2 DataSource 의 maxWaitMillis="-1" 은?

• 1ms 만 기다린다
• 풀을 쓰지 않고 매번 새 커넥션을 연다
• 커넥션이 날 때까지 무한정 기다린다
• 커넥션 대기를 거부하고 즉시 예외를 던진다

PoolDemo 의 /stats 를 처리 스레드가 아닌 별도 스레드(8087)로 둔 이유는?

• 8086 포트가 통계를 지원하지 않기 때문이다
• 처리 스레드가 전부 막혀도 상태를 읽을 길을 남기기 위해서다
• 통계 계산이 무거워 처리 스레드를 느리게 하기 때문이다
• HttpServer 가 컨텍스트 하나당 포트 하나를 요구하기 때문이다

CATALINA_BASE 를 따로 만들어 띄우는 이유는?

• Tomcat 은 CATALINA_HOME 에서 직접 뜰 수 없기 때문이다
• BASE 가 있어야 8080 포트를 열 수 있기 때문이다
• BASE 없이는 catalina.sh 가 JAVA_OPTS 를 읽지 않기 때문이다
• 설치본(bin·lib)은 두고 인스턴스별 conf·logs·webapps 를 격리해 실험할 수 있기 때문이다