[Investigation] VpnCheckerService mixes reactive and blocking code (potential performance issue)

[GabrielNat1]

VpnCheckerService (src/main/java/com/example/spring_boot_project/vpn/service/VpnCheckerService.java) mixes reactive patterns with blocking calls and may block event-loop/reactive threads, causing performance problems.

Evidence

• externalCheck() calls callVpnApi(ip).block(Duration.ofSeconds(5)), blocking a reactive Mono.
• isVpn() uses reactiveRedisTemplate.opsForValue().get(...).map(Boolean::parseBoolean).block(Duration.ofMillis(200)).
• The reactive save/set call for caching appears to lack subscription (commented placeholders), so caches may not be persisted.

Impact

• Blocking reactive threads can degrade throughput and lead to timeouts under load.
• Cache writes may not execute, causing repeated external API requests and higher latency.

Recommendations

1. Make the service fully reactive: return Mono/Flux from methods and avoid .block() in reactive flows.
2. If synchronous/blocking behavior is required, perform blocking calls on an appropriate Scheduler (e.g., boundedElastic()) to avoid occupying reactor event-loop threads.
3. Ensure reactive Redis set operations are subscribed or composed into the reactive flow (do not rely on fire-and-forget without subscription).
4. Add integration/load tests to validate behavior when Redis or the external API is slow/unavailable.

Related files

• src/main/java/com/example/spring_boot_project/vpn/service/VpnCheckerService.java