标签：Jetty

共 7 篇相关文章

IT 累计浏览 2,492

Jetty 8长连接上的又一个坑

这篇讲的是 Jetty 8 长连接处理中一个隐蔽的“坑”：超时断开机制只在数据传输阶段生效，一旦数据进入服务端处理环节，就不再检测空闲。作者从 `SelectChannelEndpoint` 类的核心代码入手，解释了连接如何通过 `setCheckForIdle` 和 `notIdle` 方法被标记为“空闲”或“非空闲”，从而控制超时判断。问题的关键点发生在请求数据收集完毕、即将提交给后端 Servlet 处理的瞬间。在 `AsyncHttpConnection` 的 `handle` 方法中，代码在调用 `_asyncEndp.setCheckForIdle(false)` 后，可能会因为复杂的处理流程和异常路径，导致该标志位未能按预期复位。这使得在后端业务逻辑执行期间，select 线程依然在监测连接的“空闲时间”，一旦处理耗时超过阈值，连接就会被错误地断开——即便业务数据正在处理中。文章通过代码走读，精准定位了这个因状态管理不严谨导致的并发陷阱。对于使用 Jetty 8 进行长连接服务的开发者来说，理解这一机制尤为重要，尤其是在设计耗时较长的异步处理逻辑时，需要格外注意避免此类意外断连。

IT 累计浏览 5,608

Netty和Jetty的Java NIO 网络框架模型分析

这篇深度对比了 Netty 与 Jetty 这两个流行 Java 网络框架的底层 NIO 模型。作者从两者处理新连接请求的入口设计切入，揭示了它们截然不同的实现思路。 Netty 采用了专门的 Acceptor Reactor（由 Boss 线程负责），它只专注于监听和接收新的连接。一旦连接建立，便会根据连接序号对事件分离器（默认数量为 CPU 核心数的两倍）取模，将其分配给对应的 NioWorker 线程进行后续的读写监听。这种模型将“接收”与“处理”显式分离，但要求耗时操作必须异步提交，否则会阻塞整个事件循环。相比之下，Jetty 的设计更接近经典的半同步/半异步模式。它在一个线程中通过同步的 `accept()` 方法阻塞等待新连接，就绪后生成变更事件注册到多路分离器，同样采用轮询策略分配负载。其代码结构往往被认为更直观。作者最后提出了一个值得深思的问题：Netty 这种为“接收”单独设立线程池的方式，是否更利于处理短连接场景；而 Jetty 同步等待的传统模式，是否对长连接（如 HTTP）更友好？这背后的性能差异，还需要更精细的并发测试来验证。

IT 累计浏览 4,475

Jetty线程“互锁”导致数据传输性能降低问题分析

这篇讲的是在Jetty 7.2.1这个特定版本中，一个会导致数据传输性能降低的“互锁”问题。作者从Jetty经典的NIO异步反映器模型入手，分析了主线程（selector）与子线程（工作线程）之间的一种微妙配合失误。问题的核心在于，当子线程遭遇网络拥塞、缓冲区写满时，它会进入阻塞状态并向主线程注册一个内部事件，等待拥塞解除的通知。然而，主线程的select循环在等待selector的网络事件时，可能并未及时轮询和处理这些内部事件，导致子线程无法被唤醒，形成“互锁”，拖累了整体性能。文章通过拆解具体的代码逻辑，清晰地展示了这种线程间交互的瓶颈点。最终，作者指出了相应的解决或规避思路，比如合理设置超时参数，以帮助开发者在类似场景下优化配置，避免性能陷阱。

IT 累计浏览 2,348

与Linux OOM-killer的第一次亲密接触

这篇讲的是作者如何在生产环境中第一次遭遇Linux OOM-killer，并从中梳理出完整的问题排查与应对思路。故事从一台内存资源紧张的服务器讲起——某天核心服务进程意外被系统终止，日志里留下了“Out of memory: Killed process”的记录。原来，是系统的OOM-killer（内核在内存耗尽时用来释放内存的机制）“盯上”了这个进程。作者从这次被动的“遭遇”出发，详细剖析了OOM-killer的工作原理：它如何根据内存占用、进程优先级等参数计算出一个评分，从而选出“最该被杀掉”的进程。文中还原了当时内存不足的完整链路：从应用程序潜在的内存使用不合理，到系统overcommit设置可能带来的乐观假定，最终触发了OOM机制。在解决问题部分，文章不仅演示了如何通过调整vm.overcommit_ratio等内核参数来“安抚”OOM-killer，还深入讲解了如何利用oom_score_adj为关键服务进程设置“免死金牌”，以及通过cgroups进行更精细的内存限制。作者最后总结，这次“亲密接触”让他认识到，理解Linux内存管理机制不能只停留在理论，更要结合监控数据与实际参数调优，才能主动规避而非被动应对OOM-killer的“误杀”。

IT 累计浏览 3,716

本周扑火之 http client 慢连接问题

这篇讲的是短链服务上线后反复出现的稳定性难题。作者从第5次故障复盘入手，定位到问题的核心：在高并发场景下，HTTP Client 的连接建立异常缓慢，直接拖垮了整体响应时间。深入排查后发现，根因在于服务所依赖的某个下游接口存在偶发延迟，而客户端库的默认超时与重试配置又过于激进。当少量慢请求出现时，连接池很快被占满，引发了雪崩效应。解决的方案并非简单扩容，而是从调优客户端参数入手：精确调整了连接超时、读取超时，并对重试策略做了更保守的设置，同时在业务层增加了对慢调用的熔断隔离。这次“扑火”经历揭示了一个常见但容易被忽视的陷阱：微服务架构中，一个不稳定依赖可能通过连接池耗尽这种间接方式，引发连锁反应。关键在于为外部调用设置合理的防护边界。

IT 累计浏览 3,535

关于 Jetty Continuation

这篇讲的是 Jetty 服务器中一个名为“Continuation”的机制。在早期的 Servlet 规范不支持异步处理的背景下，Jetty 通过这个机制解决了在长轮询（Long Polling）或 Comet 场景中，线程资源被长时间等待的请求阻塞的问题。文章详细拆解了 Continuation 的核心工作流程：它允许一个请求的处理线程主动挂起自己，释放回线程池，而底层的连接则被保持。当后续事件到达时，再由服务器重新唤醒处理线程来完成响应。这个“挂起-恢复”的模型，巧妙地让一个线程能够服务于多个先后到达的请求，极大降低了服务器在高并发、慢连接场景下的资源开销。作者还对比了 Continuation 与后来 Servlet 3.0 标准化异步处理（AsyncContext）的异同，并指出 Continuation 作为 Jetty 的私有扩展，其设计思想影响了后续的规范。对于需要维护或理解 Jetty 老版本系统的工程师来说，这篇文章清晰地阐明了这一历史特性的设计初衷和实现精髓。

IT 累计浏览 5,181

Apache + Jetty 架设 CAS 单点登录

作者从实际部署需求出发，挑战了常规的 CAS 单点登录部署方案。通常教程推荐直接使用 Tomcat 或 Jetty 绑定 443 端口并配置 SSL，但他更倾向于将 SSL 终止这一职责交给 Apache 处理，让 Jetty 专注于应用逻辑。这篇笔记详细记录了实现这一架构的具体实践。核心在于配置 Apache 作为前端，负责处理 HTTPS 请求，然后通过反向代理（如 AJP 或 mod_jk）将请求安全地转发给后端的 Jetty 服务器。文章梳理了在此过程中遇到的关键配置点与调整细节，为读者提供了一条可行的替代路径。这种架构将 Web 服务器与应用服务器职责分离，有利于统一管理 SSL 证书与安全策略，也使得后端应用部署更为灵活。对于希望在保持生产环境安全合规的同时，又不想被应用服务器的端口绑定所束缚的运维与开发人员来说，这个方案提供了值得参考的思路。