2012-05-28 8 views
8

Tengo un servlet que se utiliza para obtener los datos desde muchos puntos de datos REST terceras partes, integrar todos los datos e informar los datos en un formato HTML. También tengo un filtro que tiene el siguiente flujo -cómo actualizar filtros para apoyar Servlet 3.0 servlet asíncrono

  1. Cree un registro de eventos cuando la solicitud golpea el filtro y añadir el objeto eventrecord a la solicitud
  2. realizar chain.doFilter - que permite al servlet para añadir más detalles en el registro de eventos
  3. En el camino de regreso al navegador, filter obtiene el objeto eventrecord y lo registra.

Ahora si uso servlet asíncrono utilizando AsyncContext context = request.getAsyncContext();, que hable con los mismos puntos de datos REST, pero a medida que los datos están listos, se escribirá a la secuencia de respuesta en lugar de esperar a que todos los puntos de datos REST para responder, ¿Cómo volvería a escribir mi filtro? ¿Se adjuntará al hilo que es responsable de eliminar los datos de los puntos de datos REST para que una vez que todos los datos se procesen y se vacíen, se registre el registro de eventos? ¿Hay algún patrón común que pueda estudiar para comprender cómo se pueden manejar estos casos de uso con los servlets asíncronos de Servlet 3.0? Estoy usando JDK 6.0, Tomcat 7.0.

Respuesta

7

Sólo tiene que añadir @WebFilter(urlPatterns = {"/*" }, asyncSupported = true) en Web en XML para su filtro.

O añadir <async-supported>true</async-supported>

0

He puesto una recompensa como estoy seguro de mí mismo cómo apoyar adecuadamente la instrumentación de diagnóstico o filtros (por ejemplo Codahales metrics filters).

Mientras que la adición <async-supported>true</async-supported> a sus filtros sin duda hará que ellos parecen funcionar puede que no obtener los resultados esperados (en el caso de las métricas de todas sus peticiones serán parecen ser muy rápido).

Puede parecer como una buena idea para obtener el AsyncContext de inmediato en el filtro para enlazar datos métricos but various containers apparently have issues with this y creo marcos como Spring tienen problemas también (esto podría ser mi versión anterior de la primavera). Esa es la mayoría de los frameworks esperan que la primera mitad del manejo de la solicitud sea sincrónica (tal vez masivamente mal en esto).

En consecuencia, parece que la única manera infalible es integrar filtros en el nivel del marco. Por ejemplo, Spring ofrece org.springframework.web.context.request.async.DeferredResultProcessingInterceptor que es algo análogo a los eventos AsyncContext.

Esto es un tanto desafortunado ya que no todas las solicitudes pueden ser manejadas por el framework web pero hay una diferencia entre manejar la primera parte de la solicitud y cumplir (es decir, que ahora hay dos métricas que tal vez quiera monitorear).

0

Anotación @WebFilter se ha introducido en Java EE 6. Define elemento diferente como filterName, asyncSupported y servletNames etc. @WebFilter no se puede utilizar sin web.xml porque @WebFilter no define orden. @WebFilter reduce la otra configuración en web.xml.

@WebFilter(filterName="filterOne") 
public class FilterOne implements Filter { 
    @Override 
    public void init(FilterConfig filterConfig) throws ServletException { 
    } 
    @Override 
    public void doFilter(ServletRequest request, ServletResponse response, 
      FilterChain chain) throws IOException, ServletException { 
     System.out.println("Inside filter one."); 
     chain.doFilter(request, response); 
    } 
    @Override 
    public void destroy() { 
    } 
} 
Cuestiones relacionadas