<!-- 
RSS generated by JIRA (5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9) at Sat May 18 17:30:04 CDT 2013

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 add field=key&field=summary to the URL of your request.
For example:
http://www.couchbase.com/issues/si/jira.issueviews:issue-xml/PCBC-140/PCBC-140.xml?field=key&field=summary
-->
<rss version="0.92" >
<channel>
    <title>Couchbase</title>
    <link>http://www.couchbase.com/issues</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>5.2.4</version>
        <build-number>845</build-number>
        <build-date>26-12-2012</build-date>
    </build-info>

<item>
            <title>[PCBC-140] Connection Socket Not Closing</title>
                <link>http://www.couchbase.com/issues/browse/PCBC-140</link>
                <project id="10049" key="PCBC">Couchbase PHP client library</project>
                        <description>(See discussion @ &lt;a href=&quot;https://groups.google.com/forum/#!topic/couchbase/z5PWM5lS7gU)&quot;&gt;https://groups.google.com/forum/#!topic/couchbase/z5PWM5lS7gU)&lt;/a&gt;&lt;br/&gt;
&lt;br/&gt;
I&amp;#39;ve been getting a &amp;quot;Too many files open&amp;quot; warning while accessing pages in my site. I tracked it down to this process using LSOF&lt;br/&gt;
&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;httpd     25992 httpduser   98u     unix 0xffff81006cbcf4c0        0t0    6019192 socket&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;httpd     25992 httpduser   99u     unix 0xffff810074b160c0        0t0    6019193 socket&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;httpd     25992 httpduser  100r     0000               0,11          0    6063613 eventpoll&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;httpd     25992 httpduser  101u     unix 0xffff8100701f66c0        0t0    6063614 socket&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;httpd     25992 httpduser  102u     unix 0xffff8100701f7a00        0t0    6063615 socket&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;httpd     25992 httpduser  103r     0000               0,11          0    6064737 eventpoll&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;httpd     25992 httpduser  104u     unix 0xffff8100666eb6c0        0t0    6064738 socket&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;httpd     25992 httpduser  105u     unix 0xffff8100666eb980        0t0    6064739 socket&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;httpd     25992 httpduser  108r     0000               0,11          0    6064793 eventpoll&lt;br/&gt;
&lt;br/&gt;
Everytime I refresh a page, two new sockets and one new eventpoll shows up. These socket/eventpoll&amp;#39;s only show up on pages that make use of Coucbase -- in fact, in the email thread I narrowed it down to a single command page, so I&amp;#39;m pretty sure it&amp;#39;s CB here. These FD&amp;#39;s stick around until the apache thread is restarted (due to MaxRequestsPerChild limit reached) or an httpd restart. Eventually, the number of FD&amp;#39;s opened causes things to go very poorly for the server.&lt;br/&gt;
&lt;br/&gt;
Utilizing persistent connections lessened the problem, but the number never went down/static, just increased more slowly.</description>
                <environment>CentOS 5.5, Apache 2.2, mod_php, PHP5.3, Couchbase 2.0dp5</environment>
            <key id="20536">PCBC-140</key>
            <summary>Connection Socket Not Closing</summary>
                <type id="1" iconUrl="http://www.couchbase.com/issues/images/icons/issuetypes/bug.png">Bug</type>
                                <priority id="2" iconUrl="http://www.couchbase.com/issues/images/icons/priorities/critical.png">Critical</priority>
                    <status id="5" iconUrl="http://www.couchbase.com/issues/images/icons/statuses/resolved.png">Resolved</status>
                    <resolution id="1">Fixed</resolution>
                    <security id="10011">Public</security>
                        <assignee username="mnunberg">Mark Nunberg</assignee>
                                <reporter username="chuyskywalker">Jeff Minard</reporter>
                        <labels>
                    </labels>
                <created>Sun, 4 Nov 2012 11:13:25 -0600</created>
                <updated>Wed, 7 Nov 2012 16:09:01 -0600</updated>
                    <resolved>Wed, 7 Nov 2012 16:09:01 -0600</resolved>
                            <version>1.1.0-dp5</version>
                                                <component>library</component>
                                <votes>0</votes>
                        <watches>1</watches>
                                                    <comments>
                    <comment id="43206" author="mnunberg" created="Sun, 4 Nov 2012 12:20:50 -0600"  >I can confirm this is happening even on a CLI script. Run this script (php 5.4, debian wheezy), and lsof -p on the php process.&lt;br/&gt;
&lt;br/&gt;
This seems to be an issue in libcouchbase itself and not in the php code.&lt;br/&gt;
&lt;br/&gt;
Upon deeper analysis, the leaking fds seem to come from some odd socketpair call that libevent makes for no apparently good reason.&lt;br/&gt;
&lt;br/&gt;
It would seem libcouchbase never properly destroys the &amp;#39;event_base&amp;#39; object, and the socket pairs keep persisting until the application exits.&lt;br/&gt;
&lt;br/&gt;
(gdb) bt&lt;br/&gt;
#0  socketpair () at ../sysdeps/unix/syscall-template.S:82&lt;br/&gt;
#1  0x00007ffff3568181 in evsig_init () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5&lt;br/&gt;
#2  0x00007ffff35677c0 in ?? () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5&lt;br/&gt;
#3  0x00007ffff3556645 in event_base_new_with_config () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5&lt;br/&gt;
#4  0x00007ffff3556765 in event_base_new () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5&lt;br/&gt;
#5  0x00007ffff378b605 in lcb_create_libevent_io_opts ()&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;from /sources/libcouchbase/inst/lib/libcouchbase_libevent.so.2&lt;br/&gt;
#6  0x00007ffff3bb9dcc in lcb_create_io_ops () from /sources/libcouchbase/inst/lib/libcouchbase.so.2&lt;br/&gt;
#7  0x00007ffff3dd463d in php_couchbase_create_impl (ht=&amp;lt;optimized out&amp;gt;, return_value=0x7ffff7fbf078, &lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;this_ptr=0x7ffff7fbd2e8, oo=1, &lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;return_value_used=&amp;lt;error reading variable: Unhandled dwarf expression opcode 0xfa&amp;gt;, &lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;return_value_ptr=&amp;lt;error reading variable: Unhandled dwarf expression opcode 0xfa&amp;gt;)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;at /sources/lcb2.0-repo/php/couchbase.c:1708&lt;br/&gt;
#8  0x00007ffff3ff2edc in xdebug_execute_internal (current_execute_data=0x7ffff7f86060, return_value_used=0)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;at /srv/debian_developer/xdebug/xdebug-2.2.1/build-php5/xdebug.c:1483&lt;br/&gt;
#9  0x000000000074688e in zend_do_fcall_common_helper_SPEC (execute_data=0x7ffff7f86060)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;at /tmp/buildd/php5-5.4.4/Zend/zend_vm_execute.h:644&lt;br/&gt;
#10 0x0000000000700297 in execute (op_array=0x7ffff7fbdbc8) at /tmp/buildd/php5-5.4.4/Zend/zend_vm_execute.h:410&lt;br/&gt;
#11 0x00007ffff3ff2a81 in xdebug_execute (op_array=0x7ffff7fbdbc8)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;at /srv/debian_developer/xdebug/xdebug-2.2.1/build-php5/xdebug.c:1391&lt;br/&gt;
#12 0x00000000006a00de in zend_execute_scripts (type=8, retval=0x7ffff7fbdb90, file_count=3)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;at /tmp/buildd/php5-5.4.4/Zend/zend.c:1279&lt;br/&gt;
#13 0x000000000063f6b3 in php_execute_script (primary_file=0x7fffffff9f50)&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;at /tmp/buildd/php5-5.4.4/main/main.c:2473&lt;br/&gt;
#14 0x0000000000749003 in do_cli (argc=0, argv=0x7fffffffe40c) at /tmp/buildd/php5-5.4.4/sapi/cli/php_cli.c:988&lt;br/&gt;
#15 0x00000000004310ca in main (argc=32767, argv=0xdb9210) at /tmp/buildd/php5-5.4.4/sapi/cli/php_cli.c:1361&lt;br/&gt;
</comment>
                    <comment id="43207" author="mnunberg" created="Sun, 4 Nov 2012 12:28:31 -0600"  >I was right about the problem, but not about the real cause.&lt;br/&gt;
&lt;br/&gt;
The real cause is that the php extension creates the iops structure manually, and does not manually clean it up. Therefore the explicit creation of the iops structure causes a memory leak as well as a fd leak.&lt;br/&gt;
&lt;br/&gt;
Ideally our extension code should never be dealing with the iops structure directly, which will be done in subsequent refactors.&lt;br/&gt;
&lt;br/&gt;
This was not the case in the 1.0.x versions of libcouchbase where lcb would just assume the iops structure needed to be destroyed and freed it.</comment>
                    <comment id="43208" author="mnunberg" created="Sun, 4 Nov 2012 12:47:17 -0600"  >&lt;a href=&quot;http://review.couchbase.org/22255&quot;&gt;http://review.couchbase.org/22255&lt;/a&gt;&lt;br/&gt;
&lt;br/&gt;
You can apply this patch manually if you&amp;#39;d like as a temporary workaround.</comment>
                    <comment id="43209" author="mnunberg" created="Sun, 4 Nov 2012 12:59:31 -0600"  >For the record, in output like this:&lt;br/&gt;
&lt;br/&gt;
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;httpd 25992 httpduser 105u unix 0xffff8100666eb980 0t0 6064739 socket &lt;br/&gt;
&lt;br/&gt;
The fifth column indicates the underlying fd type. In this case, it&amp;#39;s a unix socket.&lt;br/&gt;
&lt;br/&gt;
If it were a TCP socket it&amp;#39;d say &amp;quot;IPv4&amp;quot; (or &amp;quot;IPv6&amp;quot;) - and that gave me the hint, as libcouchbase on its own does not utilize unix domain sockets.</comment>
                    <comment id="43213" author="ingenthr" created="Sun, 4 Nov 2012 20:53:04 -0600"  >Does a similar fix need to be made in 1.0.x?   I peeked at the code briefly, but enough has changed that I couldn&amp;#39;t quite tell.</comment>
                    <comment id="43215" author="mnunberg" created="Mon, 5 Nov 2012 00:33:36 -0600"  >No, this issue is specific to the lcb 2.0 iops refactor</comment>
                    <comment id="43216" author="ingenthr" created="Mon, 5 Nov 2012 00:57:10 -0600"  >Good news, thanks!</comment>
                    <comment id="43513" author="mnunberg" created="Wed, 7 Nov 2012 16:09:01 -0600"  >I&amp;#39;m marking this as resolved/fixed. Reopen if not working.</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                                                                                                                                                    <customfield id="customfield_10081" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Rank</customfieldname>
                <customfieldvalues>
                    <customfieldvalue>9766</customfieldvalue>
                </customfieldvalues>
            </customfield>
                                                                                    <customfield id="customfield_10181" key="com.atlassian.jira.ext.charting:timeinstatus">
                <customfieldname>Time In Status</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                </customfields>
    </item>
</channel>
</rss>