<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:39:34 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>Whamcloud Community JIRA</title>
    <link>https://jira.whamcloud.com</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.4.14</version>
        <build-number>940014</build-number>
        <build-date>05-12-2023</build-date>
    </build-info>


<item>
            <title>[LU-4090] OST unavailable due to possible deadlock</title>
                <link>https://jira.whamcloud.com/browse/LU-4090</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;One OST became unavailable ane kept on dumping stack traces until its service is taken over by another OSS. This issue occured a couple of time on different servers.&lt;/p&gt;

&lt;p&gt;After some inverstigation, we found that a lot of service theads hang at different places. Here is a list of where they stuck.&lt;/p&gt;

&lt;p&gt;ll_ost_01:10226,-ll_ost_07:10232,-ll_ost_09:10234,-ll_ost_11:10236,-ll_ost_13:10238,-ll_ost_15:10240,-ll_ost_18:10243&lt;br/&gt;
filter_lvbo_init&lt;br/&gt;
--filter_fid2dentry&lt;br/&gt;
----filter_parent_lock&lt;br/&gt;
------filter_lock_dentry&lt;br/&gt;
-------&lt;del&gt;LOCK_INODE_MUTEX(dparent&lt;/del&gt;&amp;gt;d_inode);&lt;/p&gt;

&lt;p&gt;ll_ost_06:10231,-ll_ost_16:10241,-ll_ost_484,-ll_ost_io_129,-ll_ost_io_123,-ll_ost_383&lt;br/&gt;
fsfilt_ext3_start&lt;br/&gt;
--ext3_journal_start&lt;br/&gt;
----journal_start&lt;br/&gt;
------start_this_handle&lt;br/&gt;
----------__jbd2_log_wait_for_space&lt;br/&gt;
-----------&lt;del&gt;mutex_lock(&amp;amp;journal&lt;/del&gt;&amp;gt;j_checkpoint_mutex);&lt;/p&gt;

&lt;p&gt;ll_ost_17:10242&lt;br/&gt;
filter_lvbo_init&lt;br/&gt;
--filter_fid2dentry&lt;br/&gt;
----filter_parent_lock&lt;br/&gt;
----lookup_one_len&lt;br/&gt;
------__lookup_hash&lt;br/&gt;
-------&lt;del&gt;inode&lt;/del&gt;&amp;gt;i_op-&amp;gt;lookup-=-ext4_lookup&lt;br/&gt;
----------ext4_iget&lt;br/&gt;
------------iget_locked&lt;br/&gt;
--------------ifind_fast&lt;br/&gt;
----------------find_inode_fast&lt;br/&gt;
------------------__wait_on_freeing_inode&lt;br/&gt;
-------------------?&lt;del&gt;ldiskfs_bread...-Child-dentry&apos;s-inode&lt;/del&gt;__I_LOCK&lt;/p&gt;

&lt;p&gt;ll_ost_io_15&lt;br/&gt;
ost_brw_write&lt;br/&gt;
--filter_commitrw_write&lt;br/&gt;
----fsfilt_ext3_commit_wait&lt;br/&gt;
------autoremove_wake_function&lt;br/&gt;
-------&lt;del&gt;fsfilt_log_wait_commit&lt;/del&gt;=-jbd2_log_wait_commit&lt;/p&gt;

&lt;p&gt;We think that is not neccessarily the problem of Lustre codes. And we found a nearly merged patch which fixes a similar deadlock problem in __jbd2_log_wait_for_space(). Maybe it is the root cause?&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/fs/jbd2/checkpoint.c?id=0ef54180e0187117062939202b96faf04c8673bc&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/fs/jbd2/checkpoint.c?id=0ef54180e0187117062939202b96faf04c8673bc&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
        <key id="21368">LU-4090</key>
            <summary>OST unavailable due to possible deadlock</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.whamcloud.com/images/icons/priorities/major.svg">Major</priority>
                        <status id="4" iconUrl="https://jira.whamcloud.com/images/icons/statuses/reopened.png" description="This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.">Reopened</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="bobijam">Zhenyu Xu</assignee>
                                    <reporter username="lixi">Li Xi</reporter>
                        <labels>
                    </labels>
                <created>Fri, 11 Oct 2013 07:25:26 +0000</created>
                <updated>Tue, 7 Jun 2016 15:38:31 +0000</updated>
                                            <version>Lustre 1.8.8</version>
                                    <fixVersion>Lustre 2.7.0</fixVersion>
                    <fixVersion>Lustre 2.5.3</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>10</watches>
                                                                            <comments>
                            <comment id="68799" author="lixi" created="Fri, 11 Oct 2013 07:28:41 +0000"  >&lt;p&gt;The debug messages are uploaded here.&lt;br/&gt;
&lt;a href=&quot;ftp://ftp.whamcloud.com/uploads/LU-4090/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;ftp://ftp.whamcloud.com/uploads/LU-4090/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="68811" author="pjones" created="Fri, 11 Oct 2013 13:17:47 +0000"  >&lt;p&gt;Bobijam&lt;/p&gt;

&lt;p&gt;Could you please comment on this one?&lt;/p&gt;

&lt;p&gt;Thanks&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="69714" author="bobijam" created="Thu, 24 Oct 2013 03:53:42 +0000"  >&lt;p&gt;yes, it is most likely the cause. I&apos;ll try to get a patch for it.&lt;/p&gt;</comment>
                            <comment id="69715" author="lixi" created="Thu, 24 Oct 2013 04:02:53 +0000"  >&lt;p&gt;Zhenyu,&lt;br/&gt;
Thank you very much for the help!&lt;/p&gt;</comment>
                            <comment id="69718" author="bobijam" created="Thu, 24 Oct 2013 04:45:31 +0000"  >&lt;p&gt;master patch &lt;a href=&quot;http://review.whamcloud.com/8059&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/8059&lt;/a&gt;&lt;br/&gt;
b1_8 patch &lt;a href=&quot;http://review.whamcloud.com/8060&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/8060&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="86509" author="lixi" created="Fri, 13 Jun 2014 00:44:51 +0000"  >&lt;p&gt;We&apos;ve seen this problem in three different systems. And there is no way to recover from it without rebooting the system. So it is a critical problem...&lt;/p&gt;</comment>
                            <comment id="88680" author="ihara" created="Thu, 10 Jul 2014 09:18:25 +0000"  >&lt;p&gt;This is really repeatable problem.&lt;br/&gt;
New patches for included SLES11 and SP3 as well as RHEL6. &lt;a href=&quot;http://review.whamcloud.com/#/c/11041/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/11041/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="88784" author="simmonsja" created="Thu, 10 Jul 2014 23:07:42 +0000"  >&lt;p&gt;Another patch seems to be floating around - &lt;a href=&quot;http://review.whamcloud.com/#/c/8059&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/8059&lt;/a&gt;. We need to pick one of them.&lt;/p&gt;</comment>
                            <comment id="91532" author="bogl" created="Wed, 13 Aug 2014 15:56:40 +0000"  >&lt;p&gt;I think &lt;a href=&quot;http://review.whamcloud.com/#/c/11041&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/11041&lt;/a&gt; is the better mod as it covers both el6 and sles.&lt;/p&gt;</comment>
                            <comment id="91839" author="pjones" created="Mon, 18 Aug 2014 13:15:15 +0000"  >&lt;p&gt;Landed for 2.7&lt;/p&gt;</comment>
                            <comment id="91874" author="yujian" created="Mon, 18 Aug 2014 17:00:24 +0000"  >&lt;p&gt;Here is the back-ported patch for Lustre b2_5 branch: &lt;a href=&quot;http://review.whamcloud.com/11492&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/11492&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="110724" author="wangshilong" created="Thu, 26 Mar 2015 08:07:58 +0000"  >&lt;p&gt;We still hit the issue, with &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-4020&quot; title=&quot;HSM copytool event monitoring capabilities&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-4020&quot;&gt;&lt;del&gt;LU-4020&lt;/del&gt;&lt;/a&gt; patch applied, see attachment.&lt;/p&gt;</comment>
                            <comment id="110725" author="bobijam" created="Thu, 26 Mar 2015 09:57:30 +0000"  >&lt;p&gt;You need to make sure that your server build does use lustre/kernel_patches/series/2.6-rhel6.series to patch the server kernel code to make the patch effect (since it&apos;s a kernel patch).&lt;/p&gt;

&lt;p&gt;You can check the patched server code fs/jbd2/checkpoint.c, find whether following code is there&lt;/p&gt;

&lt;p&gt;@@ -156,7 +156,15 @@ void __jbd2_log_wait_for_space(journal_t&lt;br/&gt;
 				/* We were able to recover space; yay! */&lt;br/&gt;
 				;&lt;br/&gt;
 			} else if (tid) {&lt;br/&gt;
+				/*&lt;br/&gt;
+				 * jbd2_journal_commit_transaction() may want&lt;br/&gt;
+				 * to take the checkpoint_mutex if JBD2_FLUSHED&lt;br/&gt;
+				 * is set.  So we need to temporarily drop it.&lt;br/&gt;
+				 */&lt;br/&gt;
+				mutex_unlock(&amp;amp;journal-&amp;gt;j_checkpoint_mutex);&lt;br/&gt;
 				jbd2_log_wait_commit(journal, tid);&lt;br/&gt;
+				spin_lock(&amp;amp;journal-&amp;gt;j_state_lock);&lt;br/&gt;
+				continue;&lt;/p&gt;</comment>
                            <comment id="110791" author="pjones" created="Thu, 26 Mar 2015 23:33:10 +0000"  >&lt;p&gt;Bobijam&lt;/p&gt;

&lt;p&gt;Ihara confirms that this patch has been in place and the issue has still hit&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="110803" author="ihara" created="Fri, 27 Mar 2015 08:53:06 +0000"  >&lt;p&gt;Bobijam, we confirmed kernel includes the follwoing codes, but hit same issue. pleaes check &lt;a href=&quot;https://jira.hpdd.intel.com/secure/attachment/17384/messages.ALPL402.txt&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://jira.hpdd.intel.com/secure/attachment/17384/messages.ALPL402.txt&lt;/a&gt; again, please.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;Index: linux-2.6.18-348.3.1.el5-b18/fs/jbd2/checkpoint.c
===================================================================
--- linux-2.6.18-348.3.1.el5-b18.orig/fs/jbd2/checkpoint.c
+++ linux-2.6.18-348.3.1.el5-b18/fs/jbd2/checkpoint.c
@@ -155,7 +155,15 @@ void __jbd2_log_wait_for_space(journal_t
 				&lt;span class=&quot;code-comment&quot;&gt;/* We were able to recover space; yay! */&lt;/span&gt;
 				;
 			} &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (tid) {
+				/*
+				 * jbd2_journal_commit_transaction() may want
+				 * to take the checkpoint_mutex &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; JBD2_FLUSHED
+				 * is set.  So we need to temporarily drop it.
+				 */
+				mutex_unlock(&amp;amp;journal-&amp;gt;j_checkpoint_mutex);
 				jbd2_log_wait_commit(journal, tid);
+				spin_lock(&amp;amp;journal-&amp;gt;j_state_lock);
+				&lt;span class=&quot;code-keyword&quot;&gt;continue&lt;/span&gt;;
 			} &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; {
 				printk(KERN_ERR &lt;span class=&quot;code-quote&quot;&gt;&quot;%s: needed %d blocks and &quot;&lt;/span&gt;
 				       &lt;span class=&quot;code-quote&quot;&gt;&quot;only had %d space available\n&quot;&lt;/span&gt;,
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                            <comment id="111331" author="bobijam" created="Thu, 2 Apr 2015 04:11:26 +0000"  >&lt;p&gt;Hi Ihara,&lt;/p&gt;

&lt;p&gt;From the messages.ALPL402.txt, I saw majorly two backtrace places, __jbd2_log_wait_for_space+0x5d and jbd2_log_wait_commit+0xa3, can you figure out what the code would be? As I&apos;ve done the lookup on my test system&lt;/p&gt;

&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;[12:04 PM]root@test1:~/work/kernel/linux-2.6.32-431.29.2.el6-master/
# gdb fs/jbd2/jbd2.ko
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later &amp;lt;http://gnu.org/licenses/gpl.html&amp;gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type &quot;show copying&quot;
and &quot;show warranty&quot; for details.
This GDB was configured as &quot;x86_64-redhat-linux-gnu&quot;.
For bug reporting instructions, please see:
&amp;lt;http://www.gnu.org/software/gdb/bugs/&amp;gt;...
Reading symbols from /root/work/kernel/linux-2.6.32-431.29.2.el6-master/fs/jbd2/jbd2.ko...done.
(gdb) l *jbd2_log_wait_commit+0xa3
0x85c3 is in jbd2_log_wait_commit (fs/jbd2/journal.c:641).
636		while (tid_gt(tid, journal-&amp;gt;j_commit_sequence)) {
637			jbd_debug(1, &quot;JBD: want %d, j_commit_sequence=%d\n&quot;,
638					  tid, journal-&amp;gt;j_commit_sequence);
639			wake_up(&amp;amp;journal-&amp;gt;j_wait_commit);
640			spin_unlock(&amp;amp;journal-&amp;gt;j_state_lock);
641			wait_event(journal-&amp;gt;j_wait_done_commit,
642					!tid_gt(tid, journal-&amp;gt;j_commit_sequence));
643			spin_lock(&amp;amp;journal-&amp;gt;j_state_lock);
644		}
645		spin_unlock(&amp;amp;journal-&amp;gt;j_state_lock);

(gdb) l *__jbd2_log_wait_for_space+0x5d
0x548d is in __jbd2_log_wait_for_space (fs/jbd2/checkpoint.c:172).
167					continue;
168				} else {
169					printk(KERN_ERR &quot;%s: needed %d blocks and &quot;
170					       &quot;only had %d space available\n&quot;,
171					       __func__, nblocks, space_left);
172					printk(KERN_ERR &quot;%s: no way to get more &quot;
173					       &quot;journal space in %s\n&quot;, __func__,
174					       journal-&amp;gt;j_devname);
175					WARN_ON(1);
176					jbd2_journal_abort(journal, 0);
(gdb) 
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The jbd2_log_wait_commit+0xa3 makes sense to, and it is waiting for the commit to finish. While other most processes hang in __jbd2_log_wait_for_space+0x5d does not look right, I want to know what code line would appear on your system.&lt;/p&gt;</comment>
                            <comment id="111732" author="lixi" created="Wed, 8 Apr 2015 13:55:25 +0000"  >&lt;p&gt;I am not sure, maybe following patch fixes a bug similar with our problem?&lt;/p&gt;

&lt;p&gt;ext4/jbd2: don&apos;t wait (forever) for stale tid caused by wraparound&lt;/p&gt;

&lt;p&gt;Tid wraparound is possible to happen on Lustre. And we saw it happened for multiple times in some systems before.&lt;/p&gt;</comment>
                            <comment id="111737" author="bobijam" created="Wed, 8 Apr 2015 15:08:15 +0000"  >&lt;p&gt;So the system still uses 1.8 version?&lt;/p&gt;</comment>
                            <comment id="111738" author="lixi" created="Wed, 8 Apr 2015 15:11:55 +0000"  >&lt;p&gt;Zhengyu, yes, it is.&lt;/p&gt;</comment>
                            <comment id="111742" author="bobijam" created="Wed, 8 Apr 2015 15:27:49 +0000"  >&lt;p&gt;I think what you described could be the reason some processes hang waiting for transaction commit, and would you give this patch a try? It changes fsfilt_ext3_commit_async() to avoid call jbd2_log_start_commit() with a stale tid.&lt;/p&gt;</comment>
                            <comment id="115618" author="wangshilong" created="Mon, 18 May 2015 04:26:47 +0000"  >&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;After applying following patch:&lt;br/&gt;
&lt;a href=&quot;https://jira.hpdd.intel.com/secure/attachment/17458/0001-LU-4090-fsfilt-don-t-wait-forever-for-stale-tid.patch&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://jira.hpdd.intel.com/secure/attachment/17458/0001-LU-4090-fsfilt-don-t-wait-forever-for-stale-tid.patch&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;We still hit this issue, please check latest uploaded logs(xxx20150518.txt). And i am wondering whether following thread is&lt;br/&gt;
related to this bug?&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://lkml.org/lkml/2012/7/11/255&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://lkml.org/lkml/2012/7/11/255&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="115634" author="bobijam" created="Mon, 18 May 2015 09:02:03 +0000"  >&lt;p&gt;What linux distro does the OST use?&lt;/p&gt;</comment>
                            <comment id="115644" author="wangshilong" created="Mon, 18 May 2015 11:17:16 +0000"  >&lt;p&gt;Hi, &lt;/p&gt;

&lt;p&gt;It is Rhel5 and kernel version is 2.6.18-348.3.1-xxx&lt;/p&gt;

&lt;p&gt;Regards,&lt;/p&gt;</comment>
                            <comment id="115980" author="bobijam" created="Wed, 20 May 2015 07:58:48 +0000"  >&lt;p&gt;found such backtrace in ALPL202.messages_20150518.txt&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;May 17 11:57:05 ALPL202 kernel: INFO: task ll_ost_io_144:20839 blocked for more than 120 seconds.
May 17 11:57:05 ALPL202 kernel: &quot;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.
May 17 11:57:05 ALPL202 kernel: ll_ost_io_144 D ffff810c3e08f7a0     0 20839      1         20840 20838 (L-TLB)
May 17 11:57:05 ALPL202 kernel:  ffff810911f63800 0000000000000046 ffff81034d1e1460 ffff8105ee5276c0
May 17 11:57:05 ALPL202 kernel:  ffff8105ee5276c0 000000000000000a ffff8108d1fee7e0 ffff810c3e08f7a0
May 17 11:57:05 ALPL202 kernel:  00129c413d2f65fb 000000000071882c ffff8108d1fee9c8 000000035a5a5a5a
May 17 11:57:05 ALPL202 kernel: Call Trace:
May 17 11:57:05 ALPL202 kernel:  [&amp;lt;ffffffff8002e4d5&amp;gt;] __wake_up+0x38/0x4f
May 17 11:57:05 ALPL202 kernel:  [&amp;lt;ffffffff88aa0840&amp;gt;] :jbd2:jbd2_log_wait_commit+0xa3/0xf5
...
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;and I checked Linux kernel patch, this patch commit 3469a32a1e948c54204b5dd6f7476a7d11349e9e fits to the symptom&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;    jbd2: don&apos;t hold j_state_lock while calling wake_up()
    
    The j_state_lock is one of the hottest locks in the jbd2 layer and
    thus one of its scalability bottlenecks.
    
    We don&apos;t need to be holding the j_state_lock while we are calling
    wake_up(&amp;amp;journal-&amp;gt;j_wait_commit), so release the lock a little bit
    earlier.
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;so I include it in this patch, would you mind give it a try?&lt;/p&gt;</comment>
                            <comment id="115981" author="bobijam" created="Wed, 20 May 2015 08:00:58 +0000"  >&lt;p&gt;I deleted the old patch and updated it.&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                            <attachment id="17907" name="0001-LU-4090-fsfilt-don-t-wait-forever-for-stale-tid.patch" size="5812" author="bobijam" created="Wed, 20 May 2015 07:58:48 +0000"/>
                            <attachment id="17809" name="ALPL202.messages_20150518.txt" size="314553" author="wangshilong" created="Mon, 18 May 2015 04:26:13 +0000"/>
                            <attachment id="17385" name="messages.ALPL401.txt" size="146987" author="wangshilong" created="Thu, 26 Mar 2015 08:07:58 +0000"/>
                            <attachment id="17384" name="messages.ALPL402.txt" size="1179043" author="wangshilong" created="Thu, 26 Mar 2015 08:07:58 +0000"/>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                            <customfield id="customfield_10890" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10490" key="com.atlassian.jira.plugin.system.customfieldtypes:datepicker">
                        <customfieldname>End date</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Wed, 20 May 2015 07:25:26 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10390" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hzw5e7:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>10994</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10060" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Severity</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10022"><![CDATA[3]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10493" key="com.atlassian.jira.plugin.system.customfieldtypes:datepicker">
                        <customfieldname>Start date</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Fri, 11 Oct 2013 07:25:26 +0000</customfieldvalue>

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