Connection Timeout

[skellner]

Hi,

I'm getting this error when initializing a volume snapmirror. The system is a bit high loaded so the command may take a bit.

15:17:55.003 INFO  [Create VSM custom] Starts an initial transfer from Q100BPLC005:q091_filelight_001 to D100BPLC001:q091_filelight_001_mirror

15:18:56.518 ERROR  [Create VSM custom] Connection to 4.247.34.145 on port 443 for protocol HTTPS timed out.

How can I bump up the timeout for the connection to the controller in WFA?

Thanks in advance

Stefan

[skellner · Accepted solution]

In the meantime I figured it out. You can increase the timeout of the controller object. To achive that you have to add the variable to the command that fails. It looks ike this

# connect to destination controller

Connect-WFAController -Array $DestinationArray

# get the host name of destination storage system

Get-WFALogger -Info -message $("Retriving host name of destination:" + $DestinationArray)

$dsthost = (Get-NaSystemInfo).SystemName

$global:CurrentNaController.TimeoutMsec = 600000

[yaronh]

Hi Stefan,

Indeed that's the right answer. You probably had to make some modifications in your command for it.

We plan to all that as a parameter in the Connect-WFA-Controller wrapper so you'd be able to handle

this like a regular parameter and not set the various objects like that.

We opened a Jira on 2.0 for that.

Best,

Yaron Haimsohn

WFA Team

[arndt]

Have there been any changes around this in recent versions of WFA?  My customer is seeing some timeouts when running some commands against busy snapvault secondary systems, and we would like to bump up the timeout values to see if that helps.  Thanks,

Mike

[ktim]

I've also been looking at this issue recently.

You can also provide a -Timeout parameter to Connect-WfaController or Connect-WfaCluster:

function Connect-WfaController{

...

                    [int]$Timeout=60000,

        [parameter(Mandatory=$false)]

It would be nice if there was a way to control the default timeout globally, since in many circumstances the timeout will occur in a certified command. One could dive in and edit WFAWrapper.psm1 but that seems slightly wrong

One of the underlying issues here is that 7-mode will only run up to 10 zapi commands concurrently, with subsequent commands queuing (up to some limit). So in a heavily accessed environment with many zapi commands running it's possible that any command could queue. So you really need to add the timeout globally and not just to specific long running commands (although that will help in many circumstances).

[adaikkap]

We Already have a RFE open for the same, the number for it is 737151.

Pls add your customer case to this, so that its prioritized.

Regards

adai

[christoff_brand]

Is there a feature implemented yet?

I have the same challenge on various commands in 7 mode.

Thanks

[sinhaa]

Christoff,

     I'm not sure if this feature will be available in WFA next release or not, but it has a very simple workaround. Do you want to try that out?

sinhaa

[dcornely1]

Any word on this feature yet?  One issue I'm trying to contend with is that if any command is modified to include this timeout option the command itself is no longer certified which means WFA won't update its internal cache with the changes it makes.  This is a challenge for our environments with a high rate of change.

[dcornely1]

For anyone else who is interested, I tried to insert a No-Op command at the beginning of my workflow that just connects to the cluster and calls out a specific timeout value.  I did this because I noticed that subsequent commands would simply leverage the cached controller connection that the first command established.  Alas, this appears to only be the case when the command that establishes the initial connection is also certified.

So I changed the default timeout by modifying the WFAWrapper.psm1 file which now works for all commands.  Until we can certify our own commands or this variable is built into the commands in some way I see no other option while still being able to leverage the cache awareness that certified commands have.