Repository navigation
When building a AppiumDriverLocalService, there is a Port number missmatch when providing --port argument #521
Copy link
Copy link
Closed
Labels
Description
Description
When providing the port number via withArgument("--port", "8998") method, there becomes a miss match in ports, i.e. server starts on one port, while java_client tries to connect to another port. In below code example/stackTrace The Appium server is started on port 8998, but the java_client tries to connect to the default port "4723" and times out with an exception.
As can be seen in below stacktrace the port number is added twice in the node arguments.
The given Node.js executable: /usr/local/Cellar/node/5.5.0/bin/node Arguments: [/usr/local/lib/node_modules/appium/build/lib/main.js, --port, 4723, --address, 0.0.0.0, --port, 8998]
Environment
- java client build version: java_client-4.1.2
- Appium server version: v1.6.1-beta
- Desktop OS/version used: MAC OSX 10.11.6
- Node.js version: v5.5.0
- Mobile platform/version under test:
- Real device
Code To Reproduce Issue [ Good To Have ]
package _play;
import java.util.HashMap;
import java.util.Map;
import org.openqa.selenium.remote.DesiredCapabilities;
import io.appium.java_client.ios.IOSDriver;
import io.appium.java_client.remote.MobileCapabilityType;
import io.appium.java_client.service.local.AppiumDriverLocalService;
import io.appium.java_client.service.local.AppiumServiceBuilder;
public class _AppiumServerClientPlay {
public static void main(String[] args) {
Map<String, String> env = new HashMap<>(System.getenv());
env.put("PATH", "/usr/local/bin:" + env.get("PATH"));
AppiumDriverLocalService server = new AppiumServiceBuilder()
.withEnvironment(env)
.withArgument(() -> "--port", "8998")
.build();
DesiredCapabilities caps = new DesiredCapabilities();
caps.setCapability(MobileCapabilityType.APP, "__/path/to/your.app__");
caps.setCapability(MobileCapabilityType.UDID, "__your_UDID_here__");
caps.setCapability(MobileCapabilityType.DEVICE_NAME, "Iphone");
new IOSDriver<>(server, caps);
}
}Ecxeption stacktraces
[Appium] Welcome to Appium v1.6.1-beta
[Appium] Non-default server args:
[Appium] port: 8998
[Appium] Appium REST http interface listener started on 0.0.0.0:8998
Exception in thread "main" org.openqa.selenium.remote.UnreachableBrowserException: Could not start a new session. Possible causes are invalid address of the remote server or browser start-up failure.
Build info: version: '2.53.1', revision: 'a36b8b1cd5757287168e54b817830adce9b0158d', time: '2016-06-30 19:26:09'
System info: host: '******', ip: '*********', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.11.6', java.version: '1.8.0_72'
Driver info: driver.version: IOSDriver
at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:665)
at io.appium.java_client.DefaultGenericMobileDriver.execute(DefaultGenericMobileDriver.java:40)
at io.appium.java_client.AppiumDriver.execute(AppiumDriver.java:1)
at io.appium.java_client.ios.IOSDriver.execute(IOSDriver.java:1)
at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:249)
at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:131)
at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:144)
at io.appium.java_client.DefaultGenericMobileDriver.<init>(DefaultGenericMobileDriver.java:36)
at io.appium.java_client.AppiumDriver.<init>(AppiumDriver.java:114)
at io.appium.java_client.AppiumDriver.<init>(AppiumDriver.java:145)
at io.appium.java_client.ios.IOSDriver.<init>(IOSDriver.java:108)
at _play._AppiumServerClientPlay.main(_AppiumServerClientPlay.java:32)
Caused by: io.appium.java_client.service.local.AppiumServerHasNotBeenStartedLocallyException: The local appium server has not been started. The given Node.js executable: /usr/local/Cellar/node/5.5.0/bin/node Arguments: [/usr/local/lib/node_modules/appium/build/lib/main.js, --port, 4723, --address, 0.0.0.0, --port, 8998]
Process output: [Appium] Welcome to Appium v1.6.1-beta
[Appium] Non-default server args:
[Appium] port: 8998
[Appium] Appium REST http interface listener started on 0.0.0.0:8998
at io.appium.java_client.service.local.AppiumDriverLocalService.start(AppiumDriverLocalService.java:155)
at io.appium.java_client.remote.AppiumCommandExecutor.execute(AppiumCommandExecutor.java:65)
at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:644)
... 11 more
Caused by: org.openqa.selenium.net.UrlChecker$TimeoutException: Timed out waiting for [http://0.0.0.0:4723/wd/hub/status] to be available after 120003 ms
at org.openqa.selenium.net.UrlChecker.waitUntilAvailable(UrlChecker.java:107)
at io.appium.java_client.service.local.AppiumDriverLocalService.ping(AppiumDriverLocalService.java:115)
at io.appium.java_client.service.local.AppiumDriverLocalService.start(AppiumDriverLocalService.java:142)
... 13 more
Caused by: com.google.common.util.concurrent.UncheckedTimeoutException: java.util.concurrent.TimeoutException
at com.google.common.util.concurrent.SimpleTimeLimiter.callWithTimeout(SimpleTimeLimiter.java:143)
at org.openqa.selenium.net.UrlChecker.waitUntilAvailable(UrlChecker.java:80)
... 15 more
Caused by: java.util.concurrent.TimeoutException
at java.util.concurrent.FutureTask.get(FutureTask.java:205)
at com.google.common.util.concurrent.SimpleTimeLimiter.callWithTimeout(SimpleTimeLimiter.java:130)
... 16 more
Reactions are currently unavailable
Activity
alexander-poulikakos commentedon Nov 23, 2016
It seems as these server flags gets a special treatment:
--log,--portand--address. I think thewithArgument(...)method should be able to handle those as well. The usecase in my case is I'm reading the appium server flags from a properties file and would prefer to treat them in the same generic way.Would modifying the
withArgument(...)method to something like the below proposal be ok? If so, I can provide a pull request (with unit tests etc.) and we can continue discussing it from there.TikhomirovSergey commentedon Nov 23, 2016
@alexander-poulikakos
Please just use these methods
Thse is the set of methods provided by DriverService (except
withIPAddress)As I can read the log there is another problem
That means that the service was started successfully (!!!).
But
Do you see the difference? This is because it considers that the port was not provided so it uses the default value (4723)
Actually current implementation does same things as you are going to propose. It adds port, log file and ip to arguments.
alexander-poulikakos commentedon Nov 24, 2016
thanks for your reply @TikhomirovSergey.
My use case is that I am reading the arguments from a properties file, something like this:
and I would like to set them in a generic way for all arguments. Not make special cases for some of the arguments.
Since the API allows any argument to be set through the ´withArgument(...)´ method, then it should work for all arguments, including
--port.For example, a unit test like below should pass. Currently it is not.
The problem is that the ´DriverService´ does not get aware of the new port when using ´withArgument(() -> "--port", "...")´ method.
No, that is not the same thing. What I propose is to make ´DriverService´ aware of the new port when using ´withArgument(...)´ method.
TikhomirovSergey commentedon Nov 24, 2016
@alexander-poulikakos Now I got your problem. Ok. You can propose the PR.
My remark: Please use
equalsIgnoreCaseinstead ofequalsAlso don't forget to provide some tests.
TikhomirovSergey commentedon Nov 25, 2016
It was improved. It is going to be published soon.
alexander-poulikakos commentedon Nov 25, 2016
Just a minor comment: This calls the
toLowerCase()method.So no need to call
equalsIgnoreCasemultiple (6) times in below code.Would be cleaner if
equalsis used :)TikhomirovSergey commentedon Nov 25, 2016
ok. Will improve that.
Code optimization #521. README update.
TikhomirovSergey commentedon Nov 25, 2016
I'm closing this ticket.