Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Health Probe for frozen server.

Is there a way to add health check to stop sending requests to a hung server (JVM)? I have 2400 Viprion.

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Disabling a node will stop node monitors for that node. Disabling a pool member will stop pool monitors for that member.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Not sure what your concerns are: Is it that you think a conventional HTTP monitor will not take out a hung server out of the server pool quick enough?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Yes. It didnt work last time. its a JVM. F5 keeps on forwarding to the hung server.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I am using 'tcp half open'. is there a custom monitor, I can create.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

If its hung and the F5 marks it as down, then am sure there is an iRule where you can disable it based on this condition. As uni mentioned, if its disabled the F5 wont send out monitor probes. Think this satisfies your requirement.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Presumably the server was still acknowledging the TCP SYN requests. TCP half-open is rarely a good choice of monitor.

Consider what you would consider an indicator that the JVM is not hung, and create a monitor accordingly. If you can't use an http monitor (with send and receive strings), see if you can devise a TCP monitor with send and receive strings.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

A "hung" serve is perhaps too general a description, and you need to find out exactly what made the server hang and in what way. For existing requests might be taking a long time to process, the OS might still be responsive, and the jvm might still be taking new incoming requests but was just not able to process them, in which case a TCP Half Open monitor would not be effective if not making things worse.

You can just create a simple HTTP monitor modeled after a generic one, using a rare random string, e.g. "/xkxjskdlskfdjgf" as the request path; if you get an error response, most likely "404 Not Found", then the jvm Webserver is working. Bear in mind that this monitor only checks if your webserver is processing an http request, not if your java application is actually working. For that you should really ask the app admin to provide a URL with defined output for use in your monitor.

0