If no output is available before the wsman:OperationTimeout expires, the server MUST return a WSManFault with the Code attribute equal to "2150858793". When the client receives this fault, it SHOULD issue another Receive request. The client SHOULD continue to issue Receive messages as soon as the previous ReceiveResponse has been received.
But the specification saids that "the client SHOULD" and not "MUST". In some use cases it's not suitable to continue thus this PR proposes to let the choice to the application.
By default the behaviour is unmodified and the ShellCommand continues to send a new Receive after an OperationTimeout fault.
Instead of use a simple boolean to parametrize the loop of retries this PR use a Predicate in order to let the possibility to the application to implement more complex scenario (e.g with a counter).
This PR proposes to add a parameter for confguring the behaviour when the operation timeout expired.
As explained by neykov in the issue https://github.com/cloudsoft/winrm4j/issues/67#issuecomment-315346167 the specification advice to post new Receive requests for waiting the complete execution of the command.: WSMan: 3.1.4.14 Receive
But the specification saids that "the client SHOULD" and not "MUST". In some use cases it's not suitable to continue thus this PR proposes to let the choice to the application.
By default the behaviour is unmodified and the ShellCommand continues to send a new Receive after an OperationTimeout fault.
Instead of use a simple
booleanto parametrize the loop of retries this PR use aPredicatein order to let the possibility to the application to implement more complex scenario (e.g with a counter).