• Drake (unregistered)

    "What if the president's daughter is sick and the server is overheating?"

    "Trust me!"

  • Gigaplex (unregistered)
    <policyEntry topic=">" producerFlowControl="true" memoryLimit="1mb">
    TRWTF is assuming the memoryLimit value is the issue when it's invalid xml (pay close attention to the quotes around the topic value).
  • Gigaplex (unregistered) in reply to Gigaplex
    Gigaplex:
    <policyEntry topic=">" producerFlowControl="true" memoryLimit="1mb">
    TRWTF is assuming the memoryLimit value is the issue when it's invalid xml (pay close attention to the quotes around the topic value).
    Or maybe I should follow my own advice, seems ">" is an acceptable value for a topic?
  • Michael (unregistered)

    Often someone's first (and most egregious) mistake is assuming that they don't make mistakes...

  • (cs)

    This comment is frist, trust me!

  • Anom nom nom (unregistered)

    TRWTF is not using asynchronous message handling.

    Captcha: "incassum" -> "In cassum of CPU bound pooling, fire The Architect."

  • (cs) in reply to Michael
    Michael:
    Often someone's first (and most egregious) mistake is assuming that they don't make mistakes...
    ...which has the corollary, that if something goes wrong, it must be someone else's fault.
  • veniam (unregistered)

    Hidden comments in the article make me smile :D

  • Cicobuff (unregistered) in reply to toon
    toon:
    Michael:
    Often someone's first (and most egregious) mistake is assuming that they don't make mistakes...
    ...which has the corollary, that if something goes wrong, it must be someone else's fault.

    Which is the best way to get promoted to the architect position.

  • michael (unregistered)

    This somehow reminds me of a MQ-powered system I used to work on. Imagine a message-consumer reading messages in batches e.g. 5 in one go and then processing them: M1, M2, M3, M4, M5 If there was a problem with M3 of some sorts, then it would ignore the remaining (M4 and M5) without putting them back onto the queue, but throwing them away without crying for help. So for the outside world it looked like they have been processed fine. Lucky us it never failed. Or did it?

  • (cs)

    This should be taught in school to show that swallowing signals, on error resume next, universal try-catch-log-ignore, and other such "error-avoidance" methods always end up making errors worse instead.

  • Bob (unregistered)

    The real wtf is opening logs in an editor. Saying that, I open 20meg files in vim all the time.

  • (cs) in reply to Bob
    Bob:
    The real wtf is opening logs in an editor. Saying that, I open 20meg files in vim all the time.
    That's cool. Read more carefully, though. A 20 *gig* file might challenge it a little more.
  • (cs) in reply to veniam
    veniam:
    Hidden comments in the article make me smile :D
    Eyes started to roll. Minds started to wonder. Conclusions started to be drawn. Snoofle started to look more and more wtf-y.
  • Flue (unregistered)

    Who's Linda Blair and what does she have to do with this?

    Unless... She's the president's daughter?!

  • Pock Suppet (unregistered)

    I wish we had his problem. We run a legacy phone switch that's about a decade old and two major software versions behind. The vendor-built servers started out below the minimum specs, and one of them (now the backup) can't stay stable for longer than an hour. Things regularly go screwy on the system - not the "hey, that's easily reproducible" sort, but the "WTF - did you just see what I saw?" sort. Despite the normalcy of this situation, we almost never get error reports. Oh, we get emails all the time that say "Oh, noes, a caller hung up early! What do we do?!?!?!?!" or "FYI - we re-ran these queries that didn't go through the first time" or "We couldn't find where to send this email" (that one shows up once per hour for an entire day, but only after a week of not succeeding). Actual errors, though, are exceedingly scarce. There is a separate logging subsystem, but the servers are too underpowered to run it beyond the "Yep, we took a call. Yep, we disconnected a call" level. The logging granularity is such that changing from 41 to 60 (out of 100) doesn't add any messages, but moving up to 61 floods the queue with enough messages to bring the system to a crawl. So far, IT has managed several minor miracles of optimization to keep things running, but that's only served to reinforce upper management's opinion that everything's fine and IT is full of whiners. We've finally had a couple semi-serious incidents lately; TRWTF is that we finally got approval to upgrade the switch. Of course, that was a year ago, and most of that time has been spent cutting red tape and keeping other plates spinning.

    All in all, getting several hundred GB of logs would leave us within a few TB of catching up on the all the logs we should have had over the last ten years.

  • tom (unregistered)

    The good ol' Pokemon Champion exception handling pattern :)

  • WhiteRabbit (unregistered) in reply to Gigaplex
    Gigaplex:
    Gigaplex:
    <policyEntry topic=">" producerFlowControl="true" memoryLimit="1mb">
    TRWTF is assuming the memoryLimit value is the issue when it's invalid xml (pay close attention to the quotes around the topic value).
    Or maybe I should follow my own advice, seems ">" is an acceptable value for a topic?

    This seems to be ActiveMQ, the ">" is a wildcard.

    TRWTF is using topics for reliable messaging instead of queues.

  • (cs) in reply to Pock Suppet
    Pock Suppet:
    So far, IT has managed several minor miracles of optimization to keep things running, but that's only served to reinforce upper management's opinion that everything's fine and IT is full of whiners.
    At the risk of seeming unsympathetic, I'd have to say that it *is* IT's fault that the situation is like it is.

    If you exert heroics to keep a lame (in the sense of crippled, apparently by design) system in operation and to hide the consequences of that lameness, then you cannot expect people to take you seriously when you complain about its shortcomings. Clearly you're just whining about it, because it works.

    If you have hard numbers on the cost in man-hours per quarter for keeping it afloat, you present them, along with a business case (complete with capital costs and estimated support-cost savings) for replacing the train-wreck with a more modern equivalent. If you don't, then you have to become less heroic, preferably right from the beginning. If you haven't been subheroic before, making the change must be gradual, as if the system is breaking slowly over time.

    And when you present the costs, NEVER use the word "guess". Go for the more business-like "estimate" even though you and I know they are effectively synonyms. In the world of business, a guess is a stab in the dark made by someone who doesn't know what he is talking about. An estimate, on the other hand, is based on facts and figures and all that guff, and can therefore be trusted more easily. (Note that I don't say "more accurately" here. In reality, estimates are just guesses with a fancy name, although the effort to produce the justifying facts and figures will usually enable the guess-maker to make a more accurate guess, er, estimate anyway.)

    Again, sorry for the slightly unsympathetic response. Hopefully the rest will serve as a warning to other readers.

  • Anon (unregistered) in reply to Michael
    Michael:
    Often someone's first (and most egregious) mistake is assuming that they don't make mistakes...

    What are these "mistakes" of which you speak? I might like to try making one once.

  • sam (unregistered)

    Isn't the code incorrect in the while loop you try to get a message if its null too.

  • Back in My Day (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Bob:
    The real wtf is opening logs in an editor. Saying that, I open 20meg files in vim all the time.
    That's cool. Read more carefully, though. A 20 *gig* file might challenge it a little more.

    You young kids and your 64 bit operating systems. Older implementations couldn't handle a 2 gig file, let alone 20.

  • Doctor_of_ineptitude (unregistered) in reply to Flue
    Flue:
    Who's Linda Blair and what does she have to do with this?

    Unless... She's the president's daughter?!

    When did Tony Blair become President? Is this part of US-UK special relationship?

  • B (unregistered) in reply to Anon
    Anon:
    Michael:
    Often someone's first (and most egregious) mistake is assuming that they don't make mistakes...

    What are these "mistakes" of which you speak? I might like to try making one once.

    Ask a woman you've dated about it. I'm sure she'll enlighten your to your faults.

  • Doctor_of_ineptitude (unregistered) in reply to Back in My Day
    Back in My Day:
    Steve The Cynic:
    Bob:
    The real wtf is opening logs in an editor. Saying that, I open 20meg files in vim all the time.
    That's cool. Read more carefully, though. A 20 *gig* file might challenge it a little more.

    You young kids and your 64 bit operating systems. Older implementations couldn't handle a 2 gig file, let alone 20.

    Yes, and you also created COBOL and thought MUMPS was quite nice. Damn those hippie non-academic non-tenured engineers creating C.

  • d.k.ALlen (unregistered) in reply to michael
    michael:
    This somehow reminds me of a MQ-powered system I used to work on. Imagine a message-consumer reading messages in batches e.g. 5 in one go and then processing them: M1, M2, M3, M4, M5 If there was a problem with M3 of some sorts, then it would ignore the remaining (M4 and M5) without putting them back onto the queue, but throwing them away without crying for help. So for the outside world it looked like they have been processed fine. Lucky us it never failed. Or did it?

    Hey, did you work where I worked?

  • qbolec (unregistered)

    OK, so TRWTF is not using usleep(100) before continue and in the exception handler, right?

  • someone (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Bob:
    The real wtf is opening logs in an editor. Saying that, I open 20meg files in vim all the time.
    That's cool. Read more carefully, though. A 20 *gig* file might challenge it a little more.

    Not really.

    Opening a 20 GB file is no problem with vim.

    Or emacs.

    There is a reason those editors are considered to be the best editors that were ever made

  • cliffhopper (unregistered)

    Came in expecting <!-- trust me --> in the code, left disappointed.

  • Calli Arcale (unregistered)

    Tip: "Trust Me" should only be trusted if it is followed with "I'm the Doctor." Unless you're a Dalek.

  • (cs)

    Way back when the system was first being designed, the Architect's Architect decreed that communication with the system was to be via JMS messaging.

    Ah, so this was back when GEnie was still around.

  • (cs)

    When I first saw the article's title, "Trust Me", my first thought was "Umm, no."

    When I saw the same title in the code comment, my first thought was still "Umm, no."

    When I got to the end of the article, and there was that request again-- still, "Umm, no."

  • Tzafrir Cohen (unregistered) in reply to Steve The Cynic

    Naturally you could use more to browse it. It uses a constant amount of memory.

    Less is more than more. It has a more usable text search capability (not just simple search forward). It uses more memory. But it will also use O(1) memory (unless you pipe data into it).

    There are also some editors that will work this way. Vim, sadly, is not one of them. I believe that nvi is, though. But my initial test shows that (unlike less) it needs to scan the whole file before providing the initial display (it uses a temporary file?)

  • (cs) in reply to someone
    someone:
    Steve The Cynic:
    Bob:
    The real wtf is opening logs in an editor. Saying that, I open 20meg files in vim all the time.
    That's cool. Read more carefully, though. A 20 *gig* file might challenge it a little more.

    Not really.

    Opening a 20 GB file is no problem with vim.

    Or emacs.

    There is a reason those editors are considered to be the best editors that were ever made

    "Considered" by who? Most engineers I know consider them both a bad joke.

  • (cs) in reply to ZPedro
    ZPedro:
    This should be taught in school to show that swallowing signals, on error resume next, universal try-catch-log-ignore, and other such "error-avoidance" methods always end up making errors worse instead.

    No kidding. I want to know about every error in my app.

  • Dan Mercer (unregistered) in reply to someone

    -- Opening a 20 GB file is no problem with vim. -- Or emacs.

    Do people not use "less" and "more" anymore?

    Captch sagaciter - a bot that generates Bob Saget's "jokes"

  • ymous (unregistered) in reply to Anon

    You need a comma before the word "once".

  • Kasper (unregistered) in reply to Dan Mercer
    Dan Mercer:
    -- Opening a 20 GB file is no problem with vim. -- Or emacs.

    Do people not use "less" and "more" anymore?

    There are people who use less or more, but probably not both at the same time.

    I use less all the time.

    If you are opening log files in an editor, you are doing it wrong. Log files are not supposed to be edited, so why would you use an editor?

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)

    In the Hollywood version, Pritesh and his girlfriend Priya hang over the second-floor lobby balcony railing, talking about how it feels like flying. Then suddenly everyone in the cubicle farm breaks out into a musical dance scene, as The Application crashes into an iceberg.

    Oh wait, sorry, that was the Bollywood version.

    In a world... where The Application was unsinkable... and simply could not go down... Coming soon from Snoofle Studios!

  • (cs) in reply to michael
    michael:
    This somehow reminds me of a MQ-powered system I used to work on. Imagine a message-consumer reading messages in batches e.g. 5 in one go and then processing them: M1, M2, M3, M4, M5 If there was a problem with M3 of some sorts, then it would ignore the remaining (M4 and M5) without putting them back onto the queue, but throwing them away without crying for help. So for the outside world it looked like they have been processed fine. Lucky us it never failed. Or did it?
    Nope. It never failed. Trust Me.
  • (cs) in reply to Dan Mercer
    Dan Mercer:
    -- Opening a 20 GB file is no problem with vim. -- Or emacs.

    Do people not use "less" and "more" anymore?

    Captch sagaciter - a bot that generates Bob Saget's "jokes"

    The sagaciter... Could there be anything more useless? Or should it be less useful?

  • o11c (unregistered) in reply to Kasper
    Kasper:
    I use less all the time.

    If you are opening log files in an editor, you are doing it wrong. Log files are not supposed to be edited, so why would you use an editor?

    I have to disagree - I open readonly files in vim all the time. The simple fact is that 'less' doesn't have nearly as many keybindings for motion and such.

    Captcha: saepius - the next generation of computers that will reject stupid programmers.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to chubertdev
    chubertdev:
    ZPedro:
    This should be taught in school to show that swallowing signals, on error resume next, universal try-catch-log-ignore, and other such "error-avoidance" methods always end up making errors worse instead.
    No kidding. I want to know about every error in my app.
    Ewwww... just today, I had a problem in a build with a post-processing program (CRC generator) that was apparently not post-processing.

    I was only able to see its error message by telling the IDE's build output window to show every message, not just the warnings/errors. Fortunately the error message (that I could now see) produced by the post-processing program was in exactly one place, so I could figure out exactly why "Header format invalid!"

  • Naranek (unregistered) in reply to Kasper
    Kasper:
    Dan Mercer:
    -- Opening a 20 GB file is no problem with vim. -- Or emacs.

    Do people not use "less" and "more" anymore?

    There are people who use less or more, but probably not both at the same time.

    I use less all the time.

    I also use less more or less all the time, and more much less.

  • Rob C. (unregistered) 
           } catch (Throwable t) {
          log.error("...",t);
       }

    RAGE

  • (cs) in reply to Drake
    Drake:
    "What if the president's daughter is sick and the server is overheating?"

    "Trust me!"

    Feature this comment! Hugo Chavezz is no more.

  • n_slash_a (unregistered)

    Oh, I see it now. TRWTF is having the try-catch block at all. After all, if the process will never (and it won't, trust me), then there is no need to wrap it in a try-catch.

  • Peter Meghalos (unregistered) in reply to someone
    someone:
    Opening a 20 GB file is no problem with vim.

    Or emacs.

    There is a reason those editors are considered to be the best editors that were ever made

    Child.

    I directly edit my 2TB hard drive with vim, sector by sector.

  • iMortalitySX (unregistered) in reply to Peter Meghalos
    Peter Meghalos:
    someone:
    Opening a 20 GB file is no problem with vim.

    Or emacs.

    There is a reason those editors are considered to be the best editors that were ever made

    Child.

    I directly edit my 2TB hard drive with vim, sector by sector.

    You guys got too much time on your hands... get on Reddit or something more productive.

  • Jazz (unregistered) in reply to WhiteRabbit
    WhiteRabbit:
    Gigaplex:
    Gigaplex:
    <policyEntry topic=">" producerFlowControl="true" memoryLimit="1mb">
    TRWTF is assuming the memoryLimit value is the issue when it's invalid xml (pay close attention to the quotes around the topic value).
    Or maybe I should follow my own advice, seems ">" is an acceptable value for a topic?
    This seems to be ActiveMQ, the ">" is a wildcard. TRWTF is using topics for reliable messaging instead of queues.

    Oh gods. TRWTF is using a language as janky and bloated as XML for every configuration file. TRWTF is also using ">" as a wildcard, especially since it has a special meaning in XML (since even if it's quoted, it's going to be that much more confusing). And finally TRWTF is ALSO ActiveMQ in general. I wasted the entire summer of 2007 with that pile of dogfood.

    (CAPTCHA: immitto – When your message queue fails, does it immitt an error?)

Leave a comment on “Trust Me”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article