Oracle WebLogic Server · Rate Limits

Oracle Weblogic Rate Limits

Oracle WebLogic Server is a customer-deployed Java application server; its RESTful Management Services, Monitoring and Diagnostics (WLDF), Deployment, WLST, and JMX APIs do not enforce a centrally-published per-second or per-minute rate-limit table. Throughput is bound by the deployed WebLogic cluster sizing (managed servers, JVM heap, work-manager configuration) and by the hosting OCI compute or on-premises hardware. Customer-deployed WebLogic instances may further apply WebLogic Work Managers, request classes, and Overload Protection settings to throttle inbound traffic.

Oracle Weblogic Rate Limits is the machine-readable rate-limit profile for Oracle WebLogic Server on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring varies and concurrent_operations.

The profile also includes 5 backoff/retry policies defined and response codes documented for unauthorized, forbidden, notFound, serverError, and serviceUnavailable.

Tagged areas include Application Server, Java EE, Middleware, Oracle Cloud, and Rate Limiting.

3 Limits
Application ServerJava EEMiddlewareOracle CloudRate Limiting

Limits

RESTful Management Services Throughput managed_server
varies
bound by managed-server JVM heap and work-manager threads
Throughput is governed by the deployed managed server's JVM heap, thread-pool / work-manager configuration, and Overload Protection settings.
Application Request Throughput cluster
varies
bound by cluster sizing and Work Manager configuration
Application throughput is bound by the WebLogic cluster's combined thread-pool capacity and any Work Manager max-threads-constraint or capacity policy.
JMX / WLST Operations domain
concurrent_operations
bound by Admin Server capacity
JMX MBean operations and WLST scripts are processed by the Admin Server; sustained operations should be paced to avoid saturating the Admin Server.

Policies

Capacity-Bound Throttling
Throughput limits are determined by the deployed WebLogic cluster sizing and by Work Manager / Overload Protection configuration rather than a published per-tenancy rate-limit table.
Backoff Strategy
Clients should implement exponential backoff with jitter on 5xx responses; honor any Retry-After header when present.
Work Manager Configuration
WebLogic administrators should use Work Managers, request classes, and max-threads / min-threads constraints to apply per-application rate control rather than relying on a global throttle.
Overload Protection
Configure WebLogic Overload Protection (Stuck-Thread Max-Time, Failure Action) to gracefully shed traffic during sustained overload events.
API Gateway Pattern
Customers exposing WebLogic-hosted APIs to third parties should front them with an API gateway (Oracle API Platform, Apigee, Kong) and apply rate limits there.

Sources