In a Spring WebFlux application, request processing is reactive, meaning that when a client cancels a request (e.g., due to a timeout or manual cancellation), Spring immediately stops execution by propagating a cancel signal in the reactive stream. However, in some cases, we want to ensure that processing continues , even if the client disconnects. This is especially important when: Database updates or external API calls must be completed to avoid an inconsistent state. Long-running operations should not be interrupted . Logging, auditing, or side effects must still be processed. How to Keep Processing After a Cancel Signal To decouple HTTP request processing from the application logic , we can use the .cache() operator. This ensures that the execution continues , even if the client drops the connection. Understanding .cache() in Reactor <T> Flux...
Many internet service providers (ISPs) require you to use their provided router, and in some cases, these routers don’t support bridge mode. This can be frustrating if you want to use your own high-performance router for better speed, security, or customization. A common workaround is to place your second router in the DMZ (Demilitarized Zone) of the ISP-provided router. In this guide, I’ll explain how to set up your ISP’s router to work with your own router while minimizing issues. How This Works 1. Setting Up DMZ Mode Since your ISP’s router does not support full bridge mode, we’ll use DMZ to forward all traffic to your second router. This allows your better router to handle most of the network management, firewall, and routing tasks. 2. Dealing with Double NAT What is Double NAT? Your ISP’s router continues to perform NAT (Network Address Translation) for devices connected to it. Your second router will also perform NAT for devices connected to it. This is called double ...