Could amazon-kclpy be updated to bundle amazon-kinesis-client 3.4.3? Is this update already in progress?
amazon-kclpy is currently at version 3.1.3, bundling amazon-kinesis-client 3.1.3 (September 2025). The Java KCL library is now at version 3.4.3 (April 2026), which includes several significant bug fixes that are not accessible to Python/MultiLangDaemon users until amazon-kclpy is updated.
Of particular interest is:
- #1734 Fix metricsScope not being closed properly in Scheduler.run (3.4.3)
- #1650 Remove explicit netty dependency to fix mismatched versions (3.2.1)
Environment:
- amazon-kclpy: 3.1.3 (latest available via pip)
- Java: 21 (OpenJDK)
- Python: 3.12
- Deployment: Docker container, AWS EC2
Context:
Over several days of monitoring I have observed slow but persistent RssAnon growth in the Java MultiLangDaemon processes. The growth is continuous and independent of record processing volume — streams processing zero records grow at the same rate as active streams — which points to the KCL infrastructure layer rather than application code. The fix in #1734 (metricsScope not being closed properly) is consistent with this pattern and may well be the cause.
Relevant properties file settings:
metricsLevel=SUMMARY
maxRecords=200
idleTimeBetweenReadsInMillis=200
shardSyncIntervalMillis=60000
failoverTimeMillis=10000
I am happy to provide detailed monitoring data if useful, but I think that an updated version of amazon-kclpy would be the preliminary step in debugging this issue.
Could amazon-kclpy be updated to bundle amazon-kinesis-client 3.4.3? Is this update already in progress?
amazon-kclpy is currently at version 3.1.3, bundling amazon-kinesis-client 3.1.3 (September 2025). The Java KCL library is now at version 3.4.3 (April 2026), which includes several significant bug fixes that are not accessible to Python/MultiLangDaemon users until amazon-kclpy is updated.
Of particular interest is:
Environment:
Context:
Over several days of monitoring I have observed slow but persistent RssAnon growth in the Java MultiLangDaemon processes. The growth is continuous and independent of record processing volume — streams processing zero records grow at the same rate as active streams — which points to the KCL infrastructure layer rather than application code. The fix in #1734 (metricsScope not being closed properly) is consistent with this pattern and may well be the cause.
Relevant properties file settings:
I am happy to provide detailed monitoring data if useful, but I think that an updated version of amazon-kclpy would be the preliminary step in debugging this issue.