starred/WireMock.Net-wiremock
1
0
Fork 0
mirror of https://github.com/wiremock/WireMock.Net.git synced 2026-01-11 22:30:41 +01:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

Port is left open after process terminates #242

New Issue
Closed
opened 2025-12-29 15:18:57 +01:00 by adam · 20 comments
adam commented 2025-12-29 15:18:57 +01:00
Owner
Copy Link

Originally created by @arnonax on GitHub (Jan 22, 2020).

I started using WireMock.net in my tests, but occasionally when I run the test I get an exception:

Failed to bind to address http://0.0.0.0:9999: address already in use. ---> Microsoft.AspNetCore.Connections.AddressInUseException: Only one usage of each socket address (protocol/network address/port) is normally permitted ---> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted.

Clearly the fault is in the previous run which didn't close the port. Using TCPView from SysInternals, I see that the process which holds that port is "" and I cannot kill it, nor find the PID in Task Manager nor able to kill it using taskkill. The only solution I found is to restart or at least to log-off/log-on to Windows. I searched the Web (and StackOverflow) in order to understand how can a process still hold a port even though it's been terminated, but didn't find any useful explanation.

Because it only happens occasionally, and because each time it happens it requires a restart, it makes it a nightmare to debug and investigate. It seems though that it happens when the sending application crashes while sending or receiving a message, but I'm not sure.

I would like to know:

  1. Is it a bug in WireMock.net? (I couldn't find a similar existing issue)
  2. Do someone knows what's the condition in which the port can be kept open after the process terminates?
  3. How can this be prevented or mitigated?
  4. In case this happens, is there a simpler way to release the port? (maybe there's a service which I can restart?)

Thanks in advance,
Arnon.

Originally created by @arnonax on GitHub (Jan 22, 2020). I started using WireMock.net in my tests, but occasionally when I run the test I get an exception: ``` Failed to bind to address http://0.0.0.0:9999: address already in use. ---> Microsoft.AspNetCore.Connections.AddressInUseException: Only one usage of each socket address (protocol/network address/port) is normally permitted ---> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted. ``` Clearly the fault is in the previous run which didn't close the port. Using TCPView from SysInternals, I see that the process which holds that port is "<non-existent>" and I cannot kill it, nor find the PID in Task Manager nor able to kill it using `taskkill`. **The only solution I found is to restart** or at least to log-off/log-on to Windows. I searched the Web (and StackOverflow) in order to understand how can a process still hold a port even though it's been terminated, but didn't find any useful explanation. Because it only happens occasionally, and because each time it happens it requires a restart, it makes it a nightmare to debug and investigate. It seems though that it happens when the sending application crashes while sending or receiving a message, but I'm not sure. I would like to know: 1. Is it a bug in WireMock.net? (I couldn't find a similar existing issue) 2. Do someone knows what's the condition in which the port can be kept open after the process terminates? 2. How can this be prevented or mitigated? 3. In case this happens, is there a simpler way to release the port? (maybe there's a service which I can restart?) Thanks in advance, Arnon.
adam added the question label 2025-12-29 15:18:57 +01:00
adam closed this issue 2025-12-29 15:18:57 +01:00
adam commented 2025-12-29 15:18:58 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jan 22, 2020):

It probably has to do with tcp port exhaustion
See this page https://docs.microsoft.com/en-us/windows/client-management/troubleshoot-tcpip-port-exhaust and you can find many like this.

When using WireMock in unit-tests, it's adviced to not define a port by yourself, but just let WireMock find a free port. (I'm not sure if you alreay are doing this?)

@StefH commented on GitHub (Jan 22, 2020): It probably has to do with **tcp port exhaustion** See this page https://docs.microsoft.com/en-us/windows/client-management/troubleshoot-tcpip-port-exhaust and you can find many like this. When using WireMock in unit-tests, it's adviced to not define a port by yourself, but just let WireMock find a free port. (I'm not sure if you alreay are doing this?)
adam commented 2025-12-29 15:18:58 +01:00
Author
Owner
Copy Link

@arnonax commented on GitHub (Jan 22, 2020):

@StefH , I don't think so, because I use a fixed port (I also tried to let WireMock choose a port, but the result was the same). Also, both from the error message and from TCPView it's pretty clear that problem is that the previously run process didn't close the port.

@arnonax commented on GitHub (Jan 22, 2020): @StefH , I don't think so, because I use a fixed port (I also tried to let WireMock choose a port, but the result was the same). Also, both from the error message and from TCPView it's pretty clear that problem is that the previously run process didn't close the port.
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jan 22, 2020):

If you use a fixed port, the only thing you can do it wait 30 seconds / 60 seconds.
Else if WireMock determines the port, this should work almost always ok, (It's not 100% I think)

@StefH commented on GitHub (Jan 22, 2020): If you use a fixed port, the only thing you can do it wait 30 seconds / 60 seconds. Else if WireMock determines the port, this should work almost always ok, (It's not 100% I think)
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@arnonax commented on GitHub (Jan 22, 2020):

Unfortunately it doesn't help either. I tried waiting much longer than that until I had to restart.
However, in the last few minutes I had the issue again, and just closed few applications, including the client process, and it released the port. Next time it will happen, I'll try to terminate only the client process to make sure that this is indeed the culprit. It won't answer all the questions, but at least I'll no longer need to restart Windows in order to recover.

@arnonax commented on GitHub (Jan 22, 2020): Unfortunately it doesn't help either. I tried waiting much longer than that until I had to restart. However, in the last few minutes I had the issue again, and just closed few applications, including the client process, and it released the port. Next time it will happen, I'll try to terminate only the client process to make sure that this is indeed the culprit. It won't answer all the questions, but at least I'll no longer need to restart Windows in order to recover.
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@arnonax commented on GitHub (Jan 28, 2020):

Seems like killing the client process released the port. However it happened to me only once since the last message, so I couldn't verify it. And unfortunately I still cannot find exactly when and why it happens.

@arnonax commented on GitHub (Jan 28, 2020): Seems like killing the client process released the port. However it happened to me only once since the last message, so I couldn't verify it. And unfortunately I still cannot find exactly when and why it happens.
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@notclive commented on GitHub (Feb 11, 2020):

I recently upgraded a project from WireMock.Net 1.0.37 to 1.1.7 and tests have started failing randomly with:

 WireMock.Exceptions.WireMockException: Service start failed with error: One or more errors occurred. (Failed to bind to address http://0.0.0.0:41570: address already in use.) --->
 System.AggregateException: One or more errors occurred. (Failed to bind to address http://0.0.0.0:41570: address already in use.) --->
 System.IO.IOException: Failed to bind to address http://0.0.0.0:41570: address already in use. --->
 Microsoft.AspNetCore.Connections.AddressInUseException: Address already in use --->
 System.Net.Sockets.SocketException: Address already in use.

In the tests, ports are being allocated dynamically by WireMock.

@notclive commented on GitHub (Feb 11, 2020): I recently upgraded a project from WireMock.Net 1.0.37 to 1.1.7 and tests have started failing randomly with: WireMock.Exceptions.WireMockException: Service start failed with error: One or more errors occurred. (Failed to bind to address http://0.0.0.0:41570: address already in use.) ---> System.AggregateException: One or more errors occurred. (Failed to bind to address http://0.0.0.0:41570: address already in use.) ---> System.IO.IOException: Failed to bind to address http://0.0.0.0:41570: address already in use. ---> Microsoft.AspNetCore.Connections.AddressInUseException: Address already in use ---> System.Net.Sockets.SocketException: Address already in use. In the tests, ports are being allocated dynamically by WireMock.
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@notclive commented on GitHub (Feb 12, 2020):

I recently upgraded a project from WireMock.Net 1.0.37 to 1.1.7 and tests have started failing randomly with:

 WireMock.Exceptions.WireMockException: Service start failed with error: One or more errors occurred. (Failed to bind to address http://0.0.0.0:41570: address already in use.) --->
 System.AggregateException: One or more errors occurred. (Failed to bind to address http://0.0.0.0:41570: address already in use.) --->
 System.IO.IOException: Failed to bind to address http://0.0.0.0:41570: address already in use. --->
 Microsoft.AspNetCore.Connections.AddressInUseException: Address already in use --->
 System.Net.Sockets.SocketException: Address already in use.

In the tests, ports are being allocated dynamically by WireMock.

After downgrading we're still seeing this, it may have been introduced by an update to .NET Core 3.1 from .NET Core 3.0.

@notclive commented on GitHub (Feb 12, 2020): > > > I recently upgraded a project from WireMock.Net 1.0.37 to 1.1.7 and tests have started failing randomly with: > > ``` > WireMock.Exceptions.WireMockException: Service start failed with error: One or more errors occurred. (Failed to bind to address http://0.0.0.0:41570: address already in use.) ---> > System.AggregateException: One or more errors occurred. (Failed to bind to address http://0.0.0.0:41570: address already in use.) ---> > System.IO.IOException: Failed to bind to address http://0.0.0.0:41570: address already in use. ---> > Microsoft.AspNetCore.Connections.AddressInUseException: Address already in use ---> > System.Net.Sockets.SocketException: Address already in use. > ``` > > In the tests, ports are being allocated dynamically by WireMock. After downgrading we're still seeing this, it may have been introduced by an update to .NET Core 3.1 from .NET Core 3.0.
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Feb 12, 2020):

Do you use Linux or Windows?

@StefH commented on GitHub (Feb 12, 2020): Do you use Linux or Windows?
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Feb 13, 2020):

https://github.com/WireMock-Net/WireMock.Net/pull/417

@StefH commented on GitHub (Feb 13, 2020): https://github.com/WireMock-Net/WireMock.Net/pull/417
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Feb 13, 2020):

@notclive I've update the code, can you test MyGet preview version : WireMock.Net.1.1.7-ci-12712.nupkg ?

@StefH commented on GitHub (Feb 13, 2020): @notclive I've update the code, can you test MyGet preview version : `WireMock.Net.1.1.7-ci-12712.nupkg` ?
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@notclive commented on GitHub (Feb 13, 2020):

These failures are happening on Linux, specifically Docker image mcr.microsoft.com/dotnet/core/sdk:3.1. I'll try out that package today.

@notclive commented on GitHub (Feb 13, 2020): These failures are happening on Linux, specifically Docker image `mcr.microsoft.com/dotnet/core/sdk:3.1`. I'll try out that package today.
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Feb 23, 2020):

Hello @notclive did you have time to check this?

@StefH commented on GitHub (Feb 23, 2020): Hello @notclive did you have time to check this?
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Mar 5, 2020):

@notclive Did you have time to check that new Linux Image?
(Note that my linux image does not yet use sdk3.1, but still 2,x)

@StefH commented on GitHub (Mar 5, 2020): @notclive Did you have time to check that new Linux Image? (Note that my linux image does not yet use sdk3.1, but still 2,x)
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Mar 13, 2020):

@notclive Did you have time to verify that new linux image.

@StefH commented on GitHub (Mar 13, 2020): @notclive Did you have time to verify that new linux image.
adam commented 2025-12-29 15:18:59 +01:00
Author
Owner
Copy Link

@notclive commented on GitHub (Apr 13, 2020):

I tried and failed to verify the new build. I set the WireMock.Net version to 1.1.7-ci-12712, but I later discovered I was actually building with 1.1.7.

... depends on WireMock.Net (>= 1.1.7-ci-12712) but WireMock.Net 1.1.7-ci-12712 was not found. An approximate best match of WireMock.Net 1.1.7 was resolved.

I now understand that the CI builds are on MyGet not NuGet.

The funny thing is that I didn't see any failures using 1.1.7, I can no longer reproduce the original problem.

Is there still any value in my verifying the new build? I can verify whether it works for me, but I can't verify that it fixes the problem. If so I'll work out how to fetch dependencies from MyGet instead of NuGet.

@notclive commented on GitHub (Apr 13, 2020): I tried and failed to verify the new build. I set the WireMock.Net version to 1.1.7-ci-12712, but I later discovered I was actually building with 1.1.7. `... depends on WireMock.Net (>= 1.1.7-ci-12712) but WireMock.Net 1.1.7-ci-12712 was not found. An approximate best match of WireMock.Net 1.1.7 was resolved. ` I now understand that the CI builds are on MyGet not NuGet. The funny thing is that I didn't see any failures using 1.1.7, I can no longer reproduce the original problem. Is there still any value in my verifying the new build? I can verify whether it works for me, but I can't verify that it fixes the problem. If so I'll work out how to fetch dependencies from MyGet instead of NuGet.
adam commented 2025-12-29 15:19:00 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Apr 13, 2020):

Hello @notclive , Thank you for spending time to test this.

How to use MyGet builds is described here:
https://github.com/WireMock-Net/WireMock.Net/wiki/MyGet-preview-versions

Please review that wiki-page, and tell me if something could be described different or more clearer if you see it.

But
If you want to just test the WireMock Linux docker image, that's not 100% possible because I don't have a .net core 3.1 version from WireMock.

But if you are just running your own code in a Linux container, that should be possible to re-test

@StefH commented on GitHub (Apr 13, 2020): Hello @notclive , Thank you for spending time to test this. How to use MyGet builds is described here: https://github.com/WireMock-Net/WireMock.Net/wiki/MyGet-preview-versions Please review that wiki-page, and tell me if something could be described different or more clearer if you see it. **But** If you want to just test the WireMock Linux docker image, that's not 100% possible because I don't have a .net core 3.1 version from WireMock. But if you are just running your own code in a Linux container, that should be possible to re-test
adam commented 2025-12-29 15:19:00 +01:00
Author
Owner
Copy Link

@notclive commented on GitHub (Apr 13, 2020):

It looks like build 1.1.7-ci-12712 no longer exists on MyGet.

@notclive commented on GitHub (Apr 13, 2020): It looks like build 1.1.7-ci-12712 no longer exists on MyGet.
adam commented 2025-12-29 15:19:00 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Apr 13, 2020):

OK. There is indeed a limit defined.

Just try official latest then.

@StefH commented on GitHub (Apr 13, 2020): OK. There is indeed a limit defined. Just try official latest then.
adam commented 2025-12-29 15:19:00 +01:00
Author
Owner
Copy Link

@notclive commented on GitHub (Apr 13, 2020):

My project's tests, running on Docker image mcr.microsoft.com/dotnet/core/sdk:3.1, are consistently passing using WireMock.Net 1.2.4.

Like I say I can't confirm that the port issue is fixed as I can no longer reproduce the issue, updating to .net core 3.1 probably wasn't the actual cause.

Thanks for all your work.

@notclive commented on GitHub (Apr 13, 2020): My project's tests, running on Docker image `mcr.microsoft.com/dotnet/core/sdk:3.1`, are consistently passing using WireMock.Net 1.2.4. Like I say I can't confirm that the port issue is fixed as I can no longer reproduce the issue, updating to .net core 3.1 probably wasn't the actual cause. Thanks for all your work.
adam commented 2025-12-29 15:19:00 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Apr 13, 2020):

OK. I'll close this issue now. In case you still encounter a problem, just raise a new one.

@StefH commented on GitHub (Apr 13, 2020): OK. I'll close this issue now. In case you still encounter a problem, just raise a new one.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
bug
doc
doc
duplicate
feature
feature
invalid
pull-request
Mirrored from GitHub Pull Request
 question
wontfix
No Label question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/WireMock.Net-wiremock#242
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?