jetty 학습 1 - SelectChannel 커 넥 터

1. jetty 서버 의 주요 구 조 는 다음 과 같다.

The Jetty Server is the plumbing between a collection of Connectors that accept HTTP connections, and a collection of Handlers that service requests from the connections and produce responses, with the work being done by threads taken from a thread pool. 

server 는 주로 connector, handler 와 ThreadPool 을 결합 합 니 다. 여 기 는 주로 SelectChannel Connector 에 대한 분석 입 니 다.
 
그 중에서 connector 는 두 개의 역할 이 있 습 니 다.

하 나 는 socket. accept () 를 담당 하 는 스 레 드 입 니 다. 하 는 일 은 accept 입 니 다. 그리고 socketChannel 을 대기 열 에 넣 고 다른 모듈 처 리 를 기다 리 는 것 입 니 다. tomcat 또는 다른 용기 의 bio 와 유사 한 방식 입 니 다.

        _manager.dispatch(new Runnable()
        {
            public void run()
            {
                final ServerSocketChannel server=_acceptChannel;
                while (isRunning() && _acceptChannel==server && server.isOpen())
                {
                    try
                    {
                        SocketChannel channel = server.accept();
                        channel.configureBlocking(false);
                        Socket socket = channel.socket();
                        configure(socket);
                        _manager.register(channel);
                    }
                    catch(IOException e)
                    {
                        Log.ignore(e);
                    }
                }
            }
        });

이곳 의manager. dispatch 가 완성 한 작업 은 이 임 무 를 스 레 드 탱크 의 스 레 드 에 맡 기 는 것 입 니 다.manager. register 가 완성 한 작업 은 채널 을 하나의 대기 열 에 넣 는 것 입 니 다 (비 차단 대기 열).여기 서 두 가지 주의해 야 할 것 이 있 습 니 다. 먼저 jetty 는 accept 에 대해 non - block io 방식 을 사용 하지 않 았 습 니 다. 왜 (예 를 들 어 여기 서 bio 를 사용 하 는 방식 이 더욱 간단 하고 효율 적 인지) 를 생각해 볼 수 있 습 니 다.다른 하 나 는 우리 가 평소에 설정 한 acceptor 갯 수 는 여기 와 관계 가 없습니다. 하나의 connector 는 이러한 스 레 드 만 있 습 니 다.

하 나 는 Acceptor 입 니 다. 대기 열 에서 socketChannel 을 가 져 오고 유형 에 따라 처리 합 니 다. (accept 스 레 드 를 잃 어 버 렸 다 면 read 이벤트 등록, new 하나의 SelectChannel EndPoint, http connection 등 정보 포함)

                    else if (change instanceof SocketChannel)
                        {
                            // Newly registered channel
                            final SocketChannel channel=(SocketChannel)change;
                            SelectionKey key = channel.register(selector,SelectionKey.OP_READ,null);
                            SelectChannelEndPoint endpoint = createEndPoint(channel,key);
                            key.attach(endpoint);
                            endpoint.schedule();
                        }

endpoint. schedule () 을 호출 할 때 endpoint 의 manager 의 dispatch 방법 으로 endpoint 의 처리 류 를 호출 합 니 다.handler 를 스 레 드 에 넣 고 실행 을 시작 합 니 다. handler 의 주요 논 리 는 다음 과 같 습 니 다.

 private void handle()
    {
            boolean dispatched=true;
            while(dispatched)
            {
                    while(true)
                    {
                        final Connection next = _connection.handle();
                        if (next!=_connection)
                        {  
                            _connection=next;
                            continue;
                        }
                        break;
                    }
                    dispatched=!undispatch();
            }
    }

전체 handle 의 과정 은 다음 과 같 습 니 다.
우선 endpoint. schedule ();아래 코드 와 함께 schedule 로 호출 되 어 읽 기 이벤트 에 스 레 드 를 할당 할 수 있 습 니 다. 여 기 는 일부 플래그 비트 를 통 해 처리 되 었 습 니 다. 즉, 읽 기 이벤트 가 처리 되 었 다 면 중복 처리 하지 않 습 니 다.
 
SelectChannel Connector 는 자바 니 오의 코드 (mina, netty 의 실현 과 유사 한 부분 이 있 음) 를 직접 사 용 했 습 니 다. 구체 적 인 세부 사항 은 코드 를 참조 할 수 있 습 니 다.여기 서 가장 중요 한 매개 변 수 는 다음 과 같다.
public void setMaxIdleTime(int maxidleTime): 기본 값 은 200, 000 ms 입 니 다.
공식 문 서 는 이렇게 설명 한다.

Description copied from class: AbstractConnector 
Set the maximum Idle time for a connection, which roughly translates to the Socket.setSoTimeout(int) call, although with NIO implementations other mechanisms may be used to implement the timeout. The max idle time is applied: 
When waiting for a new request to be received on a connection 
When reading the headers and content of a request 
When writing the headers and content of a response 
Jetty interprets this value as the maximum time between some progress being made on the connection. So if a single byte is read or written, then the timeout (if implemented by jetty) is reset. However, in many instances, the reading/writing is delegated to the JVM, and the semantic is more strictly enforced as the maximum time a single read/write operation can take. Note, that as Jetty supports writes of memory mapped file buffers, then a write may take many 10s of seconds for large content written to a slow device. 
Previously, Jetty supported separate idle timeouts and IO operation timeouts, however the expense of changing the value of soTimeout was significant, so these timeouts were merged. With the advent of NIO, it may be possible to again differentiate these values (if there is demand). 

쉽게 말 하면 시간 이 초과 되면 연결 을 닫 습 니 다 (Channel EndPoint 의 close () 를 호출 합 니 다.

    public void close() throws IOException
    {
        if (_socket!=null && !_socket.isOutputShutdown())
            _socket.shutdownOutput();
        _channel.close();
    }

그리고 호출  updateKey(); 이 endpoint 의 인용 을 가지 지 않 고 키 를 업데이트 하여 대상 을 회수 할 수 있 습 니 다.
 
이 사건 을 언제 검사 합 니까? 매번 select 의 관련 처리 가 끝 난 후에:
                    dispatch(new Runnable()                     {                         public void run()                         {                             for (SelectChannelEndPoint endp:_endPoints.keySet())                             {                                 endp.checkIdleTimestamp(idle_now);                             }                         }                     });
 
몇 시간 동안 타 이 밍 표 시 를 할 까요?
새 독일 endpoint 를 만 들 때:    public SelectChannel EndPoint (SocketChannel channel, SelectSet selectSet, Selection Key key, int maxiIdleTime) http 헤드 분석 시 두 번, 방법의 시작 과 끝:     public void headerComplete() throws IOException
         scheduleIdle
handler 처리
        scheduleIdle
 
그러나 남 은 시간 이 초과 되 었 는 지 확인 하 는 시간 이 약간 지연 되 었 기 때문에 (시간 이 초과 되 었 지만 시간 이 초과 되 었 음 을 감지 하고 연결 이 지연 되 었 음 을 감지 합 니 다) 일반적인 요청 은 몇 시간 이 지나 도 정상적으로 돌아 갈 수 있 습 니 다.