问题标签 [jetty-9]

我们想要一个简单的嵌入式 Jetty servelet，其 Web 资源位于 JAR 文件的资源文件夹中。我们在 JAR 中有一些属性文件，并使用资源路径加载它们。我们希望将 Jetty Resource Base 指定为：

• 资源/网络应用
• 设置：resource_handler。setResourceBase ( "webapp" )
  • 通过正确的 URL 指向JAR 文件中的该资源。

JAR 文件中的文件夹。这是一个简单的 JAR 文件（不是 WAR，没有框架，没有 Spring，尽管我们可能是最原始的）。初始测试继续为以下字符串引发异常：

虽然服务器似乎在运行，但结果找不到我的 index.html。（更新：）这个例子只是取自码头“嵌入式文件服务器”的例子。在这种情况下，要求 Jetty资源库映射到 JAR 文件（完整 URL）：

• "jar:file:!/webapp/index.html",

如下：

• resource_handler.setResourceBase(" jar:file:!/webapp ");

而不是给出的示例：

• resource_handler.setResourceBase(".");

我们希望它将浏览器 URL 映射为：

• 本地主机：8080/index.html
  • ...给...
• jar:file:!/webapp/index.html

为了对比适用于以下配置文件的 JAR 路径。问题：URL 应该是什么，这样 Jetty 资源库才能为我的 Index.html 文件提供服务？

• 资源/
  • 配置/
    • 显示属性

文件是：“/config/display.properties”，这适用于使用加载资源操作的相同项目代码。布局是这样的：

给出总体思路。

类似的问题：

• 为 JAR 文件启动嵌入式码头服务器

只是想问一下我的问题。我正在尝试设置码头服务器并包含我自己的 webapp。我将 web 应用程序放在码头服务器的 webapp 文件夹中。我还在码头的 lib/ext 文件夹中包含了 Web 应用程序所需的必要库，它不包含在 war 文件中。当我运行码头服务器并访问 web 应用程序时，我得到了“NoClassDefFoundError”。

我使用“java -jar start.jar”运行码头服务器。我也确信包含导致错误的类的 jar 文件位于类路径中。

我错过了什么？谢谢你。

我有一个在 Linux Mint 上运行的 Java 应用程序。每一分钟，程序都会显示出非常明显的减速——停顿。停顿是一致的 3 到 4 秒。当我们运行同一程序的更多实例时，它们也会每分钟暂停 3 到 4 秒。每个程序在一分钟的不同秒停止。

最近更新：

在最后一次更新（如下）增加线程池的线程数后，GUI 问题消失了。运行大约 40 小时后，我们观察到 JettyHttpClient 阻塞-GET ( Request.send()) 调用中的线程泄漏。为了解释机制，使用 Executor 类：主线程每隔几分钟运行一次。它使用 Executor 运行一个独立的线程，通过 HTTP GET 命令调用主机，Jetty 的HttpClient.request.send().

HttpClient运行大约 40 小时后，池中运行的线程数出现峰值。所以 40 个小时，相同的线程运行良好。工作假设是大约在那个时候，一个或多个send()调用没有完成或超时并且没有返回到调用线程。本质上，这个/这些线程挂在 Jetty 客户端中。

在查看jVisualMV中的每个常规循环时，我们会看到每个循环的正常行为；一些 HttpClient 线程为主机 GET 启动，在几秒钟内执行并离开。监视器上还有大约 10 个属于 JettyHttpClient线程池的线程，它们已经“存在”了（现在）10 个小时。

预期是在底层客户端或网络处理中存在一些错误。我很惊讶没有超时异常或编程异常。我现在可以问一些明确的问题。

1. HttpClient里面会发生什么Request.send()
2. 呼叫返回的超时时间是多少？我认为仍然会有绝对超时或锁定检查等（不是吗？）
3. I/O 系统能否挂起，让调用者线程挂起——而 Java 乖乖……
   • 在预定时间触发管理器线程，然后
   • 接下来Http.Request.send()发生，
   • 池中的新线程为下一次发送启动（似乎已经发生）。
   • 虽然早期send()陷入困境
4. 我可以限制或以其他方式清理这些卡住的线程吗？

这发生在我们增加线程池大小之前。发生的事情是，“责备”变得更加集中在问题领域。HttpClient我们也对底层系统持怀疑态度，因为我们在一天中的同一（非特定）时间再次与 Apache 发生了锁定。

（提前更新）...

观察到的暂停行为是JavaFX GUI 不更新/刷新；显示器的时钟（textView），setText()呼叫在冻结期间以每秒两次更新的速度记录（这是新信息）。时钟不会更新（在 Mint Linux 上），它在 Windows 上运行时会继续更新。为了防止我重复自己关于 GC、日志、探针等的问题。答案将是相同的；我们已经进行了数周的广泛诊断。这个问题无疑是混合了：Linux JVM / Linux Mint / 线程（每个 JavaFX）。其他新数据是线程池计数增加 +2，似乎消除了冻结——需要进一步测试来确认并调整数字。但问题是“"

我们已经连续几天在 Windows 上运行了该程序的多个实例，没有停顿。当我们在 Mint Linux 平台上运行时，我们会看到冻结，这是非常一致的。

该程序有几个按计划运行的正在运行的线程。一个线程为 http 套接字打开 Internet。当我们注释掉那个区域时，停顿就消失了。但是，我们在使用 Windows 时看不到这种行为。实验指向特定于 Mint 网络 I/O 子系统、linux 调度、Linux Java 8 JVM 或两者之间的某些交互的东西。

正如您可能猜到的那样，我们正在为此撕毁我们的头发。例如，我们关闭了日志记录并且暂停仍然存在。我们恢复了日志记录，只调用了一次 http 服务器，每 60 秒暂停一次，秒数相同。即使我们不进行其他处理，也会发生这种情况。我们尝试了不同的 http 库等。似乎很清楚它是在 JVM 或 Linux 中。

有谁知道解决这个问题的方法？

我有一个 jar 类型的项目。这个 jar 是WEB-INF/lib第三方 webapp 的“扩展模块”（可在公共 maven repo 上获得）。在pom.xml中，我对该 webapp 有战争类型的依赖。

我希望能够mvn jetty:run-forked在未提取的war文件上运行（直接从~/.m2/repository将项目依赖项和jar工件“虚拟”添加到WEB-INF / lib中。这样做似乎比预期的要简单，因为码头初始化变得相当复杂。我最终搞砸了使用 jetty/maven Java 源代码有效地重新编程 XML 中的初始化。:) 最后查看http://wiki.eclipse.org/Jetty/Zip_Exceptions_Reading_Jar_or_War_Files前面还有更多麻烦。事实上，对于非平凡的 webapps 似乎不可能运行未爆炸的战争（由于“文件不可解析或与 URLClassloader 不兼容”）。

鉴于当前的码头/Maven 来源，这可能吗？

需要做什么才能使其正常工作？

我坚持将战争部署到远程 Jetty 9。

在应用服务器端，我部署了 cargo-jetty-7-and-onwards-deployer（版本 1.4.9）。该组件似乎运行正确并响应（如 get 请求所预期的那样）：

HTTP 错误 400

访问 /cargo-jetty-deployer/ 时出现问题。原因：命令/未知 Powered by Jetty://

为了部署，我使用了 cargo-maven2-plugin（版本 1.4.9）和这个配置：

运行时：mvn cargo:deploy

这会导致以下错误消息：

在此之后，构建和部署失败。

我检查了 Jetty 上的日志，我还将日志记录级别提高到了 DEBUG，但没有迹象表明服务器端出了什么问题。

有谁知道我做错了什么？有什么方法可以让我获得更好的错误消息来指示出了什么问题？

任何帮助将不胜感激！:)

Ps 我已经删除了日志中的 ip。

Pss 我正在部署的战争之前已经过测试并且在 Jetty 上运行良好。

Server我的问题很简单：在一个 JVM 进程中拥有 2 个独立的 Jetty 实例，使用独立的 URL 映射和 SSL/TLS 设置监听不同的端口是否完全安全？我没有看到奇怪的行为，但在部署到 live 之前，我想得到一些保证，我正在做的事情是合理的。Server如果不是，那么使用具有某种不同 URL 命名空间和安全 SSL/TLS 设置的单个实例进行相同的设置是否合适？

我正在从 jetty7.6 迁移到 jetty-9.2。我看到码头连接的 idletimeout 的默认值减少了 10 倍。

在码头 7.6

在码头 9.2 中：

为什么这样 ？

正因为如此，我不断低于异常：

谢谢， 阿努杰

从 Jetty 文档 - http://www.eclipse.org/jetty/documentation/current/statistics-handler.html看来，应该非常谨慎地使用启用连接器统计信息，并且不应启用用于生产用途。

但是，我想知道是否应该启用请求统计信息（通过添加统计信息处理程序启用）或不用于生产用途？

如何使用最新版本的 jetty maven 插件在不同端口上运行多个 webapps？

org.eclipse.jetty:jetty-maven-plugin（9.2.2.v20140723撰写本文时的版本）。

例如，

官方文档在httpConnector下说明了这一点

太好了，所以我配置了 aname但是如何将它绑定到 a contextHandler？这是我到目前为止所拥有的

这个尚未迁移的 wiki建议可以使用 上的connectorNames属性来完成WebAppContext，但这不再可用。

我有一个小型应用程序，它使用 Jetty v9.2, HttpClient简单地轮询服务器。几天后，应用程序将冻结。最初，我们确定需要增加线程池的大小以减轻性能损失。该更改在几天内恢复了性能。锁定仍然存在。原因已被隔离到 HTTP GET 调用（如果我们注释掉该方法，问题就会消失）。

出现在Jetty HttpClient Connection management或Thread management的根本原因。通常 Jetty HttpClient 会创建一组线程来处理 HTTP GET（见下文），这些线程会按照您的预期启动和消失。大约 40 小时或运行后，JDK VisualVM 显示至少 9 个连接线程不会立即消失：

• HttpClient - 调度器 x 1
• HttpClient - 选择器客户端 SecectorManager x 4
• HttpClient x 4

还

• RMI TCP 连接

总共九或十个线程。在下一次读取时，会创建新的线程实例来承载负载并且客户端继续。此外应用程序。有一个带有专用线程的时钟，在应用程序锁定后继续运行，这表明 JVM、操作系统和机器本身都很好。

有时，我们会看到这些“卡住”的线程会停留长达一个小时，然后才会退出 VisualVM 线程显示。至少 36 小时后，我们看到线程仍然存在并且我们没有看到它们消失。

足够的天数后，软件锁定。指示的解释是未清理的线程实例泄漏。它出现了应用程序。线程用完了，不能做更多的工作。它肯定会阻止服务器日志所见证的 HTTP GET。

主要的 HTTP 调用使用下面的代码，HttpClient GET 方法：

这是基于简单的示例，关于使用 HttpClient 的细节很少。一切都是按照霍伊尔做的吗？

在不同的执行运行中，我们还会看到以下异常和日志消息：

• [36822522] WARN 2014-Sep-02 02:46:28.464> HttpClient@2116772232{STOPPING,8<=0<=200,i=0,q=0} 无法停止线程 [HttpClient@2116772232-729770,5 ,]

我们想知道这条消息是否与其中一个卡住的线程有关？或者，此消息是否表明我们需要检查一个单独且不同的问题？还：

• java.util.concurrent.TimeoutException (ExecutionException)

这似乎是线程超时异常。哪个线程？这是否与他的 HTTP 连接线程有关？我认为，当服务在内部捕获错误时，它们至少可以指示错误的位置和堆栈跟踪。

有一些明显的问题：

1. get() 方法代码是否按要求编写，不存在泄漏或为 Jetty HttpClient 代码留下挂起的资源？
2. 我们如何捕捉警告：“无法停止线程”错误？
   • 这个错误有什么影响？有没有办法“粉碎”这样卡住的线程？
   • 这是否与 10 个悬挂连接线程有关？只有一条警告信息。
   • 可以想象一个挂起的线程需要一个错误标签，而不是一个警告。
3. Jetty HttpClient 中是否有捕获线程错误和一般错误的过程？
4. HttpClient 可以使用哪些属性来调整服务？
   • 是否有我们可以用来直接影响线程锁定的设置？
5. HttpClient 的环境或上下文中可以使用哪些属性来控制调整服务？
6. Jetty HttpClient 是否可以重新启动/重新启动或只是停止？
   • Jetty 调用仅在所示的 GET 方法中进行（尽管有更多的日志记录等）
7. RMI 线程是否是 Jetty HttpClient 调用的一部分？

另一个观察结果是，当我们在 VisualVM 中“卡住”线程时，它会在“线程”面板中显示过多的守护程序线程，而不是非守护程序线程的增加。

通过在 for 循环中运行上面显示的代码大约 3 或 4 小时，在 HttpClient send() 调用之间有 250 毫秒的中断显示线程泄漏——在 Linux 上重现很简单。日志输出显示没有 WARNings 并且在距离线程泄漏至少 30 分钟的网络上只有两个超时错误。

欢迎提出建议、观察、改进和回答。我们提前致谢。

相关问题：

这些问题涵盖了一些非常相似的点

• 码头无故停止
• ConnectionPoolTimeoutException：等待来自池的连接超时
• 无法在 Tomcat webapp 中关闭 Neo4j Jetty 服务器
-