Is there a way to increase session time?

As --command–timeout is deprecated in appium 1.5. Is there any work around for the session to never end/ to improve session time.
newCommandTimeout is not working properly, through i am giving 3000 its ending the session in a minute.

You can specify a JSON string for default capabilities starting with 1.5.

appium --default-capabilities '{"newCommandTimeout": 3000}'

I would say to double-check your code to make sure you’re not calling any method that can end the session early, e.g. driver.quit.

What are your Appium logs?

5 Likes

When i used appium --default-capabilities ‘{“newCommandTimeout”: 3000}’ the session didnt end,
here are my previous logs without using default-capabilities

[Appium] New IosDriver session created successfully, session 924857e0-9461-46fe-b203-86d164d2bf4b added to master session list
[MJSONWP] Responding to client with driver.createSession() result: {“webStorageEnabled”:false,…
[HTTP] <-- POST /wd/hub/session 200 13594 ms - 571
[BaseDriver] Shutting down because we waited 60 seconds for a command
[debug] [iOS] Deleting ios session
[debug] [UIAuto] Destroying instruments client socket.
[debug] [UIAuto] Closing socket server.
[Appium] Closing session, cause was ‘New Command Timeout of 60 seconds expired. Try customizing the timeout using the ‘newCommandTimeout’ desired capability’
[Appium] Removing session 924857e0-9461-46fe-b203-86d164d2bf4b from our master session list
[debug] [UIAuto] Instruments socket server was closed
[debug] [Instruments] Starting shutdown.
[debug] [Instruments] Sending sigterm to instruments
[debug] [Instruments] [INST] 2016-07-21 20:29:01 +0000 Stopped: Script was stopped by the user
[debug] [Instruments] [INST STDERR] 2016-07-21 16:29:02.001 instruments[24623:652638] Attempting to set event horizon when core is not engaged, request ignored
[debug] [Instruments] [INST STDERR] 2016-07-21 16:29:02.002 instruments[24623:652401] Attempting to set event horizon when core is not engaged, request ignored
[debug] [Instruments] [INST] Instruments Trace Complete (Duration : 70.930946s; Output : /var/folders/32/l_wsl1rd6wj700vcwhxc1c3wc_dbl6/T/appium-instruments/instrumentscli0.trace)
[debug] [Instruments] Instruments exited with code 0
[debug] [iOSLog] Stopping iOS log capture
[debug] [iOS] Running ios real device reset flow

So… does this mean this option resolves your issue? This definitely sounds like it extends your session like you wanted.

Absolutely inserting the UDID and the port. Yes

1 Like

You can also set it as capability when creating driver as

DesiredCapabilities capabilities = new DesiredCapabilities();
...
capabilities.setCapability(MobileCapabilityType.NEW_COMMAND_TIMEOUT, Constants.TIMEOUT);
...

Hello Telmo,

wat is the import statement for Constants.TIMEOUT

none :slight_smile: that was my time out constant I guess. Its just an integer

is there a max time out limit ?

Looking at https://github.com/appium/appium-base-driver/blob/master/lib/basedriver/commands/timeout.js and https://github.com/appium/appium-support/blob/master/lib/util.js there is no limit defined in there.

you can use “idleTimeout” capability to increase the session timeout

Just thought of sharing something that worked for me. I initiate synchronization which takes between 14 and 17 minutes to complete. For the session to not time out and for the code to execute the next command while waiting for this synchronization command to complete, I had set the following in my Initialization of Driver method.

AndroidDriver driver;
AppiumOptions options = new AppiumOptions();
options.AddAdditionalCapability(MobileCapabilityType.NewCommandTimeout,TimeSpan.FromMinutes(20));

driver = new AndroidDriver(new Uri(“http://localhost:4723/wd/hub”), options);

For the test to not timeout, alongside the command timeout, I had specified the following:

[Test, Timeout(3000000)]
public void InvokeAutomationTestSuite()
{
…Call the individual tests / methods
}

this capability, why is it documented as a “new command timeout”, it is really not possible to clarify that this parameter also doubles as a session idle time timeout as well? Mainly since the old session time parameter got removed about a decade ago?