You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by ka...@polarisFT.com on 2012/11/01 14:14:27 UTC
Xerces clone node issue in production environment (Multi threaded). Help
needed ...
Hi Xerces users,
Greetings!.
We have an issue in the xerces parsers and specifically in cloning a
node.We browsed in apache's site and bugzilla to find if anyone had
reported any issues or bugs relevant to the one we are facing in our
production environment.
We were able to find info about few issue that were reported already and
that is more or less similar to the one we are facing now.
Let me brief out the environment wherein we are facing this issue.
OS: Sun Solaris 10
Server: Websphere 6
JDK: 1.4
Xerces version: Xerces_Version_1_2_0
Number of Daemon threads per JVM: 3
Scenario:
In our Production environment when 3 daemon threads run under a JVM.
When 3 similar type of XML messages gets parsed at same second
(concurrently) under a JVM, we notice some attribute gets missed.
Here is sample XML that gets parsed.
<?xml version="1.0"?>
<!DOCTYPE InTemplate SYSTEM "feed_dd.dtd" >
<InTemplate>
<Header>
<DataDictionary>
<element XMLName="NumberOfTxn" CFCName="NO_TRANS"
CFCType="TYPE_STRING"/>
<element XMLName="ProcessingLoc" CFCName="PR_LOC"
CFCType="TYPE_STRING"/>
<element XMLName="ServiceType" CFCName="FCO_TYP"
CFCType="TYPE_STRING"/>
</DataDictionary>
</Header>
<Body>
<DataDictionary>
<element XMLName="TxnUID" CFCName="TRAN_NO" CFCType="TYPE_STRING"/>
<collection XMLName="TxnIdentification"
CFCType="TYPE_FIELDCOLLECTION">
<element XMLName="Sequence" CFCName="BSI_SEQ"
CFCType="TYPE_STRING"/>
<element XMLName="TxnType" CFCName="PYMT_TYP"
CFCType="TYPE_STRING"/>
<element XMLName="AcctNumber" CFCName="ACCT_NO"
CFCType="TYPE_STRING"/>
<element XMLName="CCY" CFCName="ACCT_CCY_COD"
CFCType="TYPE_STRING"/>
</collection>
<element XMLName="ProcessingLocCode" CFCName="PROC_LOCA"
CFCType="TYPE_STRING"/>
<element XMLName="Status" CFCName="STA" CFCType="TYPE_STRING"/>
<element XMLName="AuthNumS015" CFCName="MEX_AUTH_NO"
CFCType="TYPE_STRING"/> ( line no 20)
<element XMLName="AuthNumS502" CFCName="MEX_FOLIO_NO"
CFCType="TYPE_STRING"/>
<element XMLName="Reference" CFCName="MT942_REF_NO"
CFCType="TYPE_STRING"/>
</DataDictionary>
</Body>
</InTemplate>
Intially, we faced something like the whole attribute in one of the child
nodes in XML itself gets missed .( like the one highlighted above in the
sample xml - the attribute CFCName="MEX_AUTH_NO" that got underlined gets
missed).The returned XML doc is with out the 'CFCName' attribute and it
looks something like
<element XMLName="AuthNumS015" CFCType="TYPE_STRING"/> (line no 20)
To fix this we placed the following code
* Parameters:
* iNode - source
* deep - If true, recursively clone the subtree under
the specified node; if false, clone only the node itself (and its
attributes, if it is an Element).
* return:
* copy of source ( xml document that was parsed)
*/
private Node cloneNode(Node inNode, boolean deep){
// clone current input node
Node outNode = inNode.cloneNode(deep);
outNode = getRenderer().getOutDocument().importNode
(outNode,true);
// put back attr.
if ( inNode.getNodeType() == Node.ELEMENT_NODE &&
inNode.hasAttributes() ){
NamedNodeMap attrMap = inNode.getAttributes();
Attr attr = null;
Attr outAttr = null ;
for ( int i=0; i<attrMap.getLength(); i++ ){
attr = (Attr)attrMap.item(i);
// only append deleted attr.
if ((((Element)outNode).getAttributeNode
(attr.getName())) == null ){
outAttr = getRenderer
().getOutDocument().createAttribute(attr.getName());
outAttr.setValue( attr.getValue
() );
((Element)outNode).setAttributeNode
(outAttr);
}
}
}
return outNode;
}
Even after that , we faced another issue ,but this time the value of the
attribute(CFCName) gets missed or it is empty like the one shown below and
not the whole attribute as we faced before.
The xml after the attribute value missed looks something like
<element XMLName="AuthNumS015" CFCName="" CFCType="TYPE_STRING"/> [Here u
can see the CFCName attribute value is empty (null)]
We are clueless about this and the most disheartening thing is that we are
not able to reproduce this behavior consistently and this occurs probably
once in 5-6 months in our environment.We tried different ways with the
threads in our IDE to reproduce but everything ended in vain.
The below issue reported in the following link is more or less similar to
the one we are facing, but we are not able to see the whole mailing thread
conversation from the site and hence seeking xerces users who reported this
already to sort this out for us.
Clone node issue
Bug getOwnerElement for cloned attributes
http://mail-archives.apache.org/mod_mbox/xerces-j-users/200102.mbox/%3c3A843476.8A61469C@us.ibm.com%3e
[Bug 937] Changed - cloneNode empties Attribute nodes
http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200103.mbox/%3C200103121958.LAA00830@nagoya-a.betaversion.org%3E
We would like to know
1.Is this issue a valid one?
2.Is this issue got fixed ,if so, in which xerces version ?.
3.Why we are not able to reproduce it consistently and what had actually
gone wrong.
sorry for the detailed explanation about issue but we have no other go.
Your help in this regard is very much appreciated.I am ready to give more
info regarding this if needed
Thanks,
karthik,
This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.
Visit us at http://www.polarisFT.com
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: Xerces clone node issue in production environment (Multi threaded). Help
needed ...
Posted by ka...@polarisFT.com.
Hi jake,
Thanks for the reply.
But we want to know whether it is an issue in 1.2.0 ?
Only if we make sure that is an issue in xerces 1.2.0 itself , only then
we can take steps to move to the latest version.
Thanks,
karthik.
From: karthikeyan.sd@polarisFT.com
To: j-users@xerces.apache.org, hlitani@jtcsv.com,
j-dev@xerces.apache.org
Cc: Rajkumar.ramachandran@outlook.com, sandygao@ca.ibm.com
Date: 11/01/2012 09:15 PM
Subject: Re: Xerces clone node issue in production environment (Multi
threaded). Help needed ...
Hi xerces users,
Correcting this mail with xml that is very similar to the one that gets
parsed.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE PaymentMessage SYSTEM "bkt.dtd">
<PaymentMessage>
<Header>
<ProcessLocCode><![CDATA[950]]></ProcessLocCode>
<Region><![CDATA[ASIA]]></Region>
<TxnTotalAmount><![CDATA[100]]></TxnTotalAmount>
<CustomerID><![CDATA[070940]]></CustomerID>
<BatchID><![CDATA[3062006RPIG]]></BatchID>
<BatchSeq>12345</BatchSeq>
</Header>
<TransacService name="Book Transfer">
<PaymentInfo>
<TxnUID><![CDATA[E1713DD98B8C484183908B4BEFD03606]]></TxnUID>
<TxnRefNumber><![CDATA[24BKT2111]]></TxnRefNumber>
<CCY><![CDATA[MYR]]></CCY>
<ValueDate><![CDATA[20121102]]></ValueDate>
<Amount><![CDATA[100]]></Amount>
<TxnType><![CDATA[BKT]]></TxnType>
</PaymentInfo>
<FromAcctType type="Debit">
<AcctNumber><![CDATA [70940019]]></AcctNumber>
</FromAcctType>
<OrderParty>
<Name><![CDATA[070940NEC SemiConductors]]></Name>
<Address>
<Address1><![CDATA[ADDRESS LINE1]]> </Address1>
</Address>
</OrderParty>
<ToAcctType type="Beneficiary">
<Name><![CDATA[BENEFICIARY NAME FOR MERCK LENGTH35]]> </Name>
<AcctNumber><![CDATA[007904018]]></AcctNumber>
<Phone>12345</Phone>
<Address>
<Address1><![CDATA[Telok Panglima Garang Ind. Est]]></Address1>
</Address>
</ToAcctType>
<PaymentDetail>
<Line1><![CDATA[PAYMENT DETAILS 1]]></Line1>
<Line2><![CDATA[PAYMENT DETAILS 2]]> </Line2>
</PaymentDetail>
<Invoices>
<InvoiceDetail>BDFRESFGG</InvoiceDetail>
</Invoices>
<FX>
<Rate><![CDATA[56.23000000]]></Rate>
<ContractNumber><![CDATA[FXCONTACRT6]]></ContractNumber>
</FX>
</TransacService>
</PaymentMessage>
In the beginning stage the attribute 'type' for tag <ToAcctType> itself
gets missed.
It looks like <ToAcctType > [Here the attribute 'type' is missing].[See
the actual xml above for reference]
After we put in the codes to fix the issue , we faced another issue , this
time the value of attribute getting missed.
Here the XML tag looks like
<ToAcctType type="">[Here the value of the attribute 'type' is missing or
empty].[See the actual xml above for reference]
Awaiting for your valuable responses.
Thanks,
karthik
From: karthikeyan.sd@polarisFT.com
To: hlitani@jtcsv.com, sandygao@ca.ibm.com,
j-users@xerces.apache.org, j-dev@xerces.apache.org
Cc: Rajkumar.ramachandran@outlook.com,
karthikeyan.sd@polarisFT.com
Date: 11/01/2012 06:46 PM
Subject: Xerces clone node issue in production environment
(Multi
threaded). Help needed ...
Hi Xerces users,
Greetings!.
We have an issue in the xerces parsers and specifically in cloning a
node.We browsed in apache's site and bugzilla to find if anyone had
reported any issues or bugs relevant to the one we are facing in our
production environment.
We were able to find info about few issue that were reported already and
that is more or less similar to the one we are facing now.
Let me brief out the environment wherein we are facing this issue.
OS: Sun Solaris 10
Server: Websphere 6
JDK: 1.4
Xerces version: Xerces_Version_1_2_0
Number of Daemon threads per JVM: 3
Scenario:
In our Production environment when 3 daemon threads run under a JVM.
When 3 similar type of XML messages gets parsed at same second
(concurrently) under a JVM, we notice some attribute gets missed.
Here is sample XML that gets parsed.
<?xml version="1.0"?>
<!DOCTYPE InTemplate SYSTEM "feed_dd.dtd" >
<InTemplate>
<Header>
<DataDictionary>
<element XMLName="NumberOfTxn" CFCName="NO_TRANS"
CFCType="TYPE_STRING"/>
<element XMLName="ProcessingLoc" CFCName="PR_LOC"
CFCType="TYPE_STRING"/>
<element XMLName="ServiceType" CFCName="FCO_TYP"
CFCType="TYPE_STRING"/>
</DataDictionary>
</Header>
<Body>
<DataDictionary>
<element XMLName="TxnUID" CFCName="TRAN_NO" CFCType="TYPE_STRING"/>
<collection XMLName="TxnIdentification"
CFCType="TYPE_FIELDCOLLECTION">
<element XMLName="Sequence" CFCName="BSI_SEQ"
CFCType="TYPE_STRING"/>
<element XMLName="TxnType" CFCName="PYMT_TYP"
CFCType="TYPE_STRING"/>
<element XMLName="AcctNumber" CFCName="ACCT_NO"
CFCType="TYPE_STRING"/>
<element XMLName="CCY" CFCName="ACCT_CCY_COD"
CFCType="TYPE_STRING"/>
</collection>
<element XMLName="ProcessingLocCode" CFCName="PROC_LOCA"
CFCType="TYPE_STRING"/>
<element XMLName="Status" CFCName="STA" CFCType="TYPE_STRING"/>
<element XMLName="AuthNumS015" CFCName="MEX_AUTH_NO"
CFCType="TYPE_STRING"/> ( line no 20)
<element XMLName="AuthNumS502" CFCName="MEX_FOLIO_NO"
CFCType="TYPE_STRING"/>
<element XMLName="Reference" CFCName="MT942_REF_NO"
CFCType="TYPE_STRING"/>
</DataDictionary>
</Body>
</InTemplate>
Intially, we faced something like the whole attribute in one of the child
nodes in XML itself gets missed .( like the one highlighted above in the
sample xml - the attribute CFCName="MEX_AUTH_NO" that got underlined gets
missed).The returned XML doc is with out the 'CFCName' attribute and it
looks something like
<element XMLName="AuthNumS015"
CFCType="TYPE_STRING"/> (line
no 20)
To fix this we placed the following code
* Parameters:
* iNode - source
* deep - If true, recursively clone the subtree under
the specified node; if false, clone only the node itself (and its
attributes, if it is an Element).
* return:
* copy of source ( xml document that was parsed)
*/
private Node cloneNode(Node inNode, boolean deep){
// clone current input node
Node outNode = inNode.cloneNode(deep);
outNode = getRenderer().getOutDocument().importNode
(outNode,true);
// put back attr.
if ( inNode.getNodeType() == Node.ELEMENT_NODE &&
inNode.hasAttributes() ){
NamedNodeMap attrMap = inNode.getAttributes();
Attr attr = null;
Attr outAttr = null ;
for ( int i=0; i<attrMap.getLength(); i++ ){
attr = (Attr)attrMap.item(i);
// only append deleted attr.
if ((((Element)outNode).getAttributeNode
(attr.getName())) == null ){
outAttr = getRenderer
().getOutDocument().createAttribute(attr.getName());
outAttr.setValue( attr.getValue
() );
((Element)outNode).setAttributeNode
(outAttr);
}
}
}
return outNode;
}
Even after that , we faced another issue ,but this time the value of the
attribute(CFCName) gets missed or it is empty like the one shown below and
not the whole attribute as we faced before.
The xml after the attribute value missed looks something like
<element XMLName="AuthNumS015" CFCName="" CFCType="TYPE_STRING"/> [Here u
can see the CFCName attribute value is empty (null)]
We are clueless about this and the most disheartening thing is that we are
not able to reproduce this behavior consistently and this occurs probably
once in 5-6 months in our environment.We tried different ways with the
threads in our IDE to reproduce but everything ended in vain.
The below issue reported in the following link is more or less similar to
the one we are facing, but we are not able to see the whole mailing thread
conversation from the site and hence seeking xerces users who reported this
already to sort this out for us.
Clone node issue
Bug getOwnerElement for cloned attributes
http://mail-archives.apache.org/mod_mbox/xerces-j-users/200102.mbox/%3c3A843476.8A61469C@us.ibm.com%3e
[Bug 937] Changed - cloneNode empties Attribute nodes
http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200103.mbox/%3C200103121958.LAA00830@nagoya-a.betaversion.org%3E
We would like to know
1.Is this issue a valid one?
2.Is this issue got fixed ,if so, in which xerces version ?.
3.Why we are not able to reproduce it consistently and what had actually
gone wrong.
sorry for the detailed explanation about issue but we have no other go.
Your help in this regard is very much appreciated.I am ready to give more
info regarding this if needed
Thanks,
karthik,
This e-Mail may contain proprietary and confidential information and is
sent for the intended recipient(s) only. If by an addressing or
transmission error this mail has been misdirected to you, you are requested
to delete this mail immediately. You are also hereby notified that any use,
any form of reproduction, dissemination, copying, disclosure, modification,
distribution and/or publication of this e-mail message, contents or its
attachment other than by its intended recipient/s is strictly prohibited.
Visit us at http://www.polarisFT.com
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
This e-Mail may contain proprietary and confidential information and is
sent for the intended recipient(s) only. If by an addressing or
transmission error this mail has been misdirected to you, you are requested
to delete this mail immediately. You are also hereby notified that any use,
any form of reproduction, dissemination, copying, disclosure, modification,
distribution and/or publication of this e-mail message, contents or its
attachment other than by its intended recipient/s is strictly prohibited.
Visit us at http://www.polarisFT.com
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.
Visit us at http://www.polarisFT.com
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: Xerces clone node issue in production environment (Multi threaded). Help
needed ...
Posted by ka...@polarisFT.com.
Hi xerces users,
Correcting this mail with xml that is very similar to the one that gets
parsed.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE PaymentMessage SYSTEM "bkt.dtd">
<PaymentMessage>
<Header>
<ProcessLocCode><![CDATA[950]]></ProcessLocCode>
<Region><![CDATA[ASIA]]></Region>
<TxnTotalAmount><![CDATA[100]]></TxnTotalAmount>
<CustomerID><![CDATA[070940]]></CustomerID>
<BatchID><![CDATA[3062006RPIG]]></BatchID>
<BatchSeq>12345</BatchSeq>
</Header>
<TransacService name="Book Transfer">
<PaymentInfo>
<TxnUID><![CDATA[E1713DD98B8C484183908B4BEFD03606]]></TxnUID>
<TxnRefNumber><![CDATA[24BKT2111]]></TxnRefNumber>
<CCY><![CDATA[MYR]]></CCY>
<ValueDate><![CDATA[20121102]]></ValueDate>
<Amount><![CDATA[100]]></Amount>
<TxnType><![CDATA[BKT]]></TxnType>
</PaymentInfo>
<FromAcctType type="Debit">
<AcctNumber><![CDATA [70940019]]></AcctNumber>
</FromAcctType>
<OrderParty>
<Name><![CDATA[070940NEC SemiConductors]]></Name>
<Address>
<Address1><![CDATA[ADDRESS LINE1]]> </Address1>
</Address>
</OrderParty>
<ToAcctType type="Beneficiary">
<Name><![CDATA[BENEFICIARY NAME FOR MERCK LENGTH35]]> </Name>
<AcctNumber><![CDATA[007904018]]></AcctNumber>
<Phone>12345</Phone>
<Address>
<Address1><![CDATA[Telok Panglima Garang Ind. Est]]></Address1>
</Address>
</ToAcctType>
<PaymentDetail>
<Line1><![CDATA[PAYMENT DETAILS 1]]></Line1>
<Line2><![CDATA[PAYMENT DETAILS 2]]> </Line2>
</PaymentDetail>
<Invoices>
<InvoiceDetail>BDFRESFGG</InvoiceDetail>
</Invoices>
<FX>
<Rate><![CDATA[56.23000000]]></Rate>
<ContractNumber><![CDATA[FXCONTACRT6]]></ContractNumber>
</FX>
</TransacService>
</PaymentMessage>
In the beginning stage the attribute 'type' for tag <ToAcctType> itself
gets missed.
It looks like <ToAcctType > [Here the attribute 'type' is missing].[See
the actual xml above for reference]
After we put in the codes to fix the issue , we faced another issue , this
time the value of attribute getting missed.
Here the XML tag looks like
<ToAcctType type="">[Here the value of the attribute 'type' is missing or
empty].[See the actual xml above for reference]
Awaiting for your valuable responses.
Thanks,
karthik
From: karthikeyan.sd@polarisFT.com
To: hlitani@jtcsv.com, sandygao@ca.ibm.com,
j-users@xerces.apache.org, j-dev@xerces.apache.org
Cc: Rajkumar.ramachandran@outlook.com, karthikeyan.sd@polarisFT.com
Date: 11/01/2012 06:46 PM
Subject: Xerces clone node issue in production environment (Multi
threaded). Help needed ...
Hi Xerces users,
Greetings!.
We have an issue in the xerces parsers and specifically in cloning a
node.We browsed in apache's site and bugzilla to find if anyone had
reported any issues or bugs relevant to the one we are facing in our
production environment.
We were able to find info about few issue that were reported already and
that is more or less similar to the one we are facing now.
Let me brief out the environment wherein we are facing this issue.
OS: Sun Solaris 10
Server: Websphere 6
JDK: 1.4
Xerces version: Xerces_Version_1_2_0
Number of Daemon threads per JVM: 3
Scenario:
In our Production environment when 3 daemon threads run under a JVM.
When 3 similar type of XML messages gets parsed at same second
(concurrently) under a JVM, we notice some attribute gets missed.
Here is sample XML that gets parsed.
<?xml version="1.0"?>
<!DOCTYPE InTemplate SYSTEM "feed_dd.dtd" >
<InTemplate>
<Header>
<DataDictionary>
<element XMLName="NumberOfTxn" CFCName="NO_TRANS"
CFCType="TYPE_STRING"/>
<element XMLName="ProcessingLoc" CFCName="PR_LOC"
CFCType="TYPE_STRING"/>
<element XMLName="ServiceType" CFCName="FCO_TYP"
CFCType="TYPE_STRING"/>
</DataDictionary>
</Header>
<Body>
<DataDictionary>
<element XMLName="TxnUID" CFCName="TRAN_NO" CFCType="TYPE_STRING"/>
<collection XMLName="TxnIdentification"
CFCType="TYPE_FIELDCOLLECTION">
<element XMLName="Sequence" CFCName="BSI_SEQ"
CFCType="TYPE_STRING"/>
<element XMLName="TxnType" CFCName="PYMT_TYP"
CFCType="TYPE_STRING"/>
<element XMLName="AcctNumber" CFCName="ACCT_NO"
CFCType="TYPE_STRING"/>
<element XMLName="CCY" CFCName="ACCT_CCY_COD"
CFCType="TYPE_STRING"/>
</collection>
<element XMLName="ProcessingLocCode" CFCName="PROC_LOCA"
CFCType="TYPE_STRING"/>
<element XMLName="Status" CFCName="STA" CFCType="TYPE_STRING"/>
<element XMLName="AuthNumS015" CFCName="MEX_AUTH_NO"
CFCType="TYPE_STRING"/> ( line no 20)
<element XMLName="AuthNumS502" CFCName="MEX_FOLIO_NO"
CFCType="TYPE_STRING"/>
<element XMLName="Reference" CFCName="MT942_REF_NO"
CFCType="TYPE_STRING"/>
</DataDictionary>
</Body>
</InTemplate>
Intially, we faced something like the whole attribute in one of the child
nodes in XML itself gets missed .( like the one highlighted above in the
sample xml - the attribute CFCName="MEX_AUTH_NO" that got underlined gets
missed).The returned XML doc is with out the 'CFCName' attribute and it
looks something like
<element XMLName="AuthNumS015" CFCType="TYPE_STRING"/> (line
no 20)
To fix this we placed the following code
* Parameters:
* iNode - source
* deep - If true, recursively clone the subtree under
the specified node; if false, clone only the node itself (and its
attributes, if it is an Element).
* return:
* copy of source ( xml document that was parsed)
*/
private Node cloneNode(Node inNode, boolean deep){
// clone current input node
Node outNode = inNode.cloneNode(deep);
outNode = getRenderer().getOutDocument().importNode
(outNode,true);
// put back attr.
if ( inNode.getNodeType() == Node.ELEMENT_NODE &&
inNode.hasAttributes() ){
NamedNodeMap attrMap = inNode.getAttributes();
Attr attr = null;
Attr outAttr = null ;
for ( int i=0; i<attrMap.getLength(); i++ ){
attr = (Attr)attrMap.item(i);
// only append deleted attr.
if ((((Element)outNode).getAttributeNode
(attr.getName())) == null ){
outAttr = getRenderer
().getOutDocument().createAttribute(attr.getName());
outAttr.setValue( attr.getValue
() );
((Element)outNode).setAttributeNode
(outAttr);
}
}
}
return outNode;
}
Even after that , we faced another issue ,but this time the value of the
attribute(CFCName) gets missed or it is empty like the one shown below and
not the whole attribute as we faced before.
The xml after the attribute value missed looks something like
<element XMLName="AuthNumS015" CFCName="" CFCType="TYPE_STRING"/> [Here u
can see the CFCName attribute value is empty (null)]
We are clueless about this and the most disheartening thing is that we are
not able to reproduce this behavior consistently and this occurs probably
once in 5-6 months in our environment.We tried different ways with the
threads in our IDE to reproduce but everything ended in vain.
The below issue reported in the following link is more or less similar to
the one we are facing, but we are not able to see the whole mailing thread
conversation from the site and hence seeking xerces users who reported this
already to sort this out for us.
Clone node issue
Bug getOwnerElement for cloned attributes
http://mail-archives.apache.org/mod_mbox/xerces-j-users/200102.mbox/%3c3A843476.8A61469C@us.ibm.com%3e
[Bug 937] Changed - cloneNode empties Attribute nodes
http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200103.mbox/%3C200103121958.LAA00830@nagoya-a.betaversion.org%3E
We would like to know
1.Is this issue a valid one?
2.Is this issue got fixed ,if so, in which xerces version ?.
3.Why we are not able to reproduce it consistently and what had actually
gone wrong.
sorry for the detailed explanation about issue but we have no other go.
Your help in this regard is very much appreciated.I am ready to give more
info regarding this if needed
Thanks,
karthik,
This e-Mail may contain proprietary and confidential information and is
sent for the intended recipient(s) only. If by an addressing or
transmission error this mail has been misdirected to you, you are requested
to delete this mail immediately. You are also hereby notified that any use,
any form of reproduction, dissemination, copying, disclosure, modification,
distribution and/or publication of this e-mail message, contents or its
attachment other than by its intended recipient/s is strictly prohibited.
Visit us at http://www.polarisFT.com
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.
Visit us at http://www.polarisFT.com
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: Xerces clone node issue in production environment (Multi threaded). Help
needed ...
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
As Jake pointed out Xerces-J 1.2.0 is ancient. It was released over 12
years ago. It's unlikely that you'll find anyone here who still uses it or
remembers how it behaves. It is more likely that someone would respond to
your questions if you were using a recent version.
Michael Glavassevich
XML Technologies and WAS Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
karthikeyan.sd@polarisFT.com wrote on 01/11/2012 11:53:37 AM:
> Hi jake,
> Thanks for the reply.
> But we want to know whether it is an issue in 1.2.0.
> Only if we make sure that is an issue in xerces 1.2.0 itself , only
then
> we can take steps to move to the latest version.
> Thanks,
> karthik.
>
>
>
> From: "Jacob Kjome" <ho...@visi.com>
> To: <j-...@xerces.apache.org>
> Date: 11/01/2012 09:15 PM
> Subject: Re: Xerces clone node issue in production environment (Multi
> threaded). Help needed ...
>
>
>
>
> If you are using Xerces 1.2.0, then you are using an ancient version...
of
> Xerces1. That hasn't been actively developed for many years.
>
> You should upgrade and see if your issue exists in the latest release of
> Xerces2, which is version 2.11.0.
>
>
> Jake
>
> On Thu, 1 Nov 2012 18:44:27 +0530
> karthikeyan.sd@polarisFT.com wrote:
> >
> > Hi Xerces users,
> >
> > Greetings!.
> >
> > We have an issue in the xerces parsers and specifically in cloning a
> > node.We browsed in apache's site and bugzilla to find if anyone had
> > reported any issues or bugs relevant to the one we are facing in our
> > production environment.
> >
> > We were able to find info about few issue that were reported already
and
> > that is more or less similar to the one we are facing now.
> >
> > Let me brief out the environment wherein we are facing this issue.
> >
> > OS: Sun Solaris 10
> > Server: Websphere 6
> > JDK: 1.4
> > Xerces version: Xerces_Version_1_2_0
> > Number of Daemon threads per JVM: 3
> >
> > Scenario:
> >
> > In our Production environment when 3 daemon threads run under a JVM.
> >
> > When 3 similar type of XML messages gets parsed at same second
> > (concurrently) under a JVM, we notice some attribute gets missed.
> >
> > Here is sample XML that gets parsed.
> >
> > <?xml version="1.0"?>
> > <!DOCTYPE InTemplate SYSTEM "feed_dd.dtd" >
> > <InTemplate>
> > <Header>
> > <DataDictionary>
> > <element XMLName="NumberOfTxn" CFCName="NO_TRANS"
> > CFCType="TYPE_STRING"/>
> > <element XMLName="ProcessingLoc" CFCName="PR_LOC"
> > CFCType="TYPE_STRING"/>
> > <element XMLName="ServiceType" CFCName="FCO_TYP"
> > CFCType="TYPE_STRING"/>
> > </DataDictionary>
> > </Header>
> > <Body>
> > <DataDictionary>
> > <element XMLName="TxnUID" CFCName="TRAN_NO"
CFCType="TYPE_STRING"/>
> > <collection XMLName="TxnIdentification"
> > CFCType="TYPE_FIELDCOLLECTION">
> > <element XMLName="Sequence" CFCName="BSI_SEQ"
> > CFCType="TYPE_STRING"/>
> > <element XMLName="TxnType" CFCName="PYMT_TYP"
> > CFCType="TYPE_STRING"/>
> > <element XMLName="AcctNumber" CFCName="ACCT_NO"
> > CFCType="TYPE_STRING"/>
> > <element XMLName="CCY" CFCName="ACCT_CCY_COD"
> > CFCType="TYPE_STRING"/>
> > </collection>
> > <element XMLName="ProcessingLocCode" CFCName="PROC_LOCA"
> > CFCType="TYPE_STRING"/>
> > <element XMLName="Status" CFCName="STA" CFCType="TYPE_STRING"/>
> > <element XMLName="AuthNumS015" CFCName="MEX_AUTH_NO"
> > CFCType="TYPE_STRING"/> ( line no 20)
> > <element XMLName="AuthNumS502" CFCName="MEX_FOLIO_NO"
> > CFCType="TYPE_STRING"/>
> >
> > <element XMLName="Reference" CFCName="MT942_REF_NO"
> > CFCType="TYPE_STRING"/>
> > </DataDictionary>
> > </Body>
> > </InTemplate>
> >
> > Intially, we faced something like the whole attribute in one of the
child
> > nodes in XML itself gets missed .( like the one highlighted above in
the
> > sample xml - the attribute CFCName="MEX_AUTH_NO" that got underlined
gets
> > missed).The returned XML doc is with out the 'CFCName' attribute and
it
> > looks something like
> >
> > <element XMLName="AuthNumS015" CFCType="TYPE_STRING"/> (line
> no 20)
> >
> >
> >
> > To fix this we placed the following code
> >
> >
> > * Parameters:
> > * iNode - source
> > * deep - If true, recursively clone the subtree
> under
> > the specified node; if false, clone only the node itself (and its
> > attributes, if it is an Element).
> > * return:
> > * copy of source ( xml document that was parsed)
> > */
> > private Node cloneNode(Node inNode, boolean deep){
> >
> > // clone current input node
> > Node outNode = inNode.cloneNode(deep);
> > outNode = getRenderer().getOutDocument().importNode
> > (outNode,true);
> >
> > // put back attr.
> > if ( inNode.getNodeType() == Node.ELEMENT_NODE &&
> > inNode.hasAttributes() ){
> >
> > NamedNodeMap attrMap = inNode.getAttributes();
> > Attr attr = null;
> > Attr outAttr = null ;
> >
> > for ( int i=0; i<attrMap.getLength(); i++ ){
> > attr = (Attr)attrMap.item(i);
> > // only append deleted attr.
> > if
((((Element)outNode).getAttributeNode
> > (attr.getName())) == null ){
> > outAttr = getRenderer
> > ().getOutDocument().createAttribute(attr.getName());
> > outAttr.setValue( attr.getValue
> > () );
>
> ((Element)outNode).setAttributeNode
>
> > (outAttr);
> > }
> > }
> > }
> > return outNode;
> > }
> >
> > Even after that , we faced another issue ,but this time the value of
the
> > attribute(CFCName) gets missed or it is empty like the one shown below
> and
> > not the whole attribute as we faced before.
> >
> >
> > The xml after the attribute value missed looks something like
> > <element XMLName="AuthNumS015" CFCName="" CFCType="TYPE_STRING"/>
[Here u
> > can see the CFCName attribute value is empty (null)]
> >
> >
> > We are clueless about this and the most disheartening thing is that we
> are
> > not able to reproduce this behavior consistently and this occurs
> probably
> > once in 5-6 months in our environment.We tried different ways with the
> > threads in our IDE to reproduce but everything ended in vain.
> >
> > The below issue reported in the following link is more or less similar
to
> > the one we are facing, but we are not able to see the whole mailing
> thread
> > conversation from the site and hence seeking xerces users who reported
> this
> > already to sort this out for us.
> >
> > Clone node issue
> >
> > Bug getOwnerElement for cloned attributes
> >
> >
> http://mail-archives.apache.org/mod_mbox/xerces-j-users/
> 200102.mbox/%3c3A843476.8A61469C@us.ibm.com%3e
>
> >
> >
> >
> > [Bug 937] Changed - cloneNode empties Attribute nodes
> >
> >
> http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200103.mbox/%
> 3C200103121958.LAA00830@nagoya-a.betaversion.org%3E
>
> >
> >
> >
> >
> > We would like to know
> >
> > 1.Is this issue a valid one?
> > 2.Is this issue got fixed ,if so, in which xerces version ?.
> > 3.Why we are not able to reproduce it consistently and what had
actually
> > gone wrong.
> >
> > sorry for the detailed explanation about issue but we have no other
go.
> > Your help in this regard is very much appreciated.I am ready to give
more
> > info regarding this if needed
> >
> >
> > Thanks,
> > karthik,
> >
> >
> >
> > This e-Mail may contain proprietary and confidential information and
is
> sent
> >for the intended recipient(s) only. If by an addressing or
transmission
> >error this mail has been misdirected to you, you are requested to
delete
> this
> >mail immediately. You are also hereby notified that any use, any form
of
> >reproduction, dissemination, copying, disclosure, modification,
> distribution
> >and/or publication of this e-mail message, contents or its attachment
> other
> >than by its intended recipient/s is strictly prohibited.
> >
> > Visit us at http://www.polarisFT.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> >For additional commands, e-mail: j-users-help@xerces.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
>
>
>
> This e-Mail may contain proprietary and confidential information and
> is sent for the intended recipient(s) only. If by an addressing or
> transmission error this mail has been misdirected to you, you are
> requested to delete this mail immediately. You are also hereby
> notified that any use, any form of reproduction, dissemination,
> copying, disclosure, modification, distribution and/or publication
> of this e-mail message, contents or its attachment other than by its
> intended recipient/s is strictly prohibited.
>
> Visit us at http://www.polarisFT.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: Xerces clone node issue in production environment (Multi threaded). Help
needed ...
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
"Jacob Kjome" <ho...@visi.com> wrote on 02/11/2012 02:19:44 PM:
<snip/>
> I feel for you, but there's little I or anyone else can do for you.
Michael
> already stated that there's no one currently working on Xerces that has
any
> deep understanding of the ancient Xerces1 codebase. All efforts have
been in
> developing Xerces2 for a very long time. And the two codebases diverge
> greatly.
For the record Xerces1 was pretty much dead before I arrived (and I've
been around a long time). As is the case for most other developers who've
worked on the project, Xerces2 is the only generation I've ever
contributed to. For folks who are still using Xerces1 they're pretty much
on their own at this point. They really need to upgrade.
> Again, your best bet in the immediate term is to update to the latest
version
> of Xerces1. Your best bet in the long term is to update to
Xerces2,which you
> will actually find support for on this list.
>
>
> Jake
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
Michael Glavassevich
XML Technologies and WAS Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: Xerces clone node issue in production environment (Multi threaded). Help needed ...
Posted by Jacob Kjome <ho...@visi.com>.
Just to be clear, I am not a Xerces developer, only a user. So I do not speak
for the Xerces project.
Anyway, the fact that you moved to a new, faster, server (likely with multiple
cores), and the fact that you can only reproduce this in production
(presumably under load), indicates to me that this is either a threading issue
in your own code, or a bug in the version of Xerces that you are using.
Clearly it is not the intended behavior. That much is clear.
Also, based on the email thread you reference, it looks to me like the user
had the issue in version 1.2, but that when he moved to version 1.3, the issue
was resolved. You should find some encouragement there.
I feel for you, but there's little I or anyone else can do for you. Michael
already stated that there's no one currently working on Xerces that has any
deep understanding of the ancient Xerces1 codebase. All efforts have been in
developing Xerces2 for a very long time. And the two codebases diverge
greatly.
Again, your best bet in the immediate term is to update to the latest version
of Xerces1. Your best bet in the long term is to update to Xerces2, which you
will actually find support for on this list.
Jake
On Fri, 2 Nov 2012 14:10:22 +0530
karthikeyan.sd@polarisFT.com wrote:
> Hi Jake,
>
> We have been using this version of xerces since 2001. Mid of last year
> (2011), we moved to powerful server. After this started seeing problem with
> XML few times.
>
> One of them is below mentioned. This happened twice in production
> environment but we could not reproduce in test environment. Now we are
> analyzing if this is really an issue with xerces 1.2 version and this won't
> happen again if we upgrade to latest version.
>
> Customers using our product are sensitive.
>
> Thanks
> karthik
>
>
>
>From: "Jacob Kjome" <ho...@visi.com>
> To: <j-...@xerces.apache.org>
> Date: 11/01/2012 09:34 PM
> Subject: Re: Xerces clone node issue in production environment (Multi
> threaded). Help needed ...
>
>
>
>
> At the very least, you should try it with the latest version of Xerces1,
> which
> is 1.4.4. Asking Xerces developers and users to spend precious time
> investigating a strange issue in an ancient release of a project that the
> Xerces site lists as a "Hibernated project" is not in good form.
>
> You need to do your own investigation first. Try the Xerces-1.4.4. That's
>
> the same codebase as 1.2.0, but with bug fixes. If your issue is cleared
> up,
> then you're done. If not, then try the latest release. If your issue
> clears
> up, then you're done. If you still have the issue after trying all that,
> ask
> again and I'm sure you'll have plenty of takers on researching the issue.
>
>
> Jake
>
>
> On Thu, 1 Nov 2012 21:23:37 +0530
> karthikeyan.sd@polarisFT.com wrote:
>> Hi jake,
>> Thanks for the reply.
>> But we want to know whether it is an issue in 1.2.0.
>> Only if we make sure that is an issue in xerces 1.2.0 itself , only then
>> we can take steps to move to the latest version.
>> Thanks,
>> karthik.
>>
>>
>>
>>From: "Jacob Kjome" <ho...@visi.com>
>> To: <j-...@xerces.apache.org>
>> Date: 11/01/2012 09:15 PM
>> Subject: Re: Xerces clone node issue in production environment
> (Multi
>> threaded). Help needed ...
>>
>>
>>
>>
>> If you are using Xerces 1.2.0, then you are using an ancient version...
> of
>> Xerces1. That hasn't been actively developed for many years.
>>
>> You should upgrade and see if your issue exists in the latest release of
>> Xerces2, which is version 2.11.0.
>>
>>
>> Jake
>>
>> On Thu, 1 Nov 2012 18:44:27 +0530
>> karthikeyan.sd@polarisFT.com wrote:
>>>
>>> Hi Xerces users,
>>>
>>> Greetings!.
>>>
>>> We have an issue in the xerces parsers and specifically in cloning a
>>> node.We browsed in apache's site and bugzilla to find if anyone had
>>> reported any issues or bugs relevant to the one we are facing in our
>>> production environment.
>>>
>>> We were able to find info about few issue that were reported already and
>>> that is more or less similar to the one we are facing now.
>>>
>>> Let me brief out the environment wherein we are facing this issue.
>>>
>>> OS: Sun Solaris 10
>>> Server: Websphere 6
>>> JDK: 1.4
>>> Xerces version: Xerces_Version_1_2_0
>>> Number of Daemon threads per JVM: 3
>>>
>>> Scenario:
>>>
>>> In our Production environment when 3 daemon threads run under a JVM.
>>>
>>> When 3 similar type of XML messages gets parsed at same second
>>> (concurrently) under a JVM, we notice some attribute gets missed.
>>>
>>> Here is sample XML that gets parsed.
>>>
>>> <?xml version="1.0"?>
>>> <!DOCTYPE InTemplate SYSTEM "feed_dd.dtd" >
>>> <InTemplate>
>>> <Header>
>>> <DataDictionary>
>>> <element XMLName="NumberOfTxn" CFCName="NO_TRANS"
>>> CFCType="TYPE_STRING"/>
>>> <element XMLName="ProcessingLoc" CFCName="PR_LOC"
>>> CFCType="TYPE_STRING"/>
>>> <element XMLName="ServiceType" CFCName="FCO_TYP"
>>> CFCType="TYPE_STRING"/>
>>> </DataDictionary>
>>> </Header>
>>> <Body>
>>> <DataDictionary>
>>> <element XMLName="TxnUID" CFCName="TRAN_NO" CFCType="TYPE_STRING"/>
>>> <collection XMLName="TxnIdentification"
>>> CFCType="TYPE_FIELDCOLLECTION">
>>> <element XMLName="Sequence" CFCName="BSI_SEQ"
>>> CFCType="TYPE_STRING"/>
>>> <element XMLName="TxnType" CFCName="PYMT_TYP"
>>> CFCType="TYPE_STRING"/>
>>> <element XMLName="AcctNumber" CFCName="ACCT_NO"
>>> CFCType="TYPE_STRING"/>
>>> <element XMLName="CCY" CFCName="ACCT_CCY_COD"
>>> CFCType="TYPE_STRING"/>
>>> </collection>
>>> <element XMLName="ProcessingLocCode" CFCName="PROC_LOCA"
>>> CFCType="TYPE_STRING"/>
>>> <element XMLName="Status" CFCName="STA" CFCType="TYPE_STRING"/>
>>> <element XMLName="AuthNumS015" CFCName="MEX_AUTH_NO"
>>> CFCType="TYPE_STRING"/> ( line no 20)
>>> <element XMLName="AuthNumS502" CFCName="MEX_FOLIO_NO"
>>> CFCType="TYPE_STRING"/>
>>>
>>> <element XMLName="Reference" CFCName="MT942_REF_NO"
>>> CFCType="TYPE_STRING"/>
>>> </DataDictionary>
>>> </Body>
>>> </InTemplate>
>>>
>>> Intially, we faced something like the whole attribute in one of the
> child
>>> nodes in XML itself gets missed .( like the one highlighted above in the
>>> sample xml - the attribute CFCName="MEX_AUTH_NO" that got underlined
> gets
>>> missed).The returned XML doc is with out the 'CFCName' attribute and it
>>> looks something like
>>>
>>> <element XMLName="AuthNumS015"
> CFCType="TYPE_STRING"/> (line
>> no 20)
>>>
>>>
>>>
>>> To fix this we placed the following code
>>>
>>>
>>> * Parameters:
>>> * iNode - source
>>> * deep - If true, recursively clone the subtree
>> under
>>> the specified node; if false, clone only the node itself (and its
>>> attributes, if it is an Element).
>>> * return:
>>> * copy of source ( xml document that was parsed)
>>> */
>>> private Node cloneNode(Node inNode, boolean deep){
>>>
>>> // clone current input node
>>> Node outNode = inNode.cloneNode(deep);
>>> outNode = getRenderer().getOutDocument().importNode
>>> (outNode,true);
>>>
>>> // put back attr.
>>> if ( inNode.getNodeType() == Node.ELEMENT_NODE &&
>>> inNode.hasAttributes() ){
>>>
>>> NamedNodeMap attrMap = inNode.getAttributes();
>>> Attr attr = null;
>>> Attr outAttr = null ;
>>>
>>> for ( int i=0; i<attrMap.getLength(); i++ ){
>>> attr = (Attr)attrMap.item(i);
>>> // only append deleted attr.
>>> if ((((Element)outNode).getAttributeNode
>>> (attr.getName())) == null ){
>>> outAttr = getRenderer
>>> ().getOutDocument().createAttribute(attr.getName());
>>> outAttr.setValue( attr.getValue
>>> () );
>>> ((Element)outNode).setAttributeNode
>
>>
>>> (outAttr);
>>> }
>>> }
>>> }
>>> return outNode;
>>> }
>>>
>>> Even after that , we faced another issue ,but this time the value of the
>>> attribute(CFCName) gets missed or it is empty like the one shown below
>> and
>>> not the whole attribute as we faced before.
>>>
>>>
>>> The xml after the attribute value missed looks something like
>>> <element XMLName="AuthNumS015" CFCName="" CFCType="TYPE_STRING"/> [Here
> u
>>> can see the CFCName attribute value is empty (null)]
>>>
>>>
>>> We are clueless about this and the most disheartening thing is that we
>> are
>>> not able to reproduce this behavior consistently and this occurs
>> probably
>>> once in 5-6 months in our environment.We tried different ways with the
>>> threads in our IDE to reproduce but everything ended in vain.
>>>
>>> The below issue reported in the following link is more or less similar
> to
>>> the one we are facing, but we are not able to see the whole mailing
>> thread
>>> conversation from the site and hence seeking xerces users who reported
>> this
>>> already to sort this out for us.
>>>
>>> Clone node issue
>>>
>>> Bug getOwnerElement for cloned attributes
>>>
>>>
>>
> http://mail-archives.apache.org/mod_mbox/xerces-j-users/200102.mbox/%3c3A843476.8A61469C@us.ibm.com%3e
>
>>
>>>
>>>
>>>
>>> [Bug 937] Changed - cloneNode empties Attribute nodes
>>>
>>>
>>
> http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200103.mbox/%3C200103121958.LAA00830@nagoya-a.betaversion.org%3E
>
>>
>>>
>>>
>>>
>>>
>>> We would like to know
>>>
>>> 1.Is this issue a valid one?
>>> 2.Is this issue got fixed ,if so, in which xerces version ?.
>>> 3.Why we are not able to reproduce it consistently and what had actually
>>> gone wrong.
>>>
>>> sorry for the detailed explanation about issue but we have no other go.
>>> Your help in this regard is very much appreciated.I am ready to give
> more
>>> info regarding this if needed
>>>
>>>
>>> Thanks,
>>> karthik,
>>>
>>>
>>>
>>> This e-Mail may contain proprietary and confidential information and is
>> sent
>>>for the intended recipient(s) only. If by an addressing or transmission
>>>error this mail has been misdirected to you, you are requested to delete
>> this
>>>mail immediately. You are also hereby notified that any use, any form of
>>>reproduction, dissemination, copying, disclosure, modification,
>> distribution
>>>and/or publication of this e-mail message, contents or its attachment
>> other
>>>than by its intended recipient/s is strictly prohibited.
>>>
>>> Visit us at http://www.polarisFT.com
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>>>For additional commands, e-mail: j-users-help@xerces.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>>For additional commands, e-mail: j-users-help@xerces.apache.org
>>
>>
>>
>>
>>
>> This e-Mail may contain proprietary and confidential information and is
> sent
>>for the intended recipient(s) only. If by an addressing or transmission
>>error this mail has been misdirected to you, you are requested to delete
> this
>>mail immediately. You are also hereby notified that any use, any form of
>>reproduction, dissemination, copying, disclosure, modification,
> distribution
>>and/or publication of this e-mail message, contents or its attachment
> other
>>than by its intended recipient/s is strictly prohibited.
>>
>> Visit us at http://www.polarisFT.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>>For additional commands, e-mail: j-users-help@xerces.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
>
>
>
> This e-Mail may contain proprietary and confidential information and is sent
>for the intended recipient(s) only. If by an addressing or transmission
>error this mail has been misdirected to you, you are requested to delete this
>mail immediately. You are also hereby notified that any use, any form of
>reproduction, dissemination, copying, disclosure, modification, distribution
>and/or publication of this e-mail message, contents or its attachment other
>than by its intended recipient/s is strictly prohibited.
>
> Visit us at http://www.polarisFT.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: Xerces clone node issue in production environment (Multi threaded). Help
needed ...
Posted by ka...@polarisFT.com.
Hi Jake,
We have been using this version of xerces since 2001. Mid of last year
(2011), we moved to powerful server. After this started seeing problem with
XML few times.
One of them is below mentioned. This happened twice in production
environment but we could not reproduce in test environment. Now we are
analyzing if this is really an issue with xerces 1.2 version and this won't
happen again if we upgrade to latest version.
Customers using our product are sensitive.
Thanks
karthik
From: "Jacob Kjome" <ho...@visi.com>
To: <j-...@xerces.apache.org>
Date: 11/01/2012 09:34 PM
Subject: Re: Xerces clone node issue in production environment (Multi
threaded). Help needed ...
At the very least, you should try it with the latest version of Xerces1,
which
is 1.4.4. Asking Xerces developers and users to spend precious time
investigating a strange issue in an ancient release of a project that the
Xerces site lists as a "Hibernated project" is not in good form.
You need to do your own investigation first. Try the Xerces-1.4.4. That's
the same codebase as 1.2.0, but with bug fixes. If your issue is cleared
up,
then you're done. If not, then try the latest release. If your issue
clears
up, then you're done. If you still have the issue after trying all that,
ask
again and I'm sure you'll have plenty of takers on researching the issue.
Jake
On Thu, 1 Nov 2012 21:23:37 +0530
karthikeyan.sd@polarisFT.com wrote:
> Hi jake,
> Thanks for the reply.
> But we want to know whether it is an issue in 1.2.0.
> Only if we make sure that is an issue in xerces 1.2.0 itself , only then
> we can take steps to move to the latest version.
> Thanks,
> karthik.
>
>
>
>From: "Jacob Kjome" <ho...@visi.com>
> To: <j-...@xerces.apache.org>
> Date: 11/01/2012 09:15 PM
> Subject: Re: Xerces clone node issue in production environment
(Multi
> threaded). Help needed ...
>
>
>
>
> If you are using Xerces 1.2.0, then you are using an ancient version...
of
> Xerces1. That hasn't been actively developed for many years.
>
> You should upgrade and see if your issue exists in the latest release of
> Xerces2, which is version 2.11.0.
>
>
> Jake
>
> On Thu, 1 Nov 2012 18:44:27 +0530
> karthikeyan.sd@polarisFT.com wrote:
>>
>> Hi Xerces users,
>>
>> Greetings!.
>>
>> We have an issue in the xerces parsers and specifically in cloning a
>> node.We browsed in apache's site and bugzilla to find if anyone had
>> reported any issues or bugs relevant to the one we are facing in our
>> production environment.
>>
>> We were able to find info about few issue that were reported already and
>> that is more or less similar to the one we are facing now.
>>
>> Let me brief out the environment wherein we are facing this issue.
>>
>> OS: Sun Solaris 10
>> Server: Websphere 6
>> JDK: 1.4
>> Xerces version: Xerces_Version_1_2_0
>> Number of Daemon threads per JVM: 3
>>
>> Scenario:
>>
>> In our Production environment when 3 daemon threads run under a JVM.
>>
>> When 3 similar type of XML messages gets parsed at same second
>> (concurrently) under a JVM, we notice some attribute gets missed.
>>
>> Here is sample XML that gets parsed.
>>
>> <?xml version="1.0"?>
>> <!DOCTYPE InTemplate SYSTEM "feed_dd.dtd" >
>> <InTemplate>
>> <Header>
>> <DataDictionary>
>> <element XMLName="NumberOfTxn" CFCName="NO_TRANS"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="ProcessingLoc" CFCName="PR_LOC"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="ServiceType" CFCName="FCO_TYP"
>> CFCType="TYPE_STRING"/>
>> </DataDictionary>
>> </Header>
>> <Body>
>> <DataDictionary>
>> <element XMLName="TxnUID" CFCName="TRAN_NO" CFCType="TYPE_STRING"/>
>> <collection XMLName="TxnIdentification"
>> CFCType="TYPE_FIELDCOLLECTION">
>> <element XMLName="Sequence" CFCName="BSI_SEQ"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="TxnType" CFCName="PYMT_TYP"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="AcctNumber" CFCName="ACCT_NO"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="CCY" CFCName="ACCT_CCY_COD"
>> CFCType="TYPE_STRING"/>
>> </collection>
>> <element XMLName="ProcessingLocCode" CFCName="PROC_LOCA"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="Status" CFCName="STA" CFCType="TYPE_STRING"/>
>> <element XMLName="AuthNumS015" CFCName="MEX_AUTH_NO"
>> CFCType="TYPE_STRING"/> ( line no 20)
>> <element XMLName="AuthNumS502" CFCName="MEX_FOLIO_NO"
>> CFCType="TYPE_STRING"/>
>>
>> <element XMLName="Reference" CFCName="MT942_REF_NO"
>> CFCType="TYPE_STRING"/>
>> </DataDictionary>
>> </Body>
>> </InTemplate>
>>
>> Intially, we faced something like the whole attribute in one of the
child
>> nodes in XML itself gets missed .( like the one highlighted above in the
>> sample xml - the attribute CFCName="MEX_AUTH_NO" that got underlined
gets
>> missed).The returned XML doc is with out the 'CFCName' attribute and it
>> looks something like
>>
>> <element XMLName="AuthNumS015"
CFCType="TYPE_STRING"/> (line
> no 20)
>>
>>
>>
>> To fix this we placed the following code
>>
>>
>> * Parameters:
>> * iNode - source
>> * deep - If true, recursively clone the subtree
> under
>> the specified node; if false, clone only the node itself (and its
>> attributes, if it is an Element).
>> * return:
>> * copy of source ( xml document that was parsed)
>> */
>> private Node cloneNode(Node inNode, boolean deep){
>>
>> // clone current input node
>> Node outNode = inNode.cloneNode(deep);
>> outNode = getRenderer().getOutDocument().importNode
>> (outNode,true);
>>
>> // put back attr.
>> if ( inNode.getNodeType() == Node.ELEMENT_NODE &&
>> inNode.hasAttributes() ){
>>
>> NamedNodeMap attrMap = inNode.getAttributes();
>> Attr attr = null;
>> Attr outAttr = null ;
>>
>> for ( int i=0; i<attrMap.getLength(); i++ ){
>> attr = (Attr)attrMap.item(i);
>> // only append deleted attr.
>> if ((((Element)outNode).getAttributeNode
>> (attr.getName())) == null ){
>> outAttr = getRenderer
>> ().getOutDocument().createAttribute(attr.getName());
>> outAttr.setValue( attr.getValue
>> () );
>> ((Element)outNode).setAttributeNode
>
>> (outAttr);
>> }
>> }
>> }
>> return outNode;
>> }
>>
>> Even after that , we faced another issue ,but this time the value of the
>> attribute(CFCName) gets missed or it is empty like the one shown below
> and
>> not the whole attribute as we faced before.
>>
>>
>> The xml after the attribute value missed looks something like
>> <element XMLName="AuthNumS015" CFCName="" CFCType="TYPE_STRING"/> [Here
u
>> can see the CFCName attribute value is empty (null)]
>>
>>
>> We are clueless about this and the most disheartening thing is that we
> are
>> not able to reproduce this behavior consistently and this occurs
> probably
>> once in 5-6 months in our environment.We tried different ways with the
>> threads in our IDE to reproduce but everything ended in vain.
>>
>> The below issue reported in the following link is more or less similar
to
>> the one we are facing, but we are not able to see the whole mailing
> thread
>> conversation from the site and hence seeking xerces users who reported
> this
>> already to sort this out for us.
>>
>> Clone node issue
>>
>> Bug getOwnerElement for cloned attributes
>>
>>
>
http://mail-archives.apache.org/mod_mbox/xerces-j-users/200102.mbox/%3c3A843476.8A61469C@us.ibm.com%3e
>
>>
>>
>>
>> [Bug 937] Changed - cloneNode empties Attribute nodes
>>
>>
>
http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200103.mbox/%3C200103121958.LAA00830@nagoya-a.betaversion.org%3E
>
>>
>>
>>
>>
>> We would like to know
>>
>> 1.Is this issue a valid one?
>> 2.Is this issue got fixed ,if so, in which xerces version ?.
>> 3.Why we are not able to reproduce it consistently and what had actually
>> gone wrong.
>>
>> sorry for the detailed explanation about issue but we have no other go.
>> Your help in this regard is very much appreciated.I am ready to give
more
>> info regarding this if needed
>>
>>
>> Thanks,
>> karthik,
>>
>>
>>
>> This e-Mail may contain proprietary and confidential information and is
> sent
>>for the intended recipient(s) only. If by an addressing or transmission
>>error this mail has been misdirected to you, you are requested to delete
> this
>>mail immediately. You are also hereby notified that any use, any form of
>>reproduction, dissemination, copying, disclosure, modification,
> distribution
>>and/or publication of this e-mail message, contents or its attachment
> other
>>than by its intended recipient/s is strictly prohibited.
>>
>> Visit us at http://www.polarisFT.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>>For additional commands, e-mail: j-users-help@xerces.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
>
>
>
> This e-Mail may contain proprietary and confidential information and is
sent
>for the intended recipient(s) only. If by an addressing or transmission
>error this mail has been misdirected to you, you are requested to delete
this
>mail immediately. You are also hereby notified that any use, any form of
>reproduction, dissemination, copying, disclosure, modification,
distribution
>and/or publication of this e-mail message, contents or its attachment
other
>than by its intended recipient/s is strictly prohibited.
>
> Visit us at http://www.polarisFT.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.
Visit us at http://www.polarisFT.com
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: Xerces clone node issue in production environment (Multi threaded). Help needed ...
Posted by Jacob Kjome <ho...@visi.com>.
At the very least, you should try it with the latest version of Xerces1, which
is 1.4.4. Asking Xerces developers and users to spend precious time
investigating a strange issue in an ancient release of a project that the
Xerces site lists as a "Hibernated project" is not in good form.
You need to do your own investigation first. Try the Xerces-1.4.4. That's
the same codebase as 1.2.0, but with bug fixes. If your issue is cleared up,
then you're done. If not, then try the latest release. If your issue clears
up, then you're done. If you still have the issue after trying all that, ask
again and I'm sure you'll have plenty of takers on researching the issue.
Jake
On Thu, 1 Nov 2012 21:23:37 +0530
karthikeyan.sd@polarisFT.com wrote:
> Hi jake,
> Thanks for the reply.
> But we want to know whether it is an issue in 1.2.0.
> Only if we make sure that is an issue in xerces 1.2.0 itself , only then
> we can take steps to move to the latest version.
> Thanks,
> karthik.
>
>
>
>From: "Jacob Kjome" <ho...@visi.com>
> To: <j-...@xerces.apache.org>
> Date: 11/01/2012 09:15 PM
> Subject: Re: Xerces clone node issue in production environment (Multi
> threaded). Help needed ...
>
>
>
>
> If you are using Xerces 1.2.0, then you are using an ancient version... of
> Xerces1. That hasn't been actively developed for many years.
>
> You should upgrade and see if your issue exists in the latest release of
> Xerces2, which is version 2.11.0.
>
>
> Jake
>
> On Thu, 1 Nov 2012 18:44:27 +0530
> karthikeyan.sd@polarisFT.com wrote:
>>
>> Hi Xerces users,
>>
>> Greetings!.
>>
>> We have an issue in the xerces parsers and specifically in cloning a
>> node.We browsed in apache's site and bugzilla to find if anyone had
>> reported any issues or bugs relevant to the one we are facing in our
>> production environment.
>>
>> We were able to find info about few issue that were reported already and
>> that is more or less similar to the one we are facing now.
>>
>> Let me brief out the environment wherein we are facing this issue.
>>
>> OS: Sun Solaris 10
>> Server: Websphere 6
>> JDK: 1.4
>> Xerces version: Xerces_Version_1_2_0
>> Number of Daemon threads per JVM: 3
>>
>> Scenario:
>>
>> In our Production environment when 3 daemon threads run under a JVM.
>>
>> When 3 similar type of XML messages gets parsed at same second
>> (concurrently) under a JVM, we notice some attribute gets missed.
>>
>> Here is sample XML that gets parsed.
>>
>> <?xml version="1.0"?>
>> <!DOCTYPE InTemplate SYSTEM "feed_dd.dtd" >
>> <InTemplate>
>> <Header>
>> <DataDictionary>
>> <element XMLName="NumberOfTxn" CFCName="NO_TRANS"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="ProcessingLoc" CFCName="PR_LOC"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="ServiceType" CFCName="FCO_TYP"
>> CFCType="TYPE_STRING"/>
>> </DataDictionary>
>> </Header>
>> <Body>
>> <DataDictionary>
>> <element XMLName="TxnUID" CFCName="TRAN_NO" CFCType="TYPE_STRING"/>
>> <collection XMLName="TxnIdentification"
>> CFCType="TYPE_FIELDCOLLECTION">
>> <element XMLName="Sequence" CFCName="BSI_SEQ"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="TxnType" CFCName="PYMT_TYP"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="AcctNumber" CFCName="ACCT_NO"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="CCY" CFCName="ACCT_CCY_COD"
>> CFCType="TYPE_STRING"/>
>> </collection>
>> <element XMLName="ProcessingLocCode" CFCName="PROC_LOCA"
>> CFCType="TYPE_STRING"/>
>> <element XMLName="Status" CFCName="STA" CFCType="TYPE_STRING"/>
>> <element XMLName="AuthNumS015" CFCName="MEX_AUTH_NO"
>> CFCType="TYPE_STRING"/> ( line no 20)
>> <element XMLName="AuthNumS502" CFCName="MEX_FOLIO_NO"
>> CFCType="TYPE_STRING"/>
>>
>> <element XMLName="Reference" CFCName="MT942_REF_NO"
>> CFCType="TYPE_STRING"/>
>> </DataDictionary>
>> </Body>
>> </InTemplate>
>>
>> Intially, we faced something like the whole attribute in one of the child
>> nodes in XML itself gets missed .( like the one highlighted above in the
>> sample xml - the attribute CFCName="MEX_AUTH_NO" that got underlined gets
>> missed).The returned XML doc is with out the 'CFCName' attribute and it
>> looks something like
>>
>> <element XMLName="AuthNumS015" CFCType="TYPE_STRING"/> (line
> no 20)
>>
>>
>>
>> To fix this we placed the following code
>>
>>
>> * Parameters:
>> * iNode - source
>> * deep - If true, recursively clone the subtree
> under
>> the specified node; if false, clone only the node itself (and its
>> attributes, if it is an Element).
>> * return:
>> * copy of source ( xml document that was parsed)
>> */
>> private Node cloneNode(Node inNode, boolean deep){
>>
>> // clone current input node
>> Node outNode = inNode.cloneNode(deep);
>> outNode = getRenderer().getOutDocument().importNode
>> (outNode,true);
>>
>> // put back attr.
>> if ( inNode.getNodeType() == Node.ELEMENT_NODE &&
>> inNode.hasAttributes() ){
>>
>> NamedNodeMap attrMap = inNode.getAttributes();
>> Attr attr = null;
>> Attr outAttr = null ;
>>
>> for ( int i=0; i<attrMap.getLength(); i++ ){
>> attr = (Attr)attrMap.item(i);
>> // only append deleted attr.
>> if ((((Element)outNode).getAttributeNode
>> (attr.getName())) == null ){
>> outAttr = getRenderer
>> ().getOutDocument().createAttribute(attr.getName());
>> outAttr.setValue( attr.getValue
>> () );
>> ((Element)outNode).setAttributeNode
>
>> (outAttr);
>> }
>> }
>> }
>> return outNode;
>> }
>>
>> Even after that , we faced another issue ,but this time the value of the
>> attribute(CFCName) gets missed or it is empty like the one shown below
> and
>> not the whole attribute as we faced before.
>>
>>
>> The xml after the attribute value missed looks something like
>> <element XMLName="AuthNumS015" CFCName="" CFCType="TYPE_STRING"/> [Here u
>> can see the CFCName attribute value is empty (null)]
>>
>>
>> We are clueless about this and the most disheartening thing is that we
> are
>> not able to reproduce this behavior consistently and this occurs
> probably
>> once in 5-6 months in our environment.We tried different ways with the
>> threads in our IDE to reproduce but everything ended in vain.
>>
>> The below issue reported in the following link is more or less similar to
>> the one we are facing, but we are not able to see the whole mailing
> thread
>> conversation from the site and hence seeking xerces users who reported
> this
>> already to sort this out for us.
>>
>> Clone node issue
>>
>> Bug getOwnerElement for cloned attributes
>>
>>
> http://mail-archives.apache.org/mod_mbox/xerces-j-users/200102.mbox/%3c3A843476.8A61469C@us.ibm.com%3e
>
>>
>>
>>
>> [Bug 937] Changed - cloneNode empties Attribute nodes
>>
>>
> http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200103.mbox/%3C200103121958.LAA00830@nagoya-a.betaversion.org%3E
>
>>
>>
>>
>>
>> We would like to know
>>
>> 1.Is this issue a valid one?
>> 2.Is this issue got fixed ,if so, in which xerces version ?.
>> 3.Why we are not able to reproduce it consistently and what had actually
>> gone wrong.
>>
>> sorry for the detailed explanation about issue but we have no other go.
>> Your help in this regard is very much appreciated.I am ready to give more
>> info regarding this if needed
>>
>>
>> Thanks,
>> karthik,
>>
>>
>>
>> This e-Mail may contain proprietary and confidential information and is
> sent
>>for the intended recipient(s) only. If by an addressing or transmission
>>error this mail has been misdirected to you, you are requested to delete
> this
>>mail immediately. You are also hereby notified that any use, any form of
>>reproduction, dissemination, copying, disclosure, modification,
> distribution
>>and/or publication of this e-mail message, contents or its attachment
> other
>>than by its intended recipient/s is strictly prohibited.
>>
>> Visit us at http://www.polarisFT.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>>For additional commands, e-mail: j-users-help@xerces.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
>
>
>
> This e-Mail may contain proprietary and confidential information and is sent
>for the intended recipient(s) only. If by an addressing or transmission
>error this mail has been misdirected to you, you are requested to delete this
>mail immediately. You are also hereby notified that any use, any form of
>reproduction, dissemination, copying, disclosure, modification, distribution
>and/or publication of this e-mail message, contents or its attachment other
>than by its intended recipient/s is strictly prohibited.
>
> Visit us at http://www.polarisFT.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: Xerces clone node issue in production environment (Multi threaded). Help
needed ...
Posted by ka...@polarisFT.com.
Hi jake,
Thanks for the reply.
But we want to know whether it is an issue in 1.2.0.
Only if we make sure that is an issue in xerces 1.2.0 itself , only then
we can take steps to move to the latest version.
Thanks,
karthik.
From: "Jacob Kjome" <ho...@visi.com>
To: <j-...@xerces.apache.org>
Date: 11/01/2012 09:15 PM
Subject: Re: Xerces clone node issue in production environment (Multi
threaded). Help needed ...
If you are using Xerces 1.2.0, then you are using an ancient version... of
Xerces1. That hasn't been actively developed for many years.
You should upgrade and see if your issue exists in the latest release of
Xerces2, which is version 2.11.0.
Jake
On Thu, 1 Nov 2012 18:44:27 +0530
karthikeyan.sd@polarisFT.com wrote:
>
> Hi Xerces users,
>
> Greetings!.
>
> We have an issue in the xerces parsers and specifically in cloning a
> node.We browsed in apache's site and bugzilla to find if anyone had
> reported any issues or bugs relevant to the one we are facing in our
> production environment.
>
> We were able to find info about few issue that were reported already and
> that is more or less similar to the one we are facing now.
>
> Let me brief out the environment wherein we are facing this issue.
>
> OS: Sun Solaris 10
> Server: Websphere 6
> JDK: 1.4
> Xerces version: Xerces_Version_1_2_0
> Number of Daemon threads per JVM: 3
>
> Scenario:
>
> In our Production environment when 3 daemon threads run under a JVM.
>
> When 3 similar type of XML messages gets parsed at same second
> (concurrently) under a JVM, we notice some attribute gets missed.
>
> Here is sample XML that gets parsed.
>
> <?xml version="1.0"?>
> <!DOCTYPE InTemplate SYSTEM "feed_dd.dtd" >
> <InTemplate>
> <Header>
> <DataDictionary>
> <element XMLName="NumberOfTxn" CFCName="NO_TRANS"
> CFCType="TYPE_STRING"/>
> <element XMLName="ProcessingLoc" CFCName="PR_LOC"
> CFCType="TYPE_STRING"/>
> <element XMLName="ServiceType" CFCName="FCO_TYP"
> CFCType="TYPE_STRING"/>
> </DataDictionary>
> </Header>
> <Body>
> <DataDictionary>
> <element XMLName="TxnUID" CFCName="TRAN_NO" CFCType="TYPE_STRING"/>
> <collection XMLName="TxnIdentification"
> CFCType="TYPE_FIELDCOLLECTION">
> <element XMLName="Sequence" CFCName="BSI_SEQ"
> CFCType="TYPE_STRING"/>
> <element XMLName="TxnType" CFCName="PYMT_TYP"
> CFCType="TYPE_STRING"/>
> <element XMLName="AcctNumber" CFCName="ACCT_NO"
> CFCType="TYPE_STRING"/>
> <element XMLName="CCY" CFCName="ACCT_CCY_COD"
> CFCType="TYPE_STRING"/>
> </collection>
> <element XMLName="ProcessingLocCode" CFCName="PROC_LOCA"
> CFCType="TYPE_STRING"/>
> <element XMLName="Status" CFCName="STA" CFCType="TYPE_STRING"/>
> <element XMLName="AuthNumS015" CFCName="MEX_AUTH_NO"
> CFCType="TYPE_STRING"/> ( line no 20)
> <element XMLName="AuthNumS502" CFCName="MEX_FOLIO_NO"
> CFCType="TYPE_STRING"/>
>
> <element XMLName="Reference" CFCName="MT942_REF_NO"
> CFCType="TYPE_STRING"/>
> </DataDictionary>
> </Body>
> </InTemplate>
>
> Intially, we faced something like the whole attribute in one of the child
> nodes in XML itself gets missed .( like the one highlighted above in the
> sample xml - the attribute CFCName="MEX_AUTH_NO" that got underlined gets
> missed).The returned XML doc is with out the 'CFCName' attribute and it
> looks something like
>
> <element XMLName="AuthNumS015" CFCType="TYPE_STRING"/> (line
no 20)
>
>
>
> To fix this we placed the following code
>
>
> * Parameters:
> * iNode - source
> * deep - If true, recursively clone the subtree
under
> the specified node; if false, clone only the node itself (and its
> attributes, if it is an Element).
> * return:
> * copy of source ( xml document that was parsed)
> */
> private Node cloneNode(Node inNode, boolean deep){
>
> // clone current input node
> Node outNode = inNode.cloneNode(deep);
> outNode = getRenderer().getOutDocument().importNode
> (outNode,true);
>
> // put back attr.
> if ( inNode.getNodeType() == Node.ELEMENT_NODE &&
> inNode.hasAttributes() ){
>
> NamedNodeMap attrMap = inNode.getAttributes();
> Attr attr = null;
> Attr outAttr = null ;
>
> for ( int i=0; i<attrMap.getLength(); i++ ){
> attr = (Attr)attrMap.item(i);
> // only append deleted attr.
> if ((((Element)outNode).getAttributeNode
> (attr.getName())) == null ){
> outAttr = getRenderer
> ().getOutDocument().createAttribute(attr.getName());
> outAttr.setValue( attr.getValue
> () );
> ((Element)outNode).setAttributeNode
> (outAttr);
> }
> }
> }
> return outNode;
> }
>
> Even after that , we faced another issue ,but this time the value of the
> attribute(CFCName) gets missed or it is empty like the one shown below
and
> not the whole attribute as we faced before.
>
>
> The xml after the attribute value missed looks something like
> <element XMLName="AuthNumS015" CFCName="" CFCType="TYPE_STRING"/> [Here u
> can see the CFCName attribute value is empty (null)]
>
>
> We are clueless about this and the most disheartening thing is that we
are
> not able to reproduce this behavior consistently and this occurs
probably
> once in 5-6 months in our environment.We tried different ways with the
> threads in our IDE to reproduce but everything ended in vain.
>
> The below issue reported in the following link is more or less similar to
> the one we are facing, but we are not able to see the whole mailing
thread
> conversation from the site and hence seeking xerces users who reported
this
> already to sort this out for us.
>
> Clone node issue
>
> Bug getOwnerElement for cloned attributes
>
>
http://mail-archives.apache.org/mod_mbox/xerces-j-users/200102.mbox/%3c3A843476.8A61469C@us.ibm.com%3e
>
>
>
> [Bug 937] Changed - cloneNode empties Attribute nodes
>
>
http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200103.mbox/%3C200103121958.LAA00830@nagoya-a.betaversion.org%3E
>
>
>
>
> We would like to know
>
> 1.Is this issue a valid one?
> 2.Is this issue got fixed ,if so, in which xerces version ?.
> 3.Why we are not able to reproduce it consistently and what had actually
> gone wrong.
>
> sorry for the detailed explanation about issue but we have no other go.
> Your help in this regard is very much appreciated.I am ready to give more
> info regarding this if needed
>
>
> Thanks,
> karthik,
>
>
>
> This e-Mail may contain proprietary and confidential information and is
sent
>for the intended recipient(s) only. If by an addressing or transmission
>error this mail has been misdirected to you, you are requested to delete
this
>mail immediately. You are also hereby notified that any use, any form of
>reproduction, dissemination, copying, disclosure, modification,
distribution
>and/or publication of this e-mail message, contents or its attachment
other
>than by its intended recipient/s is strictly prohibited.
>
> Visit us at http://www.polarisFT.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.
Visit us at http://www.polarisFT.com
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: Xerces clone node issue in production environment (Multi threaded). Help needed ...
Posted by Jacob Kjome <ho...@visi.com>.
If you are using Xerces 1.2.0, then you are using an ancient version... of
Xerces1. That hasn't been actively developed for many years.
You should upgrade and see if your issue exists in the latest release of
Xerces2, which is version 2.11.0.
Jake
On Thu, 1 Nov 2012 18:44:27 +0530
karthikeyan.sd@polarisFT.com wrote:
>
> Hi Xerces users,
>
> Greetings!.
>
> We have an issue in the xerces parsers and specifically in cloning a
> node.We browsed in apache's site and bugzilla to find if anyone had
> reported any issues or bugs relevant to the one we are facing in our
> production environment.
>
> We were able to find info about few issue that were reported already and
> that is more or less similar to the one we are facing now.
>
> Let me brief out the environment wherein we are facing this issue.
>
> OS: Sun Solaris 10
> Server: Websphere 6
> JDK: 1.4
> Xerces version: Xerces_Version_1_2_0
> Number of Daemon threads per JVM: 3
>
> Scenario:
>
> In our Production environment when 3 daemon threads run under a JVM.
>
> When 3 similar type of XML messages gets parsed at same second
> (concurrently) under a JVM, we notice some attribute gets missed.
>
> Here is sample XML that gets parsed.
>
> <?xml version="1.0"?>
> <!DOCTYPE InTemplate SYSTEM "feed_dd.dtd" >
> <InTemplate>
> <Header>
> <DataDictionary>
> <element XMLName="NumberOfTxn" CFCName="NO_TRANS"
> CFCType="TYPE_STRING"/>
> <element XMLName="ProcessingLoc" CFCName="PR_LOC"
> CFCType="TYPE_STRING"/>
> <element XMLName="ServiceType" CFCName="FCO_TYP"
> CFCType="TYPE_STRING"/>
> </DataDictionary>
> </Header>
> <Body>
> <DataDictionary>
> <element XMLName="TxnUID" CFCName="TRAN_NO" CFCType="TYPE_STRING"/>
> <collection XMLName="TxnIdentification"
> CFCType="TYPE_FIELDCOLLECTION">
> <element XMLName="Sequence" CFCName="BSI_SEQ"
> CFCType="TYPE_STRING"/>
> <element XMLName="TxnType" CFCName="PYMT_TYP"
> CFCType="TYPE_STRING"/>
> <element XMLName="AcctNumber" CFCName="ACCT_NO"
> CFCType="TYPE_STRING"/>
> <element XMLName="CCY" CFCName="ACCT_CCY_COD"
> CFCType="TYPE_STRING"/>
> </collection>
> <element XMLName="ProcessingLocCode" CFCName="PROC_LOCA"
> CFCType="TYPE_STRING"/>
> <element XMLName="Status" CFCName="STA" CFCType="TYPE_STRING"/>
> <element XMLName="AuthNumS015" CFCName="MEX_AUTH_NO"
> CFCType="TYPE_STRING"/> ( line no 20)
> <element XMLName="AuthNumS502" CFCName="MEX_FOLIO_NO"
> CFCType="TYPE_STRING"/>
>
> <element XMLName="Reference" CFCName="MT942_REF_NO"
> CFCType="TYPE_STRING"/>
> </DataDictionary>
> </Body>
> </InTemplate>
>
> Intially, we faced something like the whole attribute in one of the child
> nodes in XML itself gets missed .( like the one highlighted above in the
> sample xml - the attribute CFCName="MEX_AUTH_NO" that got underlined gets
> missed).The returned XML doc is with out the 'CFCName' attribute and it
> looks something like
>
> <element XMLName="AuthNumS015" CFCType="TYPE_STRING"/> (line no 20)
>
>
>
> To fix this we placed the following code
>
>
> * Parameters:
> * iNode - source
> * deep - If true, recursively clone the subtree under
> the specified node; if false, clone only the node itself (and its
> attributes, if it is an Element).
> * return:
> * copy of source ( xml document that was parsed)
> */
> private Node cloneNode(Node inNode, boolean deep){
>
> // clone current input node
> Node outNode = inNode.cloneNode(deep);
> outNode = getRenderer().getOutDocument().importNode
> (outNode,true);
>
> // put back attr.
> if ( inNode.getNodeType() == Node.ELEMENT_NODE &&
> inNode.hasAttributes() ){
>
> NamedNodeMap attrMap = inNode.getAttributes();
> Attr attr = null;
> Attr outAttr = null ;
>
> for ( int i=0; i<attrMap.getLength(); i++ ){
> attr = (Attr)attrMap.item(i);
> // only append deleted attr.
> if ((((Element)outNode).getAttributeNode
> (attr.getName())) == null ){
> outAttr = getRenderer
> ().getOutDocument().createAttribute(attr.getName());
> outAttr.setValue( attr.getValue
> () );
> ((Element)outNode).setAttributeNode
> (outAttr);
> }
> }
> }
> return outNode;
> }
>
> Even after that , we faced another issue ,but this time the value of the
> attribute(CFCName) gets missed or it is empty like the one shown below and
> not the whole attribute as we faced before.
>
>
> The xml after the attribute value missed looks something like
> <element XMLName="AuthNumS015" CFCName="" CFCType="TYPE_STRING"/> [Here u
> can see the CFCName attribute value is empty (null)]
>
>
> We are clueless about this and the most disheartening thing is that we are
> not able to reproduce this behavior consistently and this occurs probably
> once in 5-6 months in our environment.We tried different ways with the
> threads in our IDE to reproduce but everything ended in vain.
>
> The below issue reported in the following link is more or less similar to
> the one we are facing, but we are not able to see the whole mailing thread
> conversation from the site and hence seeking xerces users who reported this
> already to sort this out for us.
>
> Clone node issue
>
> Bug getOwnerElement for cloned attributes
>
> http://mail-archives.apache.org/mod_mbox/xerces-j-users/200102.mbox/%3c3A843476.8A61469C@us.ibm.com%3e
>
>
>
> [Bug 937] Changed - cloneNode empties Attribute nodes
>
> http://mail-archives.apache.org/mod_mbox/xerces-j-dev/200103.mbox/%3C200103121958.LAA00830@nagoya-a.betaversion.org%3E
>
>
>
>
> We would like to know
>
> 1.Is this issue a valid one?
> 2.Is this issue got fixed ,if so, in which xerces version ?.
> 3.Why we are not able to reproduce it consistently and what had actually
> gone wrong.
>
> sorry for the detailed explanation about issue but we have no other go.
> Your help in this regard is very much appreciated.I am ready to give more
> info regarding this if needed
>
>
> Thanks,
> karthik,
>
>
>
> This e-Mail may contain proprietary and confidential information and is sent
>for the intended recipient(s) only. If by an addressing or transmission
>error this mail has been misdirected to you, you are requested to delete this
>mail immediately. You are also hereby notified that any use, any form of
>reproduction, dissemination, copying, disclosure, modification, distribution
>and/or publication of this e-mail message, contents or its attachment other
>than by its intended recipient/s is strictly prohibited.
>
> Visit us at http://www.polarisFT.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
>For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org