Last updated on OCTOBER 02, 2017
Applies to:Oracle Containers for J2EE - Version 126.96.36.199.0 to 10.1.3.5.0 [Release AS10g to AS10gR3]
Information in this document applies to any platform.
***Checked for relevance on 18-Dec-2015***
At times, it is seen that when an RMI application is upgraded or the user load on the application increases noticeably, some RMI threads start piling up - mostly on the server side, sometimes on the client side. This thread stackup can lead to performance issues as these threads hang indefinitely holding on to server resources, sometime right until the server is restarted.
The reasons for this behaviour are subjective depending on various factors like RMI InitialContexts not being closed in the code, OC4J underconfigured or misconfigured, lack of resources etc. Investigation of the specific cause of a such scenarios is best done on an individual basis. However, as with most performance problems, investigation can take time or often the solution cannot be implemented rightaway especially if it involves application code changes.
For such scenarios timeout parameters provide the workaround to get around the problem & revert the server back to performing as it should. Also, these parameters can be used proactively beforehand as a tuning excercise to pre-empt potential RMI issues.
This article explains the usage of the RMI timeout parameters in Oracle Containers for J2EE (OC4J). It talks about the server-side timeout parameter as well as that on the client-side
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms