DevOps Intermediate

AutoSys Monitoring with WCC — Workload Control Center Guide

Q: What should I check if WCC is not loading?

Check if Tomcat is running (`ps -ef | grep tomcat`) and the port is listening (`ss -tlnp | grep 8080`). Restart Tomcat if needed with the startup.sh script in the WCC bin directory. Also check disk space on the AutoSys server — full disks stop Tomcat.

📅 March 19, 2026 ⏱ 6 min read 🎯 Intermediate

Where developers are forged. · Structured learning · Free forever.

📍 Part of: AutoSys → Topic 23 of 30

Learn how to use AutoSys WCC (Workload Control Center) for real-time job monitoring, flow views, job dependency graphs, and incident response.

⚙️ Intermediate — basic DevOps knowledge assumed

In this tutorial, you'll learn

Learn how to use AutoSys WCC (Workload Control Center) for real-time job monitoring, flow views, job dependency graphs, and incident response.

WCC (Workload Control Center) is the browser-based monitoring dashboard for AutoSys, hosted on Tomcat
Flow View shows jobs as a visual dependency graph — essential for understanding blast radius of a failure
Every WCC action is equivalent to a sendevent command — WCC is a visual wrapper, not a different system

thecodeforge.io

WCC Monitoring Layers

Autosys Monitoring Wcc

✦ Plain-English analogy ✦ Real code with output ✦ Interview questions

⚡Quick Answer

WCC is the browser-based UI for AutoSys, hosted on Tomcat (port 8080/8443).
Key views: Monitor > Jobs (real-time list), Flow View (dependency graph), Job Activity (timeline).
Every WCC action maps to a sendevent command — it's a visual wrapper, not a different control plane.
Performance: WCC auto-refreshes every ~30 seconds; for immediate status use autostatus or autorep.
Production insight: During an incident, Flow View shows blast radius in seconds; click a failed job to jump to its logs.
Biggest mistake: Confusing WCC's refresh lag with real-time — don't trust WCC for sub-second job status without CLI cross-check.

🚨 START HERE

Quick WCC Debug Cheat Sheet

When you're paged at 3 AM, these are the first three things to do in WCC.

🟡

Batch run stalled — no visible progress

Immediate ActionOpen WCC → Monitor > Flow View. Zoom out to see the full graph. Look for red nodes.

Commands

In Filter field, select status = FAILURE. This highlights all failed jobs instantly.

Click on the first red node in the chain (top of the failure cascade) to view its log path.

Fix NowIf it's a file watcher that failed due to missing file, verify the file exists, then right-click → Force Start. Otherwise, right-click → Rerun Job.

🟡

Job is stuck in ACTIVATED status

Immediate ActionSelect the job in Monitor > Jobs. Click the 'Depends' tab to see its conditions.

Commands

Run autorep -J job_name -d to see the exact dependency condition and current status of upstream jobs.

If an upstream job is ON HOLD, release it via right-click → Release. If it's FAILED, you need to force start it first.

Fix NowForce start the upstream job after resolving the root cause, then release this job.

🟡

WCC not loading or returning errors

Immediate ActionSSH to the AutoSys server and check Tomcat process: ps -ef | grep tomcat

Commands

Check port: ss -tlnp | grep 8080 (or 8443 for HTTPS)

If Tomcat is running but WCC is unresponsive, restart it: $AUTOSYS/wcc/bin/shutdown.sh && $AUTOSYS/wcc/bin/startup.sh

Fix NowIf WCC is completely down, use command-line: autorep for status, sendevent for job control, jil for job definitions. WCC is not required for operations.

Production Incident

The Night a Downstream Job Took Down the Entire Batch Run

A single failing job in the middle of a dependency chain caused cascading failures across 200+ jobs. The operations team spent 40 minutes tracing the root cause because they only looked at individual job statuses in Monitor > Jobs.

SymptomBatch run stalled around 2 AM. Multiple downstream jobs showing ON HOLD or ACTIVATED with no error. The team knew something was wrong but couldn't see the full picture.

AssumptionThey assumed the database was slow, so they started restarting database connections. That didn't fix it.

Root causeA file watcher job that verified an upstream file had failed because the file was missing. That failure cascaded, but because the team was looking at individual job statuses instead of the Flow View, they couldn't see the parent-child relationships.

FixOpened WCC, switched to Flow View, zoomed out to see the entire dependency graph. One red node (the file watcher) with a chain of blocked downstream jobs. Manually forced the file watcher (after verifying the file was uploaded), then released all blocked jobs via sendevent.

Key Lesson

Always start incident response with Flow View — it shows the blast radius in one glance.Never trust a single job status in isolation; always check upstream dependencies.WCC's Flow View is the fastest way to find the root cause in a multi-job chain.

Production Debug Guide

Symptom → Action: Use WCC as your first diagnostic tool

Job stuck in ACTIVATED status but not running→Check Flow View for a red upstream ancestor. Use Filter to show ON HOLD/FAILURE ancestors. The problem is almost always a dependency not met.

Job failed with exit code but no error log→Click the job in Monitor > Jobs, then 'View Log' or check the job's std_out_file/std_err_file. If WCC doesn't show the log, SSH to the agent and check the file directly.

Multiple jobs suddenly ON HOLD or INACTIVE with no obvious cause→Open Flow View, select 'Show Dependencies', and look for a single red node near the top of the chain. That's the root cause.

WCC shows job status as RUNNING but it's been running for 4+ hours→Use autorep -J job_name -q to get the exact start time and pid. If the pid is dead, it's a zombie — kill via sendevent -E FORCE_STARTJOB. Then investigate why it hung.

WCC (Workload Control Center) is the browser-based monitoring and management UI for AutoSys. It's hosted on Apache Tomcat (which AutoSys installs automatically) and accessible via a standard web browser. While experienced admins often prefer the command line for speed, WCC is invaluable for understanding the state of a complex job flow at a glance — especially during incident response.

Accessing WCC

WCC runs on the AutoSys application server. The default URL is typically http://autosys-server:8080/wcc or https://autosys-server:8443/wcc for SSL.

Before you can access it, verify Tomcat is running. The AutoSys installation includes a bundled Tomcat server configured specifically for WCC. You'll find the startup scripts in $AUTOSYS/wcc/bin/.

If you're running WCC in a clustered environment, each application server hosts its own WCC instance. You'll need to know the hostname or load balancer VIP. Most teams bookmark the URL in their on-call browser profile — don't be the person fumbling for a bookmark at 3 AM.

wcc_access.sh · BASH

1234567891011121314

# Default WCC URL format
# http://autosys-server-hostname:8080/wcc
# https://autosys-server-hostname:8443/wcc  (SSL)

# Check if WCC (Tomcat) is running on the server
ps -ef | grep -i tomcat

# Check the Tomcat port is listening
ss -tlnp | grep 8080
ss -tlnp | grep 8443

# If WCC is down, restart Tomcat
$AUTOSYS/wcc/bin/shutdown.sh
$AUTOSYS/wcc/bin/startup.sh

🔥WCC doesn't need to be on the AutoSys server

WCC is a web application — it can be accessed from any machine with network access to the server. Most operations teams access it from their laptops or monitoring workstations rather than SSH'ing into the server.

📊 Production Insight

If WCC is unresponsive but autorep works, Tomcat may be out of memory or disk space. Check $AUTOSYS/wcc/logs/catalina.out for OutOfMemory errors.

Rule: always have the CLI fallback ready — WCC is a convenience, not a requirement.

🎯 Key Takeaway

WCC is a Tomcat web app on the AutoSys server.

Access it from any browser on the same network.

If it's down, manage jobs via command-line tools — you never need WCC to run batch.

Key WCC views for day-to-day monitoring

WCC provides several views. These are the ones you'll use most:

Monitor > Jobs: A real-time list of all jobs with their current status, colour-coded. Filterable by status, machine, owner, or name pattern. This is your primary monitoring view.

Monitor > Flow View: Shows jobs as nodes in a dependency graph with connecting arrows. When a job fails, you can immediately see which downstream jobs are blocked. Essential for understanding impact during incidents.

Monitor > Job Activity: A timeline view showing job start and end times. Useful for spotting jobs that are running longer than usual.

Administration > Calendars: View and manage AutoSys calendars.

Administration > Machines: View agent machine status — which are ACTIVE, MISSING, or INACTIVE.

📊 Production Insight

Most teams rely solely on Monitor > Jobs, but that view hides dependencies. Flow View reveals the blast radius in seconds.

Rule: during any incident, always open Flow View first.

Don't trust Monitor > Jobs alone — it doesn't show parent-child relationships.

🎯 Key Takeaway

WCC has four critical views: Jobs, Flow, Activity, and Admin.

Flow View is the only one that shows dependency chains — use it for incident root cause analysis.

Job Activity is for performance trend spotting, not real-time monitoring.

Using WCC during an incident

When the on-call team gets paged at 3 AM because a batch run is failing, WCC is where you start. The flow of an incident investigation:

Open WCC and go to Monitor > Jobs. Filter by status = FAILURE to see all failed jobs.
Click on the first failed job — it's likely the root cause if multiple jobs failed.
Switch to Flow View to see the dependency chain. This shows you exactly which downstream jobs are blocked.
Check the failed job's logs by clicking 'View Log' or checking its std_out_file attribute.
After fixing the root cause, Force Start the failed job via right-click → Force Start.
Monitor the downstream jobs as they cascade from ACTIVATED to RUNNING to SUCCESS.

Pro tip: In large environments, use the filter to show only jobs that are ON HOLD or FAILURE — this reduces noise and highlights the critical path.

incident_workflow.sh · BASH

123456789101112131415161718

# Step 1: Check WCC Monitor > Jobs, filter by status = FAILURE
# Visual: red jobs immediately visible

# Parallel: command-line equivalent
autorep -J % -s FA

# Step 2: Click the failed job in WCC to see its attributes and log paths
# Command-line equivalent:
autorep -J failed_job -d
cat /logs/autosys/failed_job.err

# Step 3: Use Flow View to see which downstream jobs are blocked
# Command-line equivalent:
autorep -J % | grep -E 'AC|IN' | head -20  # show ACTIVATED/INACTIVE jobs

# Step 4: After fixing, restart via WCC (right-click > Force Start)
# Command-line equivalent:
sendevent -E FORCE_STARTJOB -J failed_job

⚠ WCC actions and command-line actions are equivalent

Every action you can take in WCC (force start, hold, kill, release) is the same as running the corresponding sendevent command. WCC is just a visual wrapper. Some teams restrict WCC access and require command-line only for audit trail purposes.

📊 Production Insight

During an incident, every second counts. WCC's refresh cycle adds 5-30 seconds of delay. If you need immediate status after a Force Start, verify with autostatus -J job_name.

Rule: never trust WCC's display alone after an action — always cross-check with CLI.

The biggest time sink during incidents is chasing the wrong failed job. Flow View eliminates that.

🎯 Key Takeaway

Incident flow: filter FAILURE jobs → click first red job → Flow View to see blast radius → fix and Force Start.

Always cross-check WCC status with CLI commands after actions.

The first failed job in the chain is the root cause — don't fix downstream symptoms.

Understanding Monitor > Jobs View

The Monitor > Jobs view is your day-to-day dashboard. It displays a table of all jobs with columns: Job Name, Status, Last Start Time, Last End Time, Machine, Owner, and Exit Code. You can sort by any column and filter by status, machine, owner, or job name pattern.

Color coding: SUCCESS (green), FAILURE (red), RUNNING (blue), ACTIVATED (yellow), ON HOLD (grey), INACTIVE (white). This makes status scanning fast.

You can right-click any job to perform actions: Force Start, Hold, Rerun, Kill, Release. The actions are equivalent to sendevent commands.

One overlooked feature: the 'View Log' popup shows the last N lines of the job's stdout and stderr. However, if the log is on the agent and the agent is unreachable, this won't work. Always have direct SSH access as a fallback.

Pro tip: Save a custom filter for jobs on your team's critical path. For example, filter by job name pattern PAYROLL% and status != SUCCESS to quickly spot non-green jobs in the nightly batch.

💡Filter by Owner to see your team's jobs

If multiple teams share the same AutoSys instance, use the Owner filter to see only your team's jobs. This reduces noise when monitoring during off-hours.

📊 Production Insight

When a job fails, the exit code matters. Exit code 0 = success, non-zero = failure. But some jobs exit with code 0 and still fail logically (e.g., a script that exits 0 after writing an error to stdout). Always check the log.

Rule: don't just rely on the colour — click the job and read the log.

WCC's log viewer is convenient but slow for large logs; use tail -100 via SSH instead.

🎯 Key Takeaway

Monitor > Jobs is the real-time list with colour-coded statuses.

Filter by status, machine, owner, or name pattern.

Always verify failures by reading the actual log — exit code alone is not enough.

Monitor > Flow View: Managing Dependencies Visually

Flow View is WCC's most powerful feature for incident response. It displays jobs as nodes in a directed graph, with arrows representing condition dependencies (SUCCESS, FAILURE, EXIT code, etc.). You can zoom in/out, pan, and click any node to see its details.

When a job fails, its node turns red. All downstream jobs that depend on it are highlighted as blocked (ON HOLD or ACTIVATED with greyed-out arrows). This visual representation immediately answers the question: 'What is affected?'

You can also edit dependencies from Flow View? No — WCC is read-only for dependencies. You must use JIL to change conditions. However, you can view the dependency details by clicking a job and looking at the 'Depends' tab.

Flow View also supports 'Trace' mode: click a job and select 'Trace Upstream' — this highlights all jobs that must succeed before this one can run. Useful for debugging a stuck ACTIVATED job.

Pro tip: In large flows with hundreds of jobs, use the Filter in Flow View to show only jobs with status = FAILURE or ON HOLD. This declutters the graph and highlights the problem chain.

flow_view_tips.sh · BASH

1234567891011

# Find jobs blocked by a specific failed job
autorep -J downstream_job -d | grep -i condition

# Show all jobs that depend on a given job (reverse dependency)
autorep -J % -q | grep "upstream_job_name"

# View the full dependency tree recursively (bash snippet)
autorep -J % -q | awk -F' ' '{print $1}' | while read job; do
  echo "--- $job depends on ---" 
  autorep -J $job -d 2>/dev/null | grep -i "condition"
done

Mental Model

Think of Flow View as the wiring diagram for your batch

Just like an electrical circuit — if a fuse blows upstream, everything downstream goes dark.

Each job = a component in the circuit.
Arrows = wires carrying voltage (conditions).
Failed job = blown fuse. Red node = fuse blown.
Downstream jobs = components waiting for power. They won't run until the upstream fuse is replaced.
WCC Flow View is the circuit schematic — trace the failure path from the blown fuse.

📊 Production Insight

In large batch environments (1000+ jobs), Flow View can be slow to load, especially on first render during an incident. If it hangs, use the command-line method to trace dependencies: autorep -J job_name -d.

Rule: for critical chains, pre-generate a static dependency map using JIL exports.

WCC Flow View is the best diagnostic tool, but don't let a slow browser delay incident response — have a CLI fallback script ready.

🎯 Key Takeaway

Flow View shows jobs as nodes with dependency arrows.

Trace Upstream helps find why a job is stuck.

Pre-generated dependency maps prevent WCC slowdown during crises.

Administering Machines and Calendars

The Administration views in WCC let you manage two critical aspects of AutoSys: machines and calendars.

Administration > Machines: Shows a list of all machines connected to the AutoSys application server. Each machine has a status: ACTIVE (agent is connected and healthy), MISSING (agent not responding after 20 minutes), INACTIVE (agent was deactivated). If a machine is MISSING, jobs assigned to that machine will stay in ACTIVATED state waiting for an available agent. You can right-click a machine to toggle its status or view properties.

Administration > Calendars: View and manage calendar definitions. Calendars control which days jobs run. You can create, edit, delete calendars. Changes take effect immediately — no restart needed. Pro tip: Never delete a calendar that's still referenced by active jobs. WCC will warn you, but double-check with autocal_asc first.

Limitation: WCC does not allow you to add or remove machines — only view and change their status. Machine registration is done via JIL or the AutoSys admin utility.

Pro tip: Use the Machine view during an incident to verify that the agent on the critical machine is ACTIVE. A MISSING agent is a common root cause of stuck jobs.

🔥Machines and agents are the same

In AutoSys, a 'machine' refers to an agent that runs jobs. Each agent registers with the application server. If the agent service stops, the machine status goes MISSING after 20 minutes of no heartbeat.

📊 Production Insight

A MISSING machine status is often caused by a stopped agent service or network issue. But sometimes it's because the agent's disk is full — the agent can't write heartbeats. Always check disk space on the agent:

df -h.

Rule: monitor machine status proactively — a MISSING machine can silently delay hundreds of jobs until someone notices.

Calendar changes are immediate, but no audit log exists in WCC. If someone deletes a calendar by mistake, recovery requires recreating it from backups.

🎯 Key Takeaway

Admin > Machines shows agent status: ACTIVE, MISSING, INACTIVE.

MISSING agents block jobs assigned to them — fix the agent or reassign jobs.

Calendars control job schedules; changes are instant but not audited via WCC.

Troubleshooting WCC Connectivity and Performance

WCC can be temperamental. Here are common issues and what to check:

WCC won't load: Check Tomcat process with ps -ef | grep tomcat. If Tomcat is running, check if the port is listening: ss -tlnp | grep 8080. If Tomcat is not running, start it: $AUTOSYS/wcc/bin/startup.sh. If it crashes immediately, check catalina.out for OutOfMemory errors or port conflicts.

Slow page loads: WCC performance degrades when the database (where AutoSys stores job data) is under load. Also, a large number of jobs (10k+) can slow down the initial page load. Tip: Use filters to reduce the data returned. For example, filter by a specific machine or job name pattern before loading.

Session timeout: WCC has a configurable session timeout (default 30 minutes). If you step away, you'll be logged out. The session is in Tomcat's web.xml. You can extend it, but that's a security trade-off.

Stale data across multiple tabs: If you have multiple WCC tabs open, each may have its own session. They don't auto-sync. Closing and reopening WCC is the quick fix.

WCC vs CLI conflict: Sometimes WCC shows a job as RUNNING but the CLI shows it as SUCCESS. This is a browser cache issue. Press Ctrl+F5 or clear the browser cache.

Log viewer fails: The 'View Log' button in WCC tries to read from the agent's log location. If the agent is unreachable (MISSING), it will fail. Use SSH to the agent directly.

wcc_troubleshoot.sh · BASH

1234567891011121314151617181920

# Check Tomcat process
ps -ef | grep tomcat

# Check if port is listening
ss -tlnp | grep -E '8080|8443'

# Check catalina logs for errors
tail -200 $AUTOSYS/wcc/logs/catalina.out

# Restart Tomcat
$AUTOSYS/wcc/bin/shutdown.sh
$AUTOSYS/wcc/bin/startup.sh

# If restart fails, check disk space
# Tomcat needs free space for logs and temp files
df -h

# If WCC is still down, continue operations via CLI
autorep -J %
sendevent -E FORCE_STARTJOB -J my_job

⚠ Do not restart Tomcat during active batch runs unless necessary

Restarting Tomcat only affects WCC, not job scheduling. sendevent and batch processing continue independently. However, if an operator is in the middle of an action in WCC (like a Force Start), it will be lost. Use CLI for critical actions during restart.

📊 Production Insight

The most common cause of WCC downtime is a full disk on the application server. Tomcat writes logs aggressively. Set up log rotation or a disk usage alert.

Rule: alerts on disk space are more important than alerts on WCC availability — WCC going down is often a symptom of disk pressure.

Always have a quick-reference card for CLI commands taped to your monitor (or bookmarked). When WCC is down, you can't afford to search for commands.

🎯 Key Takeaway

WCC issues are usually Tomcat, database, or disk related.

Restart Tomcat only when necessary — batch operations are unaffected.

Keep CLI commands at hand — WCC is not required to run or monitor jobs.

🗂 WCC Views vs CLI Equivalents

Quick reference for operator decision-making

WCC View	What it shows	CLI equivalent
Monitor > Jobs	All jobs with real-time status	autorep -J %
Monitor > Flow View	Visual dependency graph	No direct equivalent (use autorep -J % -d to see conditions)
Monitor > Job Activity	Timeline of job runs	autorep -J % -run 1
Administration > Machines	Agent machine statuses	autorep -M %
Administration > Calendars	Calendar definitions	autocal_asc -r calendar_name

🎯 Key Takeaways

WCC (Workload Control Center) is the browser-based monitoring dashboard for AutoSys, hosted on Tomcat
Flow View shows jobs as a visual dependency graph — essential for understanding blast radius of a failure
Every WCC action is equivalent to a sendevent command — WCC is a visual wrapper, not a different system
If WCC is down, all monitoring and operations can continue via command-line tools (autorep, sendevent, autostatus)
WCC's auto-refresh has 5-30 second latency; always cross-check critical actions with CLI
Use filters aggressively in WCC to reduce noise and focus on the failure chain during incidents

⚠ Common Mistakes to Avoid

✕Not bookmarking WCC in your on-call browser

Symptom

When paged at 3 AM, you waste precious minutes searching for the URL or asking teammates. Stress increases.

Fix

Add WCC URL as a bookmark with a label like 'AutoSys WCC'. Keep it in a dedicated on-call browser profile or a shared team wiki.

✕Using WCC for bulk operations

Symptom

WCC becomes sluggish when you need to force start 50 jobs. Clicking each job individually takes too long.

Fix

Use CLI loops: for job in list; do sendevent -E FORCE_STARTJOB -J $job; done. WCC is for visibility, not bulk actions.

✕Confusing WCC's refresh cycle with real-time

Symptom

After a Force Start in WCC, you see it still as FAILURE because the refresh hasn't happened yet. You may double-execute.

Fix

WCC auto-refreshes every ~30 seconds. For immediate status, use autostatus -J job_name or autorep -J job_name -q.

✕Leaving WCC sessions open across multiple tabs

Symptom

One tab shows a job as RUNNING, another shows SUCCESS. Conflicting data causes incorrect decisions.

Fix

Work with a single WCC tab during an incident. If you need multiple views, open them as separate browser windows (not tabs) — each window gets its own session.

Interview Questions on This Topic

QWhat is WCC in AutoSys?JuniorReveal
WCC (Workload Control Center) is the browser-based UI for AutoSys. It provides real-time job monitoring, visual dependency flow views, calendar management, and machine status. It runs on Apache Tomcat, which AutoSys installs automatically. WCC is a convenience layer — all operations can be performed via CLI.
QWhat is the Flow View in WCC and when would you use it?JuniorReveal
Flow View displays AutoSys jobs as nodes in a directed graph, with arrows showing condition dependencies. You'd use it during incident response to understand the blast radius of a failure — it immediately shows which downstream jobs are blocked. It's also useful for troubleshooting a stack collection by tracing upstream dependencies.
QHow do you access WCC?JuniorReveal
WCC is accessed via a web browser using the URL http://autosys-server-hostname:8080/wcc (or HTTPS on port 8443). The server must be running Tomcat, which is started via $AUTOSYS/wcc/bin/startup.sh. You need network access to the server and appropriate credentials.
QCan you perform all AutoSys operations from WCC or only some?Mid-levelReveal
WCC supports viewing job statuses, logs, calendars, and machines. It also allows job control actions like Force Start, Hold, Kill, Release, and Rerun. However, you cannot create or modify job definitions, change dependencies, or add machines via WCC — those require JIL or the command line.
QWhat do you do if WCC is down but you still need to monitor and manage jobs?SeniorReveal
You use command-line tools: autorep for job status and reporting, sendevent for job control (Force Start, Hold, Kill, etc.), and autocal_asc for calendar operations. WCC is a convenience — the core AutoSys functionality is entirely CLI-based. You should always have a quick reference card for these commands.

Frequently Asked Questions

What is WCC in AutoSys?

WCC (Workload Control Center) is the browser-based UI for AutoSys. It provides real-time job monitoring, visual dependency flow views, calendar management, and machine status. It runs on Apache Tomcat, which AutoSys installs automatically.

What port does WCC use?

WCC uses port 8080 by default (HTTP) or 8443 (HTTPS). Access it at http://your-autosys-server:8080/wcc from any browser with network access to the server.

What is the Flow View in WCC?

Flow View shows AutoSys jobs as nodes in a visual dependency graph, connected by arrows representing condition dependencies. When a job fails, you can immediately see which downstream jobs are blocked, making it invaluable during incident response.

Can I manage AutoSys without WCC?

Yes. Everything WCC does can be done via command-line tools: autorep for reporting, sendevent for job control, jil for job definitions, and autocal_asc for calendars. WCC is a convenience layer, not a requirement.

What should I check if WCC is not loading?

Check if Tomcat is running (ps -ef | grep tomcat) and the port is listening (ss -tlnp | grep 8080). Restart Tomcat if needed with the startup.sh script in the WCC bin directory. Also check disk space on the AutoSys server — full disks stop Tomcat.

Does WCC work during an Active-Active cluster?

Yes, each application server runs its own WCC instance. You can access any of them. However, the load balancer should stick to one session for a given user to avoid seeing stale data from different nodes. Also, if you kill Tomcat on one node, users on that node need to reconnect to another. DNS round-robin is common.

How do I extend the WCC session timeout?

The session timeout is configured in the Tomcat web.xml file located in $AUTOSYS/wcc/conf/web.xml. Look for the <session-timeout> element (value in minutes). Changing it requires a Tomcat restart. Be aware that longer timeouts increase security risk — sessions left open on a shared workstation could be misused.

🔥

Naren Founder & Author

Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.

About Naren Get in touch

Forged with 🔥 at TheCodeForge.io — Where Developers Are Forged