Name: skT45625 Date: 05/11/2000


java version "1.1.8"

We are running a CORBA server which parses some xml files, generates a XML
Document object out of them and serializes it to a byte[], one at a
time.(Operations are single threaded)
The XML files are a bit deeply nested and contain around 1000 lines. These files
are configuration files for other servers. So, when a new Server is added thru
the GUI (which is Swing/JSP and browser based), the server copies a template
file( Which is about 50 lines of XML) to a new file, parses the new file , gets
the XML document object out of it, and tries to serialize it to a byte[]. This
is where StackOverflow exception is thrown and it is thrown from writeObject()
method. If the server is restarted, it successfully parses all the existing
file (any number) and all corresponding documents as successfully serialized.
But again if a new request to add server comes, StackOverFlow is encountered. We
are using IBM XML Parser(org.w3c.dom.*). We can't move to JDK1.2 because of
compatibility reasons with VisiBroker(The ORB which we are using). We tried all
alternatives, code reviews at our best level but the problem remains. As this
has hampered the whole product release any quick help will be appreciated. I am
attaching the relevant code :

*******************************************************************************
CODE that produces the above mentioned bug
*******************************************************************************

  public byte[] getComponentConfiguration(String type, String instanceId) throws
DocNotFoundException, DocFormatException
    {
        String objectId=type+"."+instanceId;
        String filePath=null;
        byte[] serializedDoc=null;
 
        trace("In getComponentConfiguration");
        try
        {
            return getFromCache(objectId);
        }
        catch(DocNotFoundException e)
        {
            trace("Doc Not found exception thrown for "+objectId);
            // The doc was not in cache. Could have been added later by the
admin.
        }
        // what if it was added later ?? Need to get file path from CIC and try
once
 
        try
        {
            trace("Attempting another try to get the doc for "+objectId);
           
filePath=cicReference.getServerProperty(type,instanceId,XML_FILE_PATH);
            trace("Got the filepath : "+filePath);
        }
        catch(InvalidTypeException e)
        {
            throw new DocNotFoundException("The server "+objectId+" doesnt
exist.");
        } catch(InvalidInstanceException e)
        {
            throw new DocNotFoundException("The server "+objectId+" doesnt
exist.");
        }
//************Relevant CODE Starts here******************
        try
        {
            trace("^^^^^^^^^^^^^^^^^^^^^^^ File Path :"+filePath);
        //Parse the file and get org.w3c.dom.Document object..
Document docu = XMLConfigUtils.getDocument(filePath);
            System.out.println(XMLConfigUtils.getGlobalConfigHashtable(docu));
//**************************************************************************
//Stackoverflow occurs in This method. Code for this method is given
below

serializedDoc=XMLConfigUtils.getSerializedDocument(filePath);
            trace("Serialized the doc");
            cacheSerializedDoc(objectId,serializedDoc,false,filePath);
            trace("cached the doc");
            return serializedDoc;
        }
        catch( XMLFileNotFoundException e)
        {
            throw new DocNotFoundException("The Config file for this server was
not found");
        }
        catch(XMLFormatException e)
        {
            throw new DocFormatException("XML format of the config doc is
erroneous");
        }
        catch(UnableToSyncByteArrayException e)
        {
            throw new DocNotFoundException(e.message);
        }
                                                                                                

}
 //***************************************************************************
// Code for XMLConfigUtils.getSerializedDocument(filePath).....

  public static byte [] getSerializedDocument(String filename) throws
XMLFileNotFoundException, XMLFormatException
    {
        if(filename == null || filename.equals(""))
        {
            System.out.println("file name passed is null");
            throw new XMLFileNotFoundException("file name passed is null");
        }
        Document doc= getDocument(filename);
        System.out.println("Got the doc "+doc);
//***Failure occurs at this step. The same code works without problem
//when server is restarting. (While restarting, server parses all
//available XML files including this new one and byte[]'s of all //of
them are successfully prepared. Failure occurs with same code if //new
server is added at runtime.

        byte [] ret = serializeDocument(doc);
        System.out.println("Byte arra = "+ret);
        if(ret == null)
            throw new XMLFormatException(" failed");
 
        return ret;
   
}
//*****Code for serializeDocument(doc)........
public static byte [] serializeDocument(Document xmlDoc)
    {
        try{
        ByteArrayOutputStream bArray = new ByteArrayOutputStream();
        ObjectOutputStream oStream = new ObjectOutputStream(bArray);
        oStream.writeObject(xmlDoc);
        oStream.close();
        System.out.println("Before close in serializedDocument");
        return bArray.toByteArray();
        }catch(Throwable e)
        {
            e.printStackTrace();
            return null;
        }
   
}

=============
Additional Info:
We finally tried running our Server on JDK1.2.2_05 Production Release for a
properly patched Solaris 2.6 (512 M RAM, 1.6Gig Swap Space, New m/c). The bug
is still around. But we found one thing interesting. When we ran the same code
on a down to earth linux box (56M ram ,72M swap running kernel 2.2.14 and JDK
1.2.2 Production release for linux), it ran happily without a stack overflow.
Response time for serialization/deserialization was also quite low. So I have
confirmed from our side that this indeed is a serious bug with Solaris jvms from
1.1.x to 1.2.2_05. As this has become a stumbling block in our delivery
schedule, any quick help or workaround will be highly appreciated.

Regards & Thanks in Advance .
Parag


(Review ID: 104388)
======================================================================