Even I put the osgified the wstx-asl-3.2.9.jar (regardless other issues we had), XMLInputFactory.newInstance() does not pick the  by reading the META-INF/services (spi)
We embedded the wstx-asl-3.2.9.jar into axiom osgified bundle, but it seems it even does not resolve the issue.
How can we make wstx-asl-3.2.9.jar only visible to axiom and let the stax implementation be  witch is available in wstx-asl-3.2.9.jar ?
On a side note: sending the same message to the same mailing list multiple times in a short time interval generally doesn't increase the likelihood of getting a response.AndreasOn Thu Sep 18 2014 at 4:17:39 PM Geeth Munasinghe <firstname.lastname@example.org> wrote:ThanksHiIf anyone knows the answer for this question, please help.GeethOn Wed, Sep 17, 2014 at 9:55 PM, Geeth Munasinghe <email@example.com> wrote:We analyzed the heap dumps and found out that OOM issue was caused by org.apache.axiom.om.util.Hi all,We are using axis2-1.6.1 version, it uses axiom 1.2.11 version, We recently encountered a OOM problem with two services which uses ServiceTCCL parameter. We are using this parameter because both those services use spring and hibernate with them. Scenario is one service is calling the other service. So one service acts as the client.StAXUtils class. There are few weakhashmaps used in that class. Two of them are
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)
I 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.