jetty怎么找到eclipse中jetty路径

jetty 时间:2021-08-02 阅读:()

jetty server 类有什么用

jetty6.0引入continuations continuations优点原始servlet连接应线程短连接情况都没问题现越越运用基于连接用户并发量台线程数比数升java线程般占用64K内存包括其资源占用况且线程调度线程锁机制等都耗CPU 现请求应线程益于NIO连接能够请求处理配线程连接空闲线程放线程池连接再添加NIO Select Set检测新请求种请求应线程模式能应更用户连接于ajax运用说轮循请求取数据太要断建立连接且般连接都没取数据浪费连接所比较办服务器保持住请求直服务器数据往客户端转送或超止技术同背离请求线程初衷每客户端服务端都请求线程保持着服务端需要每客户端或线程量并发用户仍问题 jettycontinuations解决面问题产原理：使用SelectChannelConnector处理请求类基于NIO API使能够用消耗每连接线程持放连接使用continuations suspend调用实际SelectChannelConnector.RetryContinuation.suspend抛异 RetryRequest,该异传播 servlet 外并通滤器链传并由 SelectChannelConnector 捕获发该异并没响应发送给客户机请求放处于等待状态 Continuation 队列 HTTP 连接仍保持打状态该请求提供服务线程返 ThreadPool用于其请求提供服务暂停请求直保持等待状态 Continuation 队列直超指定限或者 resume() Continuation 调用 resume() ,现述任意种条件请求重新提交 servlet（通滤器链）事实整请求重新进行处理直首调用 suspend()执行第二发 suspend() 调用RetryRequest 异抛执行照进行.判断依据：if (!_pending && !resumed && timeout >= 0) ..throw _retry;其_pending指第二调用suspend....jettythread pool空闲线程处理其请求 continuations引入能用少线程处理量请求实验见： public class App { public static void main(String[] args) throws Exception { Server server = new Server(); Connector conn = new SelectChannelConnector(); conn.setPort(8080); server.setConnectors(new Connector[]{conn}); WebAppContext ctx = new WebAppContext(); ctx.setContextPath("/"); ctx.setWar("./webapp"); server.setHandler(ctx); QueuedThreadPool threadPool = new QueuedThreadPool(); threadPool.setMaxThreads(100);#设置jettythread pool100线程 server.setThreadPool(threadPool); DaemonService.bind(server); server.start(); } } DaemonServiceServletContextListener代码： public void contextInitialized(ServletContextEvent sce) { new Thread(new Runnable() { public void run() { while (true) { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } #每打印前线程池线程及空闲线程 System.out.println("thread:" + server.getThreadPool().getThreads() + "#idle:" + server.getThreadPool().getIdleThreads()); } } }).start(); } 写TestServlet应mapping/test public class TestServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } resp.getWriter().write("Test"); resp.getWriter().flush(); } } 使用ab -c 200 -n 1000 测试结： thread:2#idle:1 thread:2#idle:1 thread:89#idle:0 thread:100#idle:0 概10thread:100#idle:0 thread:100#idle:0 thread:100#idle:0 thread:99#idle:19 thread:99#idle:88 thread:99#idle:98 thread:99#idle:98 thread:99#idle:98 说明并发200jetty线程池几乎没空闲线程处理其请求 ab测试结： Requests per second: 44.54 [#/sec] (mean) Time per request: 4490.625 [ms] (mean) TestServlet代码改Continuation同停顿2秒 public class TestServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { Continuation continuation = ContinuationSupport.getContinuation(req, null); continuation.suspend(2000); resp.getWriter().write("Test"); resp.getWriter().flush(); } } 使用ab -c 200 -n 1000 测试结： thread:2#idle:1 thread:7#idle:6 thread:7#idle:6 thread:39#idle:26 thread:42#idle:41 thread:42#idle:36 thread:65#idle:64 thread:65#idle:46 thread:91#idle:90 thread:91#idle:90 thread:91#idle:89 thread:91#idle:90 thread:91#idle:83 说明并发200jetty线程池直都空闲线程 ab测试结： Requests per second: 79.21 [#/sec] (mean) Time per request: 2525.000 [ms] (mean) 结论：jettycontinuations短连接见优势连接或者台访问IO资源(数据库网络等）造 servlet响应慢问题优势让线程傻傻等待数据库访问完放入线程池处理其请求等数据库访问完再处理 servlet 3.0规范已经引入异步servlet功能写：请求/url/A AsyncContext ac = request.startAsync(); //...边处理具体资源操作db.getConnection()或其操作 ac.dispatch();

jetty的 continuations 有什么优点

jetty在6.0以后引入了continuations，那么什么是continuations？他有什么优点？原始的servlet是一个连接对应一个线程，在短连接情况下都没什么问题，但是现在有越来越多的运用是基于长连接的，这样用户并发量上去的话，后台的线程数将会以正比数上升。

一个java线程一般占用64K内存，包括其他的，资源会占用很多，况且线程调度，线程锁机制等都很耗CPU。

后来出现一个请求对应一个线程。

得益于NIO，连接能够在请求被处理时分配一个线程。

当连接空闲时，那个线程将会被放到线程池中，而连接再次添加到NIO Select Set中去检测新的请求。

这种一个请求对应一个线程的模式能应对更多的用户连接。

对于ajax运用来说，轮循请求去取数据不太好，因为要不断建立连接，而且一般连接都没取到数据，浪费很多连接，所以比较好的办法是服务器保持住那个请求，直到服务器有数据就往客户端转送或超时为止。

这是一个好技术，但是它同时也背离了一个请求一个线程的初衷，因为每个客户端在服务端都有一个请求线程保持着，因此服务端需要为每个客户端生成一个或多个线程。

在大量并发用户下仍然有问题。

jetty的continuations正是解决上面的问题而产生的。

它的原理是：使用SelectChannelConnector来处理请求，这个类是基于NIO API上的。

因此使它能够不用消耗每个连接的线程就可以持有开放的连接。

使用continuations suspend时，调用的实际是SelectChannelConnector.RetryContinuation.suspend，此时会抛出一个异常RetryRequest,该异常将传播到 servlet 以外并通过过滤器链传回，并由 SelectChannelConnector 捕获。

但是发生该异常之后并没有将响应发送给客户机，请求被放到处于等待状态的 Continuation 队列中，而 HTTP 连接仍然保持打开状态。

此时，为该请求提供服务的线程将返回 ThreadPool，用于为其他请求提供服务。

暂停的请求将一直保持在等待状态的 Continuation 队列，直到超出指定的时限，或者当对 resume() 方法的 Continuation 调用 resume() 时,出现上述任意一种条件时，请求将被重新提交到 servlet（通过过滤器链）。

事实上，整个请求被重新进行处理，直到首次调用 suspend()。

当执行第二次发生 suspend() 调用时，RetryRequest 异常不会被抛出，执行照常进行.判断的依据是：if (!_pending && !resumed && timeout >= 0) ..throw _retry;其中_pending是指是不是第二次调用了suspend....这样子，jetty中的thread pool就会有空闲线程来处理其他的请求。

continuations的引入能用很少的线程处理大量的请求。

。

实验见下： public class App { public static void main(String[] args) throws Exception { Server server = new Server(); Connector conn = new SelectChannelConnector(); conn.setPort(8080); server.setConnectors(new Connector[]{conn}); WebAppContext ctx = new WebAppContext(); ctx.setContextPath("/"); ctx.setWar("./webapp"); server.setHandler(ctx); QueuedThreadPool threadPool = new QueuedThreadPool(); threadPool.setMaxThreads(100);#设置jetty的thread pool最大为100个线程。

server.setThreadPool(threadPool); DaemonService.bind(server); server.start(); } } DaemonService是一个ServletContextListener，代码为： public void contextInitialized(ServletContextEvent sce) { new Thread(new Runnable() { public void run() { while (true) { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } #每次打印出当前线程池的线程大小及空闲线程 System.out.println("thread:" + server.getThreadPool().getThreads() + "#idle:" + server.getThreadPool().getIdleThreads()); } } }).start(); } 写一个TestServlet，对应的mapping是/test public class TestServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } resp.getWriter().write("Test"); resp.getWriter().flush(); } } 使用ab -c 200 -n 1000 http://localhost:8080/test 测试后结果如下： thread:2#idle:1 thread:2#idle:1 thread:89#idle:0 thread:100#idle:0 大概还有10多个的thread:100#idle:0 thread:100#idle:0 thread:100#idle:0 thread:99#idle:19 thread:99#idle:88 thread:99#idle:98 thread:99#idle:98 thread:99#idle:98 说明了在并发200个时，jetty线程池里几乎没有空闲线程来处理其他的请求。

ab测试结果为： Requests per second: 44.54 [#/sec] (mean) Time per request: 4490.625 [ms] (mean) 当把TestServlet代码改为Continuation时，同样是停顿2秒 public class TestServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { Continuation continuation = ContinuationSupport.getContinuation(req, null); continuation.suspend(2000); resp.getWriter().write("Test"); resp.getWriter().flush(); } } 使用ab -c 200 -n 1000 http://localhost:8080/test 测试后结果如下： thread:2#idle:1 thread:7#idle:6 thread:7#idle:6 thread:39#idle:26 thread:42#idle:41 thread:42#idle:36 thread:65#idle:64 thread:65#idle:46 thread:91#idle:90 thread:91#idle:90 thread:91#idle:89 thread:91#idle:90 thread:91#idle:83 说明在并发200个时，jetty线程池中一直都有很多空闲线程 ab测试结果为： Requests per second: 79.21 [#/sec] (mean) Time per request: 2525.000 [ms] (mean) 结论：jetty的continuations在短连接上不见得有很大的优势，但是在长连接或者在后台访问IO资源(数据库，网络等）造成的 servlet响应慢问题上，会有很大的优势，他不会让一个线程傻傻地在等待数据库访问完成，而是会放入线程池去处理其他请求。

等数据库访问完后，再过来处理。

servlet 3.0规范已经引入了异步servlet功能，写法为：请求/url/A AsyncContext ac = request.startAsync(); //...这边处理具体的资源操作，如db.getConnection()或其他的操作 ac.dispatch();

jetty什么是jetty容器嵌入式容器

Jetty是使用Java语言编写的，它的API以一组JAR包的形式发布。

开发人员可以将Jetty容器实例化成一个对象，可以迅速为一些独立运行（stand-alone）的Java应用提供网络和web连接。

软件测试人员以及定制软件生产商。

大部分的Java开发人员都可以划分到这三种情况中。

EJB ，以及其他一些功能。

你应该采用已经存在而且测试过的组件并且使用Jetty而不是从零开始。

ApacheGeronimo, JBoss , 和ObjectWeb JOnAS这些项目组在建立自己Java EE应用服务器时也是这样做的。

当已经存在的容器不能满足需要的时候，软件测试人员会得益于按照需要来生成自己的servlet容器。

例如，曾经有个同事想要寻找某种方式来驱动他为web service代码所写的单元测试对于那些开发Java EE应用作为产品的人员来说，为什么仅仅提供一个WAR文件？这样你为会容器的规范而头疼，同时也会增加你的技术支持的成本。

相反的，可以提供给客户一个自己具有启动，停止以及管理功能的应用程序。

就连硬件生产商也会从中受益：Jetty对于普通的HTTP服务（没有servlet）只需要350k的内存，这使得可以将其用在智能设备中。

你可以提供基于web的控制面板并且具有Java web应用的所有功能而不用担心那些独立的容器所带来的压力。

最后，我敢打赌嵌入式servlet容器最有趣的应用会发生在那些从来不编写传统的基于web应用的人身上。

可以将Java EE和HTTP的组合作为一个C/S结构程序的后台。

考虑一个事件驱动的服务，例如（假想的）Message-Driven Bank（onjava上的另外一篇文章中提到），从main()方法启动并且等待到来的请求，就像Unix中的daemon程序一样。

肯定会有一些人想要将这个程序暴露成一种基于用户的风格，例如一个GUI桌面应用，这只是个时间问题。

要创建自己的基础组件，协议和socket通讯代码是最令人生厌的，而且会使人从业务逻辑中分心，就更不用说将来可能要调试的事情了。

使用嵌入式的Jetty容器来将业务逻辑通过HTTP协议暴露是一个不错的选择，它不用对现有程序作过多改变。

选择采用Swing， SWT ，XUI这些GUI并且将请求包装成HTTPPost操作，，甚至SOAP来完成这个回路。

与定制的特定于某个领域的协议相比，这些通用的协议可能性能稍差，但是，用不了多久，你就会从这些已经存在的经过实际检验的协议中得到好处并且节省大量的努力。