In testing the CDATA issues (another stream) we have come across a more
serious problem.
We have found that synapse is loosing parts of files that have imbedded CR
and spaces. These are fixed format files. The script at the bottom is used
to reproduce the problem. Logging the property extracted shows the loss of
data. As the files are not small (96KB) and are full of spaces it is hard to
demonstrate or shows the full logs. Here is the start and end of the data
file only; it has 100's of records in between. The data has a "*" at the
beginning and at the end.
<Data Start>
*000000141973601M95202YBA000000014197 341316840
010402030000010
000190000000000000000000000000000000000000000000000000000000000
006770000000000000000000000000000000000000000000000020000000000
* <Data END>
Looking at the log the last part of the file is gone when Property DATA is
logged.
-----------------------------------------------------------------------------
2009-05-12 15:23:50,825 [-] [vfs-Worker-5] INFO LogMediator DATA =
*000000141973601M95202YBA000000014197 341316840
010402030000010
000190000000000000000000000000000000000000000000000000000000000
2009-05-12 15:23:54,387 [-] [vfs-Worker-5] DEBUG LogMediator End : Log
mediator
Looking at the XML created we get:
----------------------------------
<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";><soapenv:Body><data>*000000141973601M95202YBA000000014197
000190000000000000000000000000000000000000000000000000000000000</data></soapenv:Body></soapenv:Envelope>
Clearly the last part of the file has gone. I thought the error could be in
the Javascript but it appears the data is already lost at the property when
extracted from the VFS payload. Any suggestions on whats happening here ?
Could this be an issue with the XPATH property setting code?
Version of Synapse is one of recent Stable Snapshots.
Thanks
Kim
<definitions xmlns="http://ws.apache.org/ns/synapse";>
<proxy name="FileCheckProxyPRS" transports="vfs">
<parameter
name="transport.vfs.FileURI">file:///C:/work/sftpagent/testdata/prs/ndc</parameter>
<parameter name="transport.vfs.ContentType">text/plain</parameter>
<parameter name="transport.vfs.FileNamePattern">.*req</parameter>
<parameter name="transport.PollInterval">15</parameter>
<parameter
name="transport.vfs.MoveAfterProcess">file:///C:/work/sftpagent/testdata/prs/ndc/archive</parameter>
<parameter name="transport.vfs.ActionAfterProcess">MOVE</parameter>
<target inSequence="inSequencePRS"/>
</proxy>
<sequence name="inSequencePRS">
<log level="custom">
<property name="MSG" value=">>>>>>> IN"/>
</log>
<log level="custom">
<property xmlns:axis2ns="http://ws.apache.org/commons/ns/payload";
name="DATA" expression="//axis2ns:text"/>
</log>
<property xmlns:axis2ns="http://ws.apache.org/commons/ns/payload";
name="claimData" expression="//axis2ns:text"/>
<log level="full"/>
<script language="js"><![CDATA[ var claimData =
mc.getProperty("claimData").toString();
mc.setPayloadXML(<data>{claimData}</data>);
]]></script>
<send>
<endpoint>
<address uri="vfs:file:///C:/work/sftpagent/testdata/prs"/>
</endpoint>
</send>
</sequence>
</definitions>
--
View this message in context:
http://www.nabble.com/Data-Loss-Issue-VFS-tp23496565p23496565.html
Sent from the Synapse - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
