Hi Janna
The client script memory settings are defined in env-client.sh (in the same
directory as fedora-export.sh) - towards the end of this file you'll see a
line
exec_cmd="exec \"$java\" -Xms64m -Xmx96m \
Setting $JAVA_OPTS won't have any effect.
You could try increasing -Xms and -Xmx in this script. Let us know what
values work for you - it sounds like we should either increase these
defaults, or provide some mechanism for controlling memory for client
scripts?
Regards
Steve
-----Original Message-----
From: Janna Wemekamp [mailto:[email protected]]
Sent: 18 May 2010 00:09
To: Fedora Users
Subject: [Fedora-commons-users] OutOfMemoryError in client fedora-export but
not in REST API's export (archive context)
G'day,
When I run the client script fedora-export.sh and specify the PID of an
object containing three managed streams one of which is a 3MB PDF file, the
export fails with an OutOfMemoryError: Java heap space exception.
The error is only reported on the command-line and is NOT present in the
Fedora server log.
bin/fedora-export.sh dev.fedapps.toldark.com.au:80 fedoraAdmin xxx c4oc:4629
'info:fedora/fedora-system:FOXML-1.1' archive /tmp/fc/export/dev-full http
Exporting c4oc:4629 to /tmp/fc/export/dev-full/c4oc_4629.xml
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:10
0)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
at java.lang.StringBuffer.append(StringBuffer.java:224)
at
org.apache.xerces.dom.DeferredDocumentImpl.getNodeValueString(Unknown
Source)
at
org.apache.xerces.dom.DeferredDocumentImpl.getNodeValueString(Unknown
Source)
at org.apache.xerces.dom.DeferredTextImpl.synchronizeData(Unknown
Source)
at org.apache.xerces.dom.CharacterDataImpl.getNodeValue(Unknown
Source)
at
com.sun.org.apache.xml.internal.serialize.BaseMarkupSerializer.serializeNode
(BaseMarkupSerializer.java:1023)
at
com.sun.org.apache.xml.internal.serialize.XMLSerializer.serializeElement(XML
Serializer.java:1068)
at
com.sun.org.apache.xml.internal.serialize.BaseMarkupSerializer.serializeNode
(BaseMarkupSerializer.java:1190)
at
com.sun.org.apache.xml.internal.serialize.XMLSerializer.serializeElement(XML
Serializer.java:1068)
at
com.sun.org.apache.xml.internal.serialize.BaseMarkupSerializer.serializeNode
(BaseMarkupSerializer.java:1190)
at
com.sun.org.apache.xml.internal.serialize.XMLSerializer.serializeElement(XML
Serializer.java:1068)
at
com.sun.org.apache.xml.internal.serialize.BaseMarkupSerializer.serializeNode
(BaseMarkupSerializer.java:1190)
at
com.sun.org.apache.xml.internal.serialize.XMLSerializer.serializeElement(XML
Serializer.java:1068)
at
com.sun.org.apache.xml.internal.serialize.BaseMarkupSerializer.serializeNode
(BaseMarkupSerializer.java:1190)
at
com.sun.org.apache.xml.internal.serialize.BaseMarkupSerializer.serializeNode
(BaseMarkupSerializer.java:1265)
at
com.sun.org.apache.xml.internal.serialize.BaseMarkupSerializer.serialize(Bas
eMarkupSerializer.java:468)
at
fedora.client.utility.export.AutoExporter.export(AutoExporter.java:148)
at fedora.client.utility.export.Export.one(Export.java:84)
at fedora.client.utility.export.Export.main(Export.java:281)
Bumping up the Java heap size in $JAVA_OPTS or using a different Java
version has no effect; the same error occurs.
Environment: RHEL 5.5, Java 1.6.0_20, Fedora Commons 3.3
However, if I use the REST API to export the same object in archive context,
there's no problem. I can also export much larger objects successfully
although I do have to bump up the Java heap space.
Perhaps there's a bug in the client export code?
Janna
--
Janna Wemekamp
Toldark Pty Limited
------------------------------------------------------------------------------
_______________________________________________
Fedora-commons-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
