VirtualMachineError

                                                              VirtualMachineError

VirtualMachineError is the superclass of all error classes that can occur during the operation of the Virtual Machine. A VirtualMachineError indicates that the virtual machine is broken or has run out of resources necessary for it to continue operating.



 java.lang.VirtualMachineError Error Hierarchy

java.lang.Object
   |
   +----java.lang.Throwable
           |
           +----java.lang.Error
                   |
                   +----java.lang.VirtualMachineError

There is no other way to recover from this error except re-installation of JVM. While reinstalling choose maximum possible updated version that provides better stability ,reliability and overall performance.Also set the Java memory allocation parameters judiciously.

Heap size should be set as decided in system architecture Example :  HeapSize="512" maximumHeapSize="1024"

Type java –version DOS commands to know the installed JDK version on machine.

-->

ClassCircularityError

                                                         ClassCircularityError

If a class extends itself or an interface extends itself ClassCircularityError occur can occur

How can a class extends itself ?

Generally this does not happen . But is situation Where multiple version of same class exists in the library this kind of issue can occur

For example

in library Class Circular is available at two locations with different versions

com.org.online.Circular
com.org.offline.Circular

this classes are available in library defined for class Test.

So when Test class will be complied , ClassCircularityError might occur.


When is this error thrown?


java.lang.ClassCircularityError occurs when program overrides ClassLoader.loadClass and
call Class.getSimpleName().

-->


Exception stack trace generally comes like

Exception in thread "main" java.lang.ClassCircularityError: app/Class1$ChildClass
        at java.lang.Class.getDeclaringClass(Native Method)
        at java.lang.Class.getEnclosingClass(Class.java:1085)
        at java.lang.Class.getSimpleBinaryName(Class.java:1220)
        at java.lang.Class.getSimpleName(Class.java:1112)
        at server.ClassLoaderImpl.loadClass(ClassLoaderImpl.java:16)


Whhere does it fall in Error hierarchy?

Class ClassCircularityError   java.lang.Object
        java.lang.Throwable
            java.lang.Error
                java.lang.LinkageError
                    java.lang.ClassCircularityError





-->

Event Dispatcher thread

                                                                 Event Dispatcher thread

Event Dispatcher thread


This is the thread that gets runs in background while executing a Swing program .

This thread is responsible for capturing the event and delegating the control to appropriate Action class

For example :

If you click on a button , Jbutton in Swing,Event Dispatcher thread will be called. This will read the event and related mapping to execute mapped Action method.

-->

PORTLET SCOPE VERSUS APPLICATION SCOPE

                                      PORTLET SCOPE VERSUS APPLICATION SCOPE

-->

When data is kept in portlet session under portlet scope it can not be shared with other portlet in the application 

If portlet data stored in portlet session of a portlet needs to be shared with other portlet It should be stored in portlet session with Application_Scope

Application_Scope allows portlet data in portlet session to be shared among multiple portlets . Data is stored with a key. Using that key on portlet session any application portlet can access application scoped data in any other portlet of the application     

Increasing tomcat server performance by Consolidating log file handlers

                    Increasing tomcat server performance by Consolidating log file handlers

By default, Tomcat uses two handlers for generating log files. But this can be changed by opening up the logging.properties file and looking for the following entry:

.handlers = 1catalina.org.apache.juli.FileHandler,
                   java.util.logging.ConsoleHandler

By simply changing the .handlers entry to use the  FileHandler only, multiple handlers are made to log  into one and reduce the overhead in writing applications logs:

.handler = 1catalina.org.apache.juli.FileHandler

It is just a simple change, but by making this change in the log file handlers, overhead of logging is reduced a lot , and that minimizes the impact of performance monitoring

-->