Jetty中如何实现servlet的异步Request调用

在servlet3.1规范当中,已经支持在servlet中通过调用request.startAsync来开启1个异步调用,然后在相应的业务线程里面进行一些业务操作,再通过asyncContext.complete即完成业务的整个操作。一个参考的demo如下所示:

    val context = req.startAsync();
    //重新设置业务超时时间
    context.setTimeout(40_000);

    Runnable runnable = () -> {
        try{
            //执行你的业务操作

            //输出数据
            context.getResponse().getWriter().println(totalMoney);

            //完成业务
            context.complete();
        } catch(Exception e) {
            e.printStackTrace();
        }
    };
    
    new Thread(runnable).start();

在上面的参考中,原来的servlet在调用完 thread.start之后,相应的逻辑即完成。相应的容器线程则已经还给线程池,此线程即可以接收其它客户端的请求并处理了. 异步servlet的目的即在于将接收请求的io线程与实际的业务执行相分开,避免过慢的业务阻塞了整个容器,而不能再接收更多的请求了.甚至可以在后端的业务池中定义一个队列,将要进行执行的业务逻辑放入队列里面慢慢执行。

由于异步Servlet的目的在于将web容器的io线程与业务线程分离,那么关键的部分即在于当servlet方法执行完之后,当context.complete时,如何重新触发相应io流的操作。本文尝试以jetty为参考,从源码角度查看其实现的原理和机制。

本文参考的jetty版本为 9.4.11.v20180605

继续阅读“Jetty中如何实现servlet的异步Request调用”

解决jetty在windows下锁静态文件的问题

本文原英文地址:http://www.eclipse.org/jetty/documentation/9.3.0.v20150612/troubleshooting-locked-files-on-windows.html#d0e26059
在jetty容器内,对于静态文件,会采用内存缓存的实现方式,如采用buteBuffer的方式来进行缓存。如果使用NIO连接器(默认情况),jetty就会采用文件映射(filemapper)的方式。但是这个方式在windows下会存在一个问题,即使用文件内存映射会导致这个文件被进程锁住,其它进程就不能但修改或者替换这个文件了。解决这个问题的一个方法就会停掉jetty,但这种方式显示不太靠谱。

jetty提供了一个开关标记来开启或者禁止内存映射,在类DefaultServlet中有一个属性useFileMappedBuffer,此属性值默认为false,并且在配置文件webdefault.xml中进行配置。

默认的配置文件存储在jar包jetty-webapp-${version}.jar中的org/eclipse/jetty/webapp/webdefault.xml,还有一份存储在jetty-home/etc/目录中。两者的区别在于,后者由jetty运行时配置文件中默认使用。前者由在代码中WebAppContext默认使用(没有配置值的情况下).最简单的作法就是修改这个配置文件,如下所示:

<init-param>
   <param-name>useFileMappedBuffer</param-name>
   <param-value>true</param-value> <!-- change to false -->
</init-param>

继续阅读“解决jetty在windows下锁静态文件的问题”