DEV Community: Prathap Reddy

Technical post idea: WebLogic — High CPU Troubleshooting

Prathap Reddy — Wed, 16 Sep 2026 03:05:48 +0000

🚨 Oracle WebLogic Server: How I Approach a High CPU Issue

A high CPU alert on a WebLogic server doesn't always mean the JVM itself is the problem.

A structured troubleshooting approach can help identify the actual source.

🔹 1. Check OS-level CPU

Start by identifying which process is consuming CPU:

top

ps -ef | grep java

Don't immediately restart the server. First identify the process and PID.

🔹 2. Identify the WebLogic JVM

Once the Java PID is identified, verify:

• Which Managed Server is using the JVM
• JVM heap configuration
• Number of threads
• GC activity
• Application workload

🔹 3. Check WebLogic Thread Activity

Look for:

• Stuck threads
• Excessive thread usage
• Long-running requests
• Connection pool issues
• Repeated application requests

The WebLogic Administration Console and server logs can provide useful clues.

🔹 4. Take Thread Dumps

For CPU-related issues, thread dumps can help identify what the JVM threads are actually doing.

Take multiple thread dumps at intervals rather than relying on a single snapshot.

Example:

jstack <PID> > threaddump1.txt

Then compare the dumps to identify threads that remain active.

🔹 5. Check Garbage Collection

High CPU can also be associated with excessive GC activity.

Review:

• Young GC
• Full GC
• Heap utilization
• GC frequency
• Pause times

🔹 6. Check Application-Level Processes

Sometimes the WebLogic JVM is only where the symptom appears.

The underlying cause may be:

➡️ Application code
➡️ Infinite/repeated processing
➡️ Database calls
➡️ External service calls
➡️ Incorrect configuration
➡️ Memory/GC pressure

🔹 7. Don't Treat Restart as the Root-Cause Fix

Restarting the Managed Server may temporarily reduce CPU, but it doesn't explain why the CPU increased.

A better approach is:

Alert → Identify PID → Analyze threads → Check GC → Review logs → Identify root cause → Apply fix → Monitor

This approach helps convert a production incident from a "restart and recover" activity into a proper troubleshooting exercise.

💡 Key takeaway:

High CPU is a symptom. The goal is to identify the workload or thread causing it.

What other WebLogic troubleshooting topics would you like to see?

Oracle #WebLogic #OracleWebLogic #Middleware #Java #JVM #Troubleshooting #ProductionSupport #OracleTechnology #DevOps

Oracle Forms & Reports 12.2.1.4 to 12.2.1.19 Upgrade: Post-Upgrade Issues, Missing Files, and Troubleshooting Lessons

Prathap Reddy — Sun, 06 Sep 2026 14:22:04 +0000

Introduction

Oracle Forms and Reports upgrades are often considered complete once the new Oracle Home, WebLogic configuration, Forms services, and Reports services are successfully installed and started.

However, in a real enterprise environment, the upgrade does not end when the servers come up successfully.

The real challenge often begins during post-upgrade validation.

Recently, while working on an Oracle Forms & Reports upgrade from 12.2.1.4 to 12.2.1.19, we encountered several issues after the upgrade:

Forms application icons/images were missing.
Some Reports were not accessible or were failing to run.
OS-level and kernel compatibility issues required validation.
Some supporting files and custom configurations were not available in the upgraded environment.
Existing customizations from the previous environment needed to be compared and restored.

The interesting part was that the core Forms and Reports services were running. The issue was not simply that the application was down.

The problem was in the post-upgrade configuration, customizations, supporting files, and environment differences.

This blog explains our troubleshooting approach and the key lessons learned.

The Upgrade Scenario

The environment was upgraded from:

Oracle Forms & Reports 12.2.1.4

to:

Oracle Forms & Reports 12.2.1.19

At first, the upgraded environment appeared healthy:

WebLogic was running.
Forms services were running.
Reports services were running.
Application access was available.
Basic functionality was working.

But during application validation, we identified issues that were not immediately visible from the server startup status.

This is an important lesson:

A successful middleware startup does not necessarily mean a successful application upgrade.

Issue #1 – Forms Icons and Images Were Missing

One of the first issues noticed after the upgrade was that some Forms application icons/images were not displayed correctly.

The Forms application itself could be accessed, but certain visual resources were missing.

This immediately raised several questions:

Were the application resources migrated?
Were custom JAR files copied?
Was formsweb.cfg migrated correctly?
Was Registry.dat customized?
Were image/resource directories available?
Were the correct paths configured?
Were the required files available under the new Oracle Home or application deployment?

Instead of assuming that the Forms installation was corrupted, we started comparing the old and new environments.

Comparing the Old and New Environments

One of the most useful troubleshooting techniques during an upgrade is:

Compare the working 12.2.1.4 environment with the upgraded 12.2.1.19 environment.

Rather than looking only at the new environment, we treated the old environment as a reference point.

We reviewed:

Forms configuration
formsweb.cfg
default.env
Registry.dat
Application resources
*.jar
images
icons
custom resources
application-specific files
Forms directories

We also reviewed the relevant Forms configuration and application directories to identify differences.

This comparison helped us identify files and customizations that needed to be restored or merged into the upgraded environment.

Important Lesson – Do Not Blindly Copy Configuration Files

One of the biggest lessons from the troubleshooting process is that an upgrade should not be treated as:

Old Oracle Home
↓
Copy everything
↓
New Oracle Home

That approach can introduce new problems.

Instead, the better approach is:

12.2.1.4 Environment
↓
Identify customizations
↓
Compare with 12.2.1.19
↓
Validate compatibility
↓
Merge required configurations
↓
Test

The goal is to migrate required customizations, not blindly overwrite the new configuration.

Issue #2 – Reports Were Not Accessible

The second major issue was related to Oracle Reports.

Some reports that were previously accessible were no longer working correctly after the upgrade.

We therefore started investigating the Reports environment separately from Forms.

The following areas became important:

rwserver.conf
rwnetwork.conf
REPORTS_PATH
Environment variables
Reports Server configuration
Reports Tools configuration
Printer configuration
Font configuration
Report files
TNS configuration
Custom directories

Reports Configuration Validation

The Reports Server configuration was compared between the old and new environments.

Particular attention was given to:

rwserver.conf
rwnetwork.conf

We also reviewed the environment variables used by Reports.

For example:

echo $ORACLE_HOME
echo $PATH
echo $TNS_ADMIN
echo $REPORTS_PATH

The objective was to determine whether the upgraded Reports Server had access to the same required resources as the previous environment.

.prt Files – An Easily Overlooked Area

Another important area during our investigation was the Reports printer configuration.

We found differences in the available .prt files between the environments.

For example, the environment contained directories such as:

$ORACLE_HOME/reports/printer

and:

$ORACLE_HOME/reports/printers

We compared the files available in these directories between the old and new environments.

For example:

find $OLD_ORACLE_HOME/reports/printer -type f -name "*.prt" | sort

and:

find $NEW_ORACLE_HOME/reports/printer -type f -name "*.prt" | sort

The same comparison can be performed for:

$ORACLE_HOME/reports/printers

This type of comparison is useful because printer-related configuration can be overlooked when focusing only on WebLogic, Forms and Reports server startup.

OS and Kernel Compatibility

Another area that should not be ignored during a Forms & Reports upgrade is the underlying operating system.

Even if the middleware configuration looks correct, differences at the OS level can affect application behavior.

We reviewed areas such as:

OS version
Kernel version
Installed patches
Shared libraries
System dependencies
Environment variables
File permissions
Services
System-level configuration

For example:

uname -r

can be used to identify the running kernel version.

Additional OS package and library validation may also be required depending on the platform and Oracle certification requirements.

The key point is:

Middleware compatibility should always be evaluated together with the underlying OS and system libraries.

Finding the Missing Files

At this stage, the most effective method was not to guess which file was missing.

We followed a simple approach:

Step 1 – Identify the failed functionality

For example:

Missing Forms icon

or:

Report cannot be accessed
Step 2 – Identify the resource required

Determine which configuration, JAR, image, report, printer definition, environment variable, or system dependency is involved.

Step 3 – Compare old and new environments
12.2.1.4 → Working
12.2.1.19 → Not working
Step 4 – Identify the difference

Look for:

Missing file
Different configuration
Different path
Missing customization
Different permissions
Missing library
Different OS dependency
Step 5 – Restore the required customization

Only after validating the difference should the required file or configuration be added to the new environment.

Resolution

After identifying the missing files/configurations, we restored the required resources into the upgraded environment.

The environment was then restarted and application functionality was tested again.

The result was positive:

✅ Forms icons/images were displayed correctly.

✅ Previously affected Reports became accessible.

✅ The application functionality was restored.

This demonstrated an important point:

The upgrade itself was not necessarily the problem. The problem was the gap between the old customized environment and the new upgraded environment.

Recommended Post-Upgrade Validation Checklist

After completing a Forms & Reports upgrade, I recommend validating the following areas.

Forms
✓ formsweb.cfg
✓ default.env
✓ Registry.dat
✓ Custom JAR files
✓ Application images/icons
✓ Application resource directories
✓ Forms templates
✓ Environment variables
✓ Application-specific configurations
Reports
✓ rwserver.conf
✓ rwnetwork.conf
✓ REPORTS_PATH
✓ Reports Server configuration
✓ Reports Tools configuration
✓ RDF/REP/XML report locations
✓ Printer configuration
✓ .prt files
✓ Font configuration
✓ Destination configuration
✓ Database connectivity
✓ TNS configuration
Operating System
✓ OS version
✓ Kernel version
✓ Required patches
✓ Shared libraries
✓ System packages
✓ File permissions
✓ Mount points
✓ Environment variables
✓ System services
✓ OS-level compatibility
Application
✓ Forms login
✓ Forms navigation
✓ Icons/images
✓ LOVs
✓ Attachments
✓ Reports invocation
✓ Report output
✓ PDF generation
✓ Printer functionality
✓ Database connectivity
✓ Custom integrations

Old vs New Environment Comparison

One of the best practices we took from this experience is to create an explicit comparison checklist before declaring the upgrade complete.

Area 12.2.1.4 12.2.1.19 Validation
Forms configuration Available Compare Required
formsweb.cfg Customized Compare Required
default.env Customized Compare Required
Registry.dat Customized Compare Required
Custom JARs Available Verify Required
Images/icons Available Verify Required
Reports configuration Available Compare Required
rwserver.conf Customized Compare Required
.prt files Available Verify Required
REPORTS_PATH Configured Verify Required
OS kernel Existing Verify Required
Libraries Existing Verify Required
Customizations Existing Verify Required

This gives the upgrade team a much more reliable way to validate the environment.

Key Lessons Learned
Installation success ≠ application success

WebLogic, Forms and Reports services can all be running while application-level issues still exist.

Customizations are critical

Enterprise Forms & Reports environments often contain years of custom configuration, JARs, images, printer definitions, environment variables and supporting files.

These need to be identified before the upgrade.

Compare, don't guess

The working environment is one of the most valuable troubleshooting references.

A structured old-vs-new comparison can quickly reveal what changed.

Don't overwrite the new configuration blindly

The new Oracle version may contain important default configuration changes.

Custom settings should be reviewed and merged carefully.

OS-level validation matters

Kernel versions, libraries, packages and system configuration can influence middleware behavior.

Post-upgrade testing must be functional

Don't stop at:

WebLogic = RUNNING
Forms = RUNNING
Reports = RUNNING

Also test:

Application → Forms → Icons → Navigation → Reports → Output → Printing
Conclusion

The upgrade from Oracle Forms & Reports 12.2.1.4 to 12.2.1.19 gave us an important practical lesson.

A successful upgrade is not simply about installing the new Oracle version and starting the services.

The real success criteria are:

Configuration + Customizations + Application Resources + Reports + OS Compatibility + Functional Testing

In our case, some required files and configurations were missing after the upgrade. By comparing the old and new environments, identifying the differences, and restoring the required resources, the affected Forms icons and Reports functionality started working again.

For anyone planning a similar upgrade, I strongly recommend creating an old-vs-new configuration and file comparison checklist before and after the upgrade.

That small step can save significant troubleshooting time.

What has been your experience?

Have you encountered any of these issues during an Oracle Forms & Reports upgrade?

Missing Forms icons/images?
Reports not accessible?
Missing .prt files?
Configuration/customization gaps?
OS kernel or library compatibility issues?
Missing JARs or application resources?

I would love to hear your experience and learn what other commonly overlooked files or configurations should be included in a Forms & Reports upgrade checklist.

Connecting Google Gemini AI with Oracle APEX: My Hands-On Experience

Prathap Reddy — Wed, 19 Aug 2026 12:18:16 +0000

Recently, I started exploring the Generative AI capabilities available in Oracle APEX. As part of my learning, I wanted to see how easily I could connect an external AI model to APEX and test it in a real environment.

For this experiment, I chose Google Gemini and configured it through the Generative AI Services available in Oracle APEX.

The setup was quite straightforward, and I wanted to document the steps I followed and a few things I learned along the way.

Why I Tried This

I've been working with Oracle APEX and wanted to understand how AI can be brought into low-code application development.

Instead of building a separate application or writing a custom integration from scratch, APEX provides configuration options for connecting to generative AI services.

That made it a good opportunity for me to try the integration myself and understand what happens behind the scenes.

What I Used

For my setup, I used:

Oracle APEX

Google Gemini

Gemini API key

APEX Generative AI Services

APEX Workspace Administrator access

I also used my own APEX environment to test the configuration.

Configuring Gemini in Oracle APEX

I started by navigating to:

Workspace Utilities → Generative AI Services → Create/Edit

From there, I created a new Generative AI Service and selected Google Gemini as the AI provider.

I gave the configuration a meaningful name so that it would be easy to identify later.

Configuring the API Details

The next step was configuring the Gemini API details.

For the API endpoint, I used:

https://generativelanguage.googleapis.com/v1beta

I then provided the required model information and configured the credentials.

One thing I found useful here was that APEX provides the configuration directly from the UI, so I didn't have to write a separate REST integration just to establish the connection.

Adding the Gemini API Key

The next part was adding the Gemini API key.

I enabled the option to create credentials and entered the API key generated for my Gemini environment.

I also made sure that the API key had the required access for the Generative Language API.

For security reasons, I would recommend never publishing your actual API key in screenshots, blog posts, GitHub repositories, or other public places.

Enabling Gemini for APEX

After configuring the credentials, I looked at the APEX settings.

There are options such as:

Used by App Builder

Default for New Apps

For my testing, I enabled the appropriate option so that the configured AI service could be used by APEX App Builder.

This was one of the interesting parts of the setup because the integration is handled through the APEX configuration rather than requiring me to build the entire connection manually.

Testing the Connection

Before considering the configuration complete, I used the Test Connection option.

I think this is an important step because it immediately tells you whether the basic configuration is working.

If something goes wrong, I would first check:

API key

Model ID

Base URL

Endpoint URL

Credentials configuration

Network/connectivity

Whether the selected model is supported by the configured APEX integration

My Configuration Screen

This is the configuration screen from my APEX environment:

The screenshot shows the Gemini provider, API configuration, model information, credentials, and the App Builder settings.

What I Learned

The biggest takeaway for me was that connecting an AI service to APEX doesn't necessarily require a large amount of custom development.

The configuration is largely handled through the APEX interface, which makes it easier to experiment with generative AI capabilities while continuing to work within a low-code environment.

I also learned that small configuration details matter. The API key, model ID, endpoint, and credential settings all need to match the AI service being used.

Where This Could Be Useful

There are several areas where I think this type of integration could be useful in APEX applications:

Generating application content

Assisting developers during application development

Natural-language interactions

Generating SQL or application-related suggestions

AI-assisted application development

Building smarter business applications

The actual use case will depend on the application and the AI capabilities being enabled.

A Small Lesson From My Experiment

One thing I would recommend to anyone trying this for the first time is don't immediately start troubleshooting the entire application when something doesn't work.

Start with the connection itself.

Check the API key, model, endpoint, credentials, and then use Test Connection.

Once the basic connection works, move on to testing the AI features inside APEX.

That approach makes troubleshooting much easier.

Final Thoughts

This was a useful hands-on experiment for me because it helped me understand how Oracle APEX and Generative AI can work together.

I'm still exploring what can be built with this integration, but I think the combination of low-code development and AI has a lot of potential.

My next step is to move beyond the configuration and build an actual business use case with APEX and Gemini rather than just testing the connection.

Have you tried integrating Gemini, OpenAI, or another LLM with Oracle APEX? I'd be interested to hear about your experience and what you built.

OracleAPEX #GeminiAI #Oracle #GenerativeAI #LowCode #AI #AppDevelopment

Connecting Oracle APEX to Google Gemini AI: A Step-by-Step Guide

Prathap Reddy — Wed, 19 Aug 2026 11:47:00 +0000

Introduction

Oracle APEX has quietly made adding generative AI to low-code apps as simple as filling out a form. No middleware, no custom REST wrappers, no separate AI service to host. In this post, I'll walk through exactly how I connected Google Gemini to my APEX workspace using APEX's native Generative AI Services, and what it unlocks once it's set up.

Why this matters

Most teams assume "adding AI" means weeks of integration work and a dedicated ML engineer. Oracle APEX flips that: plugging in a foundation model is now a configuration task, not an engineering project. Once connected, AI capabilities like Builder AI, natural language search, and AI-assisted page generation work automatically — across every app in your workspace.

Prerequisites
An Oracle APEX workspace ( tested on 26.1)
A Google Gemini API key (Google AI Studio)
Workspace admin access to configure Generative AI Services
Step-by-step setup

Navigate to Generative AI Services
From Workspace Utilities → Generative AI Services → Create/Edit.
Set the AI Provider
Choose Google Gemini from the AI Provider dropdown, and give it a name (e.g. "Gemini API Key").
Configure the Base URL and Endpoint URL
Both point to Gemini's API:

https://generativelanguage.googleapis.com/v1beta

Add credentials
Toggle "Create Credentials" on, and paste in your Gemini API key. APEX stores this securely — you won't need to manage it in code anywhere.
Enable it for App Builder
Toggle Used by App Builder and, optionally, Default for New Apps, so every new app in the workspace automatically uses Gemini.
Test the connection
Click Test Connection to confirm APEX can reach Gemini before saving.

What this unlocks

Once configured, several AI-powered features become available immediately:

Builder AI — generate pages, forms, and reports from natural language descriptions
AI-assisted natural language search in Interactive Reports
AI-generated data models and content during app creation

**Model version compatibility

Not every Gemini model works out of the box with APEX's Generative AI Services. I found that Gemini Flash 3 and onward is what you need — earlier model versions either failed to respond correctly or weren't supported by APEX's integration layer. If you're setting this up and things aren't working, check your Model ID first before troubleshooting anything else.

API key scope
Make sure the API key you generate in Google AI Studio has access to the Generative Language API specifically — a key created for a different Google Cloud service won't authenticate correctly here.

Test Connection is your friend

Don't skip the Test Connection button before saving. It catches URL/endpoint mismatches and auth issues immediately, rather than surfacing as a vague error later inside Builder AI or natural language search.

Takeaway

Low-code and generative AI are converging faster than most people realize. If you're building on Oracle APEX and haven't tried wiring in a foundation model yet, it's a 10-minute setup that changes what your app builder can do.

Have you connected an LLM into APEX or another low-code platform? I'd love to hear what you built.