In a recent customer case, we were asked to investigate a severe performance degradation in a large-scale Oracle ADF production environment. Users were experiencing sporadic but extreme slowdowns, with some requests taking over 30 seconds to complete. The average request time hovered around 3 seconds – already high – but these spikes pointed to a deeper, underlying problem.

The customer had already reviewed SQL queries, AM pooling, page flows, and server configurations. Nothing unusual stood out.

The Clue: Long Thread Wait Times

Using the ADF Performance Monitor (ADFPM), we quickly noticed a pattern:
Java threads were frequently stuck in a waiting state, with unusually long wait times.

These weren’t typical database or ViewObject delays – this behavior pointed to something deeper in the Java runtime.

Digging Deeper: What Were the Threads Waiting For?

Thread dump analysis, together with runtime data from ADFPM, revealed several blocked threads. All signs pointed toward contention in the logging infrastructure — multiple threads were blocked while trying to write to shared logging resources:

But what was triggering this logging overload?

⚠️The Hidden Culprit: Oracle Logger Set to INFO

In Oracle Enterprise Manager, we discovered that the root logger for the oracle package had been set to INFO level. While less verbose than FINE, this level is still far too detailed for production environments, especially when applied to a large package like oracle.*.

Because this setting was configured on the root oracle package, it propagated to all sub-loggers, resulting in excessive background logging. Each request triggered log output from many components, and all threads attempted to write to the same log file at once — causing thread contention and blocking.

✅ The Fix: One Logging Change, Massive Performance Gain

Once we adjusted the the ‘oracle’ root package logger to level WARNING and updated the logging.xml to to ensure the change persisted across server restarts.

The result was immediate:

• 🚀 Average request time dropped from 3 seconds to 0.4 seconds
• 🧘 No more sporadic 30-second requests
• 📉 Thread wait times disappeared from ADFPM

Why the ADFPM Was Critical

This kind of issue is notoriously difficult to detect.

There were no errors, no stack traces, no failed transactions — just threads, silently waiting in the background.

While ADFPM didn’t directly flag the logging configuration, it clearly highlighted the unusual thread behavior. That visibility allowed us to narrow down the investigation and find the root cause.

Takeaways

• Always review logging configurations in production – especially inherited package log levels
• ADFPM surfaces deep runtime issues that are otherwise invisible
• Monitoring Java thread states is just as important as analyzing SQL or ADF lifecycles

Want to See What’s Happening Inside Your ADF Application?

If you’ve ever dealt with slowdowns, stuck threads, or unexplained performance issues – the ADF Performance Monitor can help.

👉 Learn more at adfpm.com
📩 Or feel free to contact us for a demo or trial