Private corporate batches, live online cohorts and 1-on-1 mentoring in Apache Tomcat administration — connectors and tuning, TLS, clustering, session replication — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Apache Tomcat as a JVM process with web-server behaviour: the Server, Service, Connector, Engine, Host and Context hierarchy read as an operational map; connector and executor sizing derived from measurement rather than defaults; classloader structure and the redeploy leaks it produces; and clustering with session replication costed honestly before it is switched on. Sessions run against live instances — a thread pool driven to exhaustion and diagnosed from a thread dump, TLS configured at the connector and behind a proxy, an AJP path proved to carry the real client address, and a cluster failed over with sessions intact.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Apache Tomcat that means a trainer who has run it in production — Apache Tomcat administration — connectors and tuning, TLS, clustering, session replication — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Apache Tomcat batchApache Tomcat is an open-source servlet container and web server from the Apache Software Foundation. It implements the Jakarta Servlet, JSP, Expression Language and WebSocket specifications, which makes it the runtime underneath a very large share of Java web applications — directly, or embedded inside Spring Boot, where the same connector and thread pool settings apply even though there is no standalone installation to configure.
A running Tomcat instance is a small hierarchy of components defined in server.xml: a Server containing a Service, which binds one or more Connectors to a single Engine, which contains Hosts, which contain Contexts — one per deployed application. That hierarchy is the operational map. The Connector decides protocol, port, thread pool size, keep-alive and TLS behaviour, and is where most capacity problems live. The Host decides virtual hosting and automatic deployment. The Context decides classloading, session handling and resource lookups for a single application.
For an infrastructure team, Apache Tomcat is a JVM process with web-server characteristics, and it has to be operated as both. That means connector and executor sizing rather than defaults, heap and garbage collection settings chosen from measurement, deployment through the Manager application or a build pipeline rather than by hand, TLS terminated either at Tomcat or in front of it, access and catalina logging that survives an incident review, and clustering with session replication when a single instance is no longer acceptable. Tomcat is usually run behind NGINX or the Apache HTTP Server, so the AJP and HTTP proxy path — and preserving the real client address across it — is part of the same job.
Java remains the backbone of enterprise application estates, and Tomcat is where most of it runs. The operational reality is that Tomcat is rarely anyone's declared specialism — it is a thing that already exists, running with the settings it shipped with, until it becomes the reason a release cannot be deployed or a service will not stay up.
The recurring failures are all sizing and configuration. maxThreads left at the default while the connection pool behind it is smaller, so requests queue in the wrong place. A heap that has never been sized against the actual live set, producing garbage collection pauses that look to everyone else like network latency. An AJP connector left open on all interfaces. Session replication switched on across a cluster without anyone measuring what it costs, so adding a node makes things slower. The Manager application reachable from outside with a weak account. Applications that leak classloaders on redeploy, so the tenth deploy of the day exhausts metaspace. Each of these is a known problem with a known fix that nobody was taught.
The embedded case has made this more urgent rather than less. Spring Boot ships Tomcat inside the artifact, which means the connector, thread pool and TLS settings that used to live in server.xml now live in application properties — and are configured by developers who have never operated a servlet container. Teams that can reason about connectors, threads, sessions, classloading and the JVM underneath are exactly what platform and middleware roles are asking for.
What a servlet container actually does, and where Tomcat sits between a web server and a full Jakarta EE application server. Then installation on both Linux and Windows, running Tomcat as a service, multiple instances on one host with CATALINA_HOME and CATALINA_BASE, and the JVM prerequisites that constrain everything later.
Topics: Overview of the servlet container and the specifications Tomcat implements · Tomcat versus a full application server · Setup requirements and installation on Linux · Setup requirements and installation on Windows · Running Tomcat as a service on both platforms · CATALINA_HOME, CATALINA_BASE and multiple instances · JVM selection and version compatibility
A full walkthrough of what is on disk and what each part controls. The bin, conf, lib, logs, webapps, work and temp directories; server.xml as a component tree of Server, Service, Connector, Engine, Host and Context; web.xml defaults; context.xml; catalina.properties; and the environment scripts where JVM options actually belong.
Topics: Directory layout: bin, conf, lib, logs, webapps, work and temp · server.xml and the Server, Service, Engine, Host and Context hierarchy · The default web.xml and its servlet mappings · context.xml and per-application context descriptors · catalina.properties and the common classloader · setenv.sh and where JVM options belong · Tomcat classloader hierarchy and shared libraries
Getting applications onto the server predictably. WAR structure and the deployment lifecycle, autoDeploy and deployOnStartup behaviour and their risks, deployment through the Manager application and its API, parallel deployment for versioned releases, context path control, and the classloader leaks that make repeated redeployment fail.
Topics: WAR structure and the deployment lifecycle · The deployment directory, autoDeploy and deployOnStartup · The Manager application: interface, roles and text API · Host Manager and virtual host administration · Parallel deployment and versioned application releases · Context path control and external application directories · Redeploy classloader leaks and metaspace exhaustion · Deploying from a build pipeline rather than by hand
The single most important operational module. HTTP and AJP connectors, the NIO and NIO2 implementations, maxThreads and minSpareThreads, acceptCount and the accept queue, maxConnections, keep-alive, connection and socket timeouts, shared executors, and how all of these interact with the database connection pool sitting behind them.
Topics: HTTP and AJP connectors and their protocols · NIO and NIO2 protocol implementations · maxThreads, minSpareThreads and the request thread pool · acceptCount, maxConnections and queueing behaviour · Keep-alive, connection timeout and socket settings · Shared Executor configuration across connectors · Sizing threads against the database connection pool · Diagnosing thread pool exhaustion from a thread dump
Running several sites or tenants from one Tomcat. The Host element and appBase, name-based virtual hosting and aliases, per-host application isolation and logging, virtual host creation in a shared hosting arrangement on both Linux and Windows, and the isolation limits you need to understand before you rely on them.
Topics: Virtual host overview and the Host element · appBase, unpackWARs and per-host deployment · Host aliases and name-based virtual hosting · Virtual host creation in a shared hosting environment on Windows · Virtual host creation in a shared hosting environment on Linux · Per-host logging and error handling · Isolation limits between applications in one JVM · When separate instances beat virtual hosts
Making an instance fit for production. Security basics and the Tomcat security model, realms and user management, securing the Manager application, then TLS: keystores and certificate chains, configuring the connector for HTTPS on both Windows and Linux, protocol and cipher selection, and the hardening items every audit asks about.
Topics: Tomcat security basics and the security model · Realms, roles and user management · Securing or removing the Manager and Host Manager applications · Keystores, truststores and certificate chains · Enabling SSL: configuring a certificate for a site · Enabling SSL: chains, intermediates and renewal · SSL configuration on the Linux platform · Protocol and cipher selection, and grading the result · Hardening: shutdown port, AJP secret, version disclosure, file permissions
Surviving the loss of an instance. High availability through clustering, cluster configuration on Linux and Windows, membership and the replication channel, sticky sessions versus session replication and the real cost of each, load balancing with NGINX or the Apache HTTP Server in front, and rolling restarts that keep sessions alive.
Topics: High availability using clustering · Cluster setup on Windows · Cluster setup on Linux · Cluster membership, channels and replication transport · Sticky sessions and session affinity · Session replication: delta versus backup managers · The measured cost of replication in latency and memory · NGINX load balancing in front of Tomcat on Windows · NGINX load balancing in front of Tomcat on Linux · AJP and HTTP proxying from the Apache HTTP Server · Rolling restarts without losing sessions
Explaining behaviour instead of restarting. The Tomcat logging subsystem and access log valves with useful patterns, JVM tuning — heap sizing, garbage collector choice, metaspace — driven by garbage collection logs, JMX and monitoring, and a diagnostic method built on thread dumps, heap dumps and evidence.
Topics: Tomcat logging subsystem and juli configuration · Access log valve patterns worth capturing · catalina.out, rotation and log shipping · Tuning parameters: heap sizing and the live set · Garbage collector selection and reading GC logs · Metaspace, direct memory and native memory · JMX, exporters and monitoring Tomcat · Thread dumps and heap dumps as diagnostic tools · A method for slow responses, 503s and OutOfMemoryError
We rebuild the agenda around the tools you actually run.
Request a custom agendaDrive a connector past maxThreads under load, capture a thread dump at the moment of failure, and identify precisely where requests were blocked.
Redeploy an application repeatedly until metaspace is exhausted, then find the retained classloader in a heap histogram and explain the leak.
Build a keystore with a full chain, enable TLS at the connector, verify with a scanner, then move termination to a proxy and compare the two arrangements.
Run a two-node cluster with session replication behind a load balancer, kill a node mid-session, and confirm what the user actually experienced.
Enable GC logging under a realistic workload, derive the live set, resize the heap and select a collector, then prove the pause-time improvement.
Deliver a hardened, monitored, load-balanced Tomcat cluster with pipeline deployment, then take it through a rolling upgrade and an incident drill.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.