Is there a way to get the metrics for Jetty server, for example, the queue length, processing time, etc.
I looked at the QueuedThreadPool class, and tracked the the calling chain for getQueueSize, but I didn't find it got exposed.
Thanks.
"Queue Length" is a very vague term and can apply to many many different things.
As for seeing the metrics for Jetty, enable JMX, restart your server, and take a look.
Goto your ${jetty.base} and add the jmx module.
$ cd /path/to/mybase
$ java -jar /path/to/jetty-dist/start.jar --add-to-start=jmx
Once you have restarted, use the jmc command that comes with your JDK (or if you are using an ancient JDK use jconsole) and attach to the running Jetty process to see the various things exposed by Jetty for monitoring.
Related
We are implementing distributed tracing in our environment, starting with simple auto-instrumentation, using Open Telemetry. Our environment is primarily cloud based, running on AWS.
We have had success auto-instrumenting most of our cloud services (ECS, EKS, Lambda, etc.), and are seeing context tracing being passed from one service to the next. We are also auto-instrumenting Apache and Nginx servers running on EC2, using the Otel standard, and are successfully seeing trace information being collected, but calls from Apache to another front-end or back-end service are not being tied together by trace context. Apache produces it's own trace id and the system it calls is producing it's own as well, and the linkage is lost.
Has anybody been able to get this to work and are there samples you can share?
Thanks so much!
We have tried using the Otel libraries, as well as the AWS distributed tracing libraries, and have played around with different exporters and collectors. The tracing capabilities work individually, but when it comes time to pass context from Apache and/or Nginx to some other service, the trace link is broken
I have configured Jetty as follows.
# ps aux | more
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
jetty 1 7.0 9.8 9931680 2421304 ? Ssl 12:20 4:31 java -Djava.io.tmpdir=/tmp/jetty -server -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Djava.security.egd=file:/dev/./urandom -Dhttp.proxyHost=XXX -Dhttp.proxyPort=XXX -Dhttps.proxyHost=XXX -Dhttps.proxyPort=XXX -Dhttp.nonProxyHosts=localhost\|127.*\|[::1]\|10.*\|172.16.*\|172.17.*\|172.18.*\|172.19.*\|172.20.*\|172.21.*\|172.22.*\|172.23.*\|XXX -Xms1g -Xmx3g -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=XXX -jar /usr/local/jetty/start.jar
I have the feeling that the no-proxy variable (http.nonProxyHosts) is not read out and the HTTP connect proxy is always used.
Since I cannot change a third-party software so easily myself, I wonder how I call some/certain local resources. I can only change config. How?
The JVM system properties for controlling URL networking in your command line ...
-Dhttp.proxyHost=XXX
-Dhttp.proxyPort=XXX
-Dhttps.proxyHost=XXX
-Dhttps.proxyPort=XXX
-Dhttp.nonProxyHosts=localhost\|127.*\|[::1]\|10.*\|172.16.*\|172.17.*\|172.18.*\|172.19.*\|172.20.*\|172.21.*\|172.22.*\|172.23.*\|XXX
... exist for outgoing connections made by any component in your JVM that uses the JVM specific HTTP Client behaviors.
In other words, the built in classes in the JVM.
java.net.HttpURLConnection (if using java.net.URL originated connections)
java.net.http.HttpClient (if you are using Java 9+)
If you are using an HTTP Client that doesn't use one of the 2 above classes, support for these system properties is vanishingly small.
Jetty's own org.eclipse.jetty.client.HttpClient intentionally does not support the JVM system properties (as they cast far too wide of a net for practical use)
Many REST libraries also have dedicated HTTP Clients that don't use the JVM URL based HTTP connections, and also do not support these system properties.
Jetty Server itself does not have or use these concepts for incoming connections to the Jetty Server.
These concepts only exist for outgoing connections.
In the meantime I found out that the backslashes "\" are too much. After I removed them and only pipes "|" are left in the nonProxyHosts variable, everything works. :)
I have HDFS-HA(namenode high availability) setup in my hadoop cluster(using Apache Ambari).
Now, I have one scenario in which my ambari-server machine(which also consist one Namenode i.e. active/Primary) went offline so that my other Namenode(Standby) was active and running but after some time it went offline too for some reason.Services were offline I mean.I was unable to do any operation.What if I have to start the services manually that is used to start using ambari.
I mean using command-line or something
Services can be started from the command line but they should not be in an Ambari environment typically. This is because Ambari does more then just start the service when you issue the start/restart command for any given service. Ambari also makes sure the most up to date configuration is written to each node along with other various house keeping type tasks.
You can look at the logs in Ambari when you start/restart a service to see exactly what Ambari does with respect to writing the configuration, other house keeping, and the exact command to start/restart the given service.
We are using hawtio to have a fancy and nice web interface for seeing JMX MBeans and Camel Route in our project. However, we have noticed that after weeks running Hawtio stops working and we are getting a Jetty error when trying to access it.
We are using hawtio in standalone mode, version 1.2.0/offline. Also I guess it worth to mention that our Camel routes are pretty heavy and consume many resources (not sure if that impacts hawtio). When trying to access we get this:
HTTP ERROR 404
Problem accessing /ourContextPath/. Reason:
Not Found
Powered by Jetty://
It seems like there is no active resource for our context path and I something went wrong like a thread stopped working or something.
Does anybody have any idea how to solve this or how to find what's causing this? Also, is this a known bug fixed in the latest version (1.2.1)?
Jetty needs a work/temp directory to operate.
Default behavior is to use whatever java.io.tmpdir points to.
However, on many unix installations, this points to /tmp, and that directory is often cleaned out by other processes.
To fix, either specify a java.io.tmpdir to be somewhere other than /tmp
$ java -Djava.io.tmpdir=/var/run/jetty -jar start.jar
or create a ${jetty.base}/work/ directory (if running Jetty 9.1+)
or create a ${jetty.home}/work/ directory (if running versions of Jetty prior to 9.1)
See the answer at Jetty: Starts in C:\Temp for more details on how this work/temp directory operates and is configured.
I'm still cheap.
I have a software development environment which is a bog-standard Ubuntu 11.04 plus a pile of updates from Canonical. I would like to set it up such that I can use an Amazon EC2 instance for the 2 hours per week when I need to do full system testing on a server "in the wild".
Is there a way to set up an Amazon EC2 server image (Ubuntu 11.04) so that whenever I fire it up, it starts, automatically downloads code updates (or conversely accepts git push updates), and then has me ready to fire up an instance of the application server. Is it also possible to tie that server to a URL (e.g ec2.1.mydomain.com) so that I can hit my web app with a browser?
Furthermore, is there a way that I can run a command line utility to fire up my instance when I'm ready to test, and then to shut it down when I'm done? Using this model, I would be able to allocate one or more development servers to each developer and only pay for them when they are being used.
Yes, yes and more yes. Here are some good things to google/hunt down on SO and SF
--ec2 command line tools,
--making your own AMI's from running instances (to save tedious and time consuming startup gumf),
--route53 APIs for doing DNS magic,
--ubunutu cloud-init for startup scripts,
--32bit micro instances are your friend for dev work as they fall in the free usage bracket
All of what James said is good. If you're looking for something requiring less technical know-how and research, I'd also consider:
juju (sudo apt-get install -y juju). This lets you start up a series of instances. Basic tutorial is here: https://juju.ubuntu.com/docs/user-tutorial.html