org.openqa.selenium.remote.ProtocolHandshake createSession INFORMATION: Attempting bi-dialect session with Selenium Grid - selenium

I set up a local selenium grid to test something. The build runs normal when connecting to another grid but when using the local grid the build just stops at this point:
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running xxx.xxxxxxxxxxxx.xxx.xxxxxxxxxxx.XXXXXXXXXXXX
Sep 17, 2018 3:13:49 PM org.openqa.selenium.remote.ProtocolHandshake createSession
INFORMATION: Attempting bi-dialect session, assuming Postel's Law holds true on the remote end
No error message at all. I wasn't able to achieve anything with -X and -Dwebdriver.server.session.timeout=7200
It just hangs there and I get nothing

This error message...
org.openqa.selenium.remote.ProtocolHandshake createSession
INFORMATION: Attempting bi-dialect session, assuming Postel's Law holds true on the remote end
As per the discussion Attempting bi-dialect session, assuming Postel's Law holds true on the remote end thread 'webdriver dispatcher' panicked at 'index out of bounds: the len is 0 but the index is 0 this issue was reproducible with Selenium Client v3.0.0-beta3 released on 2016-09-01 14:57:03 -0700 with GeckoDriver.
Simon in a comment mentioned that:
The root cause was a ClassCastException. We now catch that exception, log the thing that we were trying to parse and continue with other attempts to complete the handshake. The fix was available in Selenium Client v3.0.0-beta4.
Solution
Upgrade JDK to recent levels JDK 8u181.
Upgrade Selenium to current levels Version 3.14.0.
Upgrade GeckoDriver to GeckoDriver v0.20.1 level.
GeckoDriver is present in the specified location.
GeckoDriver is having executable permission for non-root users.
Upgrade Firefox version to Firefox v61.0.2 levels.
Clean your Project Workspace through your IDE and Rebuild your project with required dependencies only.
If your base Web Client version is too old, then uninstall it through Revo Uninstaller and install a recent GA and released version of Web Client.
Take a System Reboot.
Execute your Test as a non-root user.

Related

JMeter web driver logging

Is there a way to suppress output from the web driver - e.g.
Feb 09, 2023 1:22:13 PM org.openqa.selenium.chromium.ChromiumDriver lambda$new$3
WARNING: Unable to find version of CDP to use for . You may need to include a dependency on a specific version of the CDP using something similar to `org.seleniumhq.selenium:selenium-devtools-v86:4.7.2` where the version ("v86") matches the version of the chromium-based browser you're using and the version number of the artifact is the same as Selenium's.
Feb 09, 2023 1:22:14 PM org.openqa.selenium.devtools.CdpVersionFinder findNearestMatch
WARNING: Unable to find CDP implementation matching 110
Feb 09, 2023 1:22:14 PM org.openqa.selenium.chromium.ChromiumDriver lambda$new$3
WARNING: Unable to find version of CDP to use for . You may need to include a dependency on a specific version of the CDP using something similar to `org.seleniumhq.selenium:selenium-devtools-v86:4.7.2` where the version ("v86") matches the version of the chromium-based browser you're using and the version number of the artifact is the same as Selenium's.
ChromeDriver was started successfully.
ChromeDriver was started successfully.
ChromeDriver was started successfully.
ChromeDriver was started successfully.
ChromeDriver was started successfully.
ChromeDriver was started successfully.
ChromeDriver was started successfully.
If this is really what you want:
Add a setUp Thread Group to your Test Plan
Add JSR223 Sampler to the Thread Group
Put the following code into "Script" area:
java.util.logging.LogManager.getLogManager().reset()
def globalLogger = java.util.logging.Logger.getLogger(java.util.logging.Logger.GLOBAL_LOGGER_NAME)
globalLogger.setLevel(java.util.logging.Level.OFF)
Next time you run your test all Selenium-related logging will go away.

Plain vanilla Apache Ignite cluster fails setting state back to ACTIVE

I've got a plain vanilla install of ignite 2.14, with the binaries downloaded from https://ignite.apache.org/download.cgi (exact link https://dlcdn.apache.org/ignite/2.14.0/apache-ignite-2.14.0-bin.zip). I'm on Windows 10, IGNITE_HOME is not set in the PATH (this is optional), and Ignite's using this java runtime:
OpenJDK Runtime Environment 1.8.0_201-2-redhat-b09 Oracle Corporation
OpenJDK 64-Bit Server VM 25.201-b09
I start an ignite node using the default configuration provided in the downloaded zip apache-ignite-2.14.0-bin.zip :
ignite.bat ..\config\default-config.xml
This starts fine. Following the instructions at https://ignite.apache.org/docs/latest/tools/control-script I can check the state and see I've got a single node cluster in state ACTIVE (the default-config.xml must not have native persistence enabled, so the cluster goes to ACTIVE state automatically).
I can then set the state to INACTIVE like so:
control.bat --set-state INACTIVE
This works fine. However if I set the state to active again like so:
control.bat --set-state ACTIVE
I get the error pasted below and the cluster stays in the INACTIVE state. I first came across this error when using Ignite in embedded server mode, but I can still reproduce it with a fresh out-of-the-box ignite install (not using embedded). I'm surprised that a plain vanilla install just calling a couple of basic commands falls over like this. Any idea what's happening?
This is the error:
C:\temp\apache-ignite-2.14.0-bin\bin>control.bat --set-state ACTIVE
Nov 17, 2022 4:27:17 PM
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection
INFO: Client TCP connection established: /127.0.0.1:11211 Nov
17, 2022 4:27:17 PM
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection
close INFO: Client TCP connection closed: /127.0.0.1:11211 Nov 17,
2022 4:27:17 PM org.apache.ignite.internal.client.util.GridClientUtils
shutdownNow WARNING: Runnable tasks outlived thread pool executor
service [owner=GridClientConnectionManager,
tasks=[java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask#6d7b4f4c]]
Control utility [ver. 2.14.0#20220929-sha1:951e8deb] 2022 Copyright(C)
Apache Software Foundation User: info Time: 2022-11-17T16:27:16.344
null suppressed:
Command [SET-STATE] finished with code: 4 Error stack trace: class
org.apache.ignite.internal.client.GridClientException: null
suppressed:
at org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleClientResponse(GridClientNioTcpConnection.java:632)
at org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleResponse(GridClientNioTcpConnection.java:563)
at org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter$NioListener.onMessage(GridClientConnectionManagerAdapter.java:691)
at org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:116)
at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3734)
at org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
at org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1211)
at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2508)
at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2273)
at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1910)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at java.lang.Thread.run(Thread.java:748)
Control utility has completed execution at: 2022-11-17T16:27:17.642
Execution time: 1298 ms Press any key to continue . . .
It's a known issue, which is, unfortunately, not fixed yet.
As a workaround, you can execute the command with the autoconfirmation flag --yes, as shown below:
control.bat --set-state ACTIVE --yes

Jenkins starts chromedriver in background mode (like headless mode)

I've setup Jenkins server on windows 10 machine. When running the job(simply mvn test -DsuiteXmlFile=%TestSuite%) the job successfully compiles and starts tests. I can see first being skipped, second failed and then it starts passing one after one. No Chrome window is opened, but when I check in task manager I can see it opens several Chrome processes in background. When calling mvn test -DsuiteXmlFile=TestSuite in CMD(also in power shell) it opens Chrome in front.
Looking at Jenkins logs I see that it creates a .bat file in c:/System/TEMP/ directory and executes that batch file. I've even tried to copy the file, put in my project's root and call it via CMD, the same .bat file works as expected. Still jenkins opens Chrome in background. Any idea what causes this and how can I force Jenkins to run tests in Foreground?
My chromedriver vesion is 78.0.3904.70(if needed).
Logs are identical for both cases:
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO] Running TestSuite
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
18.11.2019 03:50:38.019 INFO - [AutomationListener]:Staring to run test suite with 11 tests
Nov 18, 2019 3:50:38 AM org.openqa.selenium.remote.DesiredCapabilities chrome
INFO: Using `new ChromeOptions()` is preferred to `DesiredCapabilities.chrome()`
Starting ChromeDriver 78.0.3904.70 (edb9c9f3de0247fd912a77b7f6cae7447f6d3ad5-refs/branch-heads/3904#{#800}) on port 39924
Only local connections are allowed.
Please protect ports used by ChromeDriver and related test frameworks to prevent access by malicious code.
[1574077841.726][WARNING]: Timed out connecting to Chrome, retrying...
Nov 18, 2019 3:50:43 AM org.openqa.selenium.remote.ProtocolHandshake createSession
INFO: Detected dialect: W3C
[1574077845.835][WARNING]: Timed out connecting to Chrome, retrying...
18.11.2019 03:50:55.489 INFO - [BasePage]:The element: By.cssSelector: polygon is clicked
18.11.2019 03:50:55.494 INFO - [AutomationListener]:----------------------------------------------------------------------
18.11.2019 03:50:55.495 INFO - [AutomationListener]:Starting to run TestMethod test method
18.11.2019 03:50:55.495 INFO - [AutomationListener]:----------------------------------------------------------------------
When the Jenkins slave run as service in the background every program it initiate, like running the batch file, will also be in the background. The solution is to run the Jenkins slave as a regular program in the foreground.
Yes, the slave solution is working in my case.
I have also a window machine, I have configured the Jenkins and also configured the slave within the machine and now it every time opens the browser in the foreground.
I know it's not the genuine solution but it works perfectly

Problems with CATALINA_PID and ARTIFACTORY_PID while upgrading Artifactory to the latest version

While upgrading my Artifactory server (free OSS version) from the version 5.2.0 to the latest 5.4.5, I was hit by an ARTIFACTORY_PID problem.
After migrating from 5.3.2 to 5.4.0, the Artifactory server did not want to start anymore complaining about
PID file /var/opt/jfrog/run/artifactory.pid not readable (yet?) after start.
I found the only way around it is to remove the line export CATALINA_PID=$ARTIFACTORY_PID from the setenv.sh of the tomcat.
Note that upgrade from 5.2.0 to 5.3.2 went smoothly.
However, after upgrading from 5.4.0 to the latest 5.4.5 this trick does not work anymore. Now I get an error:
Job for artifactory.service failed because a configured resource limit was exceeded. See "systemctl status artifactory.service" and "journalctl -xe" for details.
And when executing service artifactory status, I get:
● artifactory.service - Setup Systemd script for Artifactory in Tomcat Servlet Engine
Loaded: loaded (/usr/lib/systemd/system/artifactory.service; enabled; vendor preset: disabled)
Active: activating (auto-restart) (Result: resources) since Tue 2017-07-25 09:40:10 CEST; 4s ago
Process: 31912 ExecStart=/opt/jfrog/artifactory/bin/artifactoryManage.sh start (code=exited, status=0/SUCCESS)
Jul 25 09:40:10 linux systemd[1]: Failed to start Setup Systemd script for Artifactory in Tomcat Servlet Engine.
Jul 25 09:40:10 linux systemd[1]: Unit artifactory.service entered failed state.
Jul 25 09:40:10 linux systemd[1]: artifactory.service failed.
In fact Artifactory is now running showing version 5.4.5, but I am not happy about all those errors above.
Plus I am a bit failing to understand the purpose of CATALINA_PID and/or ARTIFACTORY_PID. Why the tomcat was failing on the startup because of this file? What was wrong with the permissions? I think I did no extra actions before.
The only difference that before it was installed from an official downloaded rpm. But now using an official remote yum repo.
If I try to create an empty /var/opt/jfrog/run/artifactory.pid file, while Artifactory is running, it gets deleted. Who is deleting this file and why? Is it a standard tomcat behavior?
OS: CentOS 7, up to date.
In my case (in a slow virtual machine) the error message from the command artifactoryManage.sh start was:
ERROR: Artifactory Tomcat server did not start in 60 seconds. Please check the logs
The log file told that the only problem was slowness (/var/opt/jfrog/artifactory/logs/artifactory.log):
### Artifactory successfully started (64.802 seconds) ###
The problem was solved by adding a longer timeout to the service definition at /etc/systemd/system/artifactory.service:
[Service]
Environment=START_TMO=120
After editing the service definition, as you know, systemctl daemon-reload was needed.
Run this script:
/opt/jfrog/artifactory/bin/artifactoryManage.sh start
It will show the exact error to you.
In my case it was java version not updated. So I updated to java 1.8.

SeleniumRC FF3.5.x-3.6 lock file troubles

With Selenium RC 1.0.1, and FF3.5.x or 3.6 I keep seeing this error when trying to run any test,
Failed to start new browser session:
Unable to delete file
\parent.lock
when running the server with either,
java -jar selenium-server.jar -multiwindow
or
java -jar selenium-server.jar
Any one found a way to run a selenium RC test against those version of FF? Here's the full stack trace,
ERROR - Failed to start new browser session, shutdown browser and clear all session data
java.lang.RuntimeException: Firefox refused shutdown while preparing a profile
at org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher.wai
tForFullProfileToBeCreated(FirefoxChromeLauncher.java:311)
at org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher.pop
ulateCustomProfileDirectory(FirefoxChromeLauncher.java:106)
at org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher.lau
nch(FirefoxChromeLauncher.java:83)
at org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher.lau
nchRemoteSession(FirefoxChromeLauncher.java:350)
at org.openqa.selenium.server.browserlaunchers.FirefoxLauncher.launchRem
oteSession(FirefoxLauncher.java:98)
at org.openqa.selenium.server.BrowserSessionFactory.createNewRemoteSessi
on(BrowserSessionFactory.java:357)
at org.openqa.selenium.server.BrowserSessionFactory.getNewBrowserSession
(BrowserSessionFactory.java:122)
at org.openqa.selenium.server.BrowserSessionFactory.getNewBrowserSession
(BrowserSessionFactory.java:84)
at org.openqa.selenium.server.SeleniumDriverResourceHandler.getNewBrowse
rSession(SeleniumDriverResourceHandler.java:699)
at org.openqa.selenium.server.SeleniumDriverResourceHandler.doCommand(Se
leniumDriverResourceHandler.java:393)
at org.openqa.selenium.server.SeleniumDriverResourceHandler.handleComman
dRequest(SeleniumDriverResourceHandler.java:364)
at org.openqa.selenium.server.SeleniumDriverResourceHandler.handle(Selen
iumDriverResourceHandler.java:125)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:820)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:837)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:
245)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Caused by: org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher$Fil
eLockRemainedException: Lock file still present! C:\DOCUME~1\ADMINI~1.SPS\LOCALS
~1\Temp\customProfileDirf09f31ccacf4468385010edaecd5925d\parent.lock
at org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher.wai
tForFileLockToGoAway(FirefoxChromeLauncher.java:269)
at org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher.wai
tForFullProfileToBeCreated(FirefoxChromeLauncher.java:309)
... 20 more
INFO - Got result: Failed to start new browser session: Unable to d
elete file C:\DOCUME~1\ADMINI~1.SPS\LOCALS~1\Temp\customProfileDirf09f31ccacf446
8385010edaecd5925d\parent.lock on session null
Restarting the browser, and clearing the cache didn't help. Using FF 3.0.x works just fine.
Seems seleniumRC 1.0.2 just came out today with claimed support for FF3.6 and such. Is working for me.
I was able to fix this issue by following these instructions:
http://jira.openqa.org/browse/SRC-507
This is for an older version of Selenium, but it works just the same. I am having to use 1.0.1 (for IE compatibility) and it has the MaxVersion of FF at 3.5. It was throwing the same error as above.
I changed the various files to '3.6' and it works now.
I just downloaded Selenium RC 1.0.3, and it did NOT fix the problem for me.