Content tagged with "java"
Integrate the Remote Query Cache Plugin into a Spring Boot app with application.yml config and ApplicationRunner warmup. Verified with both node-based TLS and Serverless ElastiCache.
Confirmed 98.9% hit rate over 1 hour of continuous load. No timeout recurrence after 10-minute idle. Combined with AWS docs' connection reuse recommendation, Serverless + warmup is production-viable for sustained traffic.
Compared node-based+TLS to confirm the initial timeout is Serverless-specific. A warmup connection with a 5-second wait recovers CacheMonitor to healthy state, making Serverless viable for production.
A collection of Java SDK v2 gotchas discovered across the 3-part series. HMAC gaps, enum naming mismatches, class name confusion, and other undocumented pitfalls with workarounds.
Implement TranslatePinData for PIN re-encryption without exposing plaintext, and CMAC for data integrity verification. The core of acquirer processing: key relay without touching the PIN.
Implement 3 core issuer cryptographic operations with Java SDK. Discover how GeneratePinData requires PEK and PVK simultaneously — multiple purpose-built keys cooperating in a single API call.
Create 4 types of payment cryptographic keys with Java SDK, test wrong-key-usage errors, and experience how TR-31 KeyUsage enforcement differs from KMS.
Verified the Remote Query Cache Plugin in AWS Advanced JDBC Wrapper 3.3.0 with ElastiCache for Valkey Serverless. The first connection always times out, pushing CacheMonitor into SUSPECT state — a Serverless-specific issue not seen with node-based clusters.
Verified the Remote Query Cache Plugin in AWS Advanced JDBC Wrapper 3.3.0 with Aurora PostgreSQL (1M rows) and node-based ElastiCache for Valkey. A 749ms window function query dropped to 2ms. TTL-based consistency control worked as expected.
Upgraded AWS JDBC Wrapper from 2.6.4 to 3.2.0 and re-tested Blue/Green Switchover on both PostgreSQL and MySQL. MySQL's connection failure turned out to be timing-dependent (0–1 failures). Summarizes 3.x migration guidance.
Tested Blue/Green Switchover on Aurora MySQL and compared with PostgreSQL. IN_PROGRESS phase was only 3s (vs 12s for PG), but the BG plugin may have 0–1 connection errors (timing-dependent). HikariCP's stale writer problem is engine-agnostic. Plain JDBC stayed on old host for 31s after recovery.
Compared downtime during Blue/Green Switchover across Plain JDBC, HikariCP with retry, and AWS JDBC Driver BG plugin. The plugin recorded 0 failures in 400 queries during testing. HikariCP kept connecting to the old writer — a critical pitfall.
aws-advanced-jdbc-wrapper 2.6.4 brings in slf4j-api 1.7.36 as a transitive dependency, conflicting with HikariCP 6.x which requires SLF4J 2.x. Exclude 1.7 and explicitly declare slf4j-api 2.0.
All connections are dropped during Blue/Green Switchover, but HikariCP may reconnect to the old writer via DNS cache. Write queries fail with read-only transaction errors. Same behavior on both PostgreSQL and MySQL.