Java App Fails Due to Stuck Threads and External Script Errors

Day 4: The Logging Mistake Nobody talks about this in backend development… Your logging might be slowing down production. ⸻ ⚠️ The Bug We’ve all written this: log.info("User data: " + user); Looks fine. But under load, this becomes a problem: • String concatenation happens every time • Even when logging level is OFF • Adds unnecessary CPU overhead • Can accidentally log sensitive data 👉 Silent performance + security issue ⸻ ✅ The Fix log.info("User data: {}", user); Why this works: • Lazy evaluation (only logs when needed) • No unnecessary object/string creation • Cleaner and structured logs ⸻ In high-throughput systems (millions of requests): Bad logging ≠ small issue It directly impacts: • Latency • GC pressure • Observability quality Logging should be efficient, not just informative. How do you handle logging in production systems? Structured logging / masking / async logs? #BackendDevelopment #Java #SpringBoot #Microservices #Performance #CleanCode #SoftwareEngineering #Developers #TechTips #Logging

CLR & BCL — The Engine Room of .NET You write C#. You hit Run. But what actually keeps your code alive? Meet the two unsung heroes behind every .NET application. 🔧 CLR — Common Language Runtime The CLR is the engine of .NET. It's the environment where your code actually lives and breathes. It handles: 🗑️ Garbage Collection — frees memory you forgot to free 🔒 Type Safety — makes sure you're not doing illegal operations ⚡ JIT Compilation — converts IL to native machine code at runtime 🧵 Thread Management — manages concurrency under the hood 💥 Exception Handling — catches and manages runtime errors Think of CLR as the operating system inside your application. 📚 BCL — Base Class Library The BCL is the toolbox that comes with .NET out of the box. You don't build everything from scratch — BCL has it ready. It includes: System.String → text manipulation System.Collections → Lists, Dictionaries, Queues System.IO → file reading & writing System.Threading → async & parallel programming System.Net → HTTP requests & networking System.Linq → querying data elegantly Without BCL, you'd be writing everything from zero. How they work together: Your C# Code ↓ BCL (ready-made tools you use) ↓ CLR (runs, manages & protects everything) ↓ Operating System / Hardware The simple analogy: CLR = the kitchen (heat, tools, safety rules) BCL = the ingredients already prepped for you You just cook. .NET handles the rest. Which BCL namespace do you use the most? #CSharp #dotNET #CLR #BCL #Programming #SoftwareDevelopment ------------------------------------------------------------- ⚙️ CLR و BCL — غرفة المحركات في .NET بتكتب C#. بتضغط Run. بس إيه اللي فعلاً بيخلي الكود بتاعك يشتغل؟ تعرف على اتنين من أبطال .NET اللي محدش بيتكلم عنهم. 🔧 CLR — Common Language Runtime الـ CLR هو المحرك بتاع .NET. ده البيئة اللي الكود بتاعك فعلاً بيعيش ويتنفس فيها. بيتحكم في: 🗑️ Garbage Collection — بيحرر الـ memory اللي نسيت تحررها 🔒 Type Safety — بيتأكد إنك مش بتعمل عمليات غير قانونية ⚡ JIT Compilation — بيحول الـ IL لكود آلة وقت التشغيل 🧵 Thread Management — بيدير الـ concurrency من تحت 💥 Exception Handling — بيمسك الأخطاء ويتعامل معاها فكر في الـ CLR كـ نظام تشغيل جوه تطبيقك. 📚 BCL — Base Class Library الـ BCL هو صندوق الأدوات اللي .NET بيجيب معاه من أول يوم. مش هتبني كل حاجة من الصفر — الـ BCL جاهزلك. بيشمل: System.String ← التعامل مع النصوص System.Collections ← Lists, Dictionaries, Queues System.IO ← قراءة وكتابة الملفات System.Threading ← async و parallel programming System.Net ← HTTP requests والشبكات System.Linq ← استعلام البيانات بأناقة من غير الـ BCL، كنت هتكتب كل حاجة من الصفر. إزاي بيشتغلوا مع بعض: كودك C# ↓ BCL (الأدوات الجاهزة اللي بتستخدمها) ↓ CLR (بيشغل، يدير، ويحمي كل حاجة) ↓ نظام التشغيل / الهاردوير التشبيه البسيط: CLR = المطبخ (النار، الأدوات، قواعد الأمان) BCL = المكونات المجهزة ليك مسبقاً 🍳 إنت بس بتطبخ. و.NET بيتولى الباقي. إنت أكتر BCL namespace بتستخدمه إيه؟ #سي_شارب #dotNET #CLR #BCL #برمجة #تطوير_البرمجيات

Blogged: Removing byte[] allocations in .NET Framework using ReadOnlySpan<T> https://lnkd.in/etRMxD6U In this post I describe how to remove static byte[] allocations, even on .NET Framework, by using Span<T> look at the associated IL, and discuss the potential risks #dotnet

A recent issue reminded me that performance optimizations can sometimes become production problems. We had an API that: 1️⃣ Fetches initial details 2️⃣ Extracts IDs from the response 3️⃣ Makes another database call to fetch larger secondary data To speed up step 3, parallel processing was introduced using a fixed thread pool. Sounds reasonable — until load testing began. Under heavy traffic, thread creation kept increasing across instances until limits were hit, leading to: ⚠️ "Can't create new native thread" The interesting part? The optimization worked for individual requests. But at scale, the resource model didn’t. A request with a small number of IDs didn’t always need dedicated worker threads, yet threads were still being allocated repeatedly under concurrent load. The fix was moving to a shared/reusable thread pool model with better resource control. 💡 My takeaway: Code that is fast in isolation may fail under concurrency. When designing for performance, it’s important to ask: - How does this behave at 1 request? - How does this behave at 1000 requests? - What resources grow with traffic? Scalability is often less about speed, more about control. #BackendEngineering #Java #PerformanceTesting #Scalability #Concurrency

🚧 C# 15 (Preview) — Union Types Union Type means: 👉 a variable can be one of a fixed set of types (not anything else) 👉 unlike inheritance, it’s a closed set — no one can extend it later 👉 and the compiler forces you to handle every possible case 💡 Example: public record Success<T>(T Data); public record ValidationError(string Message); public record SystemError(string Message); public union Result<T>(Success<T>, ValidationError, SystemError); 👉 Here Result<T> can only be: ➖ Success<T> ➖ ValidationError ➖ SystemError Nothing else ❗ 🧠 Service public class UserService { public Result<UserDto> GetUser(int id) { if (id <= 0) return new ValidationError("Invalid Id"); try { var user = new UserDto(id, "Mofaggol"); if (user is null) return new SystemError("User not found"); return new Success<UserDto>(user); } catch (Exception ex) { return new SystemError(ex.Message); } } } 🌐 Controller [HttpGet("{id}")] public IActionResult Get(int id) { var result = _userService.GetUser(id); return result switch { Success<UserDto> s => Ok(s.Data), ValidationError ve => BadRequest(new { error = ve.Message }), SystemError se => StatusCode(500, new { error = se.Message }) }; } ⚖️ Old vs New (short) ➖ ❌ Old approach: ➖ bool + message ➖ object ➖ exceptions for flow 👉 Not type-safe, easy to miss cases ✅ Union Type: ➖ fixed outcomes ➖ compile-time safety ➖ clean and predictable API 👉 One line: Union Types make your API responses explicit, type-safe, and compiler-enforced 🚀 Read more: https://lnkd.in/dcw33DPc Repo: https://lnkd.in/dfMm5CeY #dotnet #csharp #csharp15 #dotnetdev #aspnetcore #webapi #backend #softwareengineering #programming #cleanarchitecture #ddd #designpatterns #api #restapi #microservices #developer #coding #tech #softwaredeveloper #learncoding #100daysofcode #devcommunity #cloud #azure #fullstack #oop #bestpractices #architecture #codinglife

Proxy Pattern in Spring Boot — The Hidden Engine Behind Your Annotations! We all use annotations like "@Transactional", "@PreAuthorize", "@Aspect"… But have you ever asked: How does Spring actually make them work? --- What is Proxy-Based Pattern? In , a Proxy is an object that wraps your actual bean and intercepts method calls. 👉 Instead of: Client ->Target It becomes: Client -> Proxy- > Target --- Why is this Powerful? Because Spring can add behavior without modifying your code: ✔ Start & commit transactions ✔ Perform security checks ✔ Add logging / auditing ✔ Control execution flow --- Real Example When you use "@Transactional", Spring: 1. Creates a proxy of your class 2. Intercepts method call 3. Starts transaction 4. Calls actual method 5. Commits/Rolls back Your business logic stays clean! --- Interview Trap (VERY IMPORTANT) Self-invocation breaks proxy: public void methodA() { methodB(); // Proxy NOT used } @Transactional public void methodB() { } No transaction will be applied! Why? Because the call does NOT go through the proxy. --- Types of Proxies ✔ JDK Dynamic Proxy → Works with interfaces ✔ CGLIB Proxy → Works with classes --- Why It Matters? Without proxy pattern: 1. No transaction management 2. No AOP 3. No security interception You’d have to write all of this manually (which cause tight coupling ) --- At last we can say that “Spring uses proxy-based pattern to implement cross-cutting concerns like transactions, security, and logging by intercepting method calls without modifying the actual business logic.” --- #Java #SpringBoot #BackendDevelopment #Microservices #InterviewPrep #TechArchitecture #Spring

Popular Article: Much Ado About Nullable: Nullable Reference Types Explained, By Matthew Hess This article by Matthew Hess delves into the world of nullable reference types, exploring what they are and how they can improve code reliability. He explains the concept of non-nullable references, the benefits of using them, and how to integrate this feature into your .NET development workflow. Read the full article published in CODE Magazine here: bit.ly/4sGThg4

Day 26: 🧑💻 Retry Pattern with Exponential Backoff + Jitter: Retry — Handle Transient Failures Safely (Resilience4j + Spring Boot) We had a payment gateway that occasionally returned 503s during traffic spikes. The dev who added retries did the obvious thing: java for (int i = 0; i < 3; i++) { try { return paymentGateway.process(req); } catch (Exception e) { Thread.sleep(1000); // retry after 1s } } Fixed 1-second retry. Clean code. Logical. During the next traffic spike — the gateway went down for 12 seconds. 8,000 requests failed simultaneously. All 8,000 started retrying at exactly t=1s. The gateway tried to recover. 8,000 requests hit it simultaneously again. It went down again. Retry at t=2s. Same result. t=3s. Same result. The gateway never recovered during the spike. Every retry was a new attack. This is the Thundering Herd Problem. Three retry strategies — only one is correct: ❌ Fixed interval t=1s, t=2s, t=3s (all clients retry together) 100 clients fail → all retry at t=1s → server slammed Server starts recovering → all retry at t=2s → slammed again Never recovers ⚠️ Exponential backoff t=1s, t=2s, t=4s, t=8s (doubles each time) Better — fewer calls, server gets breathing room But all 100 clients still retry at EXACTLY t=2s, t=4s, t=8s Still synchronized. Still thundering herd. ✅ Exponential backoff + Jitter Client A: t=0.7s, t=2.3s, t=5.1s, t=9.8s Client B: t=1.3s, t=1.8s, t=4.7s, t=11.2s Client C: t=0.9s, t=2.7s, t=5.5s, t=8.3s Random ±50% added to each wait. 100 clients retry at 100 different times. Server sees a smooth trickle, not a spike. Server recovers. ✅ In Resilience4j: java RetryConfig.custom() .maxAttempts(4) .intervalFunction( IntervalFunction.ofExponentialRandomBackoff( 500, // base: 500ms 2.0, // multiplier: 500→1000→2000→4000ms 0.5)) // jitter: ±50% randomisation ← the fix .retryExceptions(IOException.class, TimeoutException.class) .ignoreExceptions( InsufficientFundsException.class, // ← DON'T retry CardDeclinedException.class) // ← DON'T retry .build(); The most important line: ignoreExceptions This is where most retry implementations go wrong. ✅ Retry: 503 Service Unavailable → server momentarily overloaded ✅ Retry: IOException → network blip ✅ Retry: TimeoutException → slow network, not a bug ❌ Don't retry: 400 Bad Request → fix the request, won't change ❌ Don't retry: 402 Payment Required → card declined — retrying won't help ❌ Don't retry: 404 Not Found → resource doesn't exist Retrying a CardDeclinedException three times doesn't un-decline the card. It just wastes 3×500ms and looks suspicious to fraud detection. #SystemDesign #RetryPattern #ExponentialBackoff #Jitter #Resilience4j #SpringBoot #Java #Microservices #DSA #DesignPattern #Pattern #Spring #Retry

🚨Application is running in production and appears to be working properly. However, even when there are no API calls or incoming requests, it still results in an OutOfMemory(OOM) error. 👉Memory Leak Objects are created but never deleted - memory fills up slowly over time 👉 Background Jobs  Scheduled tasks run silently on timer - not on user requests. They consume memory 24/7. 👉Cron Jobs  Cron jobs are fire at fixed intervals - every minute, hour, or day. Each run can load large data into memory and never release it if not handled properly. 👉JVM Schedulers  Internal JVM schedulers like ScheduledExecutorService, Timer, and TimeTask run completely inside the JVM. If tasks are registered without cancellation and shutdown, they hold memory reference silently 👉Too Many Threads Each thread eats 1MB of RAM. 1000 idle threads = nearly 1 GB gone - no traffic needed. 👉Cache Has No Limit  Your cache keeps storing data but never removes old entries - it grows forever. 👉 Logging Buffers Async loggers hold messages in a queue. If it fills up, it eats your memory. 👉Wrong JVM / Container Configuration  JVM asks for 3GB , Container only has 2.5GB - when your app tried to go beyond 2.5, the OS kills your process or application silently ➡️How to Overcome Memory Leaks -> heap dump analysis  Background Jobs -> use try-finally cleanup Cron Jobs -> batch processing  JVM Schedulers -> shutdown on app exit  Threads -> use fixed thread pool size Cache -> configure time to live on every cache  Logging -> bounded async queue  JVM Config -> match heap to container size 🎯"Memory doesn't need traffic to leak - it just needs time." #OutOfMemory #MemoryLeak #Java #JVM #JavaDeveloper #ProductionIssues #Microservices #Debugging

DAY 23 — Scoped vs Transient vs Singleton in .NET Understanding Dependency Injection lifetimes is a game changer for every .NET developer 🔹 Transient → New instance every time ✔️ Best for lightweight, stateless services ❌ Overuse → Too many objects, performance issues 🔹 Scoped → One instance per request ✔️ Best for DB operations (like DbContext) ❌ Wrong usage → Data leakage or performance problems 🔹 Singleton → Single instance for entire application ✔️ Best for caching, logging, configuration ❌ Wrong usage → Shared state issues, thread problems ⚠️ Why this matters? Choosing the wrong lifetime can lead to: ❌ Memory issues ❌ Data conflicts ❌ Hard-to-debug bugs 📌 Why register in Program.cs? ✔️ Centralized configuration ✔️ Automatic dependency injection ✔️ Lifecycle managed by .NET ✔️ Without it → Runtime error 🔥 Final takeaway: 👉 Transient = Always new 👉 Scoped = Per request 👉 Singleton = One for entire app Choose wisely = Better performance + Clean architecture #Dotnet #CSharp #ASPNetCore #WebAPI #DependencyInjection #SoftwareDevelopment #BackendDeveloper #Programming #CleanCode #CodeQuality #Architecture #PublicLearning #developers #DotnetDeveloper #Developers #CodingLife #Services #Scoped #Singleton #Transient #TechLearning #LearnToCode #100DaysOfCode