| sitelink1 | |
|---|---|
| sitelink2 | |
| sitelink3 | |
| extra_vars4 | |
| extra_vars5 | |
| extra_vars6 |
http://javaora.tistory.com/entry/DWR-Reverse-Ajax-part-2-Configuring-Reverse-AjaxConfiguring Reverse Ajax
Reverse Ajax 는 2가지 기본 모드로 작동한다. Active 와 Passive 두가지 모드 이다. Active Reverse Ajax 는 아래 3가지 모드로 정리된다.
- Full Streaming Mode
- Early Closing Mode
- Polling Mode
이 페이는 이 세가지 모드에 대해 설명하며, 어떻게 이들을 설정하는지 알아본다. 이 문서는 DWR 2.0 버젼 이상에서만 유효하다. Reverse Ajax 는 1.x 버젼에서는 작동하지 않는다.
Full Streaming Mode
이것은 Active Reverse Mode 가 작동 될 때의 기본(default)모드 이다. 이것은 빠른 응답이라는 특징을 가지고 있다. 이 방식은 매 60초 마다 한번(once) 연결을 종료하거나 브라우져가 여전히 활동(active) 중인지를 체크한다. 이 설정은 매우 간단하며 web.xml 에 init-param을 추가해주는 것 만으로 서버에서 Active Reverse Ajax 사용이 가능해진다.
·미리보기 | 소스복사·
- <servlet>
- <servlet-name>dwr-invoker</servlet-name>
- <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
- <init-param>
- <param-name>activeReverseAjaxEnabled</param-name>
- <param-value>true</param-value>
- </init-param>
- </servlet>
또한 웹페이지에 Active Reverse Ajax 에 대한 설정을 해야할 필요가 있다.
dwr.engine.setActiveReverseAjax(true);
많은 수의 connection 이 열려진체 유지되며, 이는 서버의 스레드(thread) 부족을 가져올 수도 있다. 몇몇 웹서버는 사용자로 하여금 스레드를 종료(drop)시키는 것을 허용하는 특별한 모드를 가지고 있다. DWR 은 2.0버젼부터 Jetty 서버에서 이 기능의 사용이 가능하며, 3.0 부터는 이것이 확장되어 GlassFish 와 Tomcat에서도 포함되기를 기대한다. 또한 DWR은 만일 서버의 부하가 아주 높다면 동적 연결 시간(connected time) 감소와 연결해제 시간(disconnected time)의 증가로부터 모든 서버를 보호하는 것을 시도중이다.
full streaming 방식의 문제는 이것이 가끔 network proxy나 mode_jk나 다른 네트워크 장치들의 실패(fail)로 인해 HTTP chunked mode(참고) 를 필요로 한다는 것이다. 만약 full streaming 을 시도한다면 "매 60초 마다 실행해야 된다"는 메시지를 찾게 될 것이다. - 이는 chunked mode는 data를 나눠 여러번 보내므로 한번의 전송후 60초를 기다려야 하는 문제가 발생하는 듯 하다. - DWR 2.0.3 버젼 이하는 full streaming mode 를 기본으로 사용하며 2.0.4 버젼 이상부터는 Early Closing mode를 기본으로 사용한다.
Full Streaming Mode 를 2.0.4 이상 버젼에서 사용하려면 아래 init-param 을 추가해야 한다.
·미리보기 | 소스복사·
- <init-param>
- <param-name>maxWaitAfterWrite</param-name>
- <param-value>-1</param-value>
- </init-param>
Early Closing Mode
Early Closing Mode 에서 DWR 은 connection 을 열고 연결을 유지한다는 점에선 Full Streaming Mode 와 유사하다. 그러나 이는 브라우져로의 결과가 없으면 오직 connection 연결을 60초동안 유지한다. 한번의 결과물(output)이 발생되면, DWR 은 연결을 끊기 전에 임의의 설정시간만큼 잠시 기다린다. Early Closing Mode 를 DWR 2.0.4 이상 버젼에서 사용하기 위한 설정은 필요 없다. 그러나 2.0.3 이전 버젼에서는 아래와 같은 첫번째 결과물과 연결 해제시까지의 지연시간에 대한 init-param의 설정이 필요하다.
·미리보기 | 소스복사·
- <init-param>
- <param-name>maxWaitAfterWrite</param-name>
- <param-value>500</param-value>
- </init-param>
이 케이스에선 DWR의 첫번째 결과물 이후 500 밀리초(millisecond) 동안 connection 연결이 유지 될 것이다. connection 해제에 의한 강제적인 flush 전에 추가적인 결과물이 있다면 그것의 요청으로 인해 connection이 다시 열릴 것이다.
정리하자면 Full Streaming Mode 는 첫번째 결과물 이후 60초를 기다려야 연결이 해제되어 다음작업이 수행 가능해진다. 하지만 Early Closing Mode 의 경우 첫번째 결과물 전송이후 0.5초 후 연결이 해제되며 곧바로 다음 작업이 가능해진다.
maxWaitAfterWrite 파라미터에 대한 기본 파라미터 값은 -1 이며 이는 Full Streaming Mode 와 같이 connection 연결 시간이 최대 60초로 설정되어 유지된다.
Early Closing Mode 의 단점은 애플리케이션의 결과물에대한 비용이 높다는 점이다. 원인은 큰 hit count 수에 기인한다. 이것은 maxWaitAfterWrite 값에 1000 정도의 값을 세팅하므로서 부하의 증가를 막을 수 있다.
많은 수의 connect 된 브라우져와 같은 애플리케이션에선 이들은 동시에 메시지를 보낸다. 이것들은 마치 모두 동시에 재접속을 시도하는 것과 같다. 만일 이러한 종류의 문제가 발생된다면 Full Streaming Mode를 사용하는 것을 고려해봐야 할 것 이다.
Polling Mode
connection을 연 상태로 접속을 유지하는 것이 조금 어리석어 보인다면 DWR 의 polling mode를 사용 할 수 있다. activeReverseAjaxEnable=true 의 init-param 값을 세팅하였다면 추가적으로 PollingServerLoadMonitor 값을 아래와 같이 세팅해야 한다.
·미리보기 | 소스복사·
- <init-param>
- <param-name>org.directwebremoting.extend.ServerLoadMonitor</param-name>
- <param-value>org.directwebremoting.impl.PollingServerLoadMonitor</param-value>
- </init-param>
polling mode 에서 기본 poll 비율(rate) 값은 5초이다. 이는 아래와 같이 조정가능하다.
·미리보기 | 소스복사·
- <init-param>
- <param-name>disconnectedTime</param-name>
- <param-value>60000</param-value>
- </init-param>
위 예제는 poll 작업을 매 60초(60,000 millisecond)마다 수행하게 된다. 대부분의 애플리케이션에서 응답시간 60초는 충분한 시간일 것이며 이는 웹서버가 많은 수의 클라이언트를 처리를 하게 될 것이다.
DWR 2.0.2 이전 버젼에서는 disconnectedTime 속성 대신 timeToNextPoll 이라는 속성을 사용하여야 한다.
Passive Mode
Passive Mode 는 기본 모드로서 특별한 옵션 값을 enable 시킬 필요는 없다. passive mode에서는 브라우져는 웹서버로의 어떤 추가적인 connection 도 생성하지 않는다. DWR 은 data 를 순서대로 서버로 보내며 그결과을 클라이언트로 넘긴다. 이 전송방법은 잘알려진 piggyback 전송방식이다.
Passive Mode 는 최소 응답 방식이며 서버에 추가적인 부하를 주지 않는다.
