kagamihogeの日記

kagamihogeの日記です。

spring-integrationでファイル作成を検出するサンプル

spring-integration勉強中です。

というわけで https://github.com/pakmans/spring-batch-integration-example の方のコードを参考に、監視先ディレクトリにファイルが作られたらメッセージハンドラが呼び出される、というだけのコードを動かした。詳しいことはまだ良く分かっていない。

<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>kagamihoge</groupId>
    <artifactId>integratesample1</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>integratesample1</name>
    <url>http://maven.apache.org</url>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.6.RELEASE</version>
        <relativePath />
    </parent>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <java.version>11</java.version>
        <maven-jar-plugin.version>3.1.1</maven-jar-plugin.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-integration</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.integration</groupId>
            <artifactId>spring-integration-file</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>
package kagamihoge.integratesample1;

import java.io.File;

import org.springframework.boot.WebApplicationType;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.integration.channel.DirectChannel;
import org.springframework.integration.core.MessageSource;
import org.springframework.integration.dsl.IntegrationFlow;
import org.springframework.integration.dsl.IntegrationFlows;
import org.springframework.integration.dsl.Pollers;
import org.springframework.integration.file.FileReadingMessageSource;
import org.springframework.integration.file.FileReadingMessageSource.WatchEventType;
import org.springframework.integration.file.filters.SimplePatternFileListFilter;

@SpringBootApplication
public class App {
    public static void main(String[] args) {
        new SpringApplicationBuilder(App.class).web(WebApplicationType.NONE).run(args);
    }

    @Bean
    public IntegrationFlow sampleFlow() {
        return IntegrationFlows //
                .from(fileReadingMessageSource(), c -> c.poller(Pollers.fixedDelay(5000)))//
                .channel(new DirectChannel()) //
                .handle(msg -> {
                    File file = (File) msg.getPayload();
                    System.out.println(file);
                }) //
                .get();
    }

    @Bean
    public MessageSource<File> fileReadingMessageSource() {
        FileReadingMessageSource source = new FileReadingMessageSource();
        source.setDirectory(new File("dropfolder"));
        source.setFilter(new SimplePatternFileListFilter("*.txt"));
        source.setUseWatchService(true);
        source.setWatchEvents(WatchEventType.CREATE);
        return source;
    }
}

上記を起動して監視先ディレクトリに適当にファイルを作る。そうすると以下のように出力される。

2019-06-26 22:04:10.636  INFO 5224 --- [           main] kagamihoge.integratesample1.App          : Started App in 1.366 seconds (JVM running for 1.679)
dropfolder\sdf - コピー (2).txt
dropfolder\sdf - コピー (3).txt
dropfolder\sdf - コピー.txt
dropfolder\sdf.txt

これでとりあえず、ファイル作成を検出してメッセージハンドラに通知が飛ぶ、というのが出来た。

JEP 353: Reimplement the Legacy Socket APIをテキトーに訳した

http://openjdk.java.net/jeps/353

JEP 353: Reimplement the Legacy Socket API

Owner    Alan Bateman
Type    Feature
Scope   JDK
Status  Proposed to Target
Release 13
Component   core-libs / java.net
Discussion  net dash dev at openjdk dot java dot net
Effort  S
Reviewed by Brian Goetz, Chris Hegarty, Michael McMahon
Endorsed by Brian Goetz
Created 2019/02/06 13:49
Updated 2019/05/16 19:55
Issue   8218559

Summary

java.net.Socketおよびjava.net.ServerSocket APIで使われる基底実装のリプレース。メンテナンスとデバッグがしやすいシンプルで近代的な実装にします。新規実装は、ユーザモードスレッドいわゆるfibersを使いやすいようにします。Project Loomを参照してください。

Motivation

java.net.Socketjava.net.ServerSocket APiとその基底実装はJDK 1.0の時代から存在します。この実装はレガシーJavaとCのミックスでメンテナンスとデバッグが極めて困難です。I/Oバッファーにスレッドスタックを使用しており、この方法ではデフォルトのスレッドスタックサイズを数回増やす必要がありました。非同期closeにネイティブデータ構造を使用しており、厄介な信頼性と移植性の問題が長年続いています。また、コンカンレンシーの問題もあり適切に対処するには全体的な改修が必要です。ネイティブメソッドでスレッドをブロックする代わりにfiberを将来的に使用する事を想定すると、現行実装ではフィットしません。

Description

java.net.Socketjava.net.ServerSocket APIはすべてのソケット操作をjava.net.SocketImplにデリゲートし、こうしたService Provider Interface (SPI)はJDK 1.0から存在しています。これの組み込み実装は“plain”実装と呼ばれており、非publicのPlainSocketImplとそのサポートクラスSocketInputStreamSocketOutputStreamがそれです。PlainSocketImplは2つのJDK内部実装が拡張しており、SOCKSとHTTPプロキシサーバ経由のコネクションを行います。デフォルトでは、SocketServerSocketはSOCKSベースのSocketImplで生成(場合により遅延生成)します。ServerSocketの場合、SOCKS実装の使用は奇妙な事であり、これはJDK 1.4のプロキシーサーバコネクションの実験的サポート(と削除)にさかのぼります*1

新実装NioSocketImplPlainSocketImpldrop-in replacementです。メンテナンスとデバッグをしやすくするために開発します。New I/O (NIO)などJDK内部機能を使用し、ネイティブコードを無くします。既存のバッファキャッシュ機能と統合し、I/Oにスレッドスタックを使う必要性を無くします。synchronizedメソッドではなくjava.util.concurrentのロックを使用し、将来的にfibersを使用できるように備えます。JDK 11のNIO SocketChannelとその他のSelectableChannel実装の再実装は同じ目標の下に実施しました。

以下は新規実装のポイントです。

  • SocketImplはレガシーSPIで極めてunder-specifiedです。新規実装は旧実装との互換性維持を、unspecifiedな振る舞いと該当する例外(exceptions where applicable)のエミュレートで行います。以下のRisks and Assumptionsセクションで新旧実装間の振る舞いの差の詳細を説明します。
  • タイムアウトを使うSocket操作(connect, accept, read)は、ソケットをノンブロッキングモードとソケットポーリングに変更して実装します。
  • java.lang.ref.CleanerSocketImplGC時にソケットをクローズするのに使用し、ソケットの明示的クローズは行っていません。
  • コネクションリセットハンドリングは旧実装と同様な方法で実装し、コネクションリセット後にreadしようとすると一貫して失敗します。

ServerSocketはデフォルトではNioSocketImpl(もしくはPlainSocketImpl)を使うよう修正します。SOCKS実装は使いません。

SOCKSとHTTPプロキシサーバのSocketImpl実装はデリゲートするよう修正し、新旧実装どちらでも動かせるようにします。

Java Flight RecorderのソケットI/O用のinstrumentation supportはSocketImplと独立するよう修正し、新・旧・カスタム実装のいずれの実行時にもソケットI/Oイベントを記録可能にします。

20年後に実装を切り替える際のリスク軽減のため、旧実装は削除しません。旧実装はJDKに残して、旧実装を使うためのJDKシステムプロパティを導入します。旧実装に切り替えるJDKシステムプロパティはjdk.net.usePlainSocketImplです。これを設定、ないしtrueに設定すると、起動時に旧実装を使用するようになります。将来リリースでPlainSocketImplシステムプロパティを削除する予定です。

本JEPの時点ではDatagramSocketImplの代替実装は提供しません(DatagramSocketImpljava.net.DatagramSocketがデリゲートする基底実装です)。組み込みデフォルト実装(PlainDatagramSocketImpl)はメンテナンス(と移植)の負荷が高く、別のJEPで扱う予定です。

Testing

jdk/jdkリポジトリの既存テストを新規実装に使用します。jdk_netテストグループでは長年にわたりネットワーキングにおける多数のコーナーケースの蓄積があります。テストグループのいくつかのテストは2回実行するよう修正し、2回目では-Djdk.net.usePlainSocketImplJDKが新旧実装を両方含む場合でも旧実装がbit-rot*2しないことを確認します。

今日では、java.net.Socketjava.net.ServerSocketでなくjava.nio.channelsを使うライブラリを直接・間接に使用するコードが多くあります。本提案の周知を行い、SocketServerSocketを使っているコードをearly-accessビルドでテストする事を開発者に奨励するような活動を行う予定です。early-accessビルドはjdk.java.netかどこかで公開します。

jdk/jdkリポジトリのマイクロベンチマークにはソケットのread/writeとストリーミング用のテストがあります。これらベンチマークは新旧実装間の比較を簡単に出来るよう改良が加えられてきました。現状、ソケットread/writeテストにおいて、新規実装は旧実装に比べて同じか1-3%良くなっています。

Risks and Assumptions

本提案の第一のリスクは、新旧実装で異なる振る舞いをするコーナーケースにおいてunspecified behaviorに依存する既存コードです。現在認識してえる相違のリストは以下の通りで、最初の2つ以外は-Djdk.net.usePlainSocketImplにより軽減できます。

  • PlainSocketImplgetInputStream()getOutputStream()が返すInputStreamOutputStreamは、それぞれjava.io.FileInputStreamjava.io.FileOutputStreamを拡張しています。これに依存する既存コードは、理論的にはありえますが、可能性としては低いです。
  • カスタムのSocketImplを使用するServerSocketは、プラットフォームのSocketImplを使うSocketを返すコネクションは使えません。同様に、プラットフォームのSocketImplを使うServerSocketは、カスタムのSocketImplを使うSocketを返すコネクションを使えません。
  • 旧実装が返すInputStreamOutputStreamはストリームのEOFをチェックして他のチェック前に-1を返します。新規実装はストリームEOFチェック前にnullと境界チェックをします。チェック順序に依存する壊れやすい実装は、理論的にはありえますが、可能性としては低いです。
  • Java SE 9でSocketServerSocketに導入されたsetOption(SocketOption<T>, T value)は、ソケットオプションの値が非validな場合にIllegalArgumentExceptionをスローします(例:ソケットバッファサイズに負の値を指定)。旧実装は間違った例外をスローする場合があります。新規実装は期待通りの例外をスローするものの、既存コードが現在とは異なる方法で失敗する可能性があります。
  • Oracle Solaris specific: Oracle Solarisはアプリケーションに"connection reset"を伝える方法が他のプラットフォームと異なります。例えば、setsockoptioctlはネットワークエラーで失敗する可能性があります。/etc/systemxnet_skip_checksを設定することでこの振る舞いを無効化できます(echo "xnet_skip_checks/W 1" | mdb -kw)。The old implementation handles the case where ioctl(FIOREAD) fails so that attempts to read after available fails with a “connection reset” will fail consistently. This is fragile and unmaintainable, the new implementation does not attempt to emulate this behavior.
  • Oracle Solaris specific: Oracle Solarisは接続後にTCPソケットにIPV6_TLCASSソケットオプションを変更出来ません。旧実装はsetTrafficClassの指定値をキャッシュすることでこれをマスクしています。
  • java.netパッケージにはSocketExceptionのサブクラスが多数存在します。新規実装は旧実装と同じSocketExceptionをスローしますが、そうでないものもあります。また、例外メッセージが異なるケースも多数あります。例えばMicrosoft Windowsでは、旧実装はWindows Socketエラーコードを英語オンリーのメッセージに変換していましたが、新規実装はシステムメッセージを使用します。

振る舞いの相違とは別に、新規実装のパフォーマンスは特定のワークロード実行時に旧実装と異なる可能性があります。旧実装では、ServerSocketacceptを呼ぶ複数のスレッドがカーネルにキューします。新規実装では、単一スレッドがacceptシステムコールをブロックし、それ以外はjava.util.concurrentのロックを得るためにqueue waitingします。パフォーマンス特性はこれ以外の場合にも起こりえます。

最後に、instrumentation agentsやツールでI/Oイベント取得に非publicのjava.net.SocketInputStreamjava.net.SocketOutputStreamクラスを呼ぶものがあります。これらのクラスは新規実装では利用できません。

*1: the use of the SOCKS implementation is an oddity that dates back to experimental (and since removed) support for proxying server connections in JDK 1.4. が原文。あんま訳に自信無し

*2:ぐぐってみると直訳すれば「bitが腐る」なので、ここでは「コードベースを壊す」ぐらいの感じだろうか

JEP 310: Application Class-Data Sharingをテキトーに訳した

https://openjdk.java.net/jeps/310

JEP 310: Application Class-Data Sharing

Owner    Ioi Lam
Type    Feature
Scope   Implementation
Status  Closed / Delivered
Release 10
Component   hotspot / runtime
Discussion  hotspot dash dev at openjdk dot java dot net
Reviewed by Karen Kinnear, Mikael Vidstedt, Vladimir Kozlov
Endorsed by Mikael Vidstedt, Vladimir Kozlov
Created 2017/08/08 22:02
Updated 2018/08/17 20:35
Issue   8185996

Summary

起動時間とフットプリント改善目的で、既存のClass-Data Sharing ("CDS")でアプリケーションクラスを共有アーカイブ内に配置可能なように拡張します。

Goals

  • 異なるJavaプロセス間で共通のクラスメタデータを共有する事によりフットプリントを削減。
  • 起動時間の改善。
  • JDKランタイムイメージファイル($JAVA_HOME/lib/modules)のアーカイブクラスとプラットフォームおよびシステムクラスローダにロードされるアプリケーションクラスパスを使えるようにCDSを拡張。
  • アーカイブクラスをカスタムクラスローダにロード出来るようにCDSを拡張。

Non-Goals

  • 本実装で使用する共有クラスのアーカイブストレージフォーマットの標準化はしない。
  • 本リリースでは、CDSはユーザ定義モジュール(ex. --module-pathで定義する)のクラスはアーカイブしない。将来リリースでサポート予定。

Success Metrics

本プロジェクトは、(1)複数JVMプロセス間でJavaのクラスメタデータが使用するメモリの著しい削減(2)スタートアップ時間の著しい改善、が達成出来れば成功と考えられます。

実際に適用例としては、

上記の数値は特定のベンチマーク下であり一般的に言えるとは限りません。クラスローダがロードするクラス数およびアプリケーション全体のヒープ使用量に依存します。

Description

JDK 5で導入したClass-Data Sharingは事前にクラスを共有アーカイブにすることで起動時間改善のため実行時にメモリマッピングします。また、複数JVMが同一アーカイブファイルを共有する場合、動的にメモリフットプリントを削減します。

現行のCDSアーカイブクラスのロードにはブートストラップクラスローダのみ使用可能です。Application CDS ("AppCDS")はCDSを拡張し、ビルトインシステムクラスローダ(別名"app class loader")・ビルトインプラットフォームクラスローダ・アーカイブクラスロード用のカスタムクラスローダ、を使用可能です。

大規模エンタープライズアプリケーションのメモリ使用分析によると、アプリケーションクラスローダに数万クラスをロードします。こうしたアプリケーションにAppCDSを適用するとJVMプロセスごとに数十から数百MBを削減可能です。

サーバレスクラウドサービスの分析によると、起動時に数千アプリケーションクラスをロードします。AppCDSでサービスの起動時間短縮とシステムレスポンスタイム全体を改善できます。

Enabling AppCDS

デフォルトでは、Class-Data SharingはJVMのブートストラップクラスローダでだけ有効化されています。-XX:+UseAppCDSコマンドラインオプション指定により、システムクラスローダ(別名"app class loader")・プラットフォームクラスローダ・その他のユーザ定義クラスローダ、でクラスデータ共有を有効化します。

Determining the classes to archive

多数のクラスでアプリケーションをパッケージしても、通常の実行ではそれらの一部のみしか使用しない事が多いです。そうした使用するクラスのみのアーカイブ化により、ファイルストレージサイズと実行時のメモリ使用量を削減します。これを行うには、まず-Xshare:offでアプリケーションを通常実行する際に-XX:DumpLoadedClassListでロードされる全クラスを記録します。

注意点としてデフォルトでは-XX:DumpLoadedClassListはブートストラップクラスローダがロードするクラスのみ含みます。-XX:+AppCDSオプション指定により、システムクラスローダ・プラットフォームクラスローダがロードするクラスも含むようになります。以下は例です。

java -Xshare:off -XX:+UseAppCDS -XX:DumpLoadedClassList=hello.lst -cp hello.jar HelloWorld

Creating the AppCDS archive

AppCDSアーカイブを生成するには、-Xshare:dump -XX:+UseAppCDSオプションを指定し、-XX:SharedClassListFileにクラスのリストを指定し、アプリケーションで使用するのと同じクラスパスを指定します。また、-XX:SharedArchiveFileにクラスを格納するアーカイブファイル名を指定します。注意点として、-XX:SharedArchiveFileが未指定の場合、アーカイブされるクラスはJDKインストールディレクトリに保存されます。

$ java -Xshare:dump -XX:+UseAppCDS -XX:SharedClassListFile=hello.lst \
    -XX:SharedArchiveFile=hello.jsa -cp hello.jar

Using the AppCDS archive

AppCDSアーカイブを生成したら、アプリケーション開始時にそれを使用します。-Xshare:on -XX:+UseAppCDSオプションと、アーカイブファイル名を指定する-XX:SharedArchiveFileを指定して実行します。

$ java -Xshare:on -XX:+UseAppCDS -XX:SharedArchiveFile=hello.jsa \
    -cp hello.jar HelloWorld

Classpath mismatch

-Xshare:dumpのクラスパスは、-Xshare:onのクラスパスと同一もしくはプレフィクスの必要があります。そうでない場合、JVMはミスマッチのクラスパスのエラーメッセージを表示して停止します。ミスマッチの調査には、-Xlog:class+path=infoを追加すると、JVMは期待されるクラスパスと実際に使用されたクラスパスに関する詳細な診断情報を出力します。

Using -Xshare:auto

AppCDSの動作は固定アドレスにアーカイブをメモリマッピングします。ある種のOSでは、address space layout randomization (ASLR)が有効の場合には特に、要求アドレス空間が利用不可能な場合にメモリマッピング操作が失敗することがあります。-Xshare:onを指定する場合、JVMはこれをエラーとして扱い起動を失敗します。この場合にアプリケーションを柔軟に対処させるには、代わりに-Xshare:autoを推奨します。この場合、JVMアーカイブのメモリマッピングに失敗すると、AppCDSを無効化してアプリケーションを通常実行します。

なお、-Xshare:autoはクラスパスのミスマッチの場合にもAppCDSを無効化します。よって、まずミスマッチが無いことを-Xshare:onでテストしてから本番環境で-Xshare:autoにするのを推奨します。

Listing the Classes Loaded from the AppCDS Archive

AppCDSアーカイブからロードされたクラスを参照するには-Xlog:class+load=infoを使います。ロードされたクラス名とどこからロードされたかを表示します。CDSアーカイブからロードされたクラスはsource: shared objects fileの形で表示します。

$ java -Xshare:on   -XX:+UseAppCDS -XX:SharedArchiveFile=hello.jsa \
    -cp hello.jar -Xlog:class+load=info HelloWorld | grep HelloWorld
[0.272s][info][class,load] HelloWorld source: shared objects file

Implementation

  • Platform and system class loaders: HotSpot VMはプラットフォームとシステムクラスローダのクラスロード要求を解釈します。これらローダーがCDSアーカイブのクラスを要求すると、VMは通常のクラスファイルパースおよび検証をスキップし、アーカイブのコピーをロードします。
  • Custom class loaders: カスタムクラスローダがClassLoader::defineClassを呼ぶと、アーカイブクラスとクラスファイルのマッチングを、クラスファイルデータのフィンガープリントでマッチングを試行します。もしマッチする場合、VMはクラスファイルのパースおよび検証をスキップし、アーカイブのコピーを直接ロードします。

Alternatives

複数のJVMプロセスが動的にロードするクラスの共有に共有メモリ領域を検討しましたが、共有のポテンシャルは低く*1実装困難なことが分かりました。

その代わりに、アプリケーションクラスデータの共有をstaticにしました。

  • 'dump'のひと手間が追加。
  • アプリケーションのJARファイルを更新すると再度dumpが必要。

本機能は既存のCDS上に構築するため、実装をシンプルにして、想定ユースケースにおいて高レートの共有を実現します。

Testing

互換性の保証とパフォーマンスを確認する網羅的なテストが必要です。

テストはすべてのサポートプラットフォームで実行します。ある種のプラットフォーム(特にWindows/x86)では、Address Space Layout Randomization (ASLR)が理由でJVMアーカイブマッピングが出来ずにテストが失敗する可能性があります。

Risks and Assumptions

AppCDSはJDK 8とJDK 9のOracle JDKで実装されています。本JEPではそのソースコードをオープンなリポジトリに移行し、一般利用可能にします。AppCDSはJDK 8とJDK 9で網羅的なテストをしているため、互換性と安定性のリスクは低いです。

*1:the sharing potential to be lower