[Exa*, Virtualization] Running Mixed Physical and Virtual Exalogic Elastic Cloud Software Versions in an Exalogic Rack is now Supported

原文はこちら。
https://blogs.oracle.com/csoto/entry/running_mixed_physical_and_virtual

旧バージョンではサポートされていませんでしたが、EECS (Exalogic Elastic Cloud Software) 2.0.6では、Exalogicのラック半分を仮想環境、半分を物理環境のLinuxという、混在環境で構成することができるようになっています。
  • 物理環境と仮想環境を同じラックに混在できます。例えば、本番環境は物理構成で、テストおよび開発環境は仮想環境、といった構成を取ることができます。
  • Exalogic Controlはラックの仮想Compute Nodeを管理します。物理Compute Nodeは(Partition Keyを含めて)手作業で管理します。
  • 物理環境を全てハイブリッド環境に、ハイブリッド環境を全て仮想環境にすることもできます。
  • ラック上側のNode群、下側のNode群を物理、仮想環境に選択することができます。
ラックのCompute Nodeを分割(上半分もしくは下半分)しOracle Virtual Server(OVS Hypervisor)やOracle Linuxを実行する方法に関して、詳細は以下のMy Oracle SupportのNoteをご覧下さい。
Can We Have Mixed Physical And Virtual Exalogic Elastic Cloud Software Versions In A Exalogic Rack? (ドキュメントID 1536945.1)
https://support.oracle.com/rs?type=doc&id=1536945.1
[注意]
Solarisはまだ仮想・物理の混在構成をサポートしていません。

[Java] Tyrus 1.6

原文はこちら。
https://blogs.oracle.com/PavelBucek/entry/tyrus_1_6

すてきな機能やバグ修正を含むTyrus 1.6を今週リリースしたことを発表できうれしく思います。最も重要な点をご紹介しましょう。

What’s new?

まず大きなものとして、JDK Client Transportを追加しました。これまで、クライアント側でトランスポート層を処理するためだけにGrizzlyフレームワークを使用していましたが、このリリースで、JDK1.7ベースのトランスポートへ切り替えるオプションを提供します。主な利点は、jarファイルのサイズと個数が減った、ということです。デフォルトのトランスポートはまだGrizzlyベースゆえ、JDK 1.7 AIOを試したい場合は、明示的に有効にする必要があります。詳細はTyrusのマニュアルの、JDK7のクライアントの章をご覧下さい。この機能は、Tyrusチームの新メンバーであるPetr Janouchが実装しました。
Grizzly
https://grizzly.java.net/
8.9. JDK 7 client (Tyrus 1.6 User Guide)
https://tyrus.java.net/documentation/1.6/user-guide.html#d0e1280
もう一つの重要な機能は、サーバー再度リソースの利用状況を監視し、この情報をJMX beanで統計情報を公開する、というものです。現在利用可能な統計情報はほとんど送受信メッセージの件数や種類に関するものであったり、展開されているエンドポイントのリストや同時接続クライアント数を提供するといった、よりハイレベルなものです。この機能を使ってみたい場合は、TyrusユーザーガイドのJMX Monitoringの章に設定方法の詳細が記載されています。この機能もまたPetr Janouchがやってくれました。
8.10. JMX Monitoring (Tyrus 1.6 User Guide)
https://tyrus.java.net/documentation/1.6/user-guide.html#d0e1322
次は、JSR 356での問題に関連して変更した内容です。
Session.addMessageHandler(MessageHandler) cannot work with lambda expressions.
https://java.net/jira/browse/WEBSOCKET_SPEC-226
現在のSessionインターフェースでは、メッセージハンドラ登録時にLambda expressionを使うことができますが、期待したように動作しません。APIにより、実行時にgeneric typeの情報を取得するよう実装しなければなりませんが、これはJavaの場合、いつも利用可能とは限りません。ほとんどのユースケースは問題なく動作しますが、匿名クラス実装をLambda式で置き換える場合、型情報が失われてしまいます。Tyrusは現在提案された解決策を実装していますが、言及したメソッドにアクセスできるようにするには、SessionをTyrusSessionにキャストする必要があります。その後、メッセージハンドラ(java.lang.Class)とハンドラ自体の型を提供する必要があります。型情報が分離しているので、メッセージハンドラ・インスタンスから情報を取得する必要はありません。こうすることで任意の表現で動作するはずです。現在この修正をWebSocket APIに移植しているところです。詳細はしばしお待ちください。

最後の、最も小さな機能はWSADLです。何かわからなくても心配しないでください。誰も知りませんから :)。 WSADLはデプロイ対象のアプリケーションのXML Descriptor(現在のところ)で、(登録されたメッセージ·ハンドラのように他の情報は、クライアントがエンドポイントに接続する前に取得することが容易ではなく、セッションごとに変化する可能性があるという主にそういう理由で)現在のところ展開されているエンドポイントのセットだけを提供しています。 WSADLとはWebSocket Application Descriptor Languageの略で、RESTful WebサービスにとってのWADLやSOAP WebサービスにとってのWSDLのようなものです。この機能を試してみたい場合は、WSADL_SUPPORTを有効にし(もしくは以下のテストコードを参照)、デプロイしたTyrusアプリケーションでGET /contextPath/application.wsadlを発行してください。
Tyrus 1.6 API - WSADL_SUPPORT (Class TyrusWebSocketEngine)
https://tyrus.java.net/apidocs/1.6/org/glassfish/tyrus/core/TyrusWebSocketEngine.html#WSADL_SUPPORT
tyrus-project/tyrus (GitHub)
Wsadl - WebSocket application desciption language
https://github.com/tyrus-project/tyrus/blob/master/tests/e2e/non-deployable/src/test/java/org/glassfish/tyrus/test/e2e/non_deployable/WsadlTest.java

Complete list of changes

  • TYRUS-301 Custom String encoder is not used
  • TYRUS-305 Add support for multiple client container to TestContainer
  • TYRUS-311 Session timeout on client does not work when set in onOpen method
  • TYRUS-312 TyrusFuture.get(long,TimeUnit) does not honor Future.get(long,TimeUnit) contract
  • TYRUS-293 Automatic heartbeat PING
  • TYRUS-259 Should produce a warning during deployment when OnMessage#maxMessageSize is larger than the value of org.glassfish.tyrus.servlet.incoming-buffer-size
  • TYRUS-308 JDK Client transport – SSL support
  • TYRUS-309 JDK Client transport – Proxy support
  • TYRUS-318 Writer returned from BasicRemote.getSendWriter() throws NPE when flush is called more than once.
  • TYRUS-314 Create WADL-like descriptor per deployed app
  • TYRUS-317 Allow server configuration using WebSocketContainer or WebSocketAddOn
  • TYRUS-302 Java 8 Lambda
  • TYRUS-214 Expose monitoring API/statistics
  • TYRUS-299 Missing tyrus-container-grizzly-server in the release package WebSocket RI archive
  • TYRUS-233 Provide client transport based on plain JDK
  • TYRUS-310 When max idle timeout is reset to 0, every received message or sent ping or pong causes an empty task to be scheduled and executed

Links

疑問やコメント、Tyrusに関連することで聞きたいことがあれば、メーリングリスト users [at] tyrus.java.net に投稿するのが一番簡単です。

[Java] GlassFish/Java EE Community Open Forum Tomorrow!

原文はこちら。
https://blogs.oracle.com/theaquarium/entry/glassfish_java_ee_community_open

GlassFishの目標や将来についての質問がありますか?来るGlassFish4.0.1のリリースについてもう少し知りたいですか? Java EE 8やGlassFish 5のことが気になっていますか?そんなあなたに、質問して思いを伝える絶好の機会が明日あります!

C2B2のすてきな面々と、非常に有用なオンラインイベントをLondon GlassFish User Groupのために長い時間をかけて準備してきました。質問にはオンラインでリアルタイムに、"face-to-face"で回答します。C2B2のteve Millidgeがモデレータとして参加し、会話に参加します。このイベントが無料で誰でも参加できるっていいましたっけ?
このイベントは明日(5月30日、日本時間では今晩)開催ですので、できるだけ早くC2B2のウェブサイトから登録して下さい(登録ページには、イベントの詳細が記載されています)。イベント開始時間は16:30 BST/11:30 EST/8:30 PST(訳注:日本時間では5/31の0:30から)です。是非参加して下さいね。明日お話できるのを楽しみにしています。
GlassFish Community Q&A with Reza Rahman
http://info.c2b2.co.uk/glassfish-user-group-with-reza-rahman

[Java] JDK 7u60 Released

原文はこちら。
https://blogs.oracle.com/thejavatutorials/entry/jdk_7u60_released

JDK 7u60がリリースされています。最新のJDK 7はJava SE Downloadのページからどうぞ。
Java SE Downloads
http://www.oracle.com/technetwork/java/javase/downloads/index.html
このリリースには、Java Mission Control 5.3をはじめとするアップデートが含まれています。詳しくは、リリースノートをご覧下さい。
Java Mission Control 5.3
http://docs.oracle.com/javase/7/docs/technotes/guides/jmc/index.html
Update Release Notes - Java™ SE Development Kit 7, Update 60 (JDK 7u60)
http://www.oracle.com/technetwork/java/javase/7u60-relnotes-2200106.html
(訳注)
Java Mission Control 5.3のリリースノートはこちら。
Java Mission Control 5.3 Release Notes
http://www.oracle.com/technetwork/java/javase/jmc53-release-notes-2157171.html

[Java] Adding SSE support in Java EE 8

原文はこちら。
https://blogs.oracle.com/theaquarium/entry/sse_in_java_ee_8

SSE (Server-Sent Event) はHTTPを使ってクライアントへサーバーからの通知をするための標準のメカニズムです。
High Performance Browser Networking
Chapter 16. Server-Sent Events (SSE)
http://chimera.labs.oreilly.com/books/1230000000545/ch16.html
SSEはWebSocketとよく比較されることがあります。共にHTML5をサポートしておりサーバーに対しクライアントへ通知する手段を提供しているためなのですが、両者は異なるものです。SSE、WebSocketの長所・短所は以下のリンクをご覧下さい。
WebSockets vs. Server-Sent events/EventSource (stackoverflow.comより)
http://stackoverflow.com/questions/5195452/websockets-vs-server-sent-events-eventsource/5326159#5326159
SSEは一方向のPublish-Subscribeモデルのための効果的なソリューションを提供しているため、RESTクライアントにとってきわめて補完的なものです。つまり、RESTクライアントは「購読」でき、SSEベースの通知をRESTエンドポイントから取得することができます。実際のところ、Jersey(JAX-RSの参照実装)はずいぶん前からSSEをサポートしています(詳細はJerseyのドキュメントをご覧下さい)。
Jersey 2.9 User Guide - Chapter 14. Server-Sent Events (SSE) Support
https://jersey.java.net/documentation/latest/sse.html
SSEを直接Servlet APIから使いたいと思うケースもあるかと思います。SSE通知をServlet APIで送信するのは比較的簡単です。以下のリンクに、Servlet 3.1 APIベースのSSEのサンプルが2個ありますのでご覧下さい。
Server-Sent Events with Async Servlet By Example (Shing Wai Chan)
https://weblogs.java.net/blog/swchan2/archive/2014/05/21/server-sent-events-async-servlet-example
現在Java EE 8でのSSEのサポートを追加することを検討していますが、ここで質問があります。SSEのサポートを追加するにあたり、どのプラットフォームに追加すべきか、ということです。
  • Servlet API
  • WebSocket API
  • JAX-RS
  • 専用のSSE APIを用意する(つまり専用のJSRも)
[javaee-spec users] [jsr342-experts] Server-Sent Events in Java EE 8
https://java.net/projects/javaee-spec/lists/users/archive/2014-05/message/10
Santiago Pericas-Geertsen (JAX-RSの共同スペックリード)がその質問に関連する初期調査を実施しました。様々な選択肢への賛成意見やSantiagoの調査結果は以下のリンクからご覧戴けます。
Server-Sent Events (SSE) in Java EE 8
https://java.net/downloads/javaee-spec/SSE-in-EE8.pdf
現段階では、Java EEでSSEをサポートする上ではJAX-RSが良い選択肢のように思われます。この件は当然それぞれのJCP Expert Group内で議論されますが、あなたはどう思われますか?

[Database] Oracle Database In-Memory Launch - Featuring Larry Ellison - June 10 - Joint the live webcast!

原文はこちら。
https://blogs.oracle.com/emeapartnermanageability/entry/oracle_database_in_memory_launch

35年以上の間、Oracleはデータベースの進化を定義してきました。市場をリードする技術で、お客様は競合を出し抜き、競合を上回ってきました。まもなく、もっと高速になります。ライブローンチイベントと同時開催のWebcastで、Larry Ellisonがデータベースの将来を明らかにします。この戦略的なイベントをお客様に薦めてください!
Oracle Launch Event
The Future of the Database Begins Soon
http://www.oracle.com/us/dm/sev100306382-ww-ww-lw-wi1-ev-2202435.html

開催日時
(JST) 2014年6月11日(水) 2時から3時30分
(PDT) 2014年6月10日(火) 10時から11時30分
(CET) 2014年6月10日(火) 19時から20時30分
(GMT) 2014年6月10日(火) 18時から19時30分

[Java, JavaScript] Java Day Tokyo 2014

ロジ子のお披露目といいいますか、Coming Outといいますか。。。
2014年5月22日(木)に品川プリンスホテルのプリンスホールで開催された「Java Day Tokyo 2014」にて、「JavaScript Running on Java VM : Nashorn」のセッションを担当しました。
「なぜパートナートラックで中の人が喋っているんだ?」 というツッコミは無しでお願いします(どうしても知りたい方はお酒でも呑みながら、ということで)。
そのときのスライド(本名出てますけど・・・)をSlideshareにUpしました。激し目の言葉は柔らかい言葉に書き換えています。



この手のお話はあまり取り上げられることがなかったので、結構新鮮だったのではないかなーと思っていますが、いかがでしたでしょうか。
今後もまた機会があれば、皆様の前でお話することがあるかもしれません。そのときは生暖かく、ではなく、温かい目で見守ってやってください。どうぞよろしくお願いします。

(追記)
英語版も作ってみました。中身は日本語と同じです(当然ですね)。

[Linux] Unbreakable Enterprise Kernel Release 3 Quarterly Update 2 is now available

原文はこちら。
https://blogs.oracle.com/linux/entry/unbreakable_enterprise_kernel_release_32

Oracle Linux 6用のUnbreakable Enterprise Kernel Release 3 Quarterly Update 2 (UEK R3U2)のリリースを発表できうれしく思っています。これはUEK R3(Version 3.8.13-35)に対する第2四半期のアップデートで、ドライバのアップデートやバグやセキュリティ問題に対する修正を集積したものが含まれています。
今回のアップデートのトピックを挙げてみました。
  • Support for HP Generation 9サーバーのサポート。これには、HP Smart Arrayコントローラを使う際に性能を向上させるHP SSD Smart Pathのサポートを含みます。
  • Ethernet ControllersのIntel XL710ファミリーのサポート
  • Microsoft Hyper-VでゲストOSとして動作するOracle Linuxをサポートするための準仮想化(paravirtualization)ドライバのアップデート
  • DTraceプロファイルプロバイダのアップデート。これにはすべてのアクティブなCPUにおいて高い割り込みレベルで固定間隔で起動できる profile-n プローブが含まれます。 tick-n プローブと似ていますが、前者と異なり、こちらは1個のCPUに対し固定間隔で起動します。
  • 以下のような主要パートナーのデバイスドライバ(ストレージデバイスやネットワークカードなど)のアップデート。
    • Broadcom
    • Brocade
    • Cisco
    • Emulex
    • HP
    • Intel
    • Qlogic
詳細はリリースノートをご覧下さい。ソースコードはパブリックGitリポジトリからご利用戴けます。
Oracle® Linux Release Notes for Unbreakable Enterprise Kernel Release 3 Quarterly Update 2
https://oss.oracle.com/ol6/docs/RELEASE-NOTES-UEK3-QU2-en.html
linux-uek3-3.8 repository
https://oss.oracle.com/git/?p=linux-uek3-3.8.git;a=summary

[Database] More than one PDB in the same directory?

原文はこちら。
https://blogs.oracle.com/UPGRADE/entry/more_than_one_pdb_in

同じディレクトリにプラガブルデータベース(PDB)を複数個作成することはできますか?どのようなファイル名にすればよいのでしょうか。
各PDBのSYSTEM表領域がデフォルトでsystem01.dbfという名前であることを考えれば、この質問は易しいものではありません。
この質問は先週スイスで開催したワークショップの際にお客様からいただいたのですが、この質問に対する回答は簡単です。Royのおかげで昨日のシュツットガルトからの帰路、時速170kmで走る車内で試すことができました。

[Linux, VM, Cloud] Oracle Announces OpenStack Support for Oracle Linux and Oracle VM

原文はこちら。
https://blogs.oracle.com/virtualization/entry/oracle_announces_openstack_support_for
https://blogs.oracle.com/linux/entry/oracle_announces_openstack_support_for

本日Oracle LinuxとOracle VMでOpenStackをサポートすることを発表しました。このサポートはOracle LinuxおよびOracle VMのPremier Supportに含まれており、追加費用はかかりません。
既存のお客様はOpenStackをOracle LinuxやOracle VMでデプロイでき、ソフトウェアスタック全体でサポートを受けることができます。このサポートにはOracle Linuxに加え、OpenStackをインストールするベースOS、OpenStackソフトウェア、ハイパーバイザー、ゲストOSのサポートが含まれています。スタックの全コンポーネントを含むEnd-to-Endの完全なサポートはエンタープライズのお客様の主要な要求であり、そのため、Oracle Linux/Oracle VMのPremier Supportの一部として提供することにしています。

本日テクノロジープレビューをリリースしました。お客様やパートナー様がOracle VMとOracle LinuxでOpenStackをテストすることができます。このテクノロジープレビューは以下のページからダウンロードできます。
Public Yum Server - BETA Software
http://public-yum.oracle.com/beta
テクノロジープレビューにあわせ、Getting Startedガイドを用意し、OpenStackのセットアップ手順を辿っていけるようにしました。Getting Startedは以下のページからダウンロードできます。
Getting Started with Oracle VM, Oracle Linux and OpenStack Technology Preview
http://www.oracle.com/technetwork/server-storage/vm/ovm-linux-openstack-2202503.pdf
テクノロジープレビューとGetting Startedガイドでシンプルかつ簡単にOpenStackをデプロイする方法がわかるので、OpenStackで利用可能な機能を調べる手始めになることでしょう。テクノロジープレビューはOpenStackと統合したいベンダーにとっても有用です。

OpenStackが成熟し進化するにつれて、IT基盤の標準化に対する増大するニーズにかなうソリューションが提供されています。OpenStackを幅広く採用し、お客様はエンタープライズアプリケーションなどに幅広く活用されようとしています。我々の主要な目的の一つは、お客様がアプリケーションを信頼性の高い、サポート可能な方法でデプロイできるようコミュニティと協同し、OpenStackがエンタープライズアプリケーションの領域に使われるよう前進することをアシストすることにあります。
プレスリリースは以下のページからどうぞ。
Oracle Announces OpenStack Support for Oracle Linux and Oracle VM
http://www.oracle.com/us/corporate/press/2202480
Atlantaで開催されるOpenStackコンファレンスで、もっと詳しく説明できることをうれしく思います。D14ブースにいますので、皆様のお越しをお待ちしています。

[Big Data] Announcing: Big Data Lite VM 3.0

原文はこちら。
https://blogs.oracle.com/datawarehousing/entry/announcing_big_data_lite_vm

先週Big Data Lite VM 3.0がリリースされました。このVMには全スタックの最新のアップデートが含まれています。
  • Oracle Enterprise Linux 6.4
  • Oracle Database 12c Release 1 Enterprise Edition (12.1.0.1) with Oracle Advanced Analytics, Spatial & Graph, and more
  • Cloudera’s Distribution including Apache Hadoop (CDH 5.0)
  • Oracle Big Data Connectors 3.0
    • Oracle SQL Connector for HDFS 3.0.0
    • Oracle Loader for Hadoop 3.0.0
    • Oracle Data Integrator 12c
    • Oracle R Advanced Analytics for Hadoop 2.4.0
    • Oracle XQuery for Hadoop 3.0.0
  • Oracle NoSQL Database Enterprise Edition 12cR1 (3.0.5)
  • Oracle JDeveloper 11g
  • Oracle SQL Developer 4.0
  • Oracle Data Integrator 12cR1
  • Oracle R Distribution 3.0.1
ダウンロードはこれまでと同様OTNからどうぞ。
Oracle Big Data Lite Virtual Machine
http://www.oracle.com/technetwork/database/bigdata-appliance/oracle-bigdatalite-2104726.html

[Java] Getting Started With Raspberry Pi

原文はこちら。
https://blogs.oracle.com/java/entry/getting_started_with_raspberry_pi

Globalcodeの創設者であるVinicius SengerがシンプルなアプリケーションをRaspberry Piで開発する方法をご紹介します。このハングアウトは本日(2014/05/09)の以下の時間から開催します。
Get Started with Java Embedded and Raspberry Live Talk at Indonesia JUG
https://plus.google.com/u/0/events/cs0mnpdqcgrr6shuc4kaqoe2lmc
    開始時間:2014/05/09の
    • サンパウロ(ブラジル):8時
    • ジャカルタ(インドネシア):18時
    • ロンドン(GMT):11時
    • チェンマイ(インド):16時30分
    • 東京(日本):20時
    • モスクワ(ロシア):15時
IoT Developer Challengeの締め切りはまもなくです。IoT Developer Challengeにエントリするためには、動画とプロジェクトのコードを5月30日までにお送り下さい。要件はJava Embeddedと基板やデバイス、IoTテクノロジーを使うことです。
IoT Developer Challenge
https://www.java.net/challenge
優勝チーム(3チーム)にはJavaOne 2014への参加チケット(応募者およびチームから2名)が当たりますのでお見逃しなく。認知度向上の絶好の機会です。

無料のチュートリアル、サンプルコード、コーチングやフォーラムでのサポートをIoT Developer ChallengeのWebページからご利用いただけます。リマインダやニュースを受けとりたい場合には、このWebページでニュースを購読してください。

[WLS] Diagnosing Intermittent Authentication Failures and User Lock-Outs in Oracle WebLogic

原文はこちら。
http://www.oracle.com/technetwork/articles/idm/mishra-wls-auth-2157543.html

WebLogic Serverでのログイン失敗を利用可能なデバッグフラグやログファイルを使って診断する方法をご紹介します。

Introduction

Oracle WebLogic Serverでの認証は複数の理由で失敗することがあります。失敗は通常一貫している(つまり常に発生する)場合、WebLogic Server内で認証がどのように行われているかを知っていれば、デバッグして修正することは簡単ですが、障害が偶に発生する場合はことは少々ややこしくなります。この記事では、特にLDAPのような外部システムを使うようWeblogic Serverを構成している場合、断続的な認証失敗を調べるために、どのログファイルを確認すべきか、有効化すべきデバッグオプションを探っています。また、こうした断続的な認証の失敗が原因で発生する、ユーザーアカウントのソフトロックのシナリオ、ソフトロックの確認方法、解除方法ついても説明します。
この記事は、Oracle Identity Manager(OIM)のAPIがWebLogicでの断続的な認証失敗のために断続的に失敗しはじめるという、最近のお客様の事象を背景にしています。読者のみなさんが、WebLogicセキュリティの概念と認証メカニズムをよく理解していることを前提としています。この記事で使うWebLogic Serverのバージョンは10.3.6です。

Understanding Authentication Flow in WebLogic

WebLogic Serverは、認証プロバイダを使って指定された資格情報が正しいことを証明します。WebLogicセキュリティフレームワークは、セキュリティレルムとして複数の認証プロバイダをサポートします。これらの認証プロバイダを構成(各プロバイダのJAAS制御フラグ属性)方法によっては、認証プロセスの全体的な結果に影響を与えることがあります。以下にJAAS制御フラグ属性値と、この値が認証プロセス全体をどのように制御するのかをまとめました(詳細は参考文献のセクションを参照ください)​​。
  • REQUIRED: 認証プロバイダは常に呼び出され、ユーザは常に認証テストを通過する必要があります。認証が成功しても失敗しても、認証はプロバイダのリストの下方に進みます。
  • REQUISITE: ユーザはこの認証プロバイダの認証テストを通過する必要があります。ユーザがこの認証プロバイダの認証テストを通過した場合、以降の認証プロバイダは実行されますが、(JAAS の [制御フラグ] 属性が [REQUIRED] に設定されている認証プロバイダを除いて) 失敗してもかまいません。
  • SUFFICIENT: ユーザはこの認証プロバイダの認証テストを通過する必要はありません。認証が成功した場合、以降の認証プロバイダは実行されません。認証が失敗した場合、認証はプロバイダのリストの下方に進みます。
  • OPTIONAL: ユーザはこの認証プロバイダの認証テストを通過することも失敗することもできます。ただし、セキュリティ レルムでコンフィグレーションされているすべての認証プロバイダで JAAS の [制御フラグ] 属性が [OPTIONAL] に設定されている場合、ユーザはコンフィグレーション済みプロバイダのいずれかの認証テストを通過する必要があります。
[REQUIRED]制御フラグの説明が示すように、このフラグを使用する認証プロバイダは認証をパスしなければなりません。もしくは、提供された資格情報が正しかった場合でも、エンドユーザ認証が失敗することがあります。これには、ネットワークの問題、認証プロバイダがやりとりする外部システム(例えばLDAP)の予期しない動作などが含まれます。

Turn On Security Debugging To See What's Going On

ログイン失敗を確認して最初にやるべきことは、WebLogic Servverのセキュリティデバッグを、リクエストが到着する可能性がある全てのサーバーでオンにすることです。リクエストが到着する可能性がある全てのサーバー、ロードバランサやt3のURL (t3://host1:port1,host2:port2) にある全てのサーバーに対して設定する必要があります。この設定は、サーバごとに固有です。セキュリティデバッグをオンにするには、以下の設定をする必要があります。
  1. [サーバー] > [サーバーインスタンス] > [デバッグ]へ移動
  2. WebLogic > Security > atn > DebugSecurityAtn のチェックボックスをクリック
  3. [有効化]ボタンをクリック
この変更はサーバーの再起動を必要としません。このフラグをONにすると、WebLogic Serverはデバッグ情報をサーバーログファイルに出力し始めます。以下はログイン成功時のログ出力例です。ここでセキュリティレルムをDefaultAuthenticatorで構成しています。
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
<1389453044555> <BEA-000000> 
<com.bea.common.security.internal.service.CallbackHandlerWrapper.handle got username from 
callbacks[0], UserName=weblogic> 
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
 ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
  <1389453044555> <BEA-000000> <LDAP Atn Login username: weblogic> 
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
 ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
  <1389453044555> <BEA-000000> <authenticate user:weblogic> 
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
 ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
  <1389453044555> <BEA-000000> <getConnection return conn:LDAPConnection 
  { ldapVersion:2 bindDN:""}> 
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
 ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
  <1389453044555> <BEA-000000> <getDNForUser search
  ("ou=people,ou=myrealm,dc=WLS_A",
   "(&(uid=weblogic)(objectclass=person))", base DN & below)> 
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
 ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
  <1389453044556> <BEA-000000> <DN for user weblogic: uid=weblogic,
  ou=people,ou=myrealm,dc=WLS_A> 
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
 ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
  <1389453044556> <BEA-000000> <returnConnection conn:LDAPConnection 
  { ldapVersion:2 bindDN:""}> 
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
 ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
  <1389453044556> <BEA-000000> <authenticate user:weblogicwith DN:uid=weblogic,
  ou=people,ou=myrealm,dc=WLS_A> 
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
 ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
  <1389453044556> <BEA-000000> <getConnection return conn:LDAPConnection 
  { ldapVersion:2 bindDN:""}> 
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
 ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
  <1389453044556> <BEA-000000> <authentication succeeded> 
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
 ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
  <1389453044556> <BEA-000000> <returnConnection conn:LDAPConnection 
  { ldapVersion:2 bindDN:""}> 
####<Jan 11, 2014 8:40:44 PM IST> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
 ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <>
  <1389453044556> <BEA-000000> <LDAP Atn Authenticated User weblogic>
Below is a sample output for a failed login where the security realm configured with an LDAP authenticator, and failure happened because of an LDAP connection issue:
####<Jun 5, 2013 11:07:25 PM PDT> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> 
<[ACTIVE] ExecuteThread: '2' for queue:  'weblogic.kernel.Default (self-tuning)'> 
<<WLS Kernel>> <> <5b0dc9d8a952b6d1:-1eccb494:13f1505b73b:-8000-000000000001c5b1> 
<1370498845643> <BEA-000000> 
<new LDAP connection to host  SHAIMISH-LAP port 3061 use local connection is false> 
 . 
 ####<Jun 5, 2013 11:07:25 PM PDT> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> 
 <[ACTIVE] ExecuteThread: '2' for queue:  'weblogic.kernel.Default (self-tuning)'> 
 <<WLS Kernel>> <> <5b0dc9d8a952b6d1:-1eccb494:13f1505b73b:-8000-000000000001c5b1> 
 <1370498845644> <BEA-000000> 
 <created new LDAP connection LDAPConnection {  ldapVersion:2 bindDN:""}> 
 . 
 ####<Jun 5, 2013 11:07:25 PM PDT> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> 
 <[ACTIVE] ExecuteThread: '2' for queue:  'weblogic.kernel.Default (self-tuning)'> 
 <<WLS Kernel>> <> <5b0dc9d8a952b6d1:-1eccb494:13f1505b73b:-8000-000000000001c5b1> 
 <1370498845673> <BEA-000000> 
 <connection failed netscape.ldap.LDAPException:n Server or network error (81); 
 Cannot contact LDAP server> 
 . 
 ####<Jun 5, 2013 11:07:25 PM PDT> <Debug> <SecurityAtn> <SHAIMISH-LAP><AdminServer> 
 <[ACTIVE] ExecuteThread: '2' for queue:  'weblogic.kernel.Default (self-tuning)'> 
 <<WLS Kernel>> <> <5b0dc9d8a952b6d1:-1eccb494:13f1505b73b:-8000-000000000001c5b1> 
 <1370498845673> <BEA-000000> <[Security:090294]could not get connection>
残念ながら、ログイン失敗の理由は常に明確というわけではありません。例えば、セキュリティレルムをLDAP authenticatorで構成している場合の断続的なログイン失敗で、次のような出力が出た場合、何が悪いのか明確ではありません。
####<Oct 7, 2013 12:44:21 PM EDT> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
ExecuteThread: '246' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<d99500ee4d4904e8:1daa9ea9:14193a06acc:-8000-0000000000072676> <1381164261368> <BEA-000000>
<[Security:090295]caught unexpected exception> 
.................................................................................................
####<Oct 7, 2013 12:44:21 PM EDT> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
ExecuteThread: '246' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<d99500ee4d4904e8:1daa9ea9:14193a06acc:-8000-0000000000072676> <1381164261368> <BEA-000000> 
<com.bea.common.security.internal.service.LoginModuleWrapper.commit delegated, returning false>
####<Oct 7, 2013 12:44:21 PM EDT> <Debug> <SecurityAtn> <SHAIMISH-LAP> <AdminServer> <[ACTIVE]
ExecuteThread: '246' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<d99500ee4d4904e8:1daa9ea9:14193a06acc:-8000-0000000000072676> <1381164261368> 
<BEA-000000> <weblogic.security.service.internal.WLSJAASLoginServiceImpl$ServiceImpl.authenticate 
authenticate failed for user TESTCCOUNT>
このような場合には、標準のWebLogic LDAP authenticatorの場合、ldap_trace.logATNログファイルを確認します。このファイルはドメインディレクトリ配下にあり、LDAPとの通信で発生している情報を含んでいます。上記のシナリオでは、このログファイルから、LDAPサーバーとの接続切断の問題が明らかになりました。

Propagating failure exception to caller (applicable for callers running in same JVM)

WebLogic Serverで実行中のプログラム的にログインしているコードの場合、実際のログイン失敗の原因を標準のWebLogic Authenticatorが呼び出し元に伝播することができます。authenticatorの[プロバイダ固有]タブに、「ログイン例外の原因を伝播」(Figure 1)というフラグがあります。これにチェックを入れると、ログイン例外の実際の原因を呼び出し元に伝播します(下図)。この情報は迅速にプログラムでのログイン失敗の原因を迅速に診断する上で有用です。
mishra-wls-auth-fig01
Figure 1: Propagate Cause For Login Exception

Account Soft Lockout

アカウント・ソフトロックアウトはユーザーアカウントに対するDoS攻撃を防ぐためのWebLogic Serverのメカニズムです。例えば、ユーザーアカウントログインが知られている場合、誰かが複数回の不正なログインを試行し、アカウントを管理するバックエンドシステム(例えばLDAP)でこのアカウントが永久にロックされてしまう可能性があり、その結果、実際のユーザーがアカウントロックによりログインできなくなるでしょう。このような状況を防ぐために、WebLogic Serverはアカウントのソフトロックアウト機能を提供しています。これを有効にすると、t2(時間)の間にn回の失敗ログインが発生した場合、t1(時間)の間、アカウントをWebLogic Serverランタイムでロックします。なお、t1、t2、nは設定することができます。アカウントがWebLogic Serverランタイムでソフトロックされた場合、アカウントの資格情報をバックエンドシステムに対し検証しようとしなくなります。これにより永久ロックを避けることができます。
この機能は非常に有用ではありますが、時として(具体的には断続的なログイン失敗が発生している場合)、難しい状況に陥ることがあります。アプリケーションで設定されているサービスアカウントがあり、このアカウントが頻繁に定期実行されるサービスで使われるものと仮定します。サービス開始時には、サービスアカウントの資格情報を取得し、プログラムによるログインを実行しようとします。このログインが複数回失敗した場合、WebLogic Serverランタイムはこのアカウントをソフトロックするので、このスケジュールされたサービスにとって状況は悪化します。つまり、ログイン失敗の原因が解決してもログインできない可能性がある、ということです。唯一の方法は、手動でサービスを停止し、サービスアカウントのソフトロックを解除することでしょう。
(私見ですが、アカウントライフサイクル管理の問題が発生するため、システム内にサービスの資格情報を保管すべきではありません。例えば、このアカウントのパスワードが変わると、格納されたもの全てを変更しなければならないからです。そうしないと、ログイン失敗の原因になります。のういう場合にはIDアサーションを使うべきでしょう。この場合はアカウントのユーザーIDのみがあればいいのです。WebLogic ServerでOPSSを使ってIDアサーションを実現する方法に関する情報は、参考文献のセクションをご覧下さい)。
以下のセクションでは、アカウント・ソフトロックアウトをWebLogic Serverで構成している状況と、UserLockoutManagerを使って、アカウント・ソフトロックアウトを解除する方法を説明します。

WebLogic Soft Lockout Configuration and Manager

ソフトロックアウトの設定情報は、[セキュリティ・レルム]>[レルム名] > [ユーザーのロックアウト]で確認できます(下図)。
mishra-wls-auth-fig02
Figure 2: Soft Lockout Configuration
特定のWebLogic Serverインスタンスでの無効なログインに関する統計情報は、[サーバー] > [サーバー名] > [監視] > [セキュリティ] から確認できます(下図)。
mishra-wls-auth-fig03
Figure 3: Invalid Login Stats
手動でアカウントのソフトロックアウトを解除するために、WebLogic ServerではUserLockoutManagerというMBeanを提供しています。このMBeanにはisLockedOutclearLockoutというメソッドがあります。これらのメソッドは、パラメータとして、ユーザのログインIDを取ります。アカウントのソフトロックアウトを削除するには、clearLockoutメソッドを呼び出します。isLockedOutメソッドを呼び出して、当該アカウントがソフトロックされているかどうかを確認することができます。
mishra-wls-auth-fig04
Figure 4: Account Soft Lock Status

Conclusion

この記事では、利用可能なデバッグフラグやログファイルを使って、WebLogic Serverでのログイン失敗を診断する方法を説明してきました。パフォーマンスの理由で、このデバックログ出力を有効にしたままにしないでください。認証の問題を診断したら、このフラグをOffにしてください。また、この記事では、断続的なログインの失敗により、WebLogic Serverでどのようにアカウントがソフトロックされるのか、そしてUserLockoutManagerというMBeanを使って、このソフトロックを取り除く方法もご紹介しました。

参考資料

  1. 認証プロバイダ(Authentication Providers)
    (日本語)http://docs.oracle.com/cd/E51625_01/web.1111/b61623/atn.htm
    (英語)http://docs.oracle.com/cd/E23943_01/web.1111/e13718/atn.htm
  2. 認証プロバイダの構成(Configuring Authentication Providers)
    (日本語)http://docs.oracle.com/cd/E51625_01/web.1111/b61617/atn.htm
    (英語)http://docs.oracle.com/cd/E29542_01/web.1111/e13707/atn.htm
  3. Programmatic Identity Assertion with Oracle Platform Security Services (OPSS)
    (英語)http://www.oracle.com/technetwork/articles/idm/mishra-id-opss-2088117.html
Authenticator関連の問題のトリアージの手助けをしてくれたShaun Peiに感謝いたします。

著者について

Shailesh K. Mishrah はOracle Identity Managerチームの一員で、Indian Institute of Technology (Banaras Hindu University)の工学士を取得しており、自由な時間を使ってミドルウェアのパフォーマンスとセキュリティを調べています。

[Solaris] Videos: Oracle Solaris 11.2 and More

原文はこちら。
https://blogs.oracle.com/video/entry/solaris_youtube

Oracle Solaris 11.2の情報を探していて、動画がお気に入りのメディアだったとしたら、幸運なことに、今週のLaunch Eventでお伝えした主要な新機能を取り扱っている、数多くの動画のリンクが(時間の長短問わず)Oracle Solaris YouTube Channelにあります。
Oracle Introduces Oracle Solaris 11.2—Engineered for Cloud
http://www.oracle.com/us/corporate/pressrelease/solaris-11-2-042914
Oracle Solaris (YouTube Channel)
https://www.youtube.com/user/OracleSolaris

[Java] JRockit: Artificial GC: Cleaning up Finished Threads

原文はこちら。
https://blogs.oracle.com/buck/entry/jrockit_artificial_gc_cleaning_up

実行が完了したアプリケーションスレッドをJVMがクリーンナップしようとするために頻繁にフルGCを体験しているJRockitユーザーがいらっしゃいますので、このエントリでは、このフルGCの発生原因、貴社環境でのフルGCの識別方法、考えられるソリューションをご説明しましょう。

What exactly is happening?

多くのスレッドが実行を終えたにもかかわらず、対応するjava.lang.ThreadオブジェクトをJavaヒープからガベージコレクションしていない場合、JVMは自動的にフルGCイベントを呼び出し、残存するThreadオブジェクトをクリーンアップしようとします。

Why does JRockit do this?

JRockitの内部設計により、 対応するThreadオブジェクトをJavaヒープから除去してからでないと、 JVMは実行スレッドに関連づけられている全ての内部リソースは解放することができません。これは通常問題にならないのですが、ガベージコレクションの間隔が長く、アプリケーションが数多くのスレッドを作成(し、破棄)する場合、こうしたデッドスレッドが消費する メモリや他のネイティブリソースの量は非常に大きくなります。例えば、デッドスレッドを絶えず「リーク」するテストプログラムを実行し、対応するThreadオブジェクトの各々への強参照が残っている場合、JVMのメモリ使用量はすぐに増大します。それは、数GByteのオフヒープ(ネイティブ)メモリを消費してほとんどのデッドスレッドのデータを維持しようとするからです。

What does this actually look like in practice?

この現象があなたのアプリケーションで起きているかどうかを確認する一番簡単な方法は、JRockitの memdbg冗長ログモジュール (*1) を有効にすることです。フルGCがThreadオブジェクトのクリーンアップを待つスレッドによって引き起こされると、GCイベント(*2) の開始時点で次のようなメッセージを確認することでしょう。
===
[DEBUG][memory ] [OC#7] GC reason: Artificial, description: Cleaning up Finished Threads.
===
こうしたスレッド関連のフルGCイベントを提供する別の冗長ログ出力モジュールは、スレッドモジュールです。
===
[INFO ][thread ] Trigging GC due to 5772 dead threads and 251 threads since last collect.
===
上記メッセージは、実行が終了したスレッドが現在5772個ありますが、 GCサブシステムがThreadオブジェクトを集めるのを待っています(その後、各スレッドに関連づけられている全てのリソースを完全に解放できます)。また、スレッド管理コードが引き起こした直近のフルGC以後、251個の新しいスレッドが生成されていることもわかります。つまり、「直近の収集」とは「スレッドクリーンアップコードが引き起こした直近の収集」ということです。この数は通常のGCイベントでゼロにリセットされることはなく、スレッドクリーンアップGCだけがこの数値をリセットします。

What can I do to avoid these collections?

当然ながら、最善のソリューションはそんなに多くのスレッドを作成しないことです。スレッドはコストが高いのです。アプリケーションが非常に多くのスレッドを継続的に作成(そして破棄)しているために、250スレッドごとに発生するフルGCが性能上の問題になるのであれば、おそらくそれはアプリケーションの設計をやり直し、使い捨てするようなスレッドの使い方をしないようにした方が良いでしょう。例えば、スレッドプーリングはリーズナブルな解決策になる可能性があります。HotSpot上でアプリケーションを実行していたとしても、これほど多くのスレッドを一時的に作成すると、パフォーマンスの問題が発生する可能性が高いのです。どんなJVMを使っているかに関係なく、アプリケーションを変更してスレッドを効率良く利用するようにすることを検討すべきです。
しかし、アプリケーションの再設計が有効な選択肢でない場合も当然ながらあり得ます。もしかすると、こうしたスレッドを生成しているコードはサードパーティ製で変更できないものかもしれません。もしくは、アプリケーションの変更を計画してはいるものの、しばしの間はこれらのフルGCイベントに対処する必要がある、といった場合もあるかもしれません。JVMサイドのソリューションはあるにはありますが、一時的な回避策と考えるべきでしょう。

JRockitには、MaxDeadThreadsBeforeGCとMinDeadThreadsSinceGCという2個の診断オプションがあり、これらを使うとGCの挙動を調整することができます。両者の間の違いは微妙ですが、基本的には両者を使ってスレッド管理コードがフルGCを引き起こすタイミングを決定する閾値を変更することができます。
  • MaxDeadThreadsBeforeGC (デフォルト値: 250)
    このオプションは、人為的なフルGCを引き起こすデッドスレッド(実行が完了したものの、対応するThreadオブジェクトがJavaヒープから除去されるのを待っているために 、まだクリーンアップされていないスレッド)の個数を指定します。
  • MinDeadThreadsSinceGC (デフォルト値: 250)
    このオプションは、 スレッドクリーンアップのためのGCイベント間に 新しく生成するスレッドの最小個数を指定します。この意図は、フルGCを引き起こしたとしても、Threadオブジェクトへの強参照があるために、デッドスレッドのサブセットがまだ残存する可能性があることです。つまり、フルGCを生き延びたデッドスレッドの個数がMaxDeadThreadsBeforeGCよりも大きい場合には、新しくスレッドを作成するたびにフルGCを引き起こす可能性があります。MinDeadThreadsSinceGC オプションは、デッドスレッドがMaxDeadThreadsBeforeGCで定義している個数を上回っていたとしても、直近のスレッドクリーンアップGC以後、少なくともある程度の新しいスレッドを生成することを保証します。
これらの2個のオプションは、Xverbose:threadの出力に現れる2個の数値に対応していることにご注意ください。
===
[INFO ][thread ] Trigging GC due to 5772 dead threads and 251 threads since last collect.
===
最初の数値(5772)はクリーンアップを待っているデッドスレッドの個数であり、MaxDeadThreadsBeforeGCの値と比較しています。2個目の数値(251)は、直近のスレッドクリーンアップのためのフルGC以後に生成された新しいスレッドの個数です。この2個目の数値はMinDeadThreadsSinceGCと比較しています。両数値が閾値を上回っている場合に限り、スレッドクリーンアップのGCが発生します。

スレッドクリーンアップのGCの頻度を減らす必要があり、アプリケーションを修正できない場合には、MinDeadThreadsSinceGCの閾値を大きな値にすることをお薦めします。トレードオフとして、JVMが前もって実行終了したスレッドをクリーンアップする頻度が小さくなるためにネイティブメモリの使用量が増えますので、当然ながら、こうしたオプションを本番環境で利用する前に、パフォーマンスおよび負荷テストを実施すべきです。

もう一つ重要なことですが、これらのオプションは両方ともドキュメント化されていない診断オプションです。R28では、これらのオプションを使うためには、 コマンドラインにおいて-XX:+UnlockDiagnosticVMOptionsオプションを、任意の診断オプションの前に付ける必要があります。例えば、MinDeadThreadsSinceGCを1000に設定する場合、以下のようなコマンドラインを使います。
===
$ java -XX:+UnlockDiagnosticVMOptions -XX:MaxDeadThreadsBeforeGC=1000 MyJavaApp
===
この記事全体を読み、ネイティブメモリ消費量が増大するというリスクをを理解し、本番環境に展開する前にアプリケーションの負荷テストを徹底的に実施することをいとわないのであれば、これらのオプションのいずれを使っても安全でしょう。

(*1) Xverboseオプションの使い方の詳細は以下のコマンドラインリファレンスを参照してください。
Oracle® JRockit Command-Line Reference Release R28
http://docs.oracle.com/cd/E15289_01/doc.40/e15062/optionx.htm#i1020876
(*2) この出力例は、R28からのものであることに注意してください。 R27の場合、"Floating Dead Threads"としてGCの原因に言及しています。

[Solaris] SO_FLOW_SLA socket option in Solaris 11.2

原文はこちら。
https://blogs.oracle.com/yenduri/entry/so_flow_sla_socket_option

Solaris 11.2で新しいソケットオプションであるSO_FLOW_SLAを追加しました。これを使うとアプリケーションがソケットレベルフローやリソース管理プロパティをsetsockopt()を使って作成することができます。このソケットオプションを使う場合には、PRIV_SYS_FLOW_CONFIG 権限が必要です。
setsockopt(3C) のmanページにはプログラミングAPIの詳細が全て掲載されています。利用は以下のように簡単です。
sock_flow_props_t sprop;
sock = socket(AF_INET, SOCK_STREAM, 0);
sprop.sfp_version = SOCK_FLOW_PROP_VERSION1;
sprop.sfp_mask = SFP_MAXBW;
sprop.sfp_maxbw = 500000000; /* 500 Mbps */
setsockopt(sock, SOL_SOCKET, SO_FLOW_SLA, &sprop, sizeof (sprop));
The flows created using setsockopt(3C)を用いて作成したフローは、pfiles(1)からだけでなく、flowadm(1M), flowstat(1M)を使って監視することができます。
このソケットオプションを使って-Mオプションを実装しているnc(1)/netcatツールの例を見てみましょう。
nc -l 80 を 10.2.3.118 上で実行します。
# nc -M maxbw=100M 10.2.3.118 80
...
別の画面で以下のように観察できます。
# flowadm
FLOW        LINK     PROTO LADDR             LPORT RADDR             RPORT DSFLD
24.sys.sock net1     tcp   10.2.3.117        38769 10.2.3.118        80    --
# flowadm show-flowprop
FLOW         PROPERTY        PERM VALUE          DEFAULT        POSSIBLE
24.sys.sock  maxbw           rw     100          --             -- 
24.sys.sock  priority        rw   --             medium         low,medium,high 
# pfiles `pgrep nc`
18827:  nc -M maxbw=100M 10.2.3.118 80
...
3: S_IFSOCK mode:0666 dev:556,0 ino:5341 uid:0 gid:0 size:0
O_RDWR
SOCK_STREAM
SO_SNDBUF(49152),SO_RCVBUF(128872),
SO_FLOW_SLA(maxbw: 100.000 mbits/sec)
sockname: AF_INET 10.2.3.117  port: 38769
peername: AF_INET 10.2.3.118  port: 80
congestion control: newreno
...

[Java] New Release: Java Micro Edition (ME) 8

原文はこちら。
https://blogs.oracle.com/java/entry/new_release_java_micro_edition

本日、OracleはOracle Java Micro Edition 8(Java ME 8)をリリースしたことを発表しました。
Oracle Java ME SDK Download
http://www.oracle.com/technetwork/java/javame/javamobile/download/sdk/index.html
このリリースは2年間の作業を集積したJava MEテクノロジーのメジャーアップデートであり、最新の組み込みソフトウェアプラットフォームとして、Internet Of Thingsの新サービスのための基盤として作成されました。
Java MEは、マイクロコントローラ、センサー、ゲートウェイ、携帯電話、PDA、TVのセットトップボックス、プリンタといった、組み込み機器やモバイルで動作するアプリケーション用の堅牢かつ柔軟な環境を提供し、堅牢なセキュリティ、組み込みのネットワークプロトコル、オンライン・オフラインアプリケーションのサポートも備えています。
Oracle Java ME Embedded 8は先頃承認されたJava ME 8 Standardの実装で、Java SE 8の言語機能やAPIがそのまま利用でき、機能拡張されたサービスを利用できるアプリケーションプラットフォームであり、適切なサイズにプラットフォームを調整し、Internet Of Thingsに関わる幅広いデバイスに対応することができます。Oracle Java ME SDK 8を通じてアプリケーション開発をサポートしています。
Oracle Java ME SDK Download
http://www.oracle.com/technetwork/java/javame/javamobile/download/sdk/index.html
Oracle Java ME Embedded Downloads
http://www.oracle.com/technetwork/java/embedded/downloads/javame/index.html
Java ME Embedded Documentation
http://www.oracle.com/technetwork/java/embedded/resources/me-embeddocs/index.html
Java ME Developer Tools Documentation
http://docs.oracle.com/javame/developer/developer.html
OTN Community Forum (Java ME Embedded)
https://community.oracle.com/community/developer/english/java/java_embedded/java_me_embedded
Twitter (Java Embedded)
https://twitter.com/javaembedded
Java ME 8: Top 10 Features

Oracle Java Platform, Micro Edition (Java ME)ベースの製品は、小さなデバイス上で豊富な機能をもつJavaプラットフォームに対する、Javaテクノロジーのニーズを満たすことでしょう。Create the Future with Java ME!