問題タブ [nio]

iSeries ボックス (JDK 1.5) で実行されている一部の Java NIO コードで問題が発生しています。基本的に、コードはファイルをファイルのチャンク部分に分割して、別の小さなファイルに分割します。同じコードが他の iSeries ボックスでしばらくの間問題なく動作しています。コード スニペットは次のとおりです。

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

... 11以上

私はいくつかの調査を行いましたが、これまでの原因 (親ディレクトリーのファイル許可、メモリー不足、共有メモリー制御 QSHRMEMCTL のオフ、SAN の使用) はすべて失敗していることが判明しました。

誰でもこの特定の問題の経験がありますか?

ありがとう、ブラッド。

非同期接続でクライアント アプリを実装しようとしています。SocketChannelサーバーへの接続に失敗したオブジェクトを再利用できるかどうかを知りたいです。

これが選択ループの後、接続が失敗したため、ソケットが最終的に選択されます。そのチャネルで別の接続試行をキューに入れたいのですが、何もしていないようです。メソッドはchannel.isConnectionPending()常に true を返します (finishConnect を試みても)

これを取り除きSocketChannel、新しいものを作成する唯一の解決策はありますか?

この投稿によると、UDP はブロックしません。UDP に (ノンブロッキング) NIO API を使用する利点はありますか? それとも、より簡単な「従来の」io API を使用する必要がありますか?

高度にスケーラブルなSSLクライアントを作成することをどのように推奨しますか？

現在、SocketHTTP以外のSSLソケットを必要とするAppleAPNSサーバーに接続するためにプレーンを使用しています。NIOライブラリの使用を検討しましたが、が不足しておりSSLSocketChannel、優れたライブラリや、独自のライブラリを展開するためのスムーズなチュートリアルを見つけることができませんでした。

Tomcat でメッセージを送受信するために、リモート サーバーへの SocketChannel を作成しました。リモート コンピューターからメッセージを受信するために、タスク専用のスレッドを使用しました (このスレッドのみがソケットから読み取ります)。

SocketChannel でいくつかのバイトが受信されると (新しいデータのために非ブロッキング モードで SocketChannel をポーリングし続けます)、最初に 4 バイトを読み取って次のメッセージの長さを取得し、次に SocketChannel から x バイトを割り当てて読み取ります。次に、デコードしてメッセージに再構築します。

以下は、受信スレッドのコードです。

SocketChannel から受信した最初のバイトは問題なく、メッセージのデコードに成功しました。しかし、次に SocketChannel から読み取ると、ソケットが約 100 バイト先にスキップしたため、間違ったバイトが読み取られて長さとして解釈され、すべてが破損しました。

コードの何が問題になっていますか? SocketChannel から読み取っているスレッドは他にありません。

Channels.newChannel(is) を使用して InputStream からチャネルを作成すると、Java 標準ライブラリは次のような ReadableByteChannelImpl を返します。

ご覧のとおり、 read(ByteBuffer dst) を初めて呼び出すとブロックされ、再度ブロックされることはありません。見る：

そのような奇妙な行動の背後にある理由は何ですか?

また、実際にこのチャネルを本当に中断可能にせずに AbstractInterruptibleChannel を拡張する動機は何ですか?

JDK7 のこれらすべての新しいファイル I/O クラスについて、私は少し混乱しています。

たとえば、 があり、Pathそれが表すファイルの名前を変更したいとします。Path再び aが予想される場合、新しい名前を指定するにはどうすればよいですか?

注: なぜJDK7が必要なのですか? シンボリックリンクの扱い！

問題は、実行時に名前と場所がわかっているファイルを使用する必要があることです。したがって、私が必要としているのは、古い名前パスの新しい名前パスを作成するための安全な方法 (例外的な副作用なし) です。

使用しているライブラリにいくつかの変更を加えているところです。メモリ使用量を減らすために、ライブラリは一時データをメモリに保持する代わりにディスクに書き込みます。ただし、私の使用シナリオでは、メモリに保持する方が効率的です。また、一時ファイルの名前が一定であり、異なるスレッドで同時に実行できないため、並行性の問題もあります (スレッドが互いのデータを破損するため)。

したがって、代わりにすべてのデータをメモリに保持するようにライブラリを変更する必要があります。私は最初にライブラリを作成したことがないため、コードを大幅に変更することにあまり慣れていません。したがって、できるだけ少ないリファクタリングでこれを行いたいと思います。ディスクに書き込むコードは非常に単純です。以下は (やや簡略化された) 例です。

ブロックの読み取りは非常に似ています (つまり、RandomAccessFile から取得する FileChannel を使用します)。

ファイルではなくメモリ内の場所にマップする FileChannel の実装を使用できる場合、最も簡単な解決策のように感じます。FileChannel の map-method を使用して、ファイルをメモリ内の場所にマップできることを知っています。しかし、それは逆です。これにより、ファイルへの「メモリ API」が得られます。一部のメモリに対して FileChannel インターフェイスが必要です。これの利用可能な実装はありますか?

System.in で NIO を使用することは可能ですか?

どうにかして「stdin」を選択可能なチャネルとして扱いたいと思います。誰かがこれを行う方法を見つけましたか?

現在、非常に大きな double の配列を割り当てているアルゴリズムがあり、頻繁に更新および検索しています。配列のサイズは N^2/2 で、N はアルゴリズムが動作する行数です。また、アルゴリズムを取り巻くアプリケーションに関連する目的のために、全体のコピーを保持する必要があります。

もちろん、これにより、競合するヒープの制限があるため、アルゴリズムが処理できる行数に制限が課されます。この時点まで、アルゴリズムを使用している人々に -Xmx 設定を更新してより多くのスペースを割り当てるように依頼することから逃れましたが、それはうまくいきました。ただし、この配列をメモリに収まるよりも大きくする必要があるという本当の問題があります。

この大規模な配列の必要性を軽減し、その分野でいくつかの有望な結果を得るために、アルゴリズムを変更する計画が既にあります。ただし、これはプロセスの根本的な変更であり、現在のコードの高度に洗練された状態に到達するまでには、さらに多くの作業が必要になります。

そのため、新しいアルゴリズムを完成させながら、既存のアルゴリズムの寿命を延ばしたいと考えていました。つまり、膨大な double 配列の割り当てに関連するヒープ制限に取り組む必要がありました。

私の質問は、それに対処する最善の方法は何ですか? nio FileChannel と MappedByteBuffer を使用する必要がありますか、それともより良い方法がありますか。nio アプローチを使用する場合、同じサイズのメモリ内配列と比較して、どのようなパフォーマンス ヒットが予想されるでしょうか?

ありがとう