You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Gary Tully (JIRA)" <ji...@apache.org> on 2010/07/15 17:47:52 UTC

[jira] Assigned: (AMQ-2829) HealthCheck for hardware loadbalancers

     [ https://issues.apache.org/activemq/browse/AMQ-2829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Tully reassigned AMQ-2829:
-------------------------------

    Assignee: Gary Tully

> HealthCheck for hardware loadbalancers
> --------------------------------------
>
>                 Key: AMQ-2829
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2829
>             Project: ActiveMQ
>          Issue Type: New Feature
>         Environment: ALL
>            Reporter: Dirk Alexander Schäfer
>            Assignee: Gary Tully
>            Priority: Minor
>         Attachments: com.swisscom.ei.commons.activemq.zip, jetty.xml
>
>
> hi there,
> we had the problem that we were not able to integrate our network of brokers in our cluster setup where a hardware loadbalancer was in front of the cluster. as the loadbalancer needs to run health checks against each node in the cluster, we needed to find a way to offer an endpoint the loadbalancer could send its probe requests to.
> we decided to develope a little web application that returns "pong" if the jms provider is available, "offline" else. we've created a webapp that can be deployed in the jetty that comes with activemq. i attach the whole eclipse project ziped to this issue. i haven't cleaned it so it will not fitt into the activemq package hierarchy but it should be enough to get an idea of how we did it. i also attach the modified jetty.xml were we added the webapp in order to become it loaded.
> it might look a bit oversized as it is based upon spring web mvc, spring security and tiles but our intention was to be able to put further administrative functionality into the web app once needed.
> how it works: a consumer as well as a producer are being created during the startup of the app. the consumer makes sure that messages get dispatched and do not fill the queue, allthough the messages are marked none-persistence and have a ttl of 5 secs, just to be sure. if a check request comes in (/lbProbe/ping.htm) the app tries to put a message into the queue (the queue name is configurable through spring). if this succeeds, the OK-result will be returned, otherwise the NOT-OK-result. both are configurable through spring.
> known bugs: if one deletes the queue the app is using through e.g. the admin web app, the check will strill return OK.
> things to beware of: the name of the queue the webapp uses should be configured in the excludes of the networkConnector settings ;)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.