2012-06-07 2 views
5

для отдельного приложения Java, мы видим очень редкие ошибки, где строки, содержащие действительное содержание XML являются причиной JAXB кидать исключения, как:SAXParseException XML-20221 Недопустимый символ в тексте

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

Это очень старый Java приложение, которое было написано для более старой версии Java, и у нас есть существующая зависимость:

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

код ошибка последовательно XML-20221, хотя причина может меняться, например:

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'. 

Остальная часть трассировки стека также варьируется, но обычно выглядит следующим образом:

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) 

Наша Java версия:

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) 

Наша текущая командная строка:

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 

Обычно мы видим их в небольшие всплески, которые охватывают пару секунд, что подсказывает мне, что поврежден какой-то внутренний буфер? Эти исключения становятся более распространенными, чем дольше JVM. Отскок JVM разрешает проблему в течение нескольких дней.

  • Кто-нибудь еще видел что-то подобное?
  • Если это так, вам удалось это решить?
  • Возможно, нам стоит перейти к другой реализации JAXB/JAXP?
+3

Меня все еще интересовал XML-контент. Также может случиться, что какое-то время вы работаете с другим системным свойством file.encoding, которое является кодировкой по умолчанию. Найдите «file.encoding» в остальной части кода или сделайте кодировку явной. –

+0

Я бы сначала рассмотрел XML, как предложил Joop. Возможно, эти https://blogs.oracle.com/alanb/entry/heap_dumps_are_back_with могут помочь? – Bringer128

ответ

4

Я видел подобные проблемы (спорадические исключения во время unmarshalling), когда разработчик кэшировал Unmarshaller экземпляр и делил его между различными потоками. Согласно документации, Unmarshaller не является надежным потоком.

Смежные вопросы