<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 19:56:19 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[CONTROLLER-1737] Current transaction in state READY leads to RequestTimeoutException (120s) after make-leader-local</title>
                <link>https://jira.opendaylight.org/browse/CONTROLLER-1737</link>
                <project id="10113" key="CONTROLLER">controller</project>
                    <description>&lt;p&gt;The Robot symptom is basically the same as in &lt;a href=&quot;https://jira.opendaylight.org/browse/CONTROLLER-1707&quot; title=&quot;Client not reconnecting successfully after leader movement&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CONTROLLER-1707&quot;&gt;&lt;del&gt;CONTROLLER-1707&lt;/del&gt;&lt;/a&gt;.&lt;br/&gt;
There is test which started failing &lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; quite reliably, the difference from original &lt;a href=&quot;https://jira.opendaylight.org/browse/CONTROLLER-1707&quot; title=&quot;Client not reconnecting successfully after leader movement&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CONTROLLER-1707&quot;&gt;&lt;del&gt;CONTROLLER-1707&lt;/del&gt;&lt;/a&gt; description is that there is a transaction writer on each member and there is a data tree change listener on the old leader member. Once again, the only failing writer is on the old leader member:&lt;/p&gt;

&lt;p&gt;{&quot;errors&quot;:{&quot;error&quot;:[{&quot;error-type&quot;:&quot;application&quot;,&quot;error-tag&quot;:&quot;operation-failed&quot;,&quot;error-message&quot;:&quot;Submit failed&quot;,&quot;error-info&quot;:&quot;TransactionCommitFailedException&lt;/p&gt;
{message=canCommit encountered an unexpected failure, errorList=[RpcError [message=canCommit encountered an unexpected failure, severity=ERROR, errorType=APPLICATION, tag=operation-failed, applicationTag=null, info=null, cause=org.opendaylight.controller.cluster.access.client.RequestTimeoutException: Timed out after 120.023957045seconds]]}
&lt;p&gt;\n\tat org.opendaylight.controller.md.sal.dom.broker.impl.TransactionCommitFailedExceptionMapper.newWithCause(TransactionCommitFailedExceptionMapper.java:37)\n\tat&lt;br/&gt;
...&lt;/p&gt;

&lt;p&gt;Contrary to &lt;a href=&quot;https://jira.opendaylight.org/browse/CONTROLLER-1707&quot; title=&quot;Client not reconnecting successfully after leader movement&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CONTROLLER-1707&quot;&gt;&lt;del&gt;CONTROLLER-1707&lt;/del&gt;&lt;/a&gt;, &quot;No transactions enqueued while attempting to start canCommit&quot; is not seen on the new leader.&lt;br/&gt;
Instead, the following is seen in karaf.log &lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; of the writer (member-1, old leader and listener). Not sure which log message is the critical one (if any)&lt;/p&gt;

&lt;p&gt;Very many &quot;rejecting request&quot; messages right after &quot;Received LeaderStateChanged&quot;:&lt;/p&gt;

&lt;p&gt;2017-07-02 15:57:40,058 | INFO  | rd-dispatcher-32 | Shard                            | 192 - org.opendaylight.controller.sal-clustering-commons - 1.5.1.SNAPSHOT | member-1-shard-default-config: not currently leader, rejecting request Envelope{sessionId=0, txSequence=3115, message=ModifyTransactionRequest{target=member-2-datastore-config-fe-0-chn-2-txn-4416-0, sequence=0, replyTo=Actor&lt;span class=&quot;error&quot;&gt;&amp;#91;akka.tcp://opendaylight-cluster-data@10.29.15.2:2550/user/$a#-603757263&amp;#93;&lt;/span&gt;, modifications=1, protocol=READY}}. isLeader: true, isLeaderActive: false,isLeadershipTransferInProgress: true.&lt;/p&gt;

&lt;p&gt;The NotLeaderException has been received at 15:57:41,474. The new connection has been established at 15:57:46,839. The next reconnect (without a visible reason) has been initiated at 15:59:16,939 and finished at 15:59:16,945. Another one initiated at 15:59:46,958 and finished at 15:59:46,962. Finally request timeout happened:&lt;/p&gt;

&lt;p&gt;2017-07-02 15:59:51,878 | WARN  | lt-dispatcher-43 | ConcurrentDOMDataBroker          | 199 - org.opendaylight.controller.sal-distributed-datastore - 1.5.1.SNAPSHOT | Tx: DOM-CHAIN-1-5382 Error during phase CAN_COMMIT, starting Abort&lt;br/&gt;
org.opendaylight.controller.cluster.access.client.RequestTimeoutException: Timed out after 120.023957045seconds&lt;br/&gt;
	at org.opendaylight.controller.cluster.access.client.AbstractClientConnection.lockedCheckTimeout(AbstractClientConnection.java:372)&lt;span class=&quot;error&quot;&gt;&amp;#91;197:org.opendaylight.controller.cds-access-client:1.1.1.SNAPSHOT&amp;#93;&lt;/span&gt;&lt;br/&gt;
...&lt;/p&gt;

&lt;p&gt;In the whole segment, there were multiple (arguably harmless) snapshot persist events.&lt;/p&gt;

&lt;p&gt;On the new leader &lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt;, there is only one suspicious message:&lt;/p&gt;

&lt;p&gt;2017-07-02 15:58:06,430 | WARN  | rd-dispatcher-31 | ShardDataTree                    | 199 - org.opendaylight.controller.sal-distributed-datastore - 1.5.1.SNAPSHOT | member-2-shard-default-config: Current transaction member-1-datastore-config-fe-0-chn-2-txn-5382-0 has timed out after 15000 ms in state READY&lt;/p&gt;

&lt;p&gt;Update:&lt;br/&gt;
While trying to replicate on Sandbox, two &lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt; tests &lt;span class=&quot;error&quot;&gt;&amp;#91;5&amp;#93;&lt;/span&gt; have failed. In the latter test, the failing writer was on the old leader (without listener listener), but in the former one, the failing writer was actually on the member which stayed follower (also without listener).&lt;br/&gt;
In both cases, the leader was member-2. Karaf log &lt;span class=&quot;error&quot;&gt;&amp;#91;6&amp;#93;&lt;/span&gt; is huge, but I have confirmed in both tests there was a &quot;Current transaction ... has timed out after 15000 ms in state READY&quot; message during the time the test was waiting for writer response:&lt;/p&gt;

&lt;p&gt;2017-07-03 11:29:50,834 | WARN  | rd-dispatcher-44 | ShardDataTree                    | 199 - org.opendaylight.controller.sal-distributed-datastore - 1.5.1.SNAPSHOT | member-2-shard-default-config: Current transaction member-1-datastore-config-fe-0-chn-2-txn-11757-0 has timed out after 15000 ms in state READY&lt;/p&gt;


&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;1&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/769/log.html.gz#s1-s36-t1-k2-k12&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/769/log.html.gz#s1-s36-t1-k2-k12&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;2&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/769/odl1_karaf.log.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/769/odl1_karaf.log.gz&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;3&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/769/odl2_karaf.log.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/769/odl2_karaf.log.gz&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;4&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/sandbox/jenkins091/controller-csit-3node-clustering-ls-only-carbon/3/log.html.gz#s1-s2-t1-k2-k12&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/sandbox/jenkins091/controller-csit-3node-clustering-ls-only-carbon/3/log.html.gz#s1-s2-t1-k2-k12&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;5&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/sandbox/jenkins091/controller-csit-3node-clustering-ls-only-carbon/3/log.html.gz#s1-s2-t3-k2-k12&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/sandbox/jenkins091/controller-csit-3node-clustering-ls-only-carbon/3/log.html.gz#s1-s2-t3-k2-k12&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;6&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/sandbox/jenkins091/controller-csit-3node-clustering-ls-only-carbon/3/odl2_karaf.log.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/sandbox/jenkins091/controller-csit-3node-clustering-ls-only-carbon/3/odl2_karaf.log.gz&lt;/a&gt;&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="26291">CONTROLLER-1737</key>
            <summary>Current transaction in state READY leads to RequestTimeoutException (120s) after make-leader-local</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                                <status id="5" iconUrl="https://jira.opendaylight.org/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10003">Cannot Reproduce</resolution>
                                        <assignee username="oleksii.mozghovyi">Oleksii Mozghovyi</assignee>
                                    <reporter username="vrpolak">Vratko Polak</reporter>
                        <labels>
                            <label>pt</label>
                    </labels>
                <created>Mon, 3 Jul 2017 14:22:12 +0000</created>
                <updated>Tue, 25 Jul 2023 08:24:44 +0000</updated>
                            <resolved>Fri, 2 Jul 2021 12:54:37 +0000</resolved>
                                                    <fixVersion>4.0.0</fixVersion>
                                    <component>clustering</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>4</watches>
                                                                                                                <comments>
                            <comment id="52499" author="vrpolak" created="Mon, 3 Jul 2017 14:59:19 +0000"  >&lt;p&gt;&amp;gt; In the latter test, the failing writer was on the old leader&lt;br/&gt;
&amp;gt; (without listener listener), but in the former one,&lt;br/&gt;
&amp;gt; the failing writer was actually on the member which stayed follower&lt;/p&gt;

&lt;p&gt;Releng run from today has also seen the former &lt;span class=&quot;error&quot;&gt;&amp;#91;7&amp;#93;&lt;/span&gt; and the latter &lt;span class=&quot;error&quot;&gt;&amp;#91;8&amp;#93;&lt;/span&gt; type of failure.&lt;/p&gt;

&lt;p&gt;&amp;gt; Current transaction ... in state READY&lt;/p&gt;

&lt;p&gt;This type of message is quite frequent in the logs (together with state COMMIT_PENDING). I think this is expected in isolation scenarios, just not for make-leader-local scenarios.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;7&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/770/log.html.gz#s1-s36-t1-k2-k12&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/770/log.html.gz#s1-s36-t1-k2-k12&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;8&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/770/log.html.gz#s1-s36-t5-k2-k12&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-clustering-only-carbon/770/log.html.gz#s1-s36-t5-k2-k12&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="52500" author="rovarga" created="Mon, 3 Jul 2017 16:42:57 +0000"  >&lt;p&gt;Unfortunately there is quite a bit of difference between timeouts in READY and COMMIT_PENDING.&lt;/p&gt;

&lt;p&gt;In case of READY, we have seen the transaction as sealed, but have not gotten the appropriate commit request. This happens with reconnects and remote leader, if the frontend takes too long to actually forward the commit request for whatever reason.&lt;/p&gt;

&lt;p&gt;In case of COMMIT_PENDING, should be a pure-backend transient, generated when achieving consensus in final stage of committing is taking too long.&lt;/p&gt;

&lt;p&gt;Let&apos;s deal with &lt;a href=&quot;https://jira.opendaylight.org/browse/CONTROLLER-1707&quot; title=&quot;Client not reconnecting successfully after leader movement&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CONTROLLER-1707&quot;&gt;&lt;del&gt;CONTROLLER-1707&lt;/del&gt;&lt;/a&gt; first and see its effects on this one.&lt;/p&gt;</comment>
                            <comment id="52501" author="vrpolak" created="Mon, 17 Jul 2017 11:52:33 +0000"  >&lt;p&gt;After SR1 and branch unfreeze (&lt;a href=&quot;https://jira.opendaylight.org/browse/CONTROLLER-1707&quot; title=&quot;Client not reconnecting successfully after leader movement&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CONTROLLER-1707&quot;&gt;&lt;del&gt;CONTROLLER-1707&lt;/del&gt;&lt;/a&gt; not present), this has happened, albeit in a longevity job after 13 hours.&lt;/p&gt;

&lt;p&gt;Robot failure: &lt;span class=&quot;error&quot;&gt;&amp;#91;9&amp;#93;&lt;/span&gt;, karaf.log: &lt;span class=&quot;error&quot;&gt;&amp;#91;10&amp;#93;&lt;/span&gt;.&lt;/p&gt;

&lt;p&gt;2017-07-16 12:47:57,411 | WARN  | rd-dispatcher-36 | ShardDataTree                    | 199 - org.opendaylight.controller.sal-distributed-datastore - 1.5.2.SNAPSHOT | member-1-shard-default-config: Current transaction member-2-datastore-config-fe-0-chn-345-txn-6634-0 has timed out after 15000 ms in state READY&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;9&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-ddb-expl-lead-movement-longevity-only-carbon/15/log.html.gz#s1-s2-t1-k2-k1-k1-k1-k1-k1-k1-k2-k1-k1-k2-k10&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-ddb-expl-lead-movement-longevity-only-carbon/15/log.html.gz#s1-s2-t1-k2-k1-k1-k1-k1-k1-k1-k2-k1-k1-k2-k10&lt;/a&gt;&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;10&amp;#93;&lt;/span&gt; &lt;a href=&quot;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-ddb-expl-lead-movement-longevity-only-carbon/15/odl1_karaf.log.gz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/jenkins092/controller-csit-3node-ddb-expl-lead-movement-longevity-only-carbon/15/odl1_karaf.log.gz&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="52502" author="rovarga" created="Mon, 17 Jul 2017 14:36:22 +0000"  >&lt;p&gt;&lt;a href=&quot;https://git.opendaylight.org/gerrit/60490&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/60490&lt;/a&gt; to give some more cushion during reconnect.&lt;/p&gt;</comment>
                            <comment id="52503" author="vrpolak" created="Thu, 20 Jul 2017 10:50:25 +0000"  >&lt;p&gt;&amp;gt; &lt;a href=&quot;https://git.opendaylight.org/gerrit/60490&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/60490&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;That worked on sandbox and is now merged.&lt;/p&gt;</comment>
                            <comment id="63021" author="jluhrsen" created="Mon, 21 May 2018 23:59:58 +0000"  >&lt;p&gt;I think we still have these, or maybe they have just come back and I&apos;m now noticing&lt;br/&gt;
them. example:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/controller-csit-3node-clustering-all-fluorine/91/robot-plugin/log.html.gz#s1-s16-t7-k8-k1-k1-k1&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/controller-csit-3node-clustering-all-fluorine/91/robot-plugin/log.html.gz#s1-s16-t7-k8-k1-k1-k1&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="63047" author="vrpolak" created="Tue, 22 May 2018 12:07:47 +0000"  >&lt;p&gt;&amp;gt; #s1-s16-t7-k8-k1-k1-k1&lt;/p&gt;

&lt;p&gt;That is Ddb-Sanity-Prefix-Based suite, which was never entirely stable.&lt;br/&gt;
The test Produce_Transactions_One_Node_Leader is failing on every run and stream I look at.&lt;/p&gt;

&lt;p&gt;I mean, the failure means there IS a bug, ending with RequestTimeoutException.&lt;br/&gt;
But it does not happen in the test scenario described here, and probably does not have transactions in READY state (I have not seen debug logs).&lt;/p&gt;

&lt;p&gt;I think it is a different bug, not reported so far just because none of the official tests scenarios hit it.&lt;/p&gt;</comment>
                            <comment id="69042" author="JIRAUSER12941" created="Fri, 9 Apr 2021 16:42:46 +0000"  >&lt;p&gt;So, currently, the ddb-sanity-module-based suite is stable; I don&apos;t see any failures from that one on the master branch (job: controller-csit-3node-clustering-tell-all-phosphorus). The issues related to prefix-based are still there(I&apos;ve checked on sandbox), but was commented out in 2018. If for some reason we want to bring prefix-based, then it should be a separate issue.&lt;/p&gt;</comment>
                            <comment id="69348" author="rovarga" created="Fri, 2 Jul 2021 12:54:37 +0000"  >&lt;p&gt;We have removed prefix-based shards in version 4.0.0, closing as cannot reproduce.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10000">
                    <name>Blocks</name>
                                                                <inwardlinks description="is blocked by">
                                        <issuelink>
            <issuekey id="26261">CONTROLLER-1707</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10208" key="com.atlassian.jira.plugin.system.customfieldtypes:textfield">
                        <customfieldname>External issue ID</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>8792</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10201" key="com.atlassian.jira.plugin.system.customfieldtypes:url">
                        <customfieldname>External issue URL</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[https://bugs.opendaylight.org/show_bug.cgi?id=8792]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10206" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Issue Type</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10300"><![CDATA[Bug]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i02sf3:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>