問題タブ [jetty-8]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
662 参照

ubuntu - jetty8 ClassNotFoundException の開始: HttpServletResponse

Jetty 8 の起動が HttpServlet 応答の ClassNotFoundException で失敗するのはなぜですか? 私が見逃したステップは何ですか?

Ubuntu 12.04.03 で実行

次のようにopenjdk 7をインストールしました:

sudo apt-get install openjdk-7-jdk

  • 取り付けられた桟橋 8 と:

sudo apt-get install jetty8

  • /etc/default/jetty8 ファイルを変更して、NO_START=0 と JAVA_HOME=... の値を設定しました。

しかし、「service jetty8 start」で jetty を起動すると失敗し、/var/log/start.log に次のように表示されます。

原因: java.lang.ClassNotFoundException: javax.servlet.http.HttpServletResponse

完全なスタック トレースは次のとおりです。

0 投票する
1 に答える
2112 参照

java - Jetty との TIME_WAIT 接続が多すぎます

10 台の異なるサーバーで API を実行していますが、それらはすべてファイアウォールの背後にあります。すべての http リクエストを処理するために jetty 8 を使用しています。この API の使用例は、短期間の接続です。

数か月前、ランダムToo many open file descriptorsエラーが発生し始めました。これらのエラーにより、サーバーが完全に応答しなくなります。これを修正するには、jetty サーバーを再起動する必要があります。今日、これは、私が得ているトラフィックに応じて、1日に0〜10回発生しました.

いくつかの調査の後、すべての接続が TIME_WAIT 状態でスタックしているため、新しい接続を作成できないため、利用可能な接続の数を使い果たしていることに気付きました。

この例では、TIME_WAIT 状態の接続数はかなり少ないですが、最大 50k になる可能性があります。

私はいくつかのカーネル調整を試みてきました。また、Jetty ソケットの SO_LINGER タイマーを 1 秒に設定しようとしました。これらの変更はすべて頻度を減らすのに役立ちましたが、まだ定期的にエラーが発生しています.

また、言及する価値があるのは、各サーバーで毎秒約 3,000 のリクエストを受信して​​おり、CPU 使用率が非常に低いことです。今日のトラフィックをスケーリングする際のボトルネックは、この接続の問題です。

それを正しく処理するために私ができることを知っている人はいますか?

0 投票する
1 に答える
799 参照

java - Jetty でサービス拒否攻撃の最適な戦略を実装する方法

Jetty で DoS 攻撃保護を実装する最適な方法は何ですか。すべてのクラスを拡張する必要があるか、構成をセットアップする必要があります。

0 投票する
1 に答える
4152 参照

jetty - 運用環境の Jetty 8 と Jetty 9 の比較

現在、低遅延トラフィックを提供する本番環境に Jetty 8 を使用しています。非常に低いレイテンシ要件があることを考えると、Jetty 9 に移行する利点は何だろうかと考えていました。

ありがとう!

0 投票する
0 に答える
580 参照

java - Jetty 8 との問題のある Cookie クラスのバインディング

Jetty のバージョンを 7.4 から 8.1.4 のようなサーブレット 3.0 仕様に準拠したバージョンにアップグレードし、GWT を 2.3 から 2.5 にアップグレードしようとしています。

そうしているうちに、jetty の Response.addCookie(Cookie) メソッドが宣言または実装されていない Cookie クラスのメソッドを呼び出し、次のエラーが発生することがわかりました。

すでに確認したところ、servlet-3.0 の Cookie クラスには isHttp() メソッドがありますが、gwt-user.jar には servlet 3.0 に準拠していない別の実装があります (つまり、そのメソッドや他のいくつかのメソッドを定義していません)。

この時点で、バインドしているコードがわからず、コードをデバッグできません (ログ ファイルと jar にしかアクセスできないサーバーで実行されます)。

pom ファイルの依存関係の順序を変更してもうまくいかないことが判明したため、アイデアが尽きてしまいました。

PD: サーブレット 3.0 に準拠していない Cookie クラスを持つ j2ee-1.4 jar の依存関係もあります。

0 投票する
1 に答える
2185 参照

cookies - Jetty 6 -> 8 アップグレードでセキュア Cookie を設定する

私は何時間もこれを見つめてきましたが、明らかに何かが間違っているに違いありませんが、途方に暮れています...

jetty6 では、次のような Web アプリで安全な Cookie を設定できました (WAR の対応する $jetty_home/contexts/foo.xml コンテキスト ファイル内):

jetty 8.1.8.v20121106 では、それを行うためのパスは (コードで) 次のようになります。

だから、わかりました...私は次のようにWebAppのコンテキストXML構成でそれを行います:

しかし、jetty では次のエラーが発生します。

2014-02-13 14:20:38.113:WARN:oejx.XmlConfiguration:真の java.lang.NoSuchMethodException での構成エラー: クラス org.eclipse.jetty.server.session.AbstractSessionManager$2.setSecure(boolean) 2014-02-13 14:20:38.113:WARN:oejx.XmlConfiguration:真の java.lang.NoSuchMethodException での構成エラー: クラス org.eclipse.jetty.server.session.AbstractSessionManager$2.setSecure(boolean) 2014-02-13 14:20:38.114 :WARN:oejx.XmlConfiguration:真の java.lang.NoSuchMethodException での構成エラー: クラス org.eclipse.jetty.server.session.AbstractSessionManager$2.setSecure(boolean) 2014-02-13 14:20:38.114:WARN:oejx。 XmlConfiguration: true java.lang.NoSuchMethodException での構成エラー: クラス org.eclipse.jetty.server.session.AbstractSessionManager$2.setSecure(boolean) 2014-02-13 14:20:38.115:WARN:oejd.DeploymentManager:到達できませんノードの目標: java.lang を開始しました。NoSuchMethodException: クラス org.eclipse.jetty.server.session.AbstractSessionManager$2.setSecure(boolean) at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.set(XmlConfiguration.java:586) at org.eclipse.jetty.xml. org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration. java:397) org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.get(XmlConfiguration.java:669) で org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:397) で org.eclipse .jetty.xml.XmlConfiguration$JettyXmlConfiguration.get(XmlConfiguration.java:669) org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:397) で org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:350) で org.eclipse.jetty .xml.XmlConfiguration.configure(XmlConfiguration.java:303)

明らかに間違っていることを見た人はいますか?

0 投票する
0 に答える
174 参照

webserver - Jetty 8 と Jetty 9 によってメモリにロードされる数値クラスの大きな違い

Windows 7 マシンで jetty-distribution-8.1.5.v20120716 と jetty-distribution-9.1.2.v20140210 を実行しています。

そして、Jetty 9 では、特に Web アプリがデプロイされた後、メモリにロードされるクラスの数が Jetty 8 によってロードされるクラスの数よりもはるかに多いことがわかりました。

Web アプリケーションは、Spring 3.X と Hibernate 4.1.X を使用して開発されています。

以下は私が観察した数字です。これにより、最初のリクエストの応答が遅くなり、さらに、なぜこれが起こるのか知りたいだけです

Jetty 8 をダウンロードできない場合は、ここからダウンロードできます。

各ケースでロードされたクラスの数を示す JConsole の PFA イメージ

桟橋 8

ウェブアプリなし -- ~1630

ログイン後の Web アプリの場合 -- ~1632



桟橋 9

Web アプリなし -- ~2107 クラス

Web アプリでは、最初は ~8700 クラスで、Web アプリケーションにアクセスすると、最初のリクエストで約 9600 まで増加し、その後のリクエストではスパイクが見られません

Jetty 8 WebApp なし Jetty 8 WebApp なし

Jetty 8 と WebApp Jetty 8 と WebApp

Jetty 9 WebApp なし Jetty 9 WebApp なし

Jetty 9 と WebApp Jetty 9 と WebApp