[Java] The Future of JavaFX and Other Java Client Roadmap Updates

原文はこちら。
https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

JDK 11以降、OracleはJavaFXをJDKから分離して、独立したモジュールとして利用できるようにすることで、JavaFXの採用を容易にすることにしています。これらの変更により、新しいコントリビュータ-がOpenJFXコミュニティに参加する方法が明確になりました。一方、オラクルの顧客は、Oracle JDK 8でJavaFXの継続的な商用サポートを少なくとも2022年まで享受することができます。

JavaFXは、JavaOne 2007でお披露目されました。すぐに、スクリプティングおよびクロスプラットフォームでのハードウェアアクセラレーションによるUI機能について、Adobe FlexやMicrosoft Silverlightと比較されました。この技術は2011年に完全にオープンソース化され、1年後にOracle JDKのダウンロードに加わりました。オラクルのスチュワードシップの下、JavaFXはOpenJDKコミュニティで進化を続け、クロスプラットフォームのデスクトップアプリケーションツールキットとして熱烈な支持者を引きつけています。

マルチメディア、Web、およびビジュアライゼーション技術を融合した特定の市場向けに、独自のデスクトップアプリケーションとソリューションを制作する開発者とISVの間にJavaFXの支持者がいらっしゃいます。開発者が利用できる多数のオープンソースライブラリ、フレームワーク、ツールがあります。
20 JavaFX real-world applications
https://jaxenter.com/20-javafx-real-world-applications-123653.html
Awesome JavaFX
https://github.com/mhrimaz/AwesomeJavaFX/blob/master/README.md
Java Platform Module SystemをJava SE 9から導入したことで、JavaFXをJDKから切り離して別のダウンロードとして利用できるようになりました。これにより、JavaFXを使用する開発者は、より簡単にフレームワークの自由度と柔軟性を得ることができます。
More community participation in JavaFX
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/021401.html
さらに、OpenJDKのリリースサイクルの高速化に注力しているため、JavaFXは、OracleやOpenJFXコミュニティからの貢献によるペースで前進できる必要があります。
Faster and Easier Use and Redistribution of Java SE
https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se
https://orablogs-jp.blogspot.jp/2017/09/faster-and-easier-use-and.html
OracleはJava 11(18.9 LTS)からJavaFXをJDKから切り離して別のダウンロードとして利用できるようにする予定です。

数週間前、Java 8のパブリック・アップデートの拡張を発表し、その中で、個人(non-corporate)利用向けに、少なくとも2019年1月から2020年まで延長する、としています。
Extension of Oracle Java SE 8 Public Updates and Java Web Start support
https://blogs.oracle.com/java-platform-group/extension-of-oracle-java-se-8-public-updates-and-java-web-start-support
https://orablogs-jp.blogspot.jp/2018/01/extension-of-oracle-java-se-8-public.html
より詳細な情報は以下のホワイトペーパーでご覧ください。
Java Client Roadmap Update
http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf
また、Java 11(18.9 LTS)には含まれない、Java SE 8のアプレットとWeb Startのサポートに関する追加情報も提供しています。

最後に、JavaFXのロードマップに関する詳細情報があります、この中には、少なくとも2022年まで、Oracle JDK 8のJavaFXを出荷およびサポートをOracleが予定していることも含まれています。

OpenJFXに興味のある開発者は、メーリングリストに登録してください。
openjfx-dev -- Technical discussion related to the OpenJFX Project
http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev

[Linux] Announcing Oracle Linux 7 Update 5 Developer Preview

原文はこちら。
https://blogs.oracle.com/linux/announcing-oracle-linux-7-update-5-developer-preview

Oracle Linuxを開発用のディストリビューションとするという継続する目的の一環として、Oracle Linux Update 5開発者プレビューを発表できることをOracleはうれしく思っています。

Oracle Linux 7 Update 5開発者プレビューには以下のカーネルパッケージが含まれています。
  • kernel-uek-4.1.12-112.14.15.el7uek
Unbreakable Enterprise Kernel Release 4 Update 6がデフォルトカーネルです。
  • kernel-3.10.0-830.el7
最新のRed Hat Compatible Kernel (RHCK)も同梱しています。

To get started with Oracle Linux 7 Update 5開発者プレビューを試すには、ISOイメージで単純にフレッシュインストールしてください。Oracle Technology Networkでダウンロードできます。
Developer Preview for Oracle Linux 7
http://www.oracle.com/technetwork/server-storage/linux/downloads/linux-beta-4409163.html
もしくは、Oracle Linux yumサーバーやUnbreakable Enterprise Linux (ULN)のOracle Linux 7 Update 5用開発者プレビューチャネルを使って、既存のOracle Linux 7からアップグレードすることもできます。
Oracle Linux Yum Server
http://yum.oracle.com/
Unbreakable Enterprise Network (ULN)
https://linux.oracle.com/
# vi /etc/yum.repos.d/public-yum-ol7.repo

[ol7_u5_developer]
name=Oracle Linux $releasever Update 5 installation media copy ($basearch)
baseurl=http://yum.oracle.com/repo/OracleLinux/OL7/5/developer/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1

[ol7_u5_developer_optional]
name=Oracle Linux $releasever Update 5 optional packages ($basearch)
baseurl=http://yum.oracle.com/repo/OracleLinux/OL7/optional/developer/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1 
yumチャネル設定を変更し、Oracle Linux 7 Update 5開発者プレビューチャネルを有効化した上で、アップグレードします。
# yum update
アップグレードが完了したら、システムを再起動しましょう。これでOracle Linux 7 Update 5開発者プレビューが実行されます。
# cat /etc/oracle-release
Oracle Linux Server release 7.5

# uname -a
Linux honsu-ol7-vm1 4.1.12-112.14.15.el7uek.x86_64 #2 SMP Thu Feb 8 09:58:19 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
このリリースは開発およびテスト目的のためにのみ提供されているもので、Oracle Linux Supportの範囲外です。Oracleはこのプレビューリリースの本番環境での利用は推奨しません。

ご質問があれば、Oracle Linux CommunityのOracle Linux and UEK Previewスペースをおたずねください。
Oracle Developer Community > Linux > Oracle Linux and UEK Preview
https://community.oracle.com/community/server_&_storage_systems/linux/oracle_linux_and_uek_preview
Oracle Developer Community > Linux
https://community.oracle.com/community/server_&_storage_systems/linux

[Cloud] Introducing Email Delivery on Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/introducing-email-delivery-on-oracle-cloud-infrastructure

このエントリはSarah Galler(Principal Product Manager, Oracle Cloud Infrastructure)が寄稿しました。

Oracle Cloud InfrastructureプラットフォームでEmail Delivery(電子メール配信)が可能になりました。簡単に言えば、Email Deliveryを利用すれば、顧客のアプリケーションが電子メールを送信し、より高い成功率で意図したオーディエンスに到達できるようになります。Email Deliveryは、Oracle Dynの優れたEmail Deliveryサービスをベースに構築され、 U.S. Westリージョン(アリゾナ州フェニックス)で利用可能です。
Oracle + Dyn
https://dyn.com/
Oracle + Dyn - Email Delivery Service
https://dyn.com/email/
どの地域のお客様も、Email Deliveryサービスを使用して電子メールを配信できます。他の地域も近日利用可能になる予定です。

電子メールの量が年々増加し続けているにもかかわらず、意図した相手の受信トレイに電子メールを送信することは、評判の高い送信者にとっても依然として大きな課題であり続けています。Oracle Cloud Infrastructure Email Deliveryを使用すると、信頼性、スケーラビリティ、使いやすさのために、その課題は指数関数的に簡単になります。10年以上にわたって、Oracle Dynは、業界で最もクリーンなクラウドベースのネットワークの1つを使用して、メール配信の課題を解決しました。クリーンなネットワークはよりよい評判につながり、結果として電子メール配信のより高い成功率に繋がります。

Email Deliveryは、ビジネス上重要な情報を顧客やユーザーに提供するために使用されるサービスです。これらのアクティビティには、購買領収書、パスワードリセット、welcomeメールなどのトランザクション通知が含まれます。結論として、Oracle Cloud Infrastructure Email Deliveryは、お客様に対してポジティブなエンド・ユーザー体験を提供します。

このリリースでは以下の機能を提供します。
  • SMTP(Simple Mail Transfer Protocol、電子メール送信のインターネット標準)経由の送信
  • Sender Policy Framework(SPF) - インターネットプロトコル(IP)が明示的にそのドメインに対し送信する権限を持っているかどうかをチェックすることで、電子メール受信者が電子メールのなりすましを検出できます。
  • Suppression List Management(抑制リスト管理) - 重大なバウンスや苦情のアドレスは自動的に抑制リストに追加され、コンソールまたはAPIを介して表示および管理できます。
Email Deliveryのサービス概要ビデオのリンクはこちら。


CAPEXやリソース、カスタムでのメール配信システム開発の複雑性を排除します。Oracle Cloud Infrastructure Email Deliveryがどのように今日の企業に役立つかについては、以下のページをご覧ください。
Enterprise DNS Service Features
https://cloud.oracle.com/en_US/edge
今後のエントリでは、特定のユースケースを掘り下げて、電子メール配信の設定と利点についてご紹介する予定です。

[WLS, Java, Database] Ensuring high level of performance with WebLogic JDBC

原文はこちら。
https://blogs.oracle.com/weblogicserver/ensuring-high-level-of-performance-with-weblogic-jdbc

原文はLaurent Goldsztejnによるものですが、Joseph Weinsteinが追加情報やコードサンプルを追加しています。
このエントリでは、WebLogic JDBCで高パフォーマンスを保証するためのベストプラクティスを紹介します。

Use WebLogic DataSources for connection pooling of JDBC connections

    実際にDBMS接続を作成するのは高コストで遅いので、データソースを使用して接続を保持し再利用するべきです。プールされた接続を使用する理想的なモードは、できるだけ迅速かつ短時間で使用し、必要なときにそれらを取得し、できるだけ早くそれらを閉じる(プールに戻す)ことです。これにより並行性が最大化されます。
    connection(接続)がメソッドレベルのオブジェクトであり、アプリケーションスレッド間で共有されず、アプリケーションコードの終了パスに関係なくクローズされることが重要です。そうしないと、プールから接続がリークし、すべての接続が取り出されて放棄されてしまいます。
    このエントリのベストプラクティスのコードサンプルを見てください。 WebLogic Datasourcesとアプリケーションやその他のWebLogic APIの長期的な強化と統合により、UCPやサードパーティのオプションに優先して選択できます。

    Use Oracle JDBC thin driver (Type 4) rather than OCI driver (Type 2)

      Oracle JDBC Thinドライバは、軽量(インストールと管理が容易)、プラットフォーム非依存(Javaで記述)、JDBC OCI(Oracle Call Interface)ドライバよりもわずかに高いパフォーマンスを提供します。Thinドライバは、クライアントサイドで追加ソフトウェアを必要としません。Oracle JDBCのFAQでは、Thinドライバのパフォーマンス上の利点が一貫していないこと、およびOCIドライバが一部のシナリオでより優れたパフォーマンスを提供できることも規定されています。WebLogicでOCIを使用すると、ネイティブ・ライブラリのバグによってWebLogic Server全体が停止する危険性があります。

      Use PreparedStatements objects rather than plain Statements 

        PreparedStatementsを使うと、コンパイル済SQLクエリプランはDBMSキャッシュに保持され、一度解析された後に再利用されます。

        Use/configure the WebLogic Datasource’s statement cache size wisely.

          データソースはキャッシュでき、プールされた接続から作成されたPrepared/CallableStatementを透過的に再利用できます。プールのステートメント・キャッシュサイズ(デフォルトは10)でその数を決定します。これはいくらかのメモリを必要としますが、たいていの場合、パフォーマンスが向上します。ただし、least recently usedポリシーではキャッシュサイズをパージするので、例えばデータソースを使用するアプリケーションが通常30個の個別のPreparedStatementを作成する場合、次回のリクエストごとに新しいステートメントがキャッシュに置かれ、以前利用された10個のステートメントは放り出されるため、ステートメントの再利用はできません。コンソールでは、いくつかのステートメントキャッシュ統計を使用して、すべてのステートメントを処理するようにキャッシュのサイズを設定できるようにしますが、メモリーが大きな問題になる場合は、キャッシュサイズをゼロに設定する方が良い場合があります。

          Close all JDBC resources ASAP, inline, and for safety, verify so in a finally block

            これには、LOBs、ResultSets、Statements、およびConnectionsオブジェクトが含まれ、メモリを最大限に活用しながら、特定のDBMSサイドのリソースの問題を回避します。仕様により、Connection.close()はそこからすべてのサブオブジェクトを閉じる必要があります。また、close()のWebLogicバージョンは実際の接続をプールに戻しながらクローズすることを意図していますが、一部のオブジェクトは、別のドライバで異なる実装になっている可能性があり、その実装ではWebLogicにすべてを解放させないかもしれません。LOBsなどのJDBCオブジェクトが正しく閉じられないと、以下のエラーが発生する可能性があります。
            java.sql.SQLException: ORA-01000: maximum open cursors exceeded.
            StatementとResultSetsを明示的に速やかに閉じないと、カーソルが蓄積され、接続を閉じる前にデータベースが許容する最大数を超えることがあります。

            以下はWebLogic JDBCのベストプラクティスのコード例です。
            (訳注)今ならtry-with-resourcesで書くでしょうし、例外を握りつぶしているのがなんともあれですが、原文のままにしています。

            public void myTopLevelJDBCMethod() {
                // メソッドレベルのオブジェクトとして定義され、他のスレッドが使用できる場所にはアクセスできない、もしくは保持されない。
                Connection c = null; 
            
                // JDBC利用にあたっての事前準備
            
                // このメソッド(およびサブメソッド)のすべてのJDBC操作が実行されるtryブロック
                try {
                  // WLSデータソースから直接接続を取得
                  c = myDatasource.getConnection();
            
                  // Connectionをサブメソッドに渡すことができるが、サブメソッドはConnectionを保持してはいけない。
                  // メソッドの終了後にConnectionがオープン/実行可能であることをオブジェクトまたはオブジェクトのいずれかから期待されている
                  doMyJDBCSubTaskWith( c );
            
                  // JDBC操作が終了したらすみやかに接続をクローズする
                  c.close(); 
            
                  //finallyブロックでConnectionが取得された場合でもクローズされたことがわかる
                  c = null; 
            
                  // JDBCを必要としないものは残しておいてもかまわない。
                  // JDBCとは関係ないデータの後処理を行う前にConnectionをできるだけ早く閉じると、
                  // 同時実行性が大きく向上する
                } catch (Exception e) {
            
                  // catchブロックが必要であればここに必要なロジックを記述する。
                  // ただし、finallyブロックは必ず配置しておく
            
                } finally {
                   // 接続を閉じずにここまで到達したら、finallyブロックの最初に以下を必ず実行する
                  If (c != null) try {c.close();} catch (Exception ignore){}
            
                  // finallyブロックに記述したいコード
                }
            }
            

            Set The Datasource Shrink frequency to 0 for fastest connection availability

            現在の負荷が不十分(想定よりも小さい)である場合、データソースの不要な部分(最小容量より大きい)を閉じて実際の接続数を変更するように設定でき、さらに、必要に応じて再作成されますが、これにより新しい置き換えの接続が作成されている間、負荷の上昇中にアプリケーションの速度が低下します。縮小率をゼロに設定することにより、データソースはすべての利用可能な接続を無期限に準備完了状態に保ちます。これは、あまりにも多くのアイドルセッションがある場合、DBMSのトレードオフになることがあります。

            Set the datasource test frequency to something infrequent or zero

            データソースは、アプリケーション負荷とは無関係に、現在使用されていない接続、プール内でアイドル状態の接続、不良な接続の置き換えなどを定期的にテストするように設定できます。これには、アクティブでない場合に接続を切断する可能性のあるファイアウォールやDBMSに対し、接続がビジー状態に見えるようにするなど、いくつかの利点があります。ただし、これはWLSのオーバーヘッドであり、必要に応じて予約時に接続をテスト(test connections on reserve)していれば、ほとんどの場合不要です。

            Consider skipping the SQL-query connection test on reserve sometimes

            予約時に接続をテストする機能は常にONにしておくべきです。というのも、DBMSの健全性に関するActive GridLinkの情報があっても、個々の接続が悪くなる可能性があるため、取得しようとしている接続が良好な状態であることを確実にする唯一の方法は、データソースを取得しようとしている直前にデータソーステストを行うことです。しかし、毎回この接続テストを実施するにはコストが高すぎる場合があります。具体的には短時間のユーザーユースケースに対して余計な時間が加わってしまうか、DBMSに負担がかかりすぎるためです。このような場合で、アプリケーションが時には不正な接続を取得することが多少許容される場合、データソースオプション「アイドル・プール接続を信頼する秒数」(デフォルトは10秒)があります。これは、信頼する秒数の間にプール内の接続が正常にテストされた場合、またはアプリケーションによって以前に正常に使用された場合、その接続を信頼し、それをテストせずにリクエスタに渡します。負荷が重く、回転が速い環境では、テストの明示的なオーバーヘッドを安全かつ完全に回避できます。

            Consider making the test as lightweight as possible

            データソースの 'Test Table'(テスト対象の表名)パラメータが設定されている場合、プールはそのテーブルから 'select * from'を実行して接続をテストします。DUALはOracle Databaseの場合における伝統的な選択です。JDBCのisValid()呼び出しを使用するオプションもあります。これはドライバによっては高速な場合があります。例えばOracle Databaseのdbping()の場合、実際にユーザーレベルのDBMS機能を呼び出さずにto-DBMSのネット接続をチェックします。高速ではあるものの、接続上は良好であったとしても、まれにユーザーセッション機能が壊れていることがあります。XA接続の場合、より大きなトレードオフです。テストテーブルへのクエリはそれ自身のXAトランザクション内で実行されますが、これはより大きなオーバーヘッドですが、次のユーザーXAトランザクションが失敗するようなセッションステートの問題を見つけ、回避して動作する上で有用なことがあります。

            Consider enabling Pinned-to-Thread

            デフォルトで無効になっています。このオプションは、特定のWLSスレッドにプール接続を透過的に割り当てることで、パフォーマンスを向上させることができます。これにより、データソースにアクセスする際にスレッド間の競合がなくなります。ただしpinned-to-thread(スレッドに固定)を有効にすると接続プールの最大容量が無視されるため、このパラメータは、細心の注意を払って使用する必要があります。各スレッド(おそらく数百)は独自のconnectionを必要とし、取得します。そのため、そのプールを縮小することはできません。

            Match the Maximum Thread Constraint property with the maximum capacity of database connections

            このプロパティ(コンソールのEnvironment Work Managerを参照)は、同時実行可能なアプリケーション・スレッド/実行の最大数を設定します。アプリケーションが並列実行できる場合、このWebLogicの制限以外に制限がない場合には、データソースの最大容量はこのスレッド数と一致する必要があります。したがって、他のスレッドから接続が返されるまで、アプリケーションスレッドは空のプールで待機する必要はありません。

            WebLogic Serverでシステムパフォーマンスを向上するためのJDBCデータ・ソースおよび接続プールでの追加のパラメータ・チューニングについては、以下のドキュメントをご覧ください。
            Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1.3.0)
            データ・ソース接続プールのチューニング
            https://docs.oracle.com/cd/E92951_01/wls/JDBCA/ds_tuning.htm
            Oracle® Fusion Middleware Administering JDBC Data Sources for Oracle WebLogic Server 12c (12.2.1.3.0)
            Tuning Data Source Connection Pools
            https://docs.oracle.com/middleware/12213/wls/JDBCA/ds_tuning.htm
            アプリケーション固有の設計や構成については以下のドキュメントをご覧ください。
            Oracle® Fusion Middleware Oracle WebLogic Server JDBCアプリケーションの開発 12c (12.2.1.3.0)
            JDBCアプリケーションのパフォーマンス・チューニング
            https://docs.oracle.com/cd/E92951_01/wls/JDBCP/performance.htm
            Oracle® Fusion Middleware Developing JDBC Applications for Oracle WebLogic Server 12c (12.2.1.3.0)
            Performance Tuning Your JDBC Application
            https://docs.oracle.com/middleware/12213/wls/JDBCP/performance.htm

            [Linux] Oracle Linux 7 UEK5 (Linux kernel 4.14) sneak preview

            原文はこちら。
            https://blogs.oracle.com/wim/oracle-linux-7-uek5-linux-kernel-414-sneak-preview

            次期kernel-uekの最初のプレビューバージョンをリリースしました。これはアップストリームカーネル4.14 (latest stable -14) をベースにしています(UEK4はアップストリームカーネル4.1をベースにしています)。
            試してみたいという方は以下のyumリポジトリをOracle Linux 7ベースのシステムに追加するだけでOKです。OL7の環境をすぐに用意できない場合には、Oracle Cloudの無料アカウントにサインアップし、Oracle Linux 7インスタンスを迅速に作成できますので、その後は同様にyumリポジトリを追加してください。
            このプレビュー版カーネルは定期的にアップデートされますので、開発の成果の最新情報を得ることができます。ソースコードもあり、github/oracle にgitリポジトリをまもなくPushする予定です。
            利用する側が実施することは、以下のスニペットを/etc/yum.repos.d/public-yum-ol7.repoファイルに追加するだけです。
            [ol7_developer_UEKR5]
            name=Oracle Linux $releasever UEK5 Development Packages ($basearch)
            baseurl=http://yum.oracle.com/repo/OracleLinux/OL7/developer_UEKR5/$basearch/
            gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
            gpgcheck=1
            enabled=1
            
            その後、カーネルをアップグレードします。
            yum upgrade kernel-uek
            
            再起動しておしまいです。
            最新の dtrace を一緒に試したい場合は、同じリポジトリに入っていますので、以下のようにインストールしてください。
            yum install dtrace-utils
            
            dtrace -lを実行すると、5000個委譲のプローブがあることがわかることでしょう。

            [Linux] Announcing Software Collections 3.0

            原文はこちら。
            https://blogs.oracle.com/linux/announcing-software-collections-30

            Unbreakable Linux NetworkおよびOracle Linux yumサーバーへのSoftware Collections 3.0のリリースしたことを発表しました。
            Unbreakable Linux Network
            https://linux.oracle.com/
            Oracle Linux yum server
            http://yum.oracle.com/
            Software Collectionsは、主に、Perl、PHP、Pythonなどのソフトウェアコンポーネントの最新機能にアクセスする必要がある開発環境向けです。これらの環境では、これらのコンポーネントのバージョンに依存するシステムプロセスの中断を最小限に抑える必要があります。Software Collectionsライブラリを使用すると、同じソフトウェアの複数のバージョンをシステムに同時にインストールして使用することができます。その際プロセスを中断する必要はありません。
            Software collectionsライブラリユーティリティ(scl)を使用して、インストール済みのSoftware collectionsから開発者ツールを実行します。sclユーティリティは、インストール済みの同じソフトウェアユーティリティの他のバージョンの実行の影響を受けないようにします。

            New Software Collections for Oracle Linux 7

            以下のコレクションがSoftware Collections for Oracle Linux 7に追加されました。
            • devtoolset-7
            • rh-maven35
            • rh-nginx112
            • rh-nodejs8
            • rh-php71
            Oracle Linux 7をご利用の方はOracle Linux 7ドキュメントライブラリのSoftware Collection Library 3.0 for Oracle Linux 7のリリースノートで詳細をご確認ください。
            Software Collection Library 3.0 for Oracle® Linux Release Notes
            https://docs.oracle.com/cd/E52668_01/E59096/html/index.html
            Oracle Linux 7 documentation library
            https://docs.oracle.com/cd/E52668_01/index.html

            New Software Collections for Oracle Linux 6

            Oracle Linux 6のSoftware Collectionsに以下のコレクションが追加されました。
            • devtoolset-7
            • rh-python36
            Oracle Linux 6をご利用の方は、Oracle Linux 6ドキュメントライブラリのSoftware Collection Library 3.0 for Oracle Linux 6のリリースノートで詳細をご確認ください。
            Software Collection Library 3.0 for Oracle Linux 6 Release Notes
            https://docs.oracle.com/cd/E37670_01/E59096/html/index.html
            Oracle Linux 6 documentation library
            https://docs.oracle.com/cd/E37670_01/index.html

            Support

            Software CollectionsのサポートはOracle Linux Premier Support契約に含まれており、サブスクリプション契約されているお客様は追加コストなくご利用いただけます。
            有償サポートをご利用でない場合には、Oracle Communityフォーラムでのピア・サポートをご利用いただけます。
            Oracle Developer Community Forum
            https://community.oracle.com

            [Linux] Using RDS with ipv6 Networks

            原文はこちら。
            https://blogs.oracle.com/linuxkernel/using-rds-with-ipv6-networks

            RDSとは、Oracleが開発し、Linuxカーネルに寄贈したオープンソースのReliable Datagram Socketsプロトコルです。カーネル開発者のKa-Cheong Poonが、RDSをipv6対応させるための彼の作業をまとめています。

            現在、RDSはIPv4アドレスを使用するピア間でしか動作できません。IPv6が世界中で普及しているので、IPv6アドレスを使用するピア間でRDSを動作させる必要性がますます高まっています。その要求に対応するため、Oracle Linux RDSをアップデートし、IPv6をサポートするようにました。この記事では、RDSを利用するC言語で書かれた既存のアプリケーションを、IPv6をサポートするように変更する方法について説明します。基本的なIPv6 APIについては、RFC 3493を参照してください。RFC 4291では、IPv6アドレス指定アーキテクチャについて説明しています。また、rds-toolsパッケージもアップデートして、IPv6をサポートするようにしました。いくつかの使用例もご紹介します。
            RDS Wire Specification 3.1
            https://oss.oracle.com/projects/rds/dist/documentation/rds-3.1-spec.htmlState of IPv6 Deployment 2017
            https://www.internetsociety.org/resources/doc/2017/state-of-ipv6-deployment-2017/Basic Socket Interface Extensions for IPv6
            https://tools.ietf.org/html/rfc3493IP Version 6 Addressing Architecture
            https://tools.ietf.org/html/rfc4291
            RDSのIPv6サポートは、アプリケーションに対する最小限の変更でIPv6をサポートするよう設計されています。前述のように、次の呼び出しはRDSソケットを作成します。
            int sd;
            sd = socket(AF_RDS, SOCK_SEQPACKET, 0);
            作成されたソケットは、IPv4またはIPv6アドレスを使用しピアとの通信に使用できます。これは、ソケットが作成時にアドレスファミリの指定が必要なTCPソケットとは少し異なります。では、いつこのRDSソケットをIPv6 RDSソケットに変更するのでしょうか?この説明の前に、アドレス処理の説明を簡単にするために、以下のような共用体を定義しましょう。
            union sockaddr_ip {
                struct sockaddr_in      addr4;
                struct sockaddr_in6     addr6;
            };
            この共用体は、IPv4アドレスまたはIPv6アドレスのいずれかを格納するために使用できます。アプリケーションがユーザーが提供するローカルアドレスでユーザーが提供するピアアドレスと通信する必要がある場合、次のコードを使って提供されたバッファーを解析できます。
            char *user_suuplied_laddr, *user_supplied_paddr;
            struct addrinfo *ainfo;
            union sockaddr_ip local_addr, peer_addr;
            socklen_t local_addrlen, peer_addrlen;
            
            if (getaddrinfo(user_supplied_laddr, NULL, NULL, &ainfo) != 0) {
                /* Error handling code */
            } else {
                /* Just use the first one returned. */
                local_addrlen = ainfo->ai_addrlen;
                memcpy(&local_addr, ainfo->ai_addr, local_addrlen);
                freeaddrinfo(ainfo);
                ...
            }
            if (getaddrinfo(user_supplied_paddr, NULL, NULL, &ainfo) != 0) {
                /* Error handling code */
            } else {
                /* Just use the first one returned. */
                peer_addrlen = ainfo->ai_addrlen;
                memcpy(&dst_addr, ainfo->ai_addr, peer_addrlen);
                freeaddrinfo(ainfo);
                ...
            }
            /* The following checks for address family mismatched.  Note that the
             * address family field of all socket address structures are at the same
             * position.  Hence we can use sin_family to do the check.
             */
            if (local_addr.addr4.sin_family != peer_addr.addr4.sin_family) {
                /* Error handling code */
            }
            getaddrinfo(3)関数は、IPv4とIPv6の両方のアドレスを認識し、正しい情報でアドレスを埋めます。

            ピアと通信する前に、まずRDSソケットをバインドする必要があります。これは以下のように行います。
            if (bind(sd, (struct sockaddr *)local_addr, local_addrlen) != 0) {
                /* Error handling code */
            }
            ユーザーがIPv4アドレスを指定した場合、RDSソケットはIPv4 RDSソケットになり、ユーザーがIPv6アドレスを提供した場合、RDSソケットはIPv6ソケットになります。したがって、RDSソケットのファミリはバインド時に決まります。また、RDSソケットは一度しかバインドできないことにご注意ください。(そのため) 2回目のbind()は失敗します。これは、一度RDSソケットのアドレスファミリを設定すると、変更できないことを意味します。また、RDSソケットは同じファミリのピアとしか通信できません。これは上記のアドレスファミリーのチェックで不一致になる理由です。

            (これで)アプリケーションは、以下のようにピアと対話できるようになりました。
            char *msg;
            size_t msg_len;
            
            if (sendto(sd, msg, msg_len, 0, (struct sockaddr *)peer_addr, peer_addrlen) < 0) {
                /* Error handling code */
            }
            アプリケーションが同じソケットを使い別のピアと通信することもできます。 新しいピアアドレスがバインドされたアドレスと同じファミリでなければならないことに注意してください。前述のように、getsockname()を使用してソケットにバインドされたアドレスを取得できます。
            union sockaddr_ip ipaddr;
            socklen_t addrlen;
            
            if (getsockname(sd, (struct sockaddr *)ipaddr, &addrlen) < 0) {
                /* Error handling code */
            }
            ソケットがまだバインドされていない場合、返されるアドレスファミリはAF_UNSPECです。これは、アドレスがバインド済みか否かの判断に使用できます。ソケットはIPv4アドレスまたはIPv6アドレスのいずれかにバインドできるため、ここではユニオンsockaddr_ip共用体の使用に注意してください。

            まとめると、IPv6アドレスを使用するようにRDSアプリケーションを変更するには、IPアドレスを格納するために使用されるソケットアドレス構造とそのソケットアドレス構造を格納するために使用するコードを変更する必要があります。 アドレス構造体を変更すると、他のソケット呼び出しはすべて以前とほぼ同じです。

            rds-tools package

            rds-toolsパッケージには、rds-info、rds-ping、rds-stressという3つのツールが含まれており、これらもIPv6をサポートするようにアップデートされています。以下はその使用例です。

            rds-ping

            ホストAでは
            [host-a]> ip addr show ib0
            9: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP qlen 4096
                link/infiniband 80:00:02:08:fe:80:00:00:00:00:00:00:00:02:c9:03:00:0a:79:fd brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
                inet6 2010:211::12/64 scope global
                   valid_lft forever preferred_lft forever
                inet6 fe80::202:c903:a:79fd/64 scope link
                   valid_lft forever preferred_lft forever
            そしてホストBでは
            [host-b]> ip addr show ib0
            6: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP qlen 4096
                link/infiniband 80:00:02:08:fe:80:00:00:00:00:00:00:00:02:c9:03:00:0a:75:a5 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
                inet6 2010:211::22/64 scope global
                   valid_lft forever preferred_lft forever
                inet6 fe80::202:c903:a:75a5/64 scope link
                   valid_lft forever preferred_lft forever
            であると仮定します。
            以下のように、rds-pingを使って両ホスト間のIPv6でのRDSの到達可能性をテストできます。
            [host-a]# rds-ping fe80::202:c903:a:75a5%ib0
               1: 160 usec
               2: 155 usec
               ...
            fe80::202:c903:a:75a5 はホストBのIPv6リンクローカルアドレスです。リンクローカルアドレスはインターフェイスに関連付ける必要があるため、アドレスの後に%ib0(またはこの場合は%9)を配置して、ib0を使用してそのリンクローカルアドレスに到達するように指定する必要があります。 ホストBからも可能です。
            [host-b]# rds-ping 2010:211::12
               1: 162 usec
               2: 153 usec
            ...
            この例では、ホストAのグローバルアドレスをテストしています。IPv6グローバルアドレスの場合インターフェースを指定する必要はありません。

            rds-info

            rds-infoのデフォルト出力には変更ありません。これは、下位互換性を保つためにIPv6接続情報がデフォルトで表示されないことを意味します。IPv6接続情報を表示するには、「-a」オプションを使用します。 このオプションで、IPv4とIPv6の両方の情報を表示します。rds-pingの例を引き続き使用することにしますが、ホストAで上記を行った後、rds-infoを使用してRDSの接続状態を確認できます
            [host-a]# /tmp/rds-info -Ina
            RDS IB Connections:
                        LocalAddr            RemoteAddr  Tos  SL         LocalDev        RemoteDev
                     2010:211::12          2010:211::22    0   0      fe80::2:c903:a:79fd      fe80::2:c903:a:75a5
                fe80::202:c903:a:79fd     fe80::202:c903:a:75a5    0   0      fe80::2:c903:a:79fd      fe80::2:c903:a:75a5
             
            RDS Connections:
                        LocalAddr            RemoteAddr  Tos   NextTX   NextRX Flgs
                     2010:211::12          2010:211::22    0    5    5 --C-
                fe80::202:c903:a:79fd     fe80::202:c903:a:75a5    0       11       11 --C-
            上図は、ホストAに2つのRDS接続があることを示しています(1つはホストAとBのグローバルアドレス間の接続、もう1つはホストAとBのリンクローカルアドレス間の接続)。InfiniBandインターフェイスを使用しているため、2つのIB接続もあります。IPv6情報のみが存在するため、"-a"オプションを指定しないと何も表示されません。

            rds-stress

            アドレスオプション "-s"と "-r"で、IPv6アドレスをとることができるようになりました。 以下は利用例です。
            [host-a]> rds-stress -r 2010:211::12
            waiting for incoming connection on 2010:211::12:4000
            accepted connection from 2010:211::22::41735
            negotiated options, tasks will start in 2 seconds
            Starting up....
              ...
            [host-b]> rds-stress -r 2010:211::22 -s 2010:211::12
            connecting to 2010:211::12:4000
            negotiated options, tasks will start in 2 seconds
            Starting up....
            ...
            アップデートされたrds-stressは新旧rds-stressのいずれとも通信できます。