Creating a new client for each connection.

[Tomnivore]

Hey!

I'm using winrm-java to excute commands in Windows command prompt as follows (Mutiny):

Uni<WindowsRemoteCommandResult> executeUniCommand(TargetSystem targetSystem, PsCommands command) {
    return Uni.createFrom().item(() -> {
          try {
            // Execute the command using WinRMCommandExecutor
            log.atDebug().log("Executing command: " + command.getCommand());
            return WinRMCommandExecutor.execute(
                command.getCommand(),
                null,
                targetSystem.host(),
                null,
                targetSystem.user(),
                targetSystem.password().orElse("").toCharArray(),
                null,
                TIMEOUT,
                null,
                TICKET_CACHE,
                null);
          } catch (WindowsRemoteException e) {
            throw new RetryableWindowsConnectorException("Failed to execute remote command.", e);
          } catch (IOException | TimeoutException e) {
            throw new RetryableWindowsConnectorException("Command execution failed due to IO or timeout error.", e);
          }
         })
          .runSubscriptionOn(Infrastructure.getDefaultWorkerPool())
          .invoke(result -> validateResult(result, command.getDescription()));
  }

It seems that each subscription creates a new client and does calls to get soap schemas from different places. It feels like a waste of resources but also causes 429 errors if there's enough subscriptions going on. Am I doing something wrong?

[bertysentry]

Sorry we TOTALLY missed the issue you created a while ago (no notification was received), just like a few others. Very sorry about that, we'll look into this asap!

[DempseyRoller]

Great! 😄

[anuragpaul602-netizen]

@Tomnivore Following up here — since this issue was opened, the library gained a fluent WinRMClient (part of #131, shipping in the upcoming 2.0.0) that authenticates once and reuses that connection for every subsequent operation. That directly addresses what you were seeing: the static WinRMCommandExecutor.execute(...) you're calling is the "legacy" one-shot API — it opens a connection, runs one command, and tears it down every time by design, which is exactly the per-subscription overhead (and 429s under load) you ran into.

The fix on your side is to build one WinRMClient per target host and reuse it across calls, instead of authenticating inside the Uni lambda:

// Build (and cache, e.g. per TargetSystem) once — not per call:
WinRMClient client = WinRMClient.builder(targetSystem.host())
    .credentials(targetSystem.user(), targetSystem.password().orElse("").toCharArray())
    .timeout(TIMEOUT)
    .build();

Uni<CommandResult> executeUniCommand(PsCommands command) {
    return Uni.createFrom().item(() -> {
            log.atDebug().log("Executing command: " + command.getCommand());
            try {
                return client.command(command.getCommand()).execute();
            } catch (WinRMClientException e) {
                throw new RetryableWindowsConnectorException("Command execution failed.", e);
            }
        })
        .runSubscriptionOn(Infrastructure.getDefaultWorkerPool())
        .invoke(result -> validateResult(result, command.getDescription()));
}

Two API notes vs. your original code:

• client.command(...).execute() returns CommandResult (not WindowsRemoteCommandResult), with .stdout(), .stderr(), .exitCode(), .elapsed() — so validateResult(...) would need to accept that type instead.
• WinRMClientException (org.metricshub.winrm.exceptions) is unchecked, so the single catch above replaces your three-way WindowsRemoteException / IOException / TimeoutException split — no more checked-exception plumbing through the Uni lambda.

client is AutoCloseable and safe to share across threads (operations on one client just serialize, since it's one connection). The WSDL/schema fetching "from different places" you noticed is also gone entirely — the CXF backend that caused it was removed in 2.0.0 in favor of a dependency-free implementation.

This is documented in the README's "Legacy API" section now: "They open a connection, run one operation, and close it — prefer WinRMClient for anything that runs more than one operation against the same host."

Given the new API covers this, I think this issue can be closed — let me know if I'm missing something about your use case that WinRMClient doesn't address.