You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Simon Raess (JIRA)" <ji...@apache.org> on 2007/01/31 14:18:05 UTC
[jira] Created: (JXPATH-76) CompiledExpression not completely
thread-safe
CompiledExpression not completely thread-safe
---------------------------------------------
Key: JXPATH-76
URL: https://issues.apache.org/jira/browse/JXPATH-76
Project: Commons JXPath
Issue Type: Bug
Reporter: Simon Raess
Some classes in compiled expressions are not thread-safe, because they lazily initialize some information that should be initialized at object construction. The classes I've found are Path and ExpressionPath. I've attached a path that fixes the problem.
When two threads tried to initialize such an object concurrently, it was possible that the expression was evaluated as simple expression when it should have been evaluated as complex expression. See the two stack traces below (using xpath expression //ExternalData/Order/@id). The first stack trace shows the bug in action, the second how it should look:
caused by java.lang.UnsupportedOperationException: Not supported node test for attributes: node()
at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.getNodeIterator(SimplePathInterpreter.java(Compiled Code))
at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.doStepNoPredicatesStandard(SimplePathInterpreter.java(Compiled Code))
at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.doStep(SimplePathInterpreter.java(Compiled Code))
at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.interpretSimpleLocationPath(SimplePathInterpreter.java(Inlined Compiled Code))
at org.apache.commons.jxpath.ri.compiler.Path.getSingleNodePointerForSteps(Path.java(Inlined Compiled Code))
at org.apache.commons.jxpath.ri.compiler.LocationPath.computeValue(LocationPath.java(Compiled Code))
at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getPointer(JXPathContextReferenceImpl.java(Compiled Code))
at org.apache.commons.jxpath.ri.JXPathCompiledExpression.selectSingleNode(JXPathCompiledExpression.java(Inlined Compiled Code))
This replaces the lines starting at Path.getSingleNodePointerForSteps:
LocationPath(Path).searchForPath(EvalContext) line: 183
LocationPath(Path).getSingleNodePointerForSteps(EvalContext) line: 159
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Updated: (JXPATH-76) CompiledExpression not completely
thread-safe
Posted by "Simon Raess (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JXPATH-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Raess updated JXPATH-76:
------------------------------
Attachment: jxpath.patch
patch fixing (some?) multithreading bugs in compiled expressions
> CompiledExpression not completely thread-safe
> ---------------------------------------------
>
> Key: JXPATH-76
> URL: https://issues.apache.org/jira/browse/JXPATH-76
> Project: Commons JXPath
> Issue Type: Bug
> Reporter: Simon Raess
> Attachments: jxpath.patch
>
>
> Some classes in compiled expressions are not thread-safe, because they lazily initialize some information that should be initialized at object construction. The classes I've found are Path and ExpressionPath. I've attached a path that fixes the problem.
> When two threads tried to initialize such an object concurrently, it was possible that the expression was evaluated as simple expression when it should have been evaluated as complex expression. See the two stack traces below (using xpath expression //ExternalData/Order/@id). The first stack trace shows the bug in action, the second how it should look:
> caused by java.lang.UnsupportedOperationException: Not supported node test for attributes: node()
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.getNodeIterator(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.doStepNoPredicatesStandard(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.doStep(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.interpretSimpleLocationPath(SimplePathInterpreter.java(Inlined Compiled Code))
> at org.apache.commons.jxpath.ri.compiler.Path.getSingleNodePointerForSteps(Path.java(Inlined Compiled Code))
> at org.apache.commons.jxpath.ri.compiler.LocationPath.computeValue(LocationPath.java(Compiled Code))
> at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getPointer(JXPathContextReferenceImpl.java(Compiled Code))
> at org.apache.commons.jxpath.ri.JXPathCompiledExpression.selectSingleNode(JXPathCompiledExpression.java(Inlined Compiled Code))
> This replaces the lines starting at Path.getSingleNodePointerForSteps:
> LocationPath(Path).searchForPath(EvalContext) line: 183
> LocationPath(Path).getSingleNodePointerForSteps(EvalContext) line: 159
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Resolved: (JXPATH-76) CompiledExpression not completely
thread-safe
Posted by "Matt Benson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JXPATH-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Benson resolved JXPATH-76.
-------------------------------
Resolution: Fixed
Fix Version/s: 1.3
It takes less analysis on my part (as a self-appointed, but non-expert, custodian of JXPath) to simply synchronize these methods, which I have done in SVN HEAD. Thanks for the report!
> CompiledExpression not completely thread-safe
> ---------------------------------------------
>
> Key: JXPATH-76
> URL: https://issues.apache.org/jira/browse/JXPATH-76
> Project: Commons JXPath
> Issue Type: Bug
> Affects Versions: 1.2 Final
> Reporter: Simon Raess
> Fix For: 1.3
>
> Attachments: jxpath.patch
>
>
> Some classes in compiled expressions are not thread-safe, because they lazily initialize some information that should be initialized at object construction. The classes I've found are Path and ExpressionPath. I've attached a path that fixes the problem.
> When two threads tried to initialize such an object concurrently, it was possible that the expression was evaluated as simple expression when it should have been evaluated as complex expression. See the two stack traces below (using xpath expression //ExternalData/Order/@id). The first stack trace shows the bug in action, the second how it should look:
> caused by java.lang.UnsupportedOperationException: Not supported node test for attributes: node()
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.getNodeIterator(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.doStepNoPredicatesStandard(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.doStep(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.interpretSimpleLocationPath(SimplePathInterpreter.java(Inlined Compiled Code))
> at org.apache.commons.jxpath.ri.compiler.Path.getSingleNodePointerForSteps(Path.java(Inlined Compiled Code))
> at org.apache.commons.jxpath.ri.compiler.LocationPath.computeValue(LocationPath.java(Compiled Code))
> at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getPointer(JXPathContextReferenceImpl.java(Compiled Code))
> at org.apache.commons.jxpath.ri.JXPathCompiledExpression.selectSingleNode(JXPathCompiledExpression.java(Inlined Compiled Code))
> This replaces the lines starting at Path.getSingleNodePointerForSteps:
> LocationPath(Path).searchForPath(EvalContext) line: 183
> LocationPath(Path).getSingleNodePointerForSteps(EvalContext) line: 159
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Updated: (JXPATH-76) CompiledExpression not completely
thread-safe
Posted by "Simon Raess (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JXPATH-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Raess updated JXPATH-76:
------------------------------
Affects Version/s: 1.2 Final
> CompiledExpression not completely thread-safe
> ---------------------------------------------
>
> Key: JXPATH-76
> URL: https://issues.apache.org/jira/browse/JXPATH-76
> Project: Commons JXPath
> Issue Type: Bug
> Affects Versions: 1.2 Final
> Reporter: Simon Raess
> Attachments: jxpath.patch
>
>
> Some classes in compiled expressions are not thread-safe, because they lazily initialize some information that should be initialized at object construction. The classes I've found are Path and ExpressionPath. I've attached a path that fixes the problem.
> When two threads tried to initialize such an object concurrently, it was possible that the expression was evaluated as simple expression when it should have been evaluated as complex expression. See the two stack traces below (using xpath expression //ExternalData/Order/@id). The first stack trace shows the bug in action, the second how it should look:
> caused by java.lang.UnsupportedOperationException: Not supported node test for attributes: node()
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.getNodeIterator(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.doStepNoPredicatesStandard(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.doStep(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.interpretSimpleLocationPath(SimplePathInterpreter.java(Inlined Compiled Code))
> at org.apache.commons.jxpath.ri.compiler.Path.getSingleNodePointerForSteps(Path.java(Inlined Compiled Code))
> at org.apache.commons.jxpath.ri.compiler.LocationPath.computeValue(LocationPath.java(Compiled Code))
> at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getPointer(JXPathContextReferenceImpl.java(Compiled Code))
> at org.apache.commons.jxpath.ri.JXPathCompiledExpression.selectSingleNode(JXPathCompiledExpression.java(Inlined Compiled Code))
> This replaces the lines starting at Path.getSingleNodePointerForSteps:
> LocationPath(Path).searchForPath(EvalContext) line: 183
> LocationPath(Path).getSingleNodePointerForSteps(EvalContext) line: 159
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (JXPATH-76) CompiledExpression not completely
thread-safe
Posted by "Simon Raess (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JXPATH-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469179 ]
Simon Raess commented on JXPATH-76:
-----------------------------------
I've thought about that solution too, but the change without synchronized is pretty straightforward. Instead of lazy initialization, the initialization is simply moved to the constructor. There are no side-effects and the need of synchronization is completely removed. The cost of synchronization has to be paid for each expression evaluation. It is needed only on the first time. How else can I convince you? ;-)
> CompiledExpression not completely thread-safe
> ---------------------------------------------
>
> Key: JXPATH-76
> URL: https://issues.apache.org/jira/browse/JXPATH-76
> Project: Commons JXPath
> Issue Type: Bug
> Affects Versions: 1.2 Final
> Reporter: Simon Raess
> Fix For: 1.3
>
> Attachments: jxpath.patch
>
>
> Some classes in compiled expressions are not thread-safe, because they lazily initialize some information that should be initialized at object construction. The classes I've found are Path and ExpressionPath. I've attached a path that fixes the problem.
> When two threads tried to initialize such an object concurrently, it was possible that the expression was evaluated as simple expression when it should have been evaluated as complex expression. See the two stack traces below (using xpath expression //ExternalData/Order/@id). The first stack trace shows the bug in action, the second how it should look:
> caused by java.lang.UnsupportedOperationException: Not supported node test for attributes: node()
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.getNodeIterator(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.doStepNoPredicatesStandard(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.doStep(SimplePathInterpreter.java(Compiled Code))
> at org.apache.commons.jxpath.ri.axes.SimplePathInterpreter.interpretSimpleLocationPath(SimplePathInterpreter.java(Inlined Compiled Code))
> at org.apache.commons.jxpath.ri.compiler.Path.getSingleNodePointerForSteps(Path.java(Inlined Compiled Code))
> at org.apache.commons.jxpath.ri.compiler.LocationPath.computeValue(LocationPath.java(Compiled Code))
> at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getPointer(JXPathContextReferenceImpl.java(Compiled Code))
> at org.apache.commons.jxpath.ri.JXPathCompiledExpression.selectSingleNode(JXPathCompiledExpression.java(Inlined Compiled Code))
> This replaces the lines starting at Path.getSingleNodePointerForSteps:
> LocationPath(Path).searchForPath(EvalContext) line: 183
> LocationPath(Path).getSingleNodePointerForSteps(EvalContext) line: 159
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org