When I run solr using
java -jar "C:\solr\example\start.jar"
It writes logs to C:\solr\example\logs.
When I run it using
java -Dsolr.solr.home="C:\solr\example\solr"
-Djetty.home="C:\solr\example"
-Djetty.logs="C:\solr\example\logs"
-jar "C:\solr\example\
start.jar"
it writes logs only if I run it from
C:\solr\example>
any other folder - logs are not written.
This is important as I need to run it as a service later (using nssm)
What should I change?
As you have discovered, the Jetty-hosted example distributed with Solr must be started in the example directory to function properly. Try creating a batch file that changes to the directory then invokes Java, like this:
C:
cd C:\solr\example\
java -Dsolr.solr.home="C:\solr\example\solr"
-Djetty.home="C:\solr\example"
-Djetty.logs="C:\solr\example\logs"
-jar "C:\solr\example\
Then have NSSM run the batch file instead of java.
Both answers should work for you.
You could set it up using apache Tomcat as opposed to the Jetty instance Solr comes with. Tomcat which comes standard with a startup.bat batch file that you use to start your server
Related
I encountered a problem that I could not figure out for the past week.
After installing another java JDK (Eclipse JDK) and changing the JAVA_HOME value in the computer environment, my Solr service failed to start.
I tried everything, including format to my PC, and new installation as we do every time on a new PC, and I still encounter the same problem.
This is the command the system runs to start the Solr service:
Starting java -Xms3000m -Xmx3000m -verbose:gc -XX:NewRatio=3 -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:-OmitStackTraceInFastThrow -DSTOP.PORT=7984 -DSTOP.KEY=mysecret "-Dsolr.install.dir=C:\Program Files\Morphisec Server Dev\solr-6.3.0-ssl\server.." -Djetty.host=0.0.0.0 -Djetty.port=8984 -Dsolr.jetty.https.port=8984 "-Djetty.home=C:\Program Files\Morphisec Server Dev\solr-6.3.0-ssl\server\solr" -Dsolr.autoSoftCommit.maxTime=10 "-Dsolr.log.dir=C:\Program Files\Morphisec Server Dev\solr-6.3.0-ssl\server\logs" -Dsolr.autoCommit.maxTime=60000 -Dsolr.ssl.checkPeerName=false "-Djavax.net.ssl.trustStore=C:\Program Files\Morphisec Server Dev\solr-6.3.0-ssl\server\etc\keystore.solr.jks" -Djavax.net.ssl.trustStorePassword=DEA7B39145F6478C -DzkClientTimeout=15000 -DzkRun -jar start.jar --module=https -DurlScheme=https
All the schemas in the folders of Solr do not contain any use of intPointField as mentioned, only TrieField…
We use Solr 6.3.0.
When I enter the Solr UI, into CloudàTreeà the /configs and choose one of my collections, I have a managed-schema file that does not appear in the directory on my PC, and there is a use of intPointField:
I don’t know where it gets it from. (As I mentioned, I even formatted the PC)
This is the log I get for each collection creation fail:
Does anybody work with Tosca and Jenkins?
I have problems to run my batch script from Jenkins. It does not open browser, but job is finished successfully. Batch script runs normally when I try to run in on Windows, without Jenkins.
Anybody has an experience using these two tools together?
In order to use Tosca CI with Jenkins you need to:
Configure your Jenkins build project
Add an additional build step (Execute Windows batch command)
Call ToscaCIClient.exe/ToscaCIClient.jar with parameters
e.g. "PathToTosca\ToscaCI\Client\ToscaCIClient.exe" -t junit -r PathToResults\result.xml
Further information can be found here: https://support.tricentis.com/community/article.do?number=KB0012411
The issue your facing is because your running Jenkins as windows service, in this case headless execution happens technically your script is executed for other user account.
Solution
Instead of installing Jenkins host it on Apache Tomcat server
Download Jenkins war file
Copy it inside webapps folder of Tomcat
Run startup.bat
Refer-
https://www.tutorialspoint.com/jenkins/jenkins_tomcat_setup.htm
I had faced the same issue.
I am guessing your slave machine running the test has jenkins services installed as services.
Uninstall the service. (.jenkins/jenkins-slave.exe uninstall)
Use the .jnlp or slave.jar to connect the machine as a slave.
Your test should run fine after that.
If it does just create a batch file to connect the machine as slave whenever it is logged in.
I tried that. But in any case, Jenkins does not open the browser, so Tests from Execution List and I do not know why.
We use Tosca 10.
Stackoverflow helped me a lot to reach that point but now I'm completely stuck, here is my problem :
I'm currently developing several tests to check a website. I code with Java in Eclipse, using testNG plugin with ReportNG for report, all of this using Windows 7 pro.
My tests work, and my report is well generated, so now I have to put it on Jenkins for my company so they will run my tests every X hours.
In order to launch my tests, I have made a file, named Run.bat, which runs the Java code, I tested it and it works, here is the code :
Run.bat
set classpath=blex_test_v1\bin;blex_test_v1\lib\*
java org.testng.TestNG blex_test_v1\blex_test_v1.xml
I now try to launch the tests on Jenkins, creating a new job and configuring it with the build section :
Run.bat
And this is my problem, I've tried everything (relative path, only the name of the file etc...) I always get this error :
java.io.IOException: Cannot run program "cmd" (in directory "/var/jenkins_home/jobs/blex_functional_test/workspace"): error=2, No such file or directory
So I checked the Jenkins workspace but my Run.bat is in it :
Workspace
I have read that Jenkins is in Linux so it might cause problem with bat files, so I tried to create a script but I didn't succeed either ..
So my question is : How can I run my test on Jenkins using my file Run.bat ? What am I doing wrong here ?
Thanks a lot !
Finally I can add an answer :
Jenkins is installed on a Unix machine so you can't run a bat file, it has to be a bash script.
To create a bash script, refer here.
Then you have to make sure that the plugin Xvfb is installed (and works) on the computer where Jenkins is installed.
I use testNG with reportNg and it doesn't work with the last firefox version so you I use firefox v34.0.5 and this version must be installed also on the Jenkins computer.
If you want to open the report after the execution, install another plugin and configure it (report HTML or something like that)
God it took me about a week but it's good to see it working !
I'd like to run batch using jenkins. And the status of build depends of number of files created in a specific folder. My question is how could I manage Jenkins build status depending of number of files created?
You can execute a shell script to count the files and return 1, if the count isn't expected.
Another way would be to use the Text-finder Plugin searching for a pattern in the console log.
Groovy Postbuild Plugin is another alternative:
buildUnstable() - sets the build result to UNSTABLE.
If you like to use the CLI you can use the following command:
java -jar jenkins-cli.jar -s http://...:8080/ set-build-result
Sets the result of the current build. Works only if invoked from within a build.
I'm having a little trouble understanding how Solr fits in with Jetty, and why I can't seem to get the start.jar in the distribution package to work.
I can run all of the example configurations via java -jar start.jar. However, when I try to run something like the follwing --
java -Dsolr.solr.home=/Users/jwwest/solr -jar $(brew --prefix solr)/libexec/example/start.jar
-- the following error occurs:
java.io.FileNotFoundException: No XML configuration files specified in start.config or command line.
at org.eclipse.jetty.start.Main.start(Main.java:506)
at org.eclipse.jetty.start.Main.main(Main.java:95)
I opened up the start.jar file, and there is a start.config file located inside of the jar which I'm assuming should handle this configuration for me. I'm not understanding why it will work when run from inside of the distribution examples directory, but not outside of it.
You also need to define the jetty.home property. Try:
java -Dsolr.solr.home=/Users/jwwest/solr -jar $(brew --prefix solr)/libexec/example/start.jar -Djetty.home=$(brew --prefix solr)/libexec/example
You can see the effective command line start.jar generates by using the --dry-run command line flag.
java -jar start.jar --dry-run
That will output everything with full path names so you can run it from outside the directory.
Source: http://www.eclipse.org/jetty/documentation/9.0.0.M3/advanced-jetty-start.html
The start.jar is a jetty specific mechanism that works to build out all the classpath requirements for starting up Jetty. It is generally only used in the scope of the jetty distribution. Pulling the start.jar out of the configuration and placing it somewhere else renders the default configuration of the start.config rather moot.
My understanding of Solr is that it bundles itself with a distribution of jetty, placing what it needs to run into the distribution and repackages it as its own. They may have a custom start.config file that further adds its own locations for classpath resources and the like, or not.
The exception you are seeings stems from the start.config file expecting an etc/ directory containing jetty.xml formatted xml files which are used to configure the jetty process.
Jetty being often used in an embedded format has little to do with this issue, it is simply a common use case because jetty is incredibly easy to embed into an application. Embedded instances of jetty rarely (if ever) leverage a start.jar...instead it is up to the embedding application to manage its own classpath.
First, you need to change your folder where start.jar is located, then execute the same command.
Jetty is often used as embedded container. If you want to use the jetty, then a good start would be to copy the example directory and rename it to what you want it to be. The solr directory is the one for basic configuration.
Else it is recommended to use tomcat and the solr.war file.