3.1.1 Detail Message: Java heap space
The detail message Java heap space indicates that an object could not be allocated in the Java heap. This error does not necessarily imply a memory leak. The problem can be as simple as a configuration issue, where the specified heap size (or the default size, if not specified) is insufficient for the application.
In other cases, and in particular for a long-lived application, the message might be an indication that the application is unintentionally holding references to objects, and this prevents the objects from being garbage collected. This is the Java language equivalent of a memory leak. Note that APIs that are called by an application could also be unintentionally holding object references.
3.1.2 Detail Message: PermGen space
The detail message PermGen space indicates that the permanent generation is full. The permanent generation is the area of the heap where class and method objects are stored. If an application loads a very large number of classes, then the size of the permanent generation might need to be increased using the -XX:MaxPermSize option.
Interned java.lang.String objects are no longer stored in the permanent generation. The java.lang.String class maintains a pool of strings. When the intern method is invoked, the method checks the pool to see if an equal string is already in the pool. If there is, then the intern method returns it; otherwise it adds the string to the pool. In more precise terms, the java.lang.String.intern method is used to obtain the canonical representation of the string; the result is a reference to the same class instance that would be returned if that string appeared as a literal.
When this kind of error occurs, the text ClassLoader.defineClass might appear near the top of the stack trace that is printed.
for my case, the reason being, the aspect is not waved at compile time.
it works well in Eclipse/IDE, as there is plugsin, aspectJRuntime plugin. however, when i build the war; my ant didnt call aspectjtools to weave compile the aspect.
[20-05-2014 21:47:00.957]  [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/clientinquiryweb]] [ERROR] [MSC service thread 1-10]
Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.fa
ctory.BeanCreationException: Error creating bean with name 'pageDeco' defined in ServletContext resource [/WEB-INF/spring/applicationContext.xml]: No matchin
g factory method found: factory method 'aspectOf()'. Check that a method with the specified name exists and that it is static.
Before being introduced to lock granularity, one needs to understand three concepts about locks.
lock overhead: The extra resources for using locks, like the memory space allocated for locks, the CPU time to initialize and destroy locks, and the time for acquiring or releasing locks. The more locks a program uses, the more overhead associated with the usage.
lock contention: This occurs whenever one process or thread attempts to acquire a lock held by another process or thread. The more fine-grained the available locks, the less likely one process/thread will request a lock held by the other. (For example, locking a row rather than the entire table, or locking a cell rather than the entire row.)
deadlock: The situation when each of two tasks is waiting for a lock that the other task holds. Unless something is done, the two tasks will wait forever.
There is a tradeoff between decreasing lock overhead and decreasing lock contention when choosing the number of locks in synchronization.
An important property of a lock is its granularity. The granularity is a measure of the amount of data the lock is protecting. In general, choosing a coarse granularity (a small number of locks, each protecting a large segment of data) results in less lock overhead when a single process is accessing the protected data, but worse performance when multiple processes are running concurrently. This is because of increased lock contention. The more coarse the lock, the higher the likelihood that the lock will stop an unrelated process from proceeding. Conversely, using a fine granularity (a larger number of locks, each protecting a fairly small amount of data) increases the overhead of the locks themselves but reduces lock contention. Granular locking where each process must hold multiple locks from a common set of locks can create subtle lock dependencies. This subtlety can increase the chance that a programmer will unknowingly introduce a deadlock.
the @Configurable annotation is the cure, basically, its till aspect/aspectJ to detect if any instantiation of beans marked as Configurable; and put into spring container if yes.
and it’s only put into spring container after the bean is manually instantiated. So autowired stuff won’t work in this manually instantiated bean still.
And in order to have spring beans loaded/injected into aspects
btw, I dont like spring docs now. it becomes so bulky !
8.8.1 Using AspectJ to dependency inject domain objects with Spring
8.8.3 Configuring AspectJ aspects using Spring IoC
Just configure the VM arguments to overwrite the log4j file path
it’s taken as Object by JDK.
to create new instance of the object using Reflection;
To keep the line number of the class:
<appender name="ASYNC" class="org.apache.log4j.AsyncAppender">
<param name="BufferSize" value="256"/>
<param name="LocationInfo" value="true"/>
The addAppender method adds an appender to a given logger. Each enabled logging request for a given logger will be forwarded to all the appenders in that logger as well as the appenders higher in the hierarchy. In other words, appenders are inherited additively from the logger hierarchy. For example, if a console appender is added to the root logger, then all enabled logging requests will at least print on the console. If in addition a file appender is added to a logger, say C, then enabled logging requests for C and C's children will print on a file and on the console. It is possible to override this default behavior so that appender accumulation is no longer additive by setting the additivity flag to false.
The rules governing appender additivity are summarized below.
The output of a log statement of logger C will go to all the appenders in C and its ancestors. This is the meaning of the term "appender additivity".
However, if an ancestor of logger C, say P, has the additivity flag set to false, then C's output will be directed to all the appenders in C and its ancestors upto and including P but not the appenders in any of the ancestors of P.
Loggers have their additivity flag set to true by default.
I might be late to realize this: