• P (unregistered)

    So... where's the punchline?

  • Little Bobby Tables (unregistered)

    That actually made me chortle.

  • eth0 (unregistered) in reply to P

    But what about that HTTP connection to RabbitMQ? How do you check if the HTTP connection to check the AMQP connection has succeeded?

    Maybe you could open a SSH connection to grep the HTTP server logs and see if your request went through. Yeah, sounds good.

  • rosuav (unregistered)

    Doesn't even know about response.json...

  • LXE (unregistered)

    This is a comment you'd normally expect from a devil's advocate, but nevertheless. There are good reasons to

    • write the method;
    • keep it in the code at the prototyping stage;
    • keep it after the prototyping stage. The reasons are:
    • learning the API;
    • keeping a live code sample;
    • having a handy, non-corner-cutting test to check the environment integrity. For the same reasons, this code snippet should migrate from the prototype directly into a unit test suite, without touching production. Followers more orthodox than me tend to host their prototypes in test suites right away, instead of starting from "int main(...)" or "public static void main(...)", but I refuse to admit that my TDD is less TD than theirs.
  • Pabz (unregistered)

    What would happen here if NAT was involved?

  • Brian (unregistered)

    I love how they construct the URL: variable hostname, magic-number port.

  • (nodebb)

    eth0, that is what if response and response.status_code == 200 is for. If the connection failed for any reason, either there won't be a response or there won't be a 200 response code. The code still trusts that the response is going to have json. If the response isn't json, then the code is going to throw an error in the line where they read it as json.

  • Herr Otto Flick (unregistered) in reply to Brian

    5672 is rabbitmq's "well known" port - it listens on port 5672 for amqp, port 15672 for HTTP API, 25672 for inter-node communication, so hardcoding that node isn't so crazy.

  • Andrew (unregistered)

    My comment comes at the ignorance of, before this article, having never heard of RabbitMQ. As I read through this, it seems the code is connecting to a RabbitMQ server and checking something else in that server to find if the connection was successful. That is, the code seems to assume the very subject of verification was already successful in trying to verify it was successful. Isn't it done at:

    def are_we_connected_rabbitmq():
    # condensed/paraphrased
    response = requests.get(...)
    return response
  • I can be a robot if you want me to be (unregistered)

    So many of this type of WTF, where a built-in method isn't used, can be explained by the so-called workaround being written before the built-in method was available. Whether it works or not is one thing, to to chide someone for not using something without showing it was actually available is weak.

  • Gene Wirchenko (unregistered)

    It reminds me about class discussion during my degree about knowing whether one's connection is still up. So you come up with something and then call it. You get a return value indicating the connection is up. Fine. Now, one second later, what do you do? Are you going to trust that one-second-old return value? The connection could have dropped out right after your function returned.

  • (nodebb)

    RabbitMQ would've worked, but it was eaten by a Python. Truly Kafkaesque

  • Julian Jones (unregistered)

    It's interesting to note that RabbitMQ in particular is a fickle beast when it comes to connection status. For instance: when a connection enters blocked state (due to resource limits), it will happily accept packets... And route them to /dev/null. There's hardly any direct feedback, and the client is often unable to react (synchronously, at least), leaving broken pipes (and, in synchronous environments also hung processes) everywhere when the broker is restarted.

    At our company we ultimately "solved" the problem by having a monitoring publisher/consumer pair, which feeds back to the services and tells them to maybe stop using the broker for a bit (an excellent waste of power, designed for lack of proper monitoring software).

  • I Saw a Robot (unregistered)

    Wait... the program opens up a connection to the username?

  • Phil (unregistered) in reply to I Saw a Robot

    That's the first thing I thought too; and on the password port(?)

  • (nodebb) in reply to I Saw a Robot

    username:password@host

  • medievalist (unregistered)

    In the long run it's almost always easier, simpler and more maintainable NOT to use a complex third party tool to solve routine, well understood problems.

    In the short run it pushes the product out on time, though...

Leave a comment on “Bunny Bunny”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article