Saxon

Probably this "net.sf.saxon.Configuration.reuseStyleParser(XMLReader)" is the cause for my problems and it is not something I can control by setting an option.

Also here:

net.sf.saxon.lib.DirectResourceResolver.resolve(ResourceRequest) the style parser is used:

ss = new SAXSource(config.getStyleParser(), is);

although the resolver may be called from a document() or doc-available function.

Also in this place: net.sf.saxon.Configuration.loadParser() Maybe it should ask the XML reader maker to create the XML reader if available.

For now I made two patches on our side, one in the DirectResourceResolver, to avoid using the style parser for xml nature calls :)

ss = new SAXSource(! ResourceRequest.XML_NATURE.equals(request.nature) ? config.getStyleParser() : null, is);

and two patches in the Configuration class to use the XML reader maker on the net.sf.saxon.Configuration.getSourceParser() call and to disable completely the sourceParserPool.

In general I think that maybe once the user sets an xml reader maker maybe the sourceParserPool could be disabled and the xml reader maker could be used instead.

The Javadoc could be much clearer about the exact circumstances in which the parse options set using setParseOptions() are used. Unfortunately it would be a very lengthy description! There are 33 direct references to the field defaultParseOptions, and 54 places that call getParseOptions(), so it's hard to know where to begin.

It does feel very wrong that DirectResourceResolver is invoking the StyleParser, this should only be used for stylesheets and schema documents.

Thanks for the update Michael. I do not know precisely the reason of the sourceParserPool, is it speed? Does creating xml readers instead of reusing them cause that much delay that it's worth adding a parser pool? Could there maybe be an option to control if the parsers are reused or not. In my opinion if the xml reader marker is set, it should be used more often instead of using the parser pool.

Sorry to have abandoned this in mid conversation, I'm just coming back to it now.

In answer to your last question, yes, we did have concrete evidence that the cost of parsing small documents was entirely dominated by parser initialisation cost and that for workloads where many small documents are parsed, pooling the parser has substantial benefits. Its possible this may no longer be true, but I don't think Xerces has changed that much, so I suspect that pooling is still worthwhile.

The code in DirectResourceResolver where it invokes the StyleParser seems all wrong.

Firstly, we haven't checked at this point whether the request uses TEXT_NATURE. (Which it will for an unparsed-text() request with a specified encoding). As far as I can see, if we get an unparsed-text request with an encoding parameter then unless the CatalogResolver can handle it, we're going to get a failure at this point.

Secondly, we should only be using the StyleParser if it's a stylesheet or schema. In other cases we should be using the SourceParser.

Thanks for looking further into improving this behavior Michael.

Sounds good, thank you!