Tech-Reader.blog

  The Secret Life of JavaScript: Memories # javascript # coding # programming # softwaredevelopment The Ghost Room: A Story of Closures and the Variables That Refuse to Die. Timothy stood in the doorway of a small, private study off the main library hall. He had just finished a task inside—calculating a specific number—and had written the result,  42 , on a slip of paper. He placed the paper on the desk, stepped out into the hallway, and shut the door firmly behind him. "Well, that is done," Timothy said, brushing dust from his coat. "The function has finished running. The Janitor will be along any moment to sweep the room clean." Margaret, standing nearby with a ring of keys at her belt, shook her head slightly. "Are you certain the room will be swept, Timothy?" "Of course," he replied. "That is the rule of the  Garbage Collector . When a function finishes, its local variables—its stack frame—are destroyed. The memory is freed. The room goe...

  The Complete SQS Troubleshooting Guide (The Most Common SQS Failure Traps) # aws # sqs # devops # cloud SQS is a powerful tool, but it requires you to respect its boundaries. Amazon SQS (Simple Queue Service) is deceptively simple. You send a message, you receive a message, you delete a message. But "Simple" does not mean "Foolproof." Most teams run into the same invisible walls: messages that vanish, queues that won't drain, bills that spike, and retries that loop forever. This  Fix-It Hub  collects the most common SQS failure modes—and exactly how to fix them. Part 1: Why Your DLQ Is Ignoring You The Symptom:  You configured a Dead-Letter Queue (DLQ), but failed messages never show up. They just disappear silently. The Trap:  It isn’t a bug; it’s usually a permission or logic error. Silent Drops:  If your Source Queue cannot  write  to the DLQ (IAM permissions) or  encrypt  with the DLQ's key (KMS), SQS drops the message. Premature D...

AWS SQS Error: SQS Redrive Back to Source # aws # sqs # devops # cloud This is not a failure of the Redrive tool. It is a timing and logic failure. Problem You have a Dead-Letter Queue (DLQ) full of failed messages. You identified the bug in your consumer code. You used the SQS console to "Start DLQ Redrive" to move messages back to the source queue. The DLQ drains to zero. But minutes (or seconds) later, the  DLQ fills up again  with the exact same messages. No processing succeeded. No data was saved. You just created a loop. Clarifying the Issue This is not a failure of the Redrive tool. It is a  timing and logic failure . When you redrive a message: SQS moves it back to the Source Queue. It re-exposes the message to consumers immediately. If the consumer fails again, the message cycles back to the DLQ. The Failure:  If the consumer code is not actually fixed, or if the data itself is invalid ("poison"), the consumer will fail again. The message will increment its...

  AWS Error: SQS Long Polling vs Short Polling # aws # sqs # devops # cloud Why your queue looks empty — or your bill Is high Problem Your application reads from an Amazon SQS queue, but: Messages arrive with noticeable delay The queue often looks empty even though producers are sending messages Your SQS bill shows a high number of  empty receives Polling feels inefficient and unpredictable Nothing appears “broken,” yet performance and cost don’t line up with expectations. Clarifying the Issue This is almost never a throughput problem. It is almost always a  polling configuration mismatch . By default, SQS uses  Short Polling , which: Returns immediately Often returns no messages Can miss messages temporarily Generates many empty receives Long Polling  changes this behavior entirely — but only if it’s explicitly enabled  and  supported by the client. Why It Matters Polling strategy affects  latency, reliability, and cost . Short polling: Increases...

AWS SQS Error: SQS Message Retention Period # aws # sqs # devops # cloud Why messages “disappear” Problem Messages are sent to an Amazon SQS queue successfully. Later, you go looking for them—and they’re gone. They were not processed They were not deleted by consumers No DLQ entries exist No errors were logged The messages simply  vanished . Clarifying the Issue This is almost never a bug in SQS. It is almost always the  Message Retention Period  doing exactly what it is designed to do. Every SQS queue has a retention window: Messages older than this window are  permanently deleted This happens automatically No consumer action is required No warning is issued Once the retention period expires, the message is gone forever. Why It Matters Many teams implicitly assume: “If a message is in SQS, it will stay there until something processes it.” That assumption is wrong. SQS is  not durable storage . It is a  time-bound buffer . When retention is misunderstood, t...