how to stop jetty without knowing the stop key - solr

when i ran jetty which is embedded with in apache solr. All i did was
java -jar start.jar
and it ran i put the process in the bg by doing ctrl-z and bg
i am trying to stop it by
java -DSTOP.PORT=8983 -DSTOP.KEY=stop_jetty -jar start.jar --stop
And i am not really sure if the the stop key above is correct . i get no error and go
into a new prompt. the app is still listening at that port.
and when i did
java -DSTOP.PORT=8983 -jar start.jar --stop
It said it requires the -DSTOP.KEY property as well.
I am not sure if i want to kill the process. Any tip/suggestion ? where to look for the stop key. i did not provide any keys at the start.

If the server was started without a STOP.KEY then you can't request a --stop.
Now, that being said, you can always issue a kill on the process too.
$ kill -TERM {pid of jetty}

Related

When I run 'React', it says that port 3000 is in use

I know that many methods have already come out as solutions.
However, as you can see in the picture, when I search for port 3000 in 'cmd', the process in use does not appear.
In the case of 8080, it comes out well because the Spring Boot server is running, but in the case of 'React', even if there is no process using port 3000 as shown in the picture, 'Something is already running on port 3000'. is printed out.
enter image description here
I'm using a translator so it might be difficult to understand, but any help would be appreciated.
Have you tried:
Running cmd as admin
Using :3000 instead of 3000
taskkill /PID <PID> /F kills the process, just replace with the PID, to the right of "listening".
If none works, you could just restart the pc.
NOTE: some people have encountered this error even after restarting, but managed to solve the problem with this command: npx kill-port 3000
This means you have launched another instance before... Switching off the computer can work but there is another solution
In windows, just open the Ressource Monitor (Task Manager -> Performance ->Open Ressource Monitor) then open the Listening port and check if 3000 is already running

flink - zeppelin - not responding

I am unable to run flink (1.0.3) process in zepplin. It is pending and web ui is not recording the process: both in cluster and local mode. Flink itself works fine in command line and intellij. I built zeppelin as mvn clean package.
Has anyone had a similar issue? Do I need to amend zeppelin-env.sh to rectify filk? I am unable to kill process in zeppelin web ui had to use ./bin/zeppelin-daemon.sh restart
I am using Flink 1.2 but I had the same problem.
I did two thing and it worked for me.
First of all, update your version. After, in the Interpreter I changed the value host = local to your localhost IP address.
Second, kill all the procces of Flink in terminal, just use web ui of Zeppelin.
You can check everything is going fine writting:
%flink
senv
res0: org.apache.flink.streaming.api.scala.StreamExecutionEnvironment = org.apache.flink.streaming.api.scala.StreamExecutionEnvironment#48388d9f
Let me know how it is going.
Regards! :)

Debugging jetty on a failed start

I've deployed Solr in Jetty 9.0.6 on a Debian machine and sometimes when i try to start it up, it fails without giving me any clues why. The <>.stderrout.log file is allways empty.
How could I enable logging or verbose output for the start operation?
I'm doing:
$ sudo service jetty start
Starting Jetty . . . . . . . FAILED Tue Oct 15 11:10:18 CEST 2013
thanks!
With Jetty 9.0.6 you pass into the part of your service that calls ${jetty.home}/start.jar the extra --daemon command line variable and look for the start.log files. (These files are usually found at the ${jetty.logs}/start.log location.
Along with that, also include the -DDEBUG=true to enable debug of the startup process, as well as enabling the debug on Jetty itself (until the actual logger kicks in).
Finally, if you want the default Jetty StdErrLog to log at debug level too, add the -Dorg.eclipse.jetty.LEVEL=DEBUG to the command line as well.
To put this in non-service terms ...
[jetty-distribution-9.0.6.v20130930]$ java -jar start.jar --daemon -DDEBUG=true -Dorg.eclipse.jetty.LEVEL=DEBUG
As for how to do that with a debian service, I have no clue.

solr not writing logs when it runs not from its main folder

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

Running Solr with Jetty

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.

Resources