Fixed in stable CVS.

Okay, the code to fix this had been committed to stable.

Here are the test cases:

With nodeUnresponsive set to false:

1) Stop the service
2) Make sure that a nodeLostService event is received
3) Start the service
4) Make sure that a nodeRegainedService event is received.
5) Configure the service to be "unresponsive" - i.e. a connection can be made but expected behavior
does not occur before the timeout (I did this by running httpd on port 25 so the SMTP poller would
make the connection but not get a HELO).
6) Make sure that a nodeLostService event is received.
7) Restore the configuration
8) Make sure that a nodeRegainedService event is received.

With nodeUnresponsive set to true:

1) Stop the service
2) Make sure that a nodeLostService event is received
3) Start the service
4) Make sure that a nodeRegainedService event is received.
5) Configure the service to be "unresponsive" - i.e. a connection can be made but expected behavior
does not occur before the timeout (I did this by running httpd on port 25 so the SMTP poller would
make the connection but not get a HELO).
6) Make sure that a serviceUnresponsive event is received, and no nodeLostService event is generated
7) Restore the configuration
8) Make sure that a serviceResponsive event is received.

Ted - in OpenNMS a service is down if we either can't connect to it or it doesn't respond as expected
in a particular amount of time. In the situation I describe, the server was frozen, dead, passed on,
singing in the choir invisible.

But it still responded to pings and port connections. The SMTP service should have sent a HELO, but it
didn't, so it is down.

However, there are some users who only want their availability affected if the service is totally
unreachable. In that case, they can turn on "serviceUnresponsive" in the poller configuration. This will
generate a serviceUnresponsive/serviceResponsive event pair instead of nodeLostService/
nodeRegainedService.

This is due to some changes in the poller code. Should be corrected soon.

If the service is not down, why would you want it marked as down. I think
unresponsive is indeed an accurate reflection on the state of the service.
For critical machines you probably want to add notifications for unreponsive
services. Your log does indeed show that the
SmtpMonitor: connected to host: /172.20.0.177 on port: 25
than the service is up.