learning_ops_java_spring.md

path	title
/learnings/ops_java_spring	Learnings: Ops: Java: Spring

Table Of Contents

• >
  • Jolokia Spring endpoint "built in"
  • Changing log level on the fly using HTTP
  • Reporting JMX to Metric Collection Tools
  • Debugging what metrics are / should be sent
    • Viewing metric related to Max JVM non heap memory
  • Getting Heapdumps
  • Getting threaddump
• > , >
• >
  • See also:
• >
• >
  • About the Tomcat connection thread pool:
  • Setting the size of the Tomcat Connection Thread Pool
  • >
  • >
  • See also:
• See also:

<<Learning_Ops_Java_Spring>>

See also:

• Spring_Actuators (includes more complete list)

but here's ops scenarios you're probably running into...

Jolokia Spring endpoint "built in"

See: Learning_Ops_Java_JMX_HTTP_Solution_Jolokia

/jolokia <--- automatically there for Spring WebMVC or Jersey apps. If not then you can add it (see link)

See also:

• Spring Boot docs on Jolokia for JMX over HTTP

Changing log level on the fly using HTTP

POST a partial entry (or null, meaning reset) to /loggers

this means you can increase log level to debug to temporarily debug an issue, then set it back when you're done!!!

Reporting JMX to Metric Collection Tools

Supported JMX Metrics sent to metrics registries. Sends:

• memory and buffer pools
• GC stats
• thread utilization
• number of classes loaded / unloaded

^^^^^ Note: some breaking changes around here in Spring Boot 2.0

Debugging what metrics are / should be sent

/metrics can be used to examine metrics collected.

Viewing metric related to Max JVM non heap memory

/actuator/metrics/jvm.memory.max?tag=area:nonheap

Getting Heapdumps

/heapdump <-- outputs it in hprof output format

Getting threaddump

/dump <-- outputs it in json format

See also:

• Idea for enhancing your thread names so you can see whats going on

<<Learning_Ops_Java_Spring_Servlet_Information>> , <<Learning_Ops_Java_Spring_Tomcat_Set_Threads>>

Q: How many threads does Tomcat create by default for a Spring Boot App? A: 200 by default, controlled by server.tomcat.max-thread (do a Find in that page...)

<<Learning_Ops_Java_Spring_Health_Endpoint>>

See also:

• Spring_Actuators_Health

<<Learning_Ops_Java_Spring_And_Kubernetes>>

<<Learning_Ops_Java_Tomcat>>

Tomcat provides the following features:

• HTTP Sessions. See some example code about using that directly
• A thread pool for handling connections
• A threadpool for JDBC connections in case your client connections need the database
• A cache for things??
  • code
  • responses?????

Tomcat is a:

• standalone server you can run .wars in
• embedded server Spring Boot can use

About the Tomcat connection thread pool:

Acceptor thread -> worker thread pool -> worker thread. Worker thread reads data from connection, does the thing and responds. Source.

Setting the size of the Tomcat Connection Thread Pool

See Learning_Ops_Java_Spring_Tomcat_Set_Thread

<<Learning_Ops_Java_Tomcat_Metrics_Monitoring>>

some information about when the aggregated metrics are updated

<<Learning_Ops_Java_Tomcat_Spring_Boot_Metrics>>

Published metrics from Tomcat.

Useful metrics from Spring Boot 2.0:

• tomcat.threads.busy <-- busy threads
• tomcat.threads.current <-- busy + free threads
• tomcat.threads.config.max <-- point where thread exhaustion happens. (See below)

Good explanation here at source

How to set tomcat.threads.config.max : see Learning_Ops_Java_Spring_Tomcat_Set_Threads

GOTCHA when running not embedde Tomcat: make sure you are running > 1.0.7 of micrometer metrics to avoid this bug.

See also:

• http://www.jcgonzalez.com/java-monitor-jdbc-connection-pool-servlet
• https://nixmash.com/post/how-to-increase-embedded-tomcat-cache-in-spring

See also:

• https://spring.io/blog/2015/12/10/spring-boot-memory-performance