topic Connection Timeout in Active IQ Unified Manager Discussions

Connection Timeout

skellner — Thu, 05 Jun 2025 06:21:26 GMT

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

Connection Timeout

skellner — Thu, 09 Aug 2012 12:44:15 GMT

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

Re: Connection Timeout

yaronh — Thu, 09 Aug 2012 13:47:20 GMT

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

Re: Connection Timeout

arndt — Tue, 04 Feb 2014 15:06:59 GMT

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

Re: Connection Timeout

ktim — Tue, 04 Feb 2014 21:39:22 GMT

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).

Re: Connection Timeout

adaikkap — Fri, 07 Feb 2014 10:04:37 GMT

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

Re: Connection Timeout

christoff_brand — Tue, 03 Jun 2014 09:36:35 GMT

Is there a feature implemented yet?

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

Thanks

Re: Connection Timeout

sinhaa — Tue, 03 Jun 2014 11:28:40 GMT

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

Re: Connection Timeout

dcornely1 — Mon, 25 Aug 2014 16:52:32 GMT

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.

Re: Connection Timeout

dcornely1 — Mon, 25 Aug 2014 22:19:25 GMT

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.