점프와 쉼없는 나아감

이전글

• Comet 에 대하여
  
• 자바 서블릿 컨테이너의 Comet 지원 1 - Jetty
• 자바 서블릿 컨테이너의 Comet 지원 2 - Tomcat

Resin 은 버전 3.1에서 Comet 모델을 지원한다.  Tomcat 과 마찬가지로 javax.servlet.Servlet 을 확장한 인터페이스를 제공하는 방식이다.  com.caucho.servlet.comet.CometServlet 이 그것인데 이 인터페이스에는 다음과 같은 메서드들이 있다.

public interface CometServlet extends Servlet {
  boolean service(ServletRequest request, ServletResponse response,
                            CometController controller) throws ServletException, IOException;
  boolean resume(ServletRequest request, ServletResponse response,
                             CometController controller) throws ServletException, IOException;
}

Tomcat 과 마찬가지 방식으로 이 인터페이스를 구현한 서블릿은 요청을 처리할 때 기존 서블릿의 service 메서드를 호출하지 않고 이 인터페이스의 service 메서드를 호출한다.  service 메서드의 호출 결과가 true 가 되면 요청 처리는 suspend 되고 스레드는 풀로 되돌아간다.  CometController 의 wake 메서드를 호출하면 요청 처리는 재개되어 resume 메서드가 실행된다.  resume 메서드가 true 를 반환하면 또 다시 suspend 되어 wake 를 기다리게 되고 false 를 반환하면 요청 처리가 끝나게 된다.

service, resume 메서드에 인자로 들어오는 CometController 객체는 service, resume 그리고 다른 이벤트 대기 스레드 사이에서 공유하여 신호를 보낼 수 있고(wake 메서드) 서로간 데이타 교환을 할 수도 있다(setAttribute, getAttribute).

Jetty 나 Tomcat 과는 어떻게 다른지 같은 채팅 예제로 실제 사용법을 알아보겠다. ChatServlet 과 chat.jsp 는 Jetty 의 경우와 같고 BroadcasterServlet 은 다음과 같다.

BroadcasterServlet.java
...
@Override
public boolean service(ServletRequest request, ServletResponse response,
                            CometController controller) throws ServletException, IOException {
    HttpServletResponse res = (HttpServletResponse) response;
    res.setContentType("text/html; charset=utf-8");
    messageSender.addSession(controller);
    return true;
}

@Override
public boolean resume(ServletRequest request, ServletResponse response,
                             CometController controller) throws ServletException, IOException {
    messageSender.removeSession(controller);
    String message = (String) controller.getAttribute("message");
    HttpServletResponse res = (HttpServletResponse) response;
    PrintWriter out = res.getWriter();
    out.println(message);
    res.flushBuffer();
    return false;
}
...

service 메서드에서 최초 요청 처리를 처리하면서 인자로 넘어온 CometController 객체를 messageSender 객체에 저장하여 이벤트 처리 스레드로 넘긴다.  이후 CometController 의 wake 메서드가 호출되면 resume 이 실행되고 여기서 실제 데이타를 전송한다.  전송할 데이타는 이벤트 처리 스레드에서 CometController.setAttribute 으로 넘기고 여기서는 getAttribute 로 받는다.

다음은 MessageSender 클래스이다.

MessageSender.java
public class MessageSender implements Runnable {
  private final BlockingQueue<String> messages =
                         new LinkedBlockingQueue<String>();
  private final Set<CometController> sessions =
                         new CopyOnWriteArraySet<CometController>();

  private volatile boolean running = true;

  public void stop() {
    this.running = false;
  }

  public void sendMessage(String message) {
    try {
      messages.put(message);
    } catch (InterruptedException ignore) {
      // ignore
    }
  }

  public void addSession(CometController controller) {
    sessions.add(controller);
  }

  public void removeSession(CometController controller) {
    sessions.remove(controller);
  }

  @Override
  public void run() {
    while (running) {
      String message = null;
      try {
        message = messages.take();
      } catch (InterruptedException ignore) {
        // ignore
      }
      for (CometController controller : controllers) {
        controller.setAttribute("message", message);
        controller.wake();
      }
    }
  }
}

MessageSender 는 Jetty 의 경우와 비슷하다.  CometController 들을 sessions 에 저장해 두고 채팅 메시지가 들어오면 이를 CometController 에 저장(setAttribute) 한 후 wake 를 호출해서 요청 처리가 resume 되게 한다.

Resin 의 Comet 지원은 Jetty 와 비교하면 직관적으로 이해하기 쉽다.  또한 Tomcat 처럼 번거롭지도 않다.  세 서블릿 컨테이너의 Comet 지원 중에서 가장 사용하기가 쉬운 것 같다.

이전글

• Comet 에 대하여
  
• 자바 서블릿 컨테이너의 Comet 지원 1 - Jetty
  

Tomcat 에서는 버전 6.0의 Advanced IO 지원을 통해 Comet 모델을 효과적으로 구현할 수 있게 되었다. Tomcat 6.0 에서는 Jetty 와는 달리 서블릿을 확장하는 형태로 지원하고 있다.

javax.servlet.Servlet 인터페이스를 확장한 org.apache.catalina.CometProcessor 가 그것인데 이 인터페이스는 Servlet 인터페이스를 상속한 것이다. 이 인터페이스에는 event(CometEvent) 메서드가 있는데 이 인터페이스를 구현한 클래스가 서블릿으로 등록되어 있으면 Tomcat 은 요청을 처리할 때 기존 서블릿의 service(...) 메서드를 호출하지 않고 이 event(...) 메서드를 호출하게 된다. 이 메서드는 한 요청 처리 트랜잭션에서 여러번 호출될 수 있으며 이벤트 정보가 인자로 넘어오게 된다. 이 인자로 넘어온 객체를 통해 여러 정보를 알 수 있고 IO도 처리할 수 있다. 입력(input)은 이 이벤트 처리 메서드 안에서 이루어져야 하지만, 출력(output)은 이 이벤트 처리 메서드 밖에서도 처리할 수 있다.

CometProcessor 를 사용하기 위해서는 Tomcat 설정을 조금 손봐야 한다. CometProcessor 는 Tomcat connector 가 Native 또는 NIO connector 여야 한다. 자바 1.4 버전 이상이라면 NIO 를 쓰면 되며 Tomcat 설정 파일을 다음과 같이 수정하면 된다.

<!-- 기존 설정. 아래와 같이 바꾼다.
<connector connectiontimeout="20000" port="8080" protocol="HTTP/1.1" redirectport="8443"/>
-->
<connector connectiontimeout="20000" port="8000">
     protocol="org.apache.coyote.http11.Http11NioProtocol" useComet="true" redirectPort="8443"/>

event 메서드는 BEGIN, READ, END, ERROR 이벤트가 발생할 때 호출되는데 이때 인자로 org.apache.catalina.CometEvent 객체가 넘어온다. 이 객체에는 위의 Event Type 을 얻는 메서드와 HttpServletRequest, HttpServletResponse 객체를 얻는 메서드 등이 있다.

이전 Jetty 의 경우와 마찬가지로 채팅 예제로 실제 사용법을 알아본다. 먼저 ChatServlet 과 chat.jsp 는 이전 jetty 의 경우와 같다. BroadcasterServlet 은 CometProcessor 를 사용해야 하는데 코드는 다음과 같다.

public class BroadcasterServlet extends HttpServlet implements CometProcessor {
...
  @Override
  public void event(CometEvent event) throws ServletException, IOException {
    HttpServletRequest request = event.getHttpServletRequest();
    HttpServletResponse response = event.getHttpServletResponse();
    String sessionId = request.getSessionId();

    if (CometEvent.EventType.BEGIN == event.getEventType()) {
      // 요청을 최초로 처리할 때 호출됨.
      response.setContentType("text/html; charset=utf-8");
      messageSender.addSession(sessionId, event);
    } else if (CometEvent.EventType.ERROR == event.getEventType()) {
      // IO 에러가 발생했을 때.
      messageSender.removeSession(sessionId);
      event.close(); // 요청 처리 완료.
    } else if (CometEvent.EventType.END == event.getEventType()) {
      // 요청 처리가 완료되었을 때
      log("End event");
    } else if (CometEvent.EventType.READ == event.getEventType()) {
      log("Read event");
    }
  }
...
}

요청을 최초로 처리할 때 BEGIN 이벤트가 발생하며 이때 Request 정보를 읽는 작업을 한다. 여기서는 채팅 메시지가 있을 때 메시지를 보낼 수 있도록 event 객체를 messageSender 객체에 저장해 놓는 작업도 한다.

요청에서 읽을 데이타가 준비되었을 때 (즉 request.getInputStream() 등) READ 이벤트가 발생하며, 에러가 발생했을 때 ERROR 이벤트가 요청 처리가 완료되면 END 이벤트가 발생한다. 여기서는 ERROR 이벤트가 발생하였을 때 관련 정보를 messageSender 에서 삭제하고 요청을 마치는 작업을 한다.

MessageSender 클래스는 다음과 같다. Jetty 의 경우와 조금 다른데 메시지를 실제로 보내는 작업도 여기서 처리하고 있다. CometProcessor 에 원하는 때 이벤트를 발생시킬 수 없기 때문이다. 따라서 이벤트가 발생할 때 출력을 하기 위해 미리 CometEvent 객체를 저장하여 HttpServletResponse 객체를 얻어 출력을 한다.

MessageSender.java
public class MessageSender implements Runnable {
  private volatile boolean running = true;
  private final BlockingQueue<String> messages =
                                          new LinkedBlockingQueue<String>();
  private final Map<String, CometEvent> sessions =
                                          new ConcurrentHashMap<String, CometEvent>();
  private final ExecutorService executor = Executors.newFixedThreadPool(5);

  public void send(String message) {
    try {
      messages.put(message);
    } catch (InterruptedException ignore) {
      // ignore
    }
  }

  public void addSession(String id, CometEvent event) {
    sessions.put(id, event);
  }

  public void removeSession(String id) {
    sessions.remove(id);
  }

  public void stop() {
    this.running = false;
    this.executor.shutdown();
  }

  @Override
  public void run() {
    while (running) {
      String message = null;
      try {
        message = messages.take();
      } catch (InterruptedException ignore) {
        // ignore
      }
      for (String id : sessions.keySet()) {
        executor.submit(new Task(id, message));
      }
    }
  }

  private class Task implements Runnable {
    private String sessionId;
    private String message;

    public Task(String id, String msg) {
      sessionId = id;
      message = msg;
    }

    public void run() {
      CometEvent event = sessions.get(sessionId);
      if (null == event) {
        return;
      }
      HttpServletResponse response = event.getHttpServletResponse();
      PrintWriter out = null;
      try {
        out = response.getWriter();
        out.println(message);
        out.flush();
        response.flushBuffer();
      } catch (IOException naive) {
        naive.printStackTrace();
      } finally {
        try { out.close(); } catch (Exception ignore) {}
        try { event.close(); } catch (Exception ignore) {}
        sessions.remove(sessionId);
      }
    }
  }
}

Jetty 의 경우와 달리 Tomcat 은 Servlet 인터페이스를 확장하여 웹 요청 단계에 따라 이벤트를 발생시키는 방식으로 작동한다. 네트워크 서버가 많이 취하고 있는 방식이라 쉽게 이해할 수 있다. 그러나 실제 프로그래밍을 하려면 번거로운 점이 있다. Jetty 처럼 원하는 때 resume 을 시킬 수 없기 때문에 long polling 처럼 원하는 때 출력을 하려면 서블릿 코드 밖에서 출력을 해야 하며 따라서 직접 스레드를 관리할 필요가 생긴다. 또한 Error 시에 적절히 자원을 정리하는 코드도 필요하다.

정리하자면 Tomcat 의 Comet 지원은 일반 네트워크 서버 스타일에 가깝다고 볼 수 있다. 좀더 웹 프로그래밍 스타일에 가깝게 만들었으면 좋지 않았을까 하는 생각이 든다.

Reverse Ajax, Ajax Push, Two-Way-Web, HTTP server PUSH 등등으로 불리던 말이 이제 Comet 이라는 용어로 통일되어 가는 거 같다.  개념이 나온지는 꽤 되었지만 자바 서블릿 컨테이너가 이를 효과적으로 지원하지 않아 그간 관심만 가지고 있었다.  그런데 요즘 여러 서블릿 컨테이너들이 이를 지원하기 시작했고 Servlet API로의 표준화도 논의되고 있는 거 같다.  그래서 Comet 에 관련하여 한번 정리해 보고자 한다.

Comet 이란 웹 클라이언트(보통 웹 브라우저)의 명시적인 요청이 없어도 서버에서 클라이언트로 데이타를 밀어넣는(Push) 방식으로 동작하는 웹 프로그래밍 모델을 일컫는 말이다.  다만 HTTP 트랜잭션을 웹 서버가 먼저 시작할 수는 없으므로 클라이언트가 먼저 서버에 접속하여 접속을 계속 유지한 상태에서 서버가 데이타를 전송한다.  서버가 먼저 클라이언트로 접속을 열어 데이타를 전송할 수는 없다.

원래 HTTP라는 것이 웹 브라우저에서 요청을 보내면 서버가 응답을 전송하고 끝마치는 간단한 구조라 서버에서 클라이언트로 데이타를 밀어넣는 것은 구현하기가 힘들다.  이런 어려움을 어떻게든 극복하고자 여러 시도가 있었고 이들이 Comet 이라는 이름으로 정리되어 가는 중인 거다.

Comet 은 구체적인 구현 방법을 가리키는 말은 아니며 여러 방식들을 통칭하는 말이다.  HTTP server push 를 구현하는 방법은 여러 방식이 있는데 이중의 부분 집합을 Comet 이라 할 수 있다.  HTTP Server push 방법에는 다음과 같은 것들이 있다.

1. Polling
일정 간격으로 서버에 요청을 보내어 서버의 이벤트를 받는 방식이다.  요청 간격을 줄이면 거의 실시간으로 서버의 이벤트를 받을 수 있다.  그러나 서버의 자원과 대역을 많이 소모하므로 실제로 쓰기는 어려운 방식이다.

2. Long Polling
클라이언트가 서버에 접속을 하면 서버는 계속 접속을 유지하고 있다가 이벤트가 발생하면 클라이언트로 전송하고  HTTP 트랜잭션을 마친다. 클라이언트는 메시지를 받으면 다시 서버에 접속을 하여 위의 과정을 반복한다.

3. Streaming
클라이언트와 서버의 접속을 계속 유지한 채 서버에서 이벤트가 발생할 때마다 메시지를 HTTP Chunked 방식으로 보낸다.  가장 이상적인 방법이겠으나 ajax로 구현할 때 ie 에서는 제대로 작동하지 않는다(readyState = 3 이벤트가 발생하지 않는다).  iframe 을 사용하여 <script> 태그로 둘러싼 메시지를 보내는 방식을 사용할 수 있지만 이 방식은 접속 오류를 제대로 처리하기 힘들다.

이중 Long Polling 과 Streaming 을 Comet 이라고 한다.  Server PUSH 로는 Streaming 이 이상적이겠지만 위의 한계점 때문에 보통 Long Polling 방식을 주로 사용한다.  Streaming 방식을 지원하는 것이 HTML5에서 논의 중인 것으로 보여 앞으로 이것이 구체화되면 Streaming 방식으로 좀더 효율적으로 Comet 을 구현할 수 있을 것이다.

Comet 모델을 구현하는 데 또 한 가지 걸림돌은 웹 서버의 지원이다.  Long Polling 이든 Streaming 이든 HTTP 커넥션을 계속 유지할 필요가 있는데 대부분의 웹 서버(자바 서블릿 컨테이너도 포함)들은 짧은 HTTP 트랙잭션에 맞춰져 있기 때문에 Comet 을 지원하는데 효율적이지 못하다.  특히 자바 서블릿 컨테이너는 HTTP 요청이 각각 스레드에 할당되어 처리되기 때문에 Comet 을 지원하게 되면 많은 스레드가 생성되게 된다.  스레드는 대부분 단지 커넥션을 유지하고 있을 뿐 거의 동작을 하지 않다가 서버측 이벤트가 있을 경우에만 잠깐 동작할 뿐이다.  이렇게 많은 Idle 스레드가 생기면 스레드 생성 및 컨텍스트 교환에 따른 오버헤드가 무시못하게 된다.  

Comet 을 효율적으로 지원하기 위해서는 다른 고성능 서버 프로그램처럼 하나의 스레드가 여러 커넥션(이 경우 웹 요청)을 처리할 수 있어야 한다.  현재 서블릿 API에서는 이것이 불가능하다.  따라서 이에 대한 대안이 여럿 등장했다.  Comet 요청을 전용으로 처리하고자 하는 서버도 있었으며 서블릿 컨테이너 중에는 Jetty 가 최초로 Continuation 방식의 API 를 선보였다.  이후 Tomcat 6.0, Resin 3.1 에서도 각기 나름의 API 를 선보였다.  현재 Early Draft Review 상태에 있는 Servlet 3.0 에서 Jetty의 Continuation 과 비슷한 방식으로 지원이 논의되고 있다.

다음 포스트에서 서블릿 컨테이너별로 Comet 을 지원하는 기능을 살펴보고자 한다.