And those two weak hashmaps has other weak hashmaps inside of them. Those inner hashmaps cause the issue.
We found out that when we use ServiceTCCL parameter in the service.xml, in AbstractMessageReceiver.java  of axis2 (line number 152 - 170) creates a new class loader object of the MultiParentClassLoader  for every request. So in StAXUtils class  in axiom, methods  and  uses inner weak hashmaps of inputFactoryPerCLMap, outputFactoryPerCLMap and fill them with the class loader as the key and XMLInputFactory / XMLOutputFactory as the value.
Because every request gets a new class loader object of the MultiParentClassLoader, their hash values are different. So they are keep getting filled into those inner weak hash maps. Because the same key (classloder instance) gets inserted into both weak hashmaps, garbage collector does not remove them. So server goes OOM, When we analyze the heap dumps we found out that java.util.WeakHashMap fills over 80% of the memory when it goes OOM.
I have made fix in StAXUtils in axiom as follows.
Instead map.get(cl) I change it to map.get(cl.getClass().getName())
Instead map.put(cl, factory) I changed it to map.put(cl.getClass().getName(), factory)
have attached the fix (svn diff) here with email. I am not sure I have
done the correct fix for the issue. But I found that it solves my
problem. Can some one please verify weather I have done the correct fix.
Please consider that upgrading to new axis2 is not a solution for us at the moment.
 getXMLInputFactory_perClassLoader(StAXParserConfiguration configuration)
 getXMLOutputFactory_perClassLoader(StAXWriterConfiguration configuration)
Thanks in advance.