25 October 2007

Locating the process that has a specific network port open

Ever tried to start a process on Windows, only to be told that the network port it needs is unavailable?

TNSLSNR for 32-bit Windows: Version - Production
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=mypc.oracle.com)(PORT=1521)))
TNS-12542: TNS:address already in use

Bugger. Now, which process is using that port? The task manager doesn't show you any of these sorts of details.

There's two ways I know of to work out which process which already has the port open.

1. If you have cygwin or MKS or some Unix styled set of command utilities -and who using Windows commands shells wouldn't? -- then you can use the grep and ps commands it provides with the standard netstat command.

First off, use the netstat command with the -ao switch and pipe it into grep to locate the listening details. The -o switch tells netstat to output the process-id of the owner of the port.

D:\>netstat -ao | grep 1521
TCP mypc:1521 mypc:0 LISTENING 2944

Then using the ps command, search for the process-id:

D:\>ps -eaf | grep 2944
SYSTEM 2944 1488 0 11:37:44 CONIN$ 0:00 vmware-authd

This could be combined into a nice awk script I suspect.

2. Use the very handy SysInternals utilities to locate the owning process. These used to be available on the sysinternals.com website, but the site now redirects to Microsoft, so presumably they have purchased them. Good idea Microsoft.

The specific utility for this operation is TCPView:


This comes in two flavours, GUI and cmd line and identifies each process that is using a network port. The GUI is easy to use, just fire it up, look for the port in question which then identifies the process in the process table.

I prefer using the command line utility, tcpvcon.exe.

This results in a nicely formatted text output that shows the process and network port details for all processes that have a network port in use in some manner.

D:\>tcpvcon.exe -a
[TCP] vmware-authd.exe
PID: 2944
Local: mypc:1521
Remote: mypc:0

To make it easier to identify a specific process which owns a specific port, then you can ask the output to be provided in CSV format, which lists each process on a single line, and which you can then pipe into find to locate a specific port

D:\>tcpvcon.exe -c -a | find "1521"

Listening to: John Butler Trio - Good Excuse

11 October 2007

OC4J Ant Taskname Error

OC4J 10.1.3.x supplies a set of Ant tasks that enable operations such as application deployment, resource configuration and server lifecycle tasks to be performed.

The abridged history of the tasks is:
  • OC4J introduced the basic tasks
  • OC4J and later versions extends the set of tasks to support JDBC/JMS resource configuration options and server shutdown/restart tasks
The OC4J Configuration and Administration guide documents the Ant tasks.

However in the OC4J release several of the tasks are incorrectly defined in the antlib.xml and therefore not available using the names as described in the documentation.

The documentation is correct and shows how the tasks should be named. However if you use these tasks as documented you will get errors. The screen capture below highlights the specific differences.

The workarounds are either:

1. Revert to using the names as defined in antlib.xml for these tasks:

  • addDataSourceConnectionPool == createJDBCConnectionPool
  • addManagedDataSource == createManagedDataSource
  • addNativeDataSource == createNativeDataSource
  • testDataSourceConnectionPool == testConnectionPool
2. Update the /j2ee/utilities/ant-oracle-classes.jar!/oracle/antlib.xml to change the names of the tasks so they reflect the correct names as specified in the documentation:

Change: taskdef name="createJDBCConnectionPool"
To: taskdef name="addDataSourceConnectionPool"

Change: taskdef name="createManagedDataSource"
To: taskdef name="addManagedDataSource"

Change: taskdef name="addManagedDataSource"
To: taskdef name="createNativeDataSource"

Change: taskdef name="testConnectionPool"
To: taskdef name="testDataSourceConnectionPool"

A bug has been filed for this and a patch will be released which fixes the issue along the lines of option 2 shown above.

08 October 2007

Bring on UST + Stans

My Turner Flux is shod with a Mavic Crossmax SL wheelset which is UST compatible. I've been riding it with tubes + Maxxis Crossmarks (which I think are awesome) so far since I've been a bit slow to pick up some UST tires -- I'm commerced out I think. Plus I also figured with all the other knobs and dials to tweak, I had enough new stuff to worry about.

But last Friday some new Maxxis Crossmax LUSTs I'd purchased arrived. I was hoping to put them on over the but I didn't quite get a chance to do.

And as fate or that little Irish Murphy bloke would have it, my early Monday morning blast around the Eagle MTB park resulted in a pinch flat just at the end of the SouthSide trail.

I didn't have a spare tube, but thought I was lucky that I had some patches. But of course that little Murphy bloke, smiling ever more cunningly at this stage, somehow conspired to make the CO2 cartridge I carry to refill a tube be empty.

Bugger, a 2km walk, mostly uphill back to the car.

Yes, it's my fault, I know. Always carry a spare tube and a full canister. And if you use the spare tube, make sure you buy another one to replace it. And check the canister occasionally.

The good thing is this means I now have a hard requirement to put on the USTs. I picked up some Stans sealant from Pete at BMCR, so hopefully I won't be suffering too many more punctures.

But I'll will carry a spare tube just in case.

Update: Job done!

I just spent an short while out in the shed fitting the UST tires to the wheels. It's pretty straightforward to do. I think the best piece of advice I received was to do the initial inflation using an air compressor, to get enough volume into the tire to push the beads into place in the rim. The beauty of the Mavic wheelset I discovered is that they provide you with a schraeder screw-on adapter, which lets you use the standard car tire type fitting to pump out the tire. Once the tire is seated, deflate it and make sure there are no points around the rim where the bead has come away. Once you are satisfied pump it back up to the desired using a floor pump. Easy!

Adding Stans was easy too -- just read the direction and make sure you follow the inversion tips to ensure the micro particles are in the sealant portion being added to the tire. Unset the bead from a small portion of the tire, tip in the sealant, reseat and you are done.

Total time was about 30 mins for the first tire, with a bit of mucking around and working out how to do it. The next tire took about 5 minutes to do.

Should be able to get out for a few trails this weekend, I'll update this note when I see how they ride.

Update: Stans 1, Blue Gums 0

Out on my early monday morning ride, cruising across the top of the Blue Gums trail -- which is quite rocky -- I heard a noise that I thought sounded like I had something stuck in my spokes. It went away before I could stop to check it out. When I did stop, I saw a white patch on my tire. Ahh, Stans to the rescue. I must have punctured on a sharp rock and Stans sealed it up almost immediately. I lost a little pressure, but it was still very rideable and got me back to the car easily. Sure beats walking. Pumped it back up at the car and there was no further leakage.

Rock on Stan!