ADF examining memory leaks

Developers while creating the applications often ignore guidelines of closing result sets which is the most common cause of memory leaks. In ADF applications it is the RowSetIterators that need to be closed . This scenario can easily be simulated under load testing using jmeter and turning on memory sampling in JVisualVM.  In this post i will share an example of a one page application in which there is a depiction of master detail relationship b/w a department and its employees. There is a disabled af:inputtext on the fragment that is bound to a backing bean and its getter method has code for iterating the employee table and calculating the total employee salary. Initially i have created a secondary row set iterator and left it open just to examine the memory leaks under load that occur due to this open reference. The code in the backing bean is shown below.

    public Number getSum() {
        DCBindingContainer bc=(DCBindingContainer)BindingContext.getCurrent().getCurrentBindingsEntry();
        EmpVOImpl empVoImpl=(EmpVOImpl)bc.findIteratorBinding("EmpVO1Iterator").getViewObject();
        Number totalAmount=new Number(0);
        RowSetIterator it= empVoImpl.createRowSetIterator(null);
         while(it.hasNext()){
            EmpVORowImpl row=(EmpVORowImpl)it.next();
            if(row.getSal()!=null){
            totalAmount=row.getSal().add(totalAmount);
            }
            }
        it.closeRowSetIterator();
       this.sum=totalAmount;  
        return sum;
    }

So to identify that you have open iterator issue, open the JVisualVM’s sampler tab and turn on memory sampling, when you do so you would see many instances of different types of classes but to identify open iterator issue you need to focus on ViewRowSetIteratorImpl instances and then to your project specific VOImpl classes through which you obtained the iterator in the first place. When ever you create a new RowSetIterator you are returned a ViewRowSetIteratorImpl class instance. As is obvious you would expect the number of instances to increase as you open the RowSetIterator instances and do not close them. Now when i ran the application under simulated load with JMeter with open iterator reference i could see the instances for ViewRowSetIteratorImpl class increase in number very quickly. So then i took a heap dump with JVisualVM and then clicked on the ViewRowSetIteratorImpl class in classes tab to open the instance view tab, then upon selecting an instance and querying for the nearest GC root (in the reference section) i could see that EmpVOImpl was holding a reference to the ViewRowSetIteratorImpl instance. You can also use OQL support in JVisualVM to find out the references which are keeping the object alive.

select  heap.livepaths(u,false) from oracle.jbo.server.ViewRowSetImpl u

After opening the EmpVOImpl instance by clicking on the node, I expanded the mviewrowset (it is a variable which holds ViewRowSetImpl  instance) and then further expanding its mViews property i could see a number of ViewRowSetIteratorImpl instances as shown below.

So to resolve this issue all i had to do was to close the open iterator by calling the closeRowSetIterator method on the RowSetIterator instance.

There are other alternatives also for identifying the problem in your source code by turning on profiling in JVisualVM but profiling on a production system is not recommended way of even approaching the issue.

The comparison b/w the application with open iterators and closed iterators is shown below.

 

In this application JMeter was used to simulate the load with loop controller configured to select different master rows so that upon selection change and partial refresh the getter method for the inputtext in backing bean was called again and again to increase the iterator instances.

The application and jmx file can be downloaded from below links

1. JMeter test plan



2. Application

Read More

ADF exception handling scenario

A user on OTN forum was trying to extend the AdfcExceptionHandler in which he was trying to do redirect to an error page and facing Response Already Committed exception. On examining the scenario i could see that the phase in which the exception handler was being called was RENDER_RESPONSE and by this time it is too late to do a redirect as part of the response has already been submitted (one can check this by using response.iscommitted() method). So redirects/forwards should never be issued from the AdfcExceptionHandler in a conventional way.

The question also arises why someone needs to extend the AdfcExceptionHandler  in the first place, but, we need to do this as default exception handling will not handle exceptions that occur during render response phase for example: let’s say that during the application execution the connectivity to the DB goes down, the exceptions raised then will not be handled by the default exception handling mechanism.

So we cannot use conventional redirects but we have to do redirects somehow, the solution then is to use javascript redirect from the exception handler. The code for the exception handler is shown below.

package com.blogspot.ramannanda.view.handlers;
import java.sql.SQLException;
import java.util.HashMap;
import java.util.Map;
import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseId;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import oracle.adf.view.rich.context.ExceptionHandler;
import oracle.adfinternal.controller.application.AdfcExceptionHandler;
import oracle.jbo.DMLException;
import org.apache.myfaces.trinidad.render.ExtendedRenderKitService;
import org.apache.myfaces.trinidad.util.Service;


public class MyAppUIErrorHandler extends AdfcExceptionHandler {
    public MyAppUIErrorHandler() {
        super();
    }


    @Override
    public void handleException(FacesContext facesContext, Throwable throwable,
                                PhaseId phaseId) throws Throwable {
        ExternalContext ctx =
            FacesContext.getCurrentInstance().getExternalContext();
        HttpServletRequest request = (HttpServletRequest)ctx.getRequest();
        if (phaseId.getOrdinal() == PhaseId.RENDER_RESPONSE.getOrdinal()) {
          //handle null pointer or sqlexception or runtime DMLException that might occur
            if (throwable instanceof DMLException ||
                throwable instanceof SQLException ||
                throwable instanceof NullPointerException) {
                String contextPath = request.getContextPath();
                FacesContext context = FacesContext.getCurrentInstance();
                StringBuffer script = new StringBuffer();
                //set the window.location.href property this causes the redirect.
                script.append("window.location.href= '").append(contextPath).append("/error.html';");
                ExtendedRenderKitService erks =
                    Service.getRenderKitService(context,
                                                ExtendedRenderKitService.class);
                erks.addScript(context, script.toString());
                //encoding script is required as just adding script does not work here
                erks.encodeScripts(context);
                return;
            } else {
                super.handleException(facesContext, throwable, phaseId);
            }

        }


    }
}

So by using this code we are doing redirect to error.html page, I am also checking for phaseId here as the handler will be called for each phase in turn and we can do the handling in render response phase.

Note: Note that i have used encodeScripts method after adding the script and this is required because this method outputs any required scripts by RenderKit which in our case tends to be the script we added. 

 

Read More

ADF Master Detail Table Scenarios

In this post i will share some scenarios that you might face with ADF Master Detail Table component. Typically those mentioned below:-

1. Create a row in child table on creation of row in master table (uses Accessor to programmatically create a row in child )
2. Using Cascade delete option on committed rows

The code sample is based upon scott schema and uses dept and emp tables. The dept table serves as master table and the emp table serves as child table. Also,the association relationship between the entities involved is a composition relationship.

There are a few pre-requisites for this sample to work, basically, you need to create triggers on both the tables and database sequences that will be used to populate  primary key values. The SQL script is present in the sample app.

 

1. Creating row in child table whenever a row is created in master table:-

To accomplish this i have created a method in the application module implementation class that creates a row for department programmatically and then uses the exposed accessor to create the row in child. The snippet is shown below :-

    /**
     * Creates and inserts Dept and Emp Row
     */
    public void createDeptAndEmpRow(){
        DeptVOImpl deptVO=this.getDeptVO1();
        DeptVORowImpl row=(DeptVORowImpl)deptVO.createRow();
        deptVO.insertRow(row);
        RowIterator iterator= row.getEmpVO();
        Number deptNumber=row.getDeptno().getSequenceNumber();
        NameValuePairs nvps=new NameValuePairs();
        nvps.setAttribute("Deptno", deptNumber);
        EmpVORowImpl empRow=(EmpVORowImpl)iterator.createAndInitRow(nvps);
        iterator.insertRow(empRow);
        }

Here i have used the *VOImpl and *VORowImpl class implementations. Also note  the partial triggers on employee table for “create department and employee button” and “Delete department” button which causes the employee table to refresh.

2. Using cascade delete option on committed rows:-

Default database foreign key constraints ensure that you cannot delete rows from a parent while records exist in child table, so if you issue a delete statement on master table i.e Department table you will receive a  foreign key constraint violation exception. The solution is to make the foreign key constraint deferrable which ensures that validation happens when you issue a  commit and not while you issue the delete statement. So to get this to work drop the existing constraint and recreate it as following.

ALTER TABLE emp
ADD CONSTRAINT fk_deptno
FOREIGN KEY (deptno)
REFERENCES dept (deptno)
ON DELETE CASCADE
DEFERRABLE
INITIALLY DEFERRED ;

 

Also note the “ON DELETE CASCADE” clause which will delete the records in child table whenever a row from master table is deleted.

 

The database scripts for triggers and sequences are present in the sample project which can be downloaded from here.

 

Read More