2012-06-07 6 views
5

Para una aplicación independiente de Java, estamos viendo errores muy raros en los que las cadenas que contengan contenido XML válido están causando JAXB para lanzar excepciones como:SAXParseException XML-20221 Char no válida en el texto

javax.xml.bind.UnmarshalException 
- with linked exception: 
[org.xml.sax.SAXParseException: 
    <Line 1, Column 129>: XML-20221: (Fatal Error) Invalid char in text.] 

Ésta es una de Java muy antigua aplicación, que fue escrito para una versión anterior de Java, y tenemos una dependencia existente:

<dependency> 
    <groupId>com.oracle</groupId> 
    <artifactId>xdb-xmlparser</artifactId> 
    <version>10.2.0.3.0</version> 
</dependency> 

el código de error es consistente XML-20221, aunque la causa puede variar, por ejemplo:

XML-20221: (Fatal Error) Invalid char in text. 

XML-20100: (Fatal Error) Expected '?>'.] 

XML-20121: (Fatal Error) End tag does not match start tag 'TotalDepositReqd'. 

El resto de la traza de la pila también varía, pero por lo general se parece a:

at oracle.xml.parser.v2.XMLError.flushErrorHandler(XMLError.java:415) 
at oracle.xml.parser.v2.XMLError.flushErrors1(XMLError.java:284) 
at oracle.xml.parser.v2.NonValidatingParser.parseEndTag(NonValidatingParser.java:1359) 
at oracle.xml.parser.v2.NonValidatingParser.parseElement(NonValidatingParser.java:1304) 
at oracle.xml.parser.v2.NonValidatingParser.parseRootElement(NonValidatingParser.java:326) 
at oracle.xml.parser.v2.NonValidatingParser.parseDocument(NonValidatingParser.java:293) 
at oracle.xml.parser.v2.XMLParser.parse(XMLParser.java:209) 
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:211) 
versión

Nuestra Java es:

java version "1.6.0_16" 
Java(TM) SE Runtime Environment (build 1.6.0_16-b01) 
Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode) 

Nuestra línea de comandos actual es:

java 
-server 
-Xmx2048m 
-Xms2048m 
-XX:MaxPermSize=128m 
-XX:+UseConcMarkSweepGC 
-Dsun.rmi.dgc.server.gcInterval=0x2932E00 
-Dsun.rmi.dgc.client.gcInterval=3600000 
-verbosegc 
-Xloggc:/path/to/file 
-gc.log 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl 
-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl 
-Djava.endorsed.dirs=/path/to/endorsed 
-Duser.country=GB 
-Duser.language=en 
-Dhttp.keepAlive=false foo.ListenerServer 

Por lo general, vemos esto en pequeñas ráfagas que abarcan un par de segundos, lo que me sugiere que se ha dañado un poco el buffer interno? Estas excepciones se vuelven más comunes cuanto más tiempo demora la JVM. Un rebote de la JVM resuelve el problema durante varios días.

  • ¿Alguien ha visto algo similar?
  • Si es así, ¿logró resolver esto?
  • ¿Quizás deberíamos pasar a una implementación JAXB/JAXP diferente?
+3

Todavía me interesaría el contenido XML. También podría ser que durante un tiempo se esté ejecutando en propiedad del sistema file.encoding, que es la codificación predeterminada. Busque "file.encoding" en el resto del código o haga que la codificación sea explícita. –

+0

Primero miraría el XML como sugirió Joop. Quizás estos https://blogs.oracle.com/alanb/entry/heap_dumps_are_back_with pueden ayudar? – Bringer128

Respuesta

4

He visto problemas similares (excepciones esporádicas durante el desemparejamiento) cuando un desarrollador guardó en caché la instancia Unmarshaller y la compartió entre diferentes subprocesos. De acuerdo con la documentación, el Unmarshaller no es seguro para subprocesos.