Clients: Pixel Art Company
Start Day: 13/01/2024
Tags: Marketing, Business
Project Duration: 9 Month
Client Website: Pixelartteams.com
Download a detailed report on this case
Call us directly, submit a sample or email us!
While serving as BASIS Lead for a large-scale SAP Solution Manager 7.2 environment — a dual-stack system running both ABAP and Java — we faced a critical incident during peak business hours. End users began reporting intermittent timeouts and transaction failures across both the ABAP and Java stacks simultaneously. Monitoring dashboards showed the Java AS ICM (Internet Communication Manager) threads were exhausted, while the ABAP work processes were queuing up with long wait times. The incident coincided with a quarterly Business Intelligence reporting cycle that was driving heavy background load through both stacks.
My first step was to isolate whether the issue was stack-specific or systemic. I used SM50/SM66 on the ABAP side to examine work process utilization and identified a spike in “CPIC” type work processes — a clear indicator of ABAP-to-Java communication bottlenecks. On the Java side, I accessed the NWA (NetWeaver Administrator) and reviewed the thread dump using the Monitoring > System > Performance nodes, revealing Java dispatcher threads were stuck waiting on JDBC connections to the shared HANA database.
Using HANA Studio and the M_CONNECTIONS system view, I identified that the HANA database had hit its configured maximum connections limit. The culprit was a misconfigured connection pool in the Java AS — specifically, the maxConnections parameter in the datasource pool (accessible via NWA > Configuration > Infrastructure > JDBC) had not been adjusted after a recent landscape scaling exercise. The pool was sized for a smaller system footprint and was no longer adequate for the expanded load profile.
Root Cause: Undersized JDBC connection pool on the Java AS causing cascading exhaustion into shared HANA database connections, which in turn stalled ABAP-Java RFC/CPIC channels, bringing both stacks to near-halt under concurrent peak load.
I immediately engaged three teams: the NetWeaver Java team (for datasource reconfiguration), the HANA DBA team (to extend the max_connections parameter at the database layer), and the application team (to temporarily throttle the BI background jobs via SM37 to reduce load during the fix window).
The resolution was executed in coordinated phases:
Within 45 minutes of implementing Phase 3, ICM thread utilization normalized and ABAP work process queuing disappeared. System response times returned to baseline SLA levels and the BI reporting cycle completed without further incident. The total business impact was approximately 2.5 hours of degraded performance affecting ~300 concurrent users.
Post-incident, I documented the event via an RCA report and drove three systemic improvements: (1) a connection pool sizing standard tied to system landscape sizing documentation, (2) proactive monitoring alerts in Solution Manager for JDBC pool saturation thresholds, and (3) a pre-release checklist for landscape scaling events that included both ABAP and Java stack parameter reviews. These changes reduced similar incidents to zero over the following 18 months and were adopted as a standard in our PCE delivery methodology.
Duis consequat libero ac tincidunt consectetur. Curabitur a magna sit amet orci mollis vehicula. Morbi at enim a ex mollis sodales ut eu elit. Quisque egestas.
