2012-08-08 06:33 AM
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 18.104.22.168 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
Solved! SEE THE SOLUTION
2012-08-09 05:44 AM
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
2012-08-09 06:47 AM
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.
2014-02-04 07:06 AM
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,
2014-02-04 01:39 PM
I've also been looking at this issue recently.
You can also provide a -Timeout parameter to Connect-WfaController or Connect-WfaCluster:
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).
2014-06-03 04:28 AM
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?
2014-08-25 09:52 AM
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.
2014-08-25 03:19 PM
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.