問題タブ [undertow]

Undertow からリモート MYSQL サーバーに接続する次のコードがあります。

Undertow サーバーをしばらく実行すると、次のエラーが表示されます。

への接続を閉じる方法を知りたい

1. Mysql データソース
2. 繋がり
3. 声明

アプリケーションで頻繁に読み取り要求が発生します (1 秒あたり 10000 READ 要求)。

mysql.getConnection().close();交換ヘッダーを設定する直前に使用することを考えましたが、本番システムのコードを必ず変更する必要があります。

ありがとう！

次の行を myに追加して、2 つのハンドラー関数の呼び出しcompojure defroutesを使用します。clojure-paypal-ipn

POSTImmutant 内でリクエストを処理するにはどうすればよいですか?

Clojure 1.7-beta1 で Immutant 2.0 を使用し、Immutant 機能のデモを構築しています。PayPal IPN を使用しようとしていますが、cURL で直接投稿しても同じ結果が得られます。

:bodyCompojure から InputStreamのコンテンツを安全に取得するにはどうすればよいですか?

背景については、関連するが異なる質問を参照してください。

Friend を使用してリングルートを認証しようとしていますが、httpリクエスト (Java ) からcompojure handler/site読み取ろうとすると、閉じられます::bodyPOSTInputStream

ハンドラーを削除すると、問題はなくなります。すべてのリクエストをキャプチャして保存するグラウンドホッグと呼ばれる解決策を見つけました。私が使用しているライブラリは、clojure-paypal-ipnもともとresetstream で呼び出されていましたUndertowが、 (または実際には他のいくつかの Java/Clojure サーバー) でサポートされていないため、回避しました。

これは、compojure の作成者である weavejester との関連するディスカッションです。

ここに私のコードのいくつかのスニペットがあります:

payment.cljそして、これが（paypal-dataそして今paypal-errorすぐpprint入力する）の根性です：

ワイルドフライでは、数分ごとに巨大なゴミが生成されます。フル GC はメモリを再利用できますが、作成されるオブジェクト数の増加によりヒープが占有されるため、フル GC が頻繁に発生します。この問題は、60 ユーザーの Jmeter 負荷テストで再現できます。これは、Jboss 7.1.1Final には当てはまりませんでした。

ヒープダンプを分析した後、巨大な文字配列が作成され、マイナー GC によってガベージ コレクションされません。char 配列の着信参照は、io.undertow.servlet.spec.HttpServletRequestImpl への有効な参照があることを示唆しています。ただし、フル gc はメモリを回復できます。io.undertow.servlet.spec.HttpServletRequestImpl の属性がマイナー gc によって gced されない理由がわかりません。

「org.apache.struts.tiles.ComponentContext」は、io.undertow.servlet.spec.HttpServletRequestImpl によって属性 Map に保持されます。org.apache.struts.tiles.ComponentContext には大きな char 配列が含まれています。引き波に問題があると思われます。
添付の Eclipse MAT から取得した画像 https://www.dropbox.com/sh/qgsitzb7x27j8kc/AABoQwR1qPwTPiDtO6B0_Pm7a?dl=0

We have a project running on Undertow & SpringBoot and are trying to add File Uploads. The first attempts were successful, the Files have been bound to the appropriate Beans by using the StandardServletMultipartResolver and configuring it using the application.properties. However, we ran into terrible difficulties when it came to Error Handling. We found a "solution" by configuring the standard resolver to 100MB and using CommonsMultipartResolver. We then added a filter like this

Requestwrapper:

The @Controller-method then checks for oversized Files and adds the result to the BindingResult, which works great, except for the fact that the files are not bound to the bean. It turns out that the CommonsMultipartResolver, when trying to parse the request, throws a MalformedStreamException in ItemInputStream.makeAvailable(), which always returns the Message String ended unexpectedly.

So we went back to using the StandardServletMultipartResolver, and were able to catch the RuntimeExceptionit throws just fine, however it delivers absolutely no form data when even one file exceeds its size boundaries.

We are absolutely stumped as it is no matter if the Resolver works lazily or not. If anyone has any further ideas how to resolve this matter, be welcome to suggest answers =)

Further Code for reference:

Extract from WebAppInitializer

Extract from Controller:

processUpload() so far has no functionality, which is why I'm not including it here.

Extract from Form-Backing Bean:

This is, as stated, not the entire code, but the necessary code for this particular problem. The Exception thrown when uploading oversized files is either:

or the mentioned FileUploadBase.FileSizeLimitExceedeException

And last but not least, an extract of the form-page

If you followed the problems down here, you should have realized that we already tried several possible solutions, most being from here. Right now, the Filter catches RuntimeException and checks for IOException as cause, also, the sizes are no longer set within the application.properties

Any help or suggestions at all would be very much appreciated.

More Information

So, I debugged the StandardServletMultipartResolver and found that it uses the ISO-8859-1-charset for its parsing. This does produce the desired effects, even though the pages are UTF-8 encoded and the request object also hast UTF-8-Charset. I have been trying to force the ISO-Charset with a Filter like so

but, for some reason, the CommonsMultipartResolver finds a UTF-8 Encoded request object, so either this encoding does not work, or I have made another mistake I don't see.

I have also tried to find the exact moment of the thrown Exception, to maybe extend the class myself and make sure the already resolved form-data is kept, so far to no avail.

Even more Information

As suggested by another thread here, I tried to force the ISO-8859-1 charset on the request. At first, this completely bypassed the CommonsMultipartResolver and messed up my text, now it filters to the correct resolver, but this one still states that there are no files within the multipart data. Just for reference, the Filterclass I used:

Made a Bean from it and changed name of multipartResolver()-Bean to filterMultipartResolver()

HTTPServer と REST Handler の両方を実行しようとしています。一度に 1 つのみが機能し、両方を同時に機能させることはできません。HTMLページとAPIも提供する必要があります。

これが私のコードです。

Apache ベンチマークを使用して 100K リクエスト 20K 同時ユーザー:

以下は Undertow (バージョン 1.2.6 + xnio-api 3.3.1) PingServer です。

必要な Linux カーネル ソケットと sysctl によるスレッド設定はすべて完了しています。これが、20,000 ユーザーの最初の 90,000 リクエストを問題なく実行できる理由です。