[ 
https://issues.apache.org/jira/browse/XALANJ-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511608#comment-13511608
 ] 

Nash commented on XALANJ-2564:
------------------------------

I did check that the core application API uses TransformerFactories for 
concurrent processing. The code or rather the class which does the processing 
is a stateless session bean. We have no control over that code as is part of 
the Oracle product. We have opened a Service Request with Oracle and 
following-up with them. I did reverse-engineer the code to make sure 
TransformerFactories are being and it does or else in a heavy-multi-threaded 
environment like ours which sees a high volume of transactions each day, the 
issue would have occured with each and every order. The Project went live in 
early Sep 2012 and since then we have seen numerous accounts of this strange 
behaviour. We have lots of other xsls too which update order data but what is 
intruiging is its just with this one xsl that the problem arises consistently. 
I don't see anything wrong with the XSL. 

No objects are shared between threads. 
                
> variable value calculated incorrectly within for-each in xsl transformation 
> output
> ----------------------------------------------------------------------------------
>
>                 Key: XALANJ-2564
>                 URL: https://issues.apache.org/jira/browse/XALANJ-2564
>             Project: XalanJ2
>          Issue Type: Bug
>      Security Level: No security risk; visible to anyone(Ordinary problems in 
> Xalan projects.  Anybody can view the issue.) 
>    Affects Versions: 2.7
>         Environment: Weblogic 9.2 MP3 on HP-UX Itanium(B.11.31). 
> Multi-threaded environment. 
> Xalan 7.0. 
> Hardware: 
> Processors: 4
> architecture: IA64N
> Java: 1.5
> Physical Memory: 32G
>            Reporter: Nash
>            Assignee: Steven J. Hathaway
>         Attachments: Incorrect Transformation.zip
>
>
> We are encountering a strange issue in Production environment which we are 
> not able to replicate in any environments. The Order Process & Management 
> application which generates this error processes thousands of orders in a day 
> avg. 4000 order. The order xmls are transformed using various xslt to update 
> order data. There is no XLS transformation exception thrown but the xml 
> output is not what is expected which leads to an "OrderUpdateException" being 
> thrown by the application API. 
> When this exception occurs, there are always 2 orders involved i.e. 2 
> different order xmls being transformed at the same time(same timestamp) using 
> same xslt. The resulting XML transformation output for both the orders are 
> also well-formed but due to incorrect value evaluated by a variable declared 
> inside <xsl:for-each, wrong path information is being supplied to <Add 
> instruction for updating the order. Morever, the issue seems to go away on 
> retry of order task from the application web client. As a result, the orders 
> get updated and processing continues. Here retry means applying the same 
> transformation again on order xml. The input order xmls were not modified 
> whatsoever during retry.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to