1. Up-gradation to class loader architecture to avoid deadlocks in non-hierarchical class-loader topologies.
2. A method has been added to free the underlying resources, such as open files, held by a URLClassLoader.
3. A lightweight fork/join framework, flexible and reusable synchronization barriers, transfer queues, a concurrent-reference HashMap, and thread-local pseudo-random number generators.
4. Upgraded to supported version of Unicode 6.0 for more from internationalization.
5. the java.util.Locale class to support IETF BCP 47 and UTR 35 now.
6. Now there will be a two separate locale for user and user-interface.
7. New APIs for filesystem access, scalable asynchronous I/O operations, socket-channel binding and configuration, and multicast datagrams
8. New fully functional file system provider NIO.2 for zip/jar archiving.
9. JDBC upgraded to 4.1 and Rowset to 1.1
10. XML stack is upgraded to new stable version for more on web.
11. JSR 292 providing support for dynamically typed language.
Friday, November 19, 2010
Thursday, November 18, 2010
OutOfMemoryError: PermGen space while reloading webapp in tomcat
This annoying error of PermGen space OOMs when reloading the webapp in tomact is because in tomcat the class loader only loads the classes and this class loader and loaded classes are never garbage collected. Each time you reload your webapp, copies of classes will be added to memory, basically the permanent heap space used by tomcat. This eventually makes tomcat run out of memory to further carry out operation.
This is common and can happen with other containers also until unless in some version the owner have made changes to take care of this. Try reloading the application again and again until unless your container cry of Out of Memory Error. What we can do in such a situation is to restart the container which basically clean up the heap and load the application again.
Additionally try no putting your JDBC and commons jar in the WEB-INF. Instead you can put them in the TOMCAT-HOME/common/lib folder because these are already bootstrapped by tomcat. If you face issue of 'No suitable driver' Exception after placing your jdbc jar in tomcat common/lib, try adding you jndi db definition in context.xml like
<\Context path="/test" reloadable="true" debug="1">
<\Resource name="jdbc/db" auth="Container" type="javax.sql.DataSource" maxActive="30" maxIdle="3"
maxWait="10000" username="testing" password="testing" driverClassName="net.sourceforge.jtds.jdbc.Driver" url="jdbc:testdburl;lastupdatecount=true" />
This is common and can happen with other containers also until unless in some version the owner have made changes to take care of this. Try reloading the application again and again until unless your container cry of Out of Memory Error. What we can do in such a situation is to restart the container which basically clean up the heap and load the application again.
Additionally try no putting your JDBC and commons jar in the WEB-INF. Instead you can put them in the TOMCAT-HOME/common/lib folder because these are already bootstrapped by tomcat. If you face issue of 'No suitable driver' Exception after placing your jdbc jar in tomcat common/lib, try adding you jndi db definition in context.xml like
<\Context path="/test" reloadable="true" debug="1">
<\Resource name="jdbc/db" auth="Container" type="javax.sql.DataSource" maxActive="30" maxIdle="3"
maxWait="10000" username="testing" password="testing" driverClassName="net.sourceforge.jtds.jdbc.Driver" url="jdbc:testdburl;lastupdatecount=true" />
Subscribe to:
Comments (Atom)