TCP session keeps open at an arbitrary port to a Windows Server

Description

On one of the Windows2000/NT server machines we have, Opennms starts opening ports without closing them, every 5 minutes one. See the enclosed graph with the open TCP connection for the Opennms server. Note the drops to 30-40 happen after restarting opennms. Every time Opennms restarts another Windows Server is 'picked', but only one at the time.

Up until now the ports used have been: 1980, 1974 and 4095 that are not even in the capsd-configuration.xml nor the poller-configuration.xml

This happens on Opennms 1.7.2 on an intel machine with Solaris10 x86 06/06 and after we implemented monitoring with WMI for Windows.

Output from:

  1. netstat -an | grep ESTABLISHED :

10.228.130.119.55382 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED

10.228.130.119.55539 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.56102 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.56224 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.56560 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.56893 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.56913 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.57423 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.57619 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.57950 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.58330 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.58352 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.58988 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.59166 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.59665 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
10.228.130.119.59851 10.228.128.91.1980 17520 0 49640 0 ESTABLISHED
.... etc

Environment

Operating System: Solaris Platform: PC

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Matt Raykowski March 16, 2010 at 11:41 AM

This should no longer be a problem. RangerRick moved the mgr.close() to the "finally" block in revision 13077 (rev comment: "disconnect cleanly after any wmi exceptions") - assuredly this was much later after 1.7.2. The solution is more than likely to advise the customer to upgrade.

Seth Leger (community account) March 15, 2010 at 6:00 PM

Is this still an issue? 1.7.2 is kinda old.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

PagerDuty

Created November 6, 2009 at 10:40 AM
Updated January 27, 2017 at 4:25 PM
Resolved May 20, 2010 at 1:27 AM