Dockerfileの無駄なレイヤリングを排除してビルドを高速化する - nekop's blog
Docker Advent Calendar 2016の10日目の記事です。土曜日は子供と遊んでいると思うので1日早く金曜日に公開しちゃいます。 Dockerでコンテナイメージを作成するときにはDockerfileを利用するのが最も一般的ですが、標準のdocker buildはインストラクション毎に中間レイヤーを作成し保存することを強制するようになっており、イメージ肥大化およびイメージビルドのパフォーマンス低下を避けるために、ユーザはコマンドを&&で繋げるRUNインストラクションを必要最小限な数になるよう最適化した奇妙なDockerfileを記述するという理不尽な作業が必要となります。 この強制レイヤリングは一応イメージビルド時の試行錯誤をしているときに中間までキャッシュできるので良い、という建前になっており、最初のうちはちょっと便利かなぁと思ったりもしますが、要件が固まっているベースレイ
G1GCのつかいどころメモ - nekop's blog
以下の環境とテストでCMSとG1GCを比較してみた。かなり急ぎでやったので間違っている可能性が多少ある。 16 cores, 32GB mem -Xms24g -Xmx24g 8 instances Infinispan 6.0.3.Final DIST cache, put 4GB data (1KB entry * 2M, 2GB data with one backup copy, 2GB * 2 = 4GB) CMS: -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=30 G1GC: -XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:InitiatingHeapOccupancyPercent=30 $ java -XX:+UseG1GC -XX:+PrintFlagsFinal
Java 7 CMS GCの基本的な情報の整理 - nekop's blog
バッチ処理などスループット重視のアプリケーションはデフォルトのパラレルGCで良いが、Java EEアプリケーションサーバなどレスポンスタイム重視のものやHadoopなどのクラスタ系ソフトウェアで死活監視に引っ掛る系などのstop the worldをなるべく避けたいいわゆるサーバ系ソフトウェアを運用する場合には、UseConcMarkSweepGCを付与して停止時間の短いCMS GCを使う。その場合にCMSのチューニングに踏み込もうとするとなんだか難しい記述がいっぱいで若干困るので、簡単なガイドをメモとして書いておく。 対象バージョンは以下。 $ java -version java version "1.7.0_51" OpenJDK Runtime Environment (fedora-2.4.5.1.fc20-x86_64 u51-b31) OpenJDK 64-Bit Serve
EJBとは - nekop's blog
世に出ているEJBの説明はクソみたいなものが多く、簡潔に機能や特徴を記述しているものが見当たらないので書きました。Java EE 6, 7を対象として書いています。 EJBというのはJava EEアプリケーションサーバ上で利用できるJavaのコンポーネントです。トランザクション制御などの煩雑な部分をEJBが自動的に面倒を見てくれるので、開発者はEJBの基本的なルールを抑えたあとはビジネスロジックの記述に集中することができる、というものです。EJBには4種類あります。 基本となるステートレスセッションビーン (Stateless Session Bean, SLSB) 状態を保持できるステートフルセッションビーン (Stateful Session Bean, SFSB) 単一インスタンスのシングルトンセッションビーン (Singleton Session Bean, SSB) メッセージ(
JJBugでJava VMの起動高速化の話をしました - nekop's blog
Japan JBoss User Group - 灼熱の JBossでJava VMの起動高速化の話をしました。非圧縮jarによる高速化はみなさんも使っている有名なソフトウェアで採用されていますが、あまり知られていないチューニングだと思います。大抵の場合200%くらいの高速化ができます。 Java Drag Race Tuning from nekop CMS GCを使わないほうがちょっとだけ速い、とか効果が小さめなオプションについては特に解説していません。 あと話すの忘れてましたがScalaがチューニングしてもあまり変わっておらず、最初から高速なのはデフォルトでbootclasspathを使っているからです。bootclasspathはクラス検証されないので、-Xverify:noneが既に適用されてるのと一緒です。 紹介したのは主にクラスローディングを高速化することによりJavaで書か
JBoss ASで受信メール処理 - nekop's blog
MDBでゴー。 import javax.ejb.ActivationConfigProperty; import javax.ejb.MessageDriven; import javax.mail.Message; import javax.mail.MessagingException; import org.jboss.annotation.ejb.ResourceAdapter; import org.jboss.resource.adapter.mail.inflow.MailListener; @MessageDriven(activationConfig={ @ActivationConfigProperty(propertyName="mailServer", propertyValue="server"), @ActivationConfigProperty(prope
JBoss ASで定期処理 - nekop's blog
EC-One ナレッジセンター レスキューサービス ブログ さんの方で見かけたトピック。035 jboss-5.1.0.GAでcronのような定期処理を実現という記事。 一番簡単な方法が紹介されていなかったので紹介。その方法というのはMDB。コンパイルしてデプロイすればおしまい。cron形式で実行を指定できる。 http://community.jboss.org/wiki/QuartzSchedulerIntegration 以下コード例。 import javax.ejb.ActivationConfigProperty; import javax.ejb.MessageDriven; import org.jboss.annotation.ejb.ResourceAdapter; import org.quartz.Job; import org.quartz.JobExecutio
MDBとJCAのおはなし - nekop's blog
JBoss Advent Calendar 2011の13日目のエントリです。 MDBはメッセージドリブンビーンの略であり、メッセージを処理するEJBコンポーネントです。MDBはJMSのメッセージを処理するコンポーネント、という古い認識の人もたまに居るのですが、MDBはかなり前からJMSに限定しない技術となっています。 最初にMDBが策定されたのはJ2EE 1.3に含まれていたEJB 2.0仕様で、この時点ではMDBはJMSのメッセージを処理するもの、と規程されていました。J2EE 1.4の時代となり、EJB2.1の策定に伴いMDBの動作の仕様の中心はJCA仕様(Java EE Connector Architecture)に移り、メッセージはJMSのものに限定せず、ありとあらゆるメッセージ受信処理ができるよう一段階上の抽象化がなされました。 JCAはJava EEと外部システムをつなぐイ
JNDIをさらっと振り返る - nekop's blog
JBoss Advent Calendar 2011の12日目のエントリです。 JNDIはJava EEサーバのEJB、JDBCデータソースやJMSのConnectionFactoryなど、各種サービスにアクセスするためのエントリポイントとなる部分なのですが、あまりエキサイティングな技術ではないので注目されることはないですし、どのようなものなのかを調べたりする機会もなかなかないでしょう。というわけでさらっと振り返ります。 まず基本的な機能はリモートアクセスもできるサーバ上のグローバルHashMapみたいなものです。メソッド名がちょっと違い、get()ではなくlookup()、put()ではなくrebind()となっています。 データソースを取得するようなコードはこのようになります。 InitialContext context = new InitialContext(); DataSou
JDBC XAデータソース - nekop's blog
JBoss Advent Calendar 2011の14日目のエントリです。今日はJDBC XAデータソースの説明。 XAってなによ？ ツーフェーズコミット(2相コミット, 2PC)するためのインタフェースです。 XAとか2PCってどんなときに使うの？ 一つのトランザクションで2つ以上のトランザクショナルリソース(JDBC JCAリソースアダプタ=データベースとか、JMS JCAリソースアダプタとか)を扱う場合に利用します。 XAとか2PCってなんで必要なの？ 例えばデータベースが二つ、DB-AとDB-Bがあって、DB-AからDB-Bにデータを移す処理をするとします。このとき、DB-AからSELECTして削除してDB-Bにインサートする、というようなことをするわけですが、この処理が途中で落ちたら即データ消滅、データ重複などのデータ不整合という結果になってしまいます。XAを使うとこういった
「GroovyでEJB作成は辛い」の解説 - nekop's blog
GroovyでEJB作成は辛い、でなにがどうなっているのかの解説。 Exception while loading the app : EJB Container initialization error javax.ejb.EJBException: Illegal non-business method access on no-interface view at megascus.javaee6groovy.__EJB31_Generated__MessageFacade__Intf____Bean__.$getStaticMetaClass(Unknown Source) at megascus.javaee6groovy.MessageFacade.<init>(MessageFacade.groovy) at megascus.javaee6groovy.__EJB31_Gen
JBoss Developer Frameworkはじめました - nekop's blog
JBoss Developer Frameworkというショーケースのようなプロジェクトがオープンしました。Java EE 6やJBossのプロジェクトをどのように利用し始めれば良いかという具体例やドキュメントを提供します。 クイックスタート クイックスタートでは現時点で53個の様々なテクノロジ(JAX-RS, GWT, HTML5など)を利用するクイックスタートプロジェクトを提供しています。 サンプルアプリケーション クイックスタートは確かに役に立ちますが、クイックスタートのようなごく小さいサンプル集ではなく、もう少し現実的な大きさのプロジェクトもあると良いですよね。というわけで、チケットモンスターという通常サイズのモダンなJava EE 6サンプルアプリケーションも用意されています。 マイグレーション Seam 2、Spring、Java EE 5プロジェクトからJava EE 6への
Java EE Application Client - nekop's blog
Java EEでは.earファイル、.warファイル、.jarファイルなどのアーカイブがあります。マイナーどころでは.rarというのもあります。今日紹介するのはそのなかでも抜群にマイナーであろう.carファイル、Java EE Application Clientです。 Java EE Application Clientを利用するとリモートクライアントからのEJB呼び出しとかJMS呼び出しとかJNDI呼び出しが簡単にできるようになります。 昨日のJavaFX勉強会でApplication Clientを使うというネタをよっしーがやってたっぽいので、JBoss AS7でもやってみます。JavaFXは抜きです。しかしApplication Client見かけるの久しぶりすぎる。 今日のJavaFX勉強会の発表資料をアップ致しました。#jjfxugURL 2012-07-03 00:38:42
JBoss ASのクラスローディング - nekop's blog
前回のクラスローダの話に引き続き、JBoss ASのクラスローディングについて書いておく。 JBoss ASのクラスローダの実装面の細かい話とか、ブートストラップクラスローダとシステムクラスローダの違いだとかendorsedとかのお役立ち度の低い細かい話は対象外。利用者が最低限抑えておきたいところ、という観点で書く。 基本的な構造 JBoss ASのクラスローディングは基本的には以下の構造になっている。 システムクラスローダ JBoss AS共通部 EAR WAR ロード順はもちろん子優先(Child-firstもしくはParent-lastと呼ばれる)。たったの4階層だし、特に難しいことや困ることは無いはず。 EARの分離モード JBoss ASでは一点だけ注意するところがある。JBoss ASは歴史的な理由から、EARのクラスローディング分離がデフォルトでOFFになっている。これは、上
JVM勉強会でLTしゃべってきました - nekop's blog
わかる!JavaVM — 2時間でわかる?JavaVM入門 : ATND 主催のゆるよろさん、会場提供のOracleさんありがとうありがとう！ 発表スライド http://www.slideshare.net/nekop/classloader-leak-patterns 利用したソースコード http://github.com/nekop/sandbox/blob/master/java/src/main/java/sandbox/ThreadLocalKeyValue.java 僕は緊張しまくって発表中挙動不審でした。もうちょっと落ち着きましょう。でもドラはなくともきっちり5分は守ったぞ！ ThreadLocalKeyValue.javaはソースコード上見えない参照が2つあるので結局のところGCされないよ、という問題。Bob LeeのBlogを読んでたりするような人にはきっと既出だった
Java EE環境における非同期プログラミング - nekop's blog
Java EE環境では基本的にスレッドの生成は許されていません。この制限はEJB仕様書に記述されており、ブループリントなど他のドキュメントにも記載されています。これらの制限はかなり古い時代に考えうる最大の制限を記述したものであり、「ファイルにアクセスしてはならない」など今となってはあまり現実的ではない記述も多くなっています。しかしながら、「スレッドを生成してはならない」というのは依然多くのコンテナに適用される現在も有効な制限であり、実際にスレッドの生成などを行うと誤動作するケースがあります。今回は、なぜこのスレッドの制限があるのか、現実的にどうすれば良いのか解説します。 コンテナは様々なものをスレッドに結びつけて管理しています。様々なものというのは例えばセキュリティ、トランザクション、データソースなどのコンテナリソースです。コードのほうがイメージしやすいでしょうから、以下に擬似コードを挙げ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
