tcpdumpからKafkaのリトライ可能エラーを追う - n-agetsumaの日記
Kafkaのメッセージロストの原因の1つに、プロデューサの設定のretries(デフォルト0:リトライしない)の未設定がある。 Kafkaクライアントの送信リトライ プロデューサからメッセージ送信時のエラーには、retires設定によりKafkaのクライアントライブラリ内で自動リトライ可能なエラーと、リトライせずにProducer.sendメソッドの呼び出し元に例外を投げるエラーがある。自動リトライ可能なエラーで発生する例外は、org.apache.kafka.common.errors.RetriableExceptionの継承クラスである。代表的なものを以下に示す。 retiresによりリトライするエラー NotLeaderForPartitionException リーダーパーティションではないブローカーにメッセージが送られた場合のエラー応答。ブローカー障害によるフェールオーバ中にメ
LogstashからIngest Nodeへの移行 - n-agetsumaの日記
Elasticsearch 5.xからはIngest Nodeを使うと、Logstashを使わなくてもElasticsearchでログの変換ができるとElastic社のスライドにまとまっていたので、LogstashからIngest Nodeへの移行についてメモ。 LogstashからIngest Nodeへの移行 今までFilebeatで集めてきたログをLogstashに送ってjson変換していたところ、Elasticsearchで直接json変換できるようになるため、Logstashを使わなくてもログの収集と可視化が可能となる。 Filebeat(収集) -> Logstash(変換) -> Elasticsearch(蓄積) Filebeat(収集) -> Elasticsearch(変換/蓄積) Logstashのfilterプラグインの多くはIngest Nodeの機能にProce
Commons Lang 3.5 でJava EEにBreakerを組み込む - n-agetsumaの日記
この記事は Java EE Advent Calendar 2016の12/13分の記事です。 昨日はsuke_masaさんの必要最小限のサンプルでThymeleafを完全マスターでした。 明日は@kazuhira_rさんです。 Payara MicroやWildFly Swarmをベースとしたマイクロサービス対応の共通仕様の規定を目指しているmicroprofile.ioでは、Circuit Breakerの仕様盛り込みがこのスレッドで議論されています。 Circuit Breaker実装というとHystrixが有名ですが、上記スレッドでCommons Langに簡易なCircuit Breaker実装が追加されたことに言及があったため紹介します。 2016年10月にリリースされたCommons Lang 3.5より、LANG-1085により、シンプルなBreaker実装が加わっています
Javaバッチ処理のNFS向けファイルI/O - n-agetsumaの日記
この記事は Java EE Advent Calendar 2015の12/7分の記事です。 明日は@btnrougeさんです。 Java EEのAPIが直接関連する話ではなくて恐縮ですが、サーバサイドJavaでファイルI/Oを含むバッチ処理の性能Tipsをまとめます。 テーマはjava.io.BufferedWriterクラスのバッファサイズについてです。 デフォルトは8KBでBufferedWriterのコンストラクタにおいて変更可能ですが、javadocには以下の記載があります。 バッファのサイズは、デフォルト値のままにすることも、特定の値を指定することもできます。デフォルト値は、通常の使い方では十分な大きさです。 http://docs.oracle.com/javase/jp/8/docs/api/java/io/BufferedWriter.html あまり変更する機会もないせ
Javaトラブルに応じた初動対応のまとめ - n-agetsumaの日記
Javaトラブルでは『情報がなくて、再現もなかなかしません』といった状況に陥ることがある。このような状況を回避するために、以下の3つの代表的なトラブルを例に、アプリケーションサーバを再起動する前に何を取得すれば良いのかをまとめてみる。 アプリケーションから応答がない アプリケーションが遅い ヒープメモリが足りない(OutOfMemoryErrorの発生) アプリケーションから応答がない 取得する情報 スレッドダンプ データ取得方法 スレッドダンプとは、コマンド実行時点でのJavaスレッド実行状態を出力したものである。応答がない場合、何らかの要因によりどこかで処理が止まっていることが想定される。スレッドダンプは『どこで止まっているのか？』を切り分けるのに大切な情報である。 取得方法はJDKのバージョンによって色々ある。 kill -3 <pid> (少なくとも1.4.2にはある〜JDK7でも
JSF2.0のエラーハンドリング - n-agetsumaの日記
JSF2.0のエラーハンドリングについて調べてみたのでまとめる。 ここで言う『エラーハンドリング』とは、Struts1.xの<globa-exceptions>や、org.apache.struts.action.ExceptionHandlerを継承してユーザが作成するカスタム例外ハンドラを想定しており、Struts1.xと同じようなことがJSF2.0でも可能か確かめることが目的だ。 今回は、以下のようなバッキングBeanからランタイム例外が投げられた場合に、スタックトレースが表示されないようにしたい。 @Model public class BookController { @EJB private BookService service; @Inject private Book book; public String createBook() { service.persist(b
JBossAS7 データソース設定 WebコンソールとCLIの違い - n-agetsumaの日記
JBossAS7でEJBのコンテナ管理トランザクションが動かないことではまっていたが、WebコンソールとCLIでJTAを有効にするかどうかのデフォルトが違ったのが原因だったようだ。 Webコンソールの場合 Webコンソールから作成すると、デフォルトでUse JTA?はfalseになっている。この属性がfalseになっていると、データソースから取得したコネクションはautocommit=trueになっていた。このため、EJBのコンテナ管理トランザクションがうまく動かず、insert/update/deleteするとEJBのトランザクション管理を待たずして即時にコミットされていた。 standalone.xmlからもjta属性がfalseになっていることが確認できる。 <datasource jta="false" jndi-name="java:/test" pool-name="test"
JBossAS7でトランザクションの動作を確認する - n-agetsumaの日記
Spring3 入門を読んでいて、トランザクションの開始・終了がEJBを使ったJavaEEアプリケーションでも出力できないか考えてみた。 CDIのTransactionnal Observerで試行錯誤 : 失敗 CDIでは、トランザクションの成功・失敗・開始などの合わせてイベントを起動するTransactional Observerと呼ばれる仕様がある。 しかし、下記のように明示的にfire()でイベント発火する必要があり、ちょっとトランザクションの挙動をロギングする用途にはアプリケーションには余分なコードに見えてしまう。あくまでWeld Referenceの例のように、トランザクションの成功・失敗をフックに、何かListの状態を変更したり、なんらかのビジネスロジックを実行するために使いそうだ。 @Inject @Any Event<Book> bookEvent; public voi
Faceletsにコメント文を書く - n-agetsumaの日記
FaceletsのXHTMLにコメントを書く時に少しはまったのでメモ。(以下のコードはJBossAS7.1で確認) うまくいかない例 (HTMLコメントをそのまま使う) コマンドボタンを以下のようにコメントアウトすると、Submitしたときではなく、ボタンを含むページを開いたときの『RENDER_RESPONSE』フェーズでaction属性に設定したアクションが実行されてしまう。 <!-- うまくいかないコメント例 --> <!-- <h:commandButton styleClass="btn" action="#{userManageController.changePassword()}" value="コメント"/> --> 上記の例では、action属性に設定されたuserManageController.changePassword()が呼ばれてしまう。 生成されたHTMLを
Apache MyFaces Extension Validator(extVal)で相関チェック - n-agetsumaの日記
BeanValidationはJSF2.xと統合した場合に、JSFから自動的に呼び出されるのはプロパティ単位のバリデーションのみである。クラス単位のバリデーションは呼び出されない。 (参考 http://stackoverflow.com/questions/11972419/cross-field-bean-validation-why-you-no-work ) この仕様上、BeanValidationの自作ルールでフィールド間チェック(cross-field valudation)を実装してJSFに適用するのは難しい。そんなときの使えるのがApache MyFacesが提供している拡張バリデータ「extVal」である。 MyFacesと関連がありそうだが、JSFの仕様を満たしているソフトウェア上ではなんでも動くようだ。手元ではJBossAS7にバンドルされたmojjaraで動かしてい
CDIとiBATIS2.3を組み合わせる - n-agetsumaの日記
ネイティブクエリのみをシンプルに実行したい場合は、まだまだiBATIS(MyBATIS)を使う機会もあると思います。ここではiBATIS2.3とJava EE6のContest and Dependency Injection(CDI)を組み合わせて、JPAのEntityManagerのように、iBATISのSqlMapClientをインジェクションする方法を考えます。 まず、iBATISの設定ファイル(SqlMapConfig.xml)を読み込んで、初期化する部分のコードです。 // import文はポイントなる部分だけ抜粋 import javax.annotation.PostConstruct; import javax.ejb.Singleton; import javax.ejb.Startup; import javax.enterprise.inject.Produces;
JSF2.xでValidationグループを設定する - n-agetsumaの日記
BeanValidation1.0では、@NotNullなどの各検証アノテーションにgroup属性を設定することができます。これは、同じドメインオブジェクトに対して、検証のルールのパターンが複数ある場合に有効です。 例えば、以下のような画面を想定してみます。 本の登録では、ISBNコードとタイトルの両方の入力を必須とします。検索の場合は、どちらか一方が指定されていれば良いこととします。この入力値がバインドされるドメインオブジェクトは両方とも本を示すBookクラスです。 /** 検索の場合にも両方とも必須入力となるケース */ public class Book { @NotNull private String isbn; @NotNull private String title; // getterとsetterは省略 } 上記のように、何もグループを指定せずに@NotNullをフィー
BeanValidationで日本語メッセージを出力する - n-agetsumaの日記
BeanValidation1.0の参照実装であるHibernate Validatorのデフォルトメッセージは英語です。 例えば@NotNullでは「may not be null」、@AssertTrueでは「must be true」といったメッセージが出力されます。通常、JSF2.0を組み合わせて使うときには『"名前"が入力されていません』のように、日本語でかつ入力箇所をメッセージとして出力したいかと思います。 具体例を紹介すると、以下のようなコードを書いた場合のメッセージ表示についてです。 こんな入力フォーム(facelets/XHTML)を作って <h:inputText id="isbn" label="ISBNコード" value="#{controller.book.isbn}" /> <br/> <h:message for="isbn" errorStyle="col
@NotNull/@NotEmpty/@NotBlankの違い - n-agetsumaの日記
JavaEE6から新しい仕様BeanValidation(JSR303)が導入されています。 BeanValidationではアノテーションでユーザ入力チェックを定義することができます。Struts1.xではvalidation.xmlの記述量が多く、度重なるタイプミスとランタイムエラーに苦しめられてきましたが、アノテーションのタイプミスはコンパイル時にチェックされるので、苦しみが軽減されています。 JSF2.0と組み合わせて使用するとき、「必須入力チェック」について同じような意味を持つアノテーションがいくつかあったので、違いを以下にまとめておきます。 以下のようなPersonクラスを定義し、各アノテーションの挙動の違いを確認します。 import javax.validation.constraints.NotNull; import org.hibernate.validator.co
JSF2.0でボタンの２度押しチェックをする - n-agetsumaの日記
この記事は Java EE Advent Calendar 2012*1 の12/18分の記事です。 昨日は@yumix_hさんの JAX-RSでファイルアップロード! です。 明日は@den2snさんです。 今回は、ボタンの2度押しチェックについて考えてみたいと思います。 1. ボタンの2度押しとは 2度押しと書くと、直感的にSubmitボタンを連打されることが思い浮かびますが、Webアプリケーションでよくある問題として、画面遷移後にF5(更新)された場合も意図しない多重POSTが発生します。以下の図をみてください。 JSF2.0を使う場合に、それぞれの2度押しにどう対処するかを以下に示します。特に2つ目に紹介するトークンの実装は手間がかかったので、もっとシンプルな方法があれば大歓迎です。 2. Post-Redirect-Getによって、ブラウザ更新による再POSTを防ぐ Post-R
CDIとMyBATIS3.1を組み合わせる - n-agetsumaの日記
iBATIS2.xの後継ソフトウェアである、MyBatis3.xとJavaEE環境をどう組み合わせるか考える。 MyBatis3.xは、iBATISの開発グループがApache Software FoundationからGoogleCodeに場所を移して開発が続けられているSQLベースのO/Rマッパである。2010年5月にバージョン3.0がリリースされ、2013年1月現在のバージョンは3.1.1である。 JPA(主にHibernate)のようなSQLコーディングなしでDBアクセスというわけにはいかないが、機能がシンプルであり、マニュアルもポイントが絞られて書かれているので覚えやすいフレームワークだ。マニュアルが日本語に翻訳されているのも嬉しい。 1. iBATISとMyBATISの違い 実際に触ってみて、主に2つの点が便利になっている(と私は思う)。 複数データソースを1ファイルで定義 i
ELとCDI管理Beanがうまく結びつかないとき - n-agetsumaの日記
Struts1.xユーザがJSF2.0に移行すると、javax.el.PropertyNotFoundExceptionが500エラーの原因として表示されたり、@ModelでアノテートしたCDI管理Beanのパラメータが#{bean.property}でうまく出力されないことがあると思います。 この原因は主に２つあります。 1. CDI管理Beanにgetter/setterメソッドを忘れている Strutsのように操作(Action)と状態(ActionForm)が分かれたプログラミングモデルに慣れていると、どうしても見落としがちなのがアクセッサです。例えば、以下のような簡単なBeanを想定します。 CDI管理Bean(StrutsのAction相当)のソース @Model public class BookController { /* 画面から入力したデータをインジェクション */
JavaEE7の"Managed Bean"の行方 - n-agetsumaの日記
JavaEE6を使い始めて、つまずいたのが"Managed Bean"の考え方。 JavaEE6では、大きく分けて以下のコンテナ管理Beanがある。 JSFのManagedBean CDIのManagedBean EJBのManagedBean Servlet、Filter、JAX-RS、JPAなどのその他コンテナ管理オブジェクト @javax.annotation.ManagedBeanでアノテートされたクラス それぞれどんなコンセプトがあって、JavaEE7に向けてどう整理していくのか。 JavaEE7仕様策定エキスパートグループのメーリングリストでも議論されている。 以下、不正確な点も多いと思うが、JavaEEのSpecLeadの提案を翻訳してみた。 原文と、本文中に出てくるMatrix(表資料)のURLはこちら。 http://java.net/projects/javaee-sp
Java EE 7 バッチ標準仕様について調べてみた - n-agetsumaの日記
JavaOne2012でセッションを聞いてから、ずーっとさぼっていたがやっと調べた。 Batch Applications for the Java Platform (JSR352) Javaバッチフレームワークの標準仕様がJava EE 7に向けて策定が進められている。 Spring Batchをベースに策定され、現在のステータスはPublic Reviewが終わった段階。上半期中には最終仕様が出てくると思う。詳細についてはJCPのページから確認できる。 なぜJavaでバッチ？ バッチというと、COBOLとか汎用機とかベテランとかそんな言葉が思い浮かぶが、やはり同じ開発プロジェクトでオンラインとバッチを両方開発するとき、プログラミング言語が変わるとメンバも変わってきて、コミュニケーションにも影響してくるからではないだろうか。 『プログラミング言語は適材適所』という考え方ももちろんあると
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
