Long-lived `WinRMClient` keeps failing with WSManFault 2150859174 after a terminate Signal fails
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 25/100
Research direction
Start by reading WsmanClient.terminateCompleted() and the issue’s reproduction steps; the payload does not name a source file or test. Check open pull request #197 before starting, since work is already underway. Done means a failed terminate Signal triggers best-effort shell deletion and clears shellId, while the command result is still returned and the quota-1 reproduction can run another command.
Written by the indexing model from the issue text.
Description
Disclaimer: Although the following content is generated by AI, I have thoroughly reviewed and cleaned it.
Problem
A long-lived WinRMClient used for periodic polling can start failing every command with:
HTTP 500 (WSManFault 2150859174): The WS-Management service cannot process the request. The maximum number of concurrent operations for this user has been exceeded.
It never recovers on its own. Only closing the client and recreating it fixes the problem.
Cause
After a command completes, the client sends a Terminate Signal so the server releases the command's resources. According to [MS-WSMV] 2.2.4.38:
- http://schemas.microsoft.com/wbem/wsman/1/windows/shell/signal/Terminate
This control code is sent by the client to acknowledge receipt of the end of the command output from the service and to clean up any resources associated with command execution. Because the service might have to cache this information until it knows that the client has received the entire stream, the client MUST send this before a new command can be executed.
When the server answers that Signal with a fault, WsmanClient.terminateCompleted() ignores it:
} catch (final WinRMFaultException ignored) {
// The Signal was answered with a fault: the exchange completed, the connection is in
// sync — and the command's completion is what matters.
}
As a result:
- The command is never terminated and keeps holding an operation of the user's quota (
MaxConcurrentOperationsPerUser). - The Signal is never retried, and the shell is kept and reused by the next commands.
- Each failed Signal leaves one more operation open. Once the quota is full, every Command is refused.
- Nothing releases those operations until the shell is deleted, which only happens in close() .
The failure is swallowed silently, so nothing in the logs shows the Signals failing before the quota errors start.
Reproduction
A FakeWsmanServer with an operation quota of 1 (a counter: +1 per accepted Command, −1 per accepted Terminate Signal, reset on shell Delete):
- Poll 1: Create, Command, Receive, then the terminate Signal fails. The poll still returns success.
- Poll 2: the Command reuses the same shell and is refused with WSManFault 2150859174.
Proposed Fix
When the terminate Signal fails, delete the shell (best effort) and clear shellId. Deleting the shell releases the command still open in it, and the next command creates a fresh shell. The caller still gets the command's result.
- Dominant language
- Java
- Stars
- 13
- Forks
- 4
- Avg merge
- 12h 44m
- Merged PRs (30d)
- 17
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MetricsHub/winrm-java
-
bug documentation
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
MetricsHub/winrm-java#202 ·
Maintainers usually reply within 1 day
-
WQL array properties: add the trailing separator to match wmi-javaPossibly taken @bertysentry claimed this 1 day ago. Openenhancement
Difficulty 3/5 1-2 days Newbie friendliness 58/100
MetricsHub/winrm-java#201 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 78/100
MetricsHub/winrm-java#199 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 30/100
MetricsHub/winrm-java#194 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 38/100
MetricsHub/winrm-java#176 ·
Maintainers usually reply within 1 day
All issues in MetricsHub/winrm-java
Similar issues
-
`GET /v1/event/token/{uuid}` can report a BOM upload as done before policy evaluation and metrics have finishedPossibly taken @Zargath claimed this today. Opendefect in triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
DependencyTrack/dependency-track#7646 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
floci-io/floci#5425 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
objectionary/eo-graphs#80 ·
-
WebMvcStreamableServerTransportProvider: idle-session eviction stops permanently after a NullPointerException when a session is deleted mid-sweepPossibly taken @lejuho claimed this today. Openstatus: waiting-for-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
spring-projects/spring-ai#7133 ·
Maintainers usually reply within 6 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
objectionary/jucs#141 ·
Maintainers usually reply within 1 day