Project

Profile

Help

Actions
Send by e-mail Copy link

Bug #2914

closed

Concurrency Issue: Internal error evaluating template

Added by Oussama Cherif about 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Michael Kay
Category:
s9api API
Sprint/Milestone:
9.6.0.8
Start date:
2016-08-31
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.6, 9.7, trunk
Fix Committed on Branch:
9.6, 9.7, trunk
Fixed in Maintenance Release:
9.7.0.8, 9.6.0.10
Platforms:

Description

Hello,

I had a strange Saxonica error in my application.

When i launched the XSLT transformation for the first time i got the error below but at the second time everything was OK.

The line 33 of my XSLT is:

<xsl:template match="/MyService/*/OST/dividende">

Could you please advice me?

Kind Regards

java.lang.RuntimeException: Internal error evaluating template at line 33 in module file:/D:/Proj/xslt/transfo.xslt

at net.sf.saxon.expr.instruct.Template.applyLeavingTail(Template.java:353)

at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1155)

at net.sf.saxon.trans.TextOnlyCopyRuleSet.process(TextOnlyCopyRuleSet.java:65)

at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1131)

at net.sf.saxon.trans.TextOnlyCopyRuleSet.process(TextOnlyCopyRuleSet.java:65)

at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1131)

at net.sf.saxon.trans.TextOnlyCopyRuleSet.process(TextOnlyCopyRuleSet.java:65)

at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1131)

at net.sf.saxon.trans.TextOnlyCopyRuleSet.process(TextOnlyCopyRuleSet.java:65)

at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1131)

at net.sf.saxon.Controller.transformDocument(Controller.java:2108)

at net.sf.saxon.Controller.transform(Controller.java:1704)

at net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:547)

Caused by: java.lang.IndexOutOfBoundsException: Index: 2, Size: 6

at java.util.ArrayList.rangeCheck(ArrayList.java:653)

at java.util.ArrayList.get(ArrayList.java:429)

at com.saxonica.ee.optim.IndexedValue.findItems(IndexedValue.java:141)

at com.saxonica.ee.optim.IndexedFilterExpression.iterate(IndexedFilterExpression.java:358)

at net.sf.saxon.value.Closure.iterate(Closure.java:182)

at net.sf.saxon.expr.VariableReference.iterate(VariableReference.java:449)

at net.sf.saxon.expr.instruct.ForEach.iterate(ForEach.java:441)

at net.sf.saxon.value.Closure.iterate(Closure.java:182)

at net.sf.saxon.expr.UserFunctionCall.iterate(UserFunctionCall.java:475)

at net.sf.saxon.expr.VennExpression.iterate(VennExpression.java:589)

at net.sf.saxon.expr.instruct.ApplyTemplates.apply(ApplyTemplates.java:255)

at net.sf.saxon.expr.instruct.ApplyTemplates.processLeavingTail(ApplyTemplates.java:231)

at net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:672)

at net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:689)

at net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:672)

at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:144)

at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:452)

at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:391)

at net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:672)

at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:144)

at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:452)

at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:391)

at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:144)

at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:452)

at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:391)

at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:144)

at net.sf.saxon.expr.instruct.ResultDocument.processInstruction(ResultDocument.java:603)

at net.sf.saxon.Configuration.processResultDocument(Configuration.java:1860)

at com.saxonica.config.EnterpriseConfiguration.processResultDocument(EnterpriseConfiguration.java:1598)

at net.sf.saxon.expr.instruct.ResultDocument.process(ResultDocument.java:519)

at net.sf.saxon.expr.instruct.ResultDocument.processLeavingTail(ResultDocument.java:505)

at net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:672)

at net.sf.saxon.expr.LetExpression.processLeavingTail(LetExpression.java:689)

at net.sf.saxon.expr.instruct.Template.applyLeavingTail(Template.java:340)

... 20 common frames omitted
Actions
Copy link
 #1

Updated by Michael Kay about 8 years ago

Thanks for reporting it. There's a call on ResultDocument on the stack trace, and xsl:result-document in Saxon-EE is multi-threaded, so it looks like a concurrency issue. If you can send us a repro we would much appreciate it. As a workaround:

(a) please try Saxon 9.7 - some issues have been fixed

(b) switch multithreading off (processor.setConfigurationProperty(FeatureKeys.ALLOW_MULTITHREADING, false))

Actions
Copy link
 #2

Updated by Oussama Cherif about 8 years ago

Hello Mr. Michael,

Thanks you for your prompt reply.

I am using the following statement in side of the xs:template bloc :

<xsl:result-document href="$DOCTYPE={$Doctype}" omit-xml-declaration="yes" >

Could this be the root case of the issue?

Actions
Copy link
 #3

Updated by Michael Kay about 8 years ago

Actually (and unusually) I can see from the stack trace what the problem is. It's evaluating an "indexed expression" which is used when optimizing joins, and involves building an index to speed access to data using a predicate, and it looks as if there is data which is only updated in a synchronized block, but is read without synchronization.

Actions
Copy link
 #4

Updated by Oussama Cherif about 8 years ago

Could you please give me some advises and best practices to avoid this issue.

I would also like to have the last stable version of Saxonica 9.7. Is it the 9.7.0.7?

Thanks in advance

Actions
Copy link
 #5

Updated by Oussama Cherif about 8 years ago

Could this parameter configuration (saxon:asynchronous="no") resolve the issue?

<xsl:result-document href="$DOCTYPE={$Doctype}" omit-xml-declaration="yes" saxon:asynchronous="no">

Regards,

Actions
Copy link
 #6

Updated by Michael Kay about 8 years ago

  • Subject changed from Random Issue[Saxon 9.6.0.8]: Internal error evaluating template to Concurrency Issue: Internal error evaluating template
  • Applies to branch 9.6, 9.7 added

(1) Yes, setting saxon:asynchronous="no" on xsl:result-document is probably the best workaround.

(2) The latest maintenance release is 9.7.0.7. We are working on releasing 9.7.0.8 hopefully this week. I wouldn't advise switching major release (9.6.0.x to 9.7.0.x) in a production workload without some QA testing to ensure that everything is working OK.

Actions
Copy link
 #7

Updated by Michael Kay about 8 years ago

Note: the setting href="$DOCTYPE={$Doctype}" seems a very strange way of setting xsl:result-document/@href (the value is supposed to be a URI) but I doubt it is connected to this problem.

Actions
Copy link
 #8

Updated by Michael Kay about 8 years ago

  • Status changed from New to Resolved
  • Priority changed from High to Normal
  • Fix Committed on Branch 9.6, 9.7 added

A fix (to widen the synchronization block in IndexedValue.findItems()) has been applied on the 9.6, 9.7, and 9.8 branches, and regression-tested.

Actions
Copy link
 #9

Updated by Oussama Cherif about 8 years ago

Thanks a lot Mr. Michael for your help.

Best regards,

Actions
Copy link
 #10

Updated by Oussama Cherif about 8 years ago

Hello Mr. Mickael,

Without using the workaround, i had an other strange issue which is random.

The problem is located in the same bloc that i sent you for the previous bug of multi threading but the process didn't rise any Saxonica exception at this time.

<xsl:template match="/MyService/*/OST/dividende">

...

<xsl:result-document href="$DOCTYPE={$Doctype}" omit-xml-declaration="yes" >

...

</xsl:template>

I have 1500 element dividende in my input xml file but some time my xslt transformation created 1499 or 1498 result documents as output

which is wrong. But when i relaunched the transformation i get a correct number of result documents which is 1500.

Could you please advise me since this issue is in production and every day i should relaunch the application in order to generate a correct number of result xml documents. (What is very strange, i have not this issue in my development environment which have the same technical characteristics as the production environment) .

Thanks in advance.

Actions
Copy link
 #11

Updated by Michael Kay about 8 years ago

Since you are using such a strange format for your href URI, I guess you are probably using an OutputURIResolver? Are you sure your OutputURIResolver is thread-safe?

Actions
Copy link
 #12

Updated by Oussama Cherif about 8 years ago

Indeed, i a am using an OutputURIResolver. I think that it is not thread-safe since i didn't find some synchronized blocs or methods.

Should i modifiy my OutputURIResolver?

Actions
Copy link
 #13

Updated by Oussama Cherif about 8 years ago

This is the way that i used to create an OutputURIResolver instance :

@Override

public OutputURIResolver newInstance() {

    return ApplicationContext.getInstance().getApplicationContext()

            .getBean("OutputUriResolverImpl", OutputUriResolverImpl.class);

}

Is it the best way?

Actions
Copy link
 #14

Updated by Oussama Cherif about 8 years ago

I would like to precise that we create a new instance of OutputURIResolver for each new call:

<bean id="OutputUriResolverImpl"

	class="com.resolver.OutputUriResolverImpl"

	scope="prototype">
Actions
Copy link
 #15

Updated by Michael Kay about 8 years ago

I don't think it matters how you create your OutputURIResolver. But if it maintains any internal data, and modifies that data in the resolve/close methods, then the internal data needs to be protected by synchronization (or to use thread-safe classes such as ConcurrentHashMap).

Actions
Copy link
 #16

Updated by Oussama Cherif about 8 years ago

Thank you for your help.

I will check the process using synchronized internal data and i will give you a feedback about the result.

Regards,

Actions
Copy link
 #17

Updated by O'Neil Delpratt about 8 years ago

  • % Done changed from 0 to 100

Bug fix applied in the Saxon 9.7.0.8 maintenance release.

Actions
Copy link
 #18

Updated by O'Neil Delpratt about 8 years ago

  • Fixed in Maintenance Release 9.7.0.8 added
Actions
Copy link
 #19

Updated by O'Neil Delpratt almost 8 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.6.0.10 added

Bug fix applied on the Saxon 9.6.0.10 maintenance release.

Actions
Copy link
 #20

Updated by O'Neil Delpratt over 7 years ago

  • Applies to branch trunk added
  • Applies to branch deleted (9.8)
Actions
Copy link
 #21

Updated by O'Neil Delpratt over 7 years ago

  • Fix Committed on Branch trunk added
  • Fix Committed on Branch deleted (9.8)

Please register to edit this issue

Actions
Send by e-mail Copy link

Also available in: Atom PDF