[
https://issues.apache.org/jira/browse/TIKA-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225668#comment-17225668
]
Hudson commented on TIKA-3009:
------------------------------
UNSTABLE: Integrated in Jenkins build Tika ยป tika-branch1x-jdk8 #25 (See
[https://ci-builds.apache.org/job/Tika/job/tika-branch1x-jdk8/25/])
TIKA-3009 -- workaround for weblogic's xml parser (tallison:
[https://github.com/apache/tika/commit/1b81d200e8ffb882276264618c9004ba4bf72ecb])
* (edit) tika-core/src/main/java/org/apache/tika/utils/XMLReaderUtils.java
> XML Parser reset() detection no working in weblogic 12.2.1.3
> ------------------------------------------------------------
>
> Key: TIKA-3009
> URL: https://issues.apache.org/jira/browse/TIKA-3009
> Project: Tika
> Issue Type: Bug
> Components: core
> Affects Versions: 1.20, 1.21, 1.22, 1.23
> Environment: JDK 1.8.0_231
> Oracle Weblogic Server 12.2.1.3
> Reporter: Daniel
> Assignee: Tim Allison
> Priority: Critical
> Fix For: 1.25
>
>
> Starting with tika 1.20 the org.apache.tika.utils.XMLReaderUtils try to
> detect if a XML parser supports the reset() functionality by calling reset()
> during the poolParser creation and watching for a
> UnsupportedOperationException.
> This unfortunately does not work in weblogic server as the attained
> RegistryParser itself caches underlying SAX parsers. Only after first use the
> reset() of the underlying SAXParser is called and will produce the
> UnsupportedOperationException. A first call to reset() will not produce this
> exception and XMLReaderUtils thinks, the parser supports reset() which in
> effect is not true.
> This results in exhaustion of the parser pool and intermittent errors and
> delays in processing as the pool is reset when a parser is not available
> after 5 minutes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
