Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

EJB jar file Times Out - Poor System Performance in weblogic

 
Nishant Chandani
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Logs :-
<log4j:throwable><![CDATA[java.rmi.RemoteException: EJB Exception: ; nested exception is:
java.lang.RuntimeException: An invocation of EJB <anonymous>.jar) timed out while waiting to get an instance from the free pool.

There were a whole lot of threads (70) in the Weblogic console related to EJB.jar - I could not see them getting processed.

From BEA doc
form BEA edoc:

A high pool timeout ratio could be indicative of an improperly sized free pool. Increasing the maximum size of your free pool via the max-beans-in-free-pool setting will increase the number of bean instances available to service requests and may reduce your pool timeout ratio.
Another factor affecting the number of pool timeouts is the configured transaction timeout for your bean. The maximum amount of time a thread will wait for a bean from the pool is equal to the default transaction timeout for the bean. Increasing the trans-timeout-seconds setting in your weblogic-ejb-jar.xml file will give threads more time to wait for a bean instance to become available.

But its not the initial stage(application start up) where the Bean gets time out, its in the middle of the apllication where the users are accessing it.


Plese give me ideas how it happens and why ??
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How many JDBC Connections have you configured? If the number is, say, 10, then set your max-beans-in-free-pool to 10 as well.

Another thing to do is to ensure that each Connection is closed after use in order to release it back to the pool. It is a common error to not do this, thus causing pool exhaustion.
 
Nishant Chandani
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Roger Chung-Wee:
How many JDBC Connections have you configured? If the number is, say, 10, then set your max-beans-in-free-pool to 10 as well.

Another thing to do is to ensure that each Connection is closed after use in order to release it back to the pool. It is a common error to not do this, thus causing pool exhaustion.
 
Nishant Chandani
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nishant Chandani:
We didnt configured <max-beans-free-pool>, by default weblogic 9.2 will take 1000 for this tag.
If they're exceeding 1000 instances then there's something else severely wrong going on and increasing the max-beans-in-free-pool isn't going to fix this.

There were a whole lot of threads (70) in the Weblogic console related to EJB.jar file- I could not see them getting processed.

we are monitoring weblogic console to see if the number of bean instances for that ejb
Is there anything that to see in java source code to how it could possibly ever leak an ejb such that it never gets released??
[QB][/QB]
 
Marcos Maia
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My first suggestion is taking a Thread dump e analyze what threads are doing at that moment. Also would check for pool sizes, etc.. you need to provide more information if you still need help on this.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there anything that to see in java source code to how it could possibly ever leak an ejb such that it never gets released??

You need to read what I said about failure to close Connections.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic