When Using XMPP Notifications (tested at least via direct chat) with Users having empty XMPP addresses, I have seen problems with OpenFire 3.6.4.
I use XMPP Notfications with an OpenNMS 1.8.3 and have included Users with an empty XMPP address in the Notification Path.
It seems to me that OpenNMS does not check the existence of a non-empty XMPP_TO and passed empty arguments to the chat server. The OpenFire error-log has a message like this (hostnames XXXXXXed by me), note the empty 'to=""':
2010.08.30 13:11:49 [org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:135)] Closing connection due to error while processing message: <message id="dJq81-64" to="" from="opennms@XXXXXXXXXXX/notifd" type="chat"><body>Das Pollen von HTTP auf Interface YYYYYYYYYY (172.xx.xx.xx) auf Node XXXXXXXXXXXX ist um Monday, August 30, 2010 1:11:41 PM CEST fehlgeschlagen.</body><thread>HgRcn211</thread></message>
Looking at network traffic, this seems to generate an RST packet from the chat server to OpenNMS.
After that, I notice communication failures in the Opennms-notifyd-log file:
2010-08-30 14:42:51,624 FATAL [Thread-35352] XMPPNotificationManager: XMPP Manager unable to connect
I propose checking for non-empty XMPP-To addresses, something along the lines of this change in the send-Method in opennms-services/src/main/java/org/opennms/netmgt/notifd/XMPPNotificationStrategy.java :
if ( ( parsedArgs[XMPP_TO] == null ) || (
"".equals(parsedArgs[XMPP_TO]) ) )
I have not tried this as I have not yet succeeded in building OpenNMS and I do not know all the consequences of having a message fail in this way (return 1).
And of course, thanks for a great product, we are almost at the end of evaluating it and enjoying it very much!