{5} Assigned, Active Tickets by Owner (Full Description) (11 matches)
List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.
moo (11 matches)
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #159 | White pages after raising size to any greater than 0 | cacher | 1.3.0 | defect | 12/30/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi, i'm fiddling around with xcache for some hours now but i can't get any more than white pages after raising size to any greater than 0 - googling around didn't help unfortunately :( any idea? I'm running php 5.2.5 and apache. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #37 | xcache_get SEGV using objects | cacher | 1.4.0 | defect | 09/24/2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
PHP 5.1.6 xcache_get SEGV with objects. <?php
//php built in stdClass
xcache_set("foo" , new stdClass);
var_dump(xcache_get("foo"));
?>
well, I expect either and error if objects are not supported, or the actual stored object var_dump'ed but not a segv :) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #53 | 500 error with Wordpress | coverager | 1.3.0 | defect | 11/17/2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi, I'm seeing a 500 error returned in Wordpress. It is fixed with either a restart of the php fastcgi processes, or clearing the xcache cache from the xcache admin page. It is not with all Wordpress pages, so far I've seen it when posting a comment. Posting comments works fine for a few hours/days then consistently returns a 500 error. This is with php5-cgi 5.1.2-1ubuntu3.4 package on Ubuntu Dapper running as a fastcgi process under lighttpd. It's with xcache 1.1.0 compiled from source (and observed from at least xcache trunk svn r262). I get no error output from php (to the error_log or php stderr) when accessing the broken page (though I know php error logging to be working). I think the php script causing the problem is wp-comments-post.php but I've got a couple of comment related plugins installed, such as Akismet and a threaded comments plugin. I've got other Wordpress installations on the same box which *reportedly* had the same problem (but at different times), though I've not seen it myself. I'm getting no coredump on the error. root@mule:~# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --with-tune=pentium4
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
root@mule:~# php-cgi -v
PHP 5.1.2 (cgi-fcgi) (built: Nov 2 2006 12:24:48)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
with XCache v1.1.0, Copyright (c) 2005-2006, by mOo
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #95 | Memory is not free()'d after xcache_get() data is unset | cacher | 1.4.0 | defect | 05/15/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I've tested EA vs XCache performance on cache reads and got the following problem: Code: <?php function ea_read ($max) # void { global $DATA; for($i = 0;$i<10;$i++) { $key[$i] = 'some_key_'.$i; eaccelerator_put($key[$i], $DATA); } for($i = 0;$i<$max;$i++) $val = eaccelerator_get($key[$i%10]); } function xcache_read ($max) # void { global $DATA; for($i = 0;$i<10;$i++) { $key[$i] = 'some_key_'.$i; xcache_set($key[$i], $DATA); } for($i = 0;$i<$max;$i++) { $val = xcache_get($key[$i%10]); } } Result ($max = 10000): <?php $DATA = str_repat('x',10000); Everything is ok. <?php $DATA = array_map('uniqid', range(1,10)); Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 15 bytes). It seems that XCache somehow marks array items that they aren't released (may be it increases ref_count?). I tried to add "unset($val);" after "$val = xcache_get();" but it didn't help. The only solution I've found is: <?php xcache_set($key,serialize($data)); $val = unserialize(xcache_get($key)); but it looks weird (and slows down xcache calls) ... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #161 | xcache keeps on crashing, core attached | cacher | 1.3.0 | defect | 01/14/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hello xcache keeps on crashin. I have three core files saved with an identical backtrace: Core was generated by `/usr/sbin/apache2 -k start'. Program terminated with signal 11, Segmentation fault. (gdb) bt #0 0x00002b215f95f887 in xcache_fcall_end_handler () from /usr/lib/php5/20060613/xcache.so #1 0x00002b215aef5db2 in get_zend_version () from /usr/lib/apache2/modules/libphp5.so #2 0x00002b215af00cd5 in zend_hash_apply () from /usr/lib/apache2/modules/libphp5.so #3 0x00002b215aef6247 in zend_post_deactivate_modules () from /usr/lib/apache2/modules/libphp5.so #4 0x00002b215aeb473a in php_request_shutdown () from /usr/lib/apache2/modules/libphp5.so #5 0x00002b215af75943 in php_ap2_register_hook () from /usr/lib/apache2/modules/libphp5.so #6 0x0000000000432cf9 in ap_run_handler () #7 0x0000000000435e72 in ap_invoke_handler () #8 0x0000000000441fe8 in ap_process_request () #9 0x000000000043f4cc in ap_register_input_filter () #10 0x0000000000439851 in ap_run_process_connection () #11 0x0000000000445961 in ap_graceful_stop_signalled () #12 0x0000000000445bd4 in ap_graceful_stop_signalled () #13 0x0000000000445c76 in ap_graceful_stop_signalled () #14 0x00000000004468cd in ap_mpm_run () #15 0x0000000000420e70 in main () I'm running xcache-1.2.2 with apache 2.2.3-4+etch3 + php5-5.2.5 on a Debian 4.0 'etch' system with the following config: web8:/var/cache/apache2# php -i|egrep '(jit|xcac)' /etc/php5/cli/conf.d/xcache.ini, auto_globals_jit => Off => Off xcache.admin.enable_auth => On => On xcache.cacher => On => On xcache.coredump_directory => no value => no value xcache.count => 8 => 8 xcache.coveragedump_directory => no value => no value xcache.coverager => Off => Off xcache.gc_interval => 0 => 0 xcache.mmap_path => /var/cache/apache2/php_xcache => /var/cache/apache2/php_xcache xcache.optimizer => Off => Off xcache.readonly_protection => 1 => 1 xcache.shm_scheme => mmap => mmap xcache.size => 128M => 128M xcache.slots => 16K => 16K xcache.stat => On => On xcache.test => no value => no value xcache.ttl => 0 => 0 xcache.var_count => 2 => 2 xcache.var_gc_interval => 300 => 300 xcache.var_maxttl => 0 => 0 xcache.var_size => 32M => 32M xcache.var_slots => 8K => 8K xcache.var_ttl => 0 => 0 It's gone now and I saw a warning that I set xcache.mmap_path to a directory. Maybe that was the resason but still it definetly should not segfault! As I had segfaults under Load for a couple of days now :( bye, -christian- |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #186 | Degraded performance when using Zend Guard encoded files with XCache 1.2.2 and Zend Optimizer 3.3.0 | cacher | defect | 07/15/2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hello. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #142 | support for php 5.3 | cacher | enhancement | 10/30/2007 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
/home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c: In function `xc_redo_pass_two': /home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:183: error: structure has no member named `is_ref' /home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:184: error: structure has no member named `refcount' /home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:187: error: structure has no member named `is_ref' /home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:188: error: structure has no member named `refcount' /home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c: In function `xc_do_early_binding': /home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:376: error: structure has no member named `is_ref' /home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:410: error: structure has no member named `is_ref' /home/builder/rpm/pld/BUILD/xcache-1.2.1/utils.c:411: error: structure has no member named `is_ref' make: *** [utils.lo] Error 1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #179 | 新 API 建议 | cacher | enhancement | 05/31/2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
一般情况下,在执行的 PHP 脚本中,很少会只用一次两次的 var cache。 都会这么写: foreach ($data AS $key => $value) {
} xcache_get 也基本上差不多,尤其在把数据库的记录当作一个 key -> value 对存在的时候,往往做一个列表页的情况下,会进行很大批量的 get 和 set 操作。从性能开销的考虑来看,由 xcache 支持批量操作,速度会提升 5-10 倍。目前 APC 和 MEMCACHE 的 get 操作都支持批量 key 的存取。我想除了方便的角度,也有性能提升的考虑吧。 我设想增加 xcache_gets API,原型为: array xcache_gets(array $keys, [array &$unget_keys]) 变量 keys 为一批 key,变量 unget_keys 为在缓存中未获得到的 key 的数组。方便后期代码中进行数据的获取,而不需要再进行循环操作。 如果可以的话,也可以增加 xcache_sets 函数,原型为: bool xcache_sets(array $data, $ttl) 变量 $data 为 key -> $value 对。 以上建议请希望开发者慎重考虑~ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #79 | coredump on oom | cacher | 2.0.0 | defect | 03/08/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
xcache.size=1M, non debug build analyze result: ce->parent need to be fixed, because parent class is copied into class_table and changes the pointer of parent class after sandbox_install. this is php4 only |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #173 | win php5.2 distribution - admin does not include header.tpl.php and footer.tpl.php | cacher | 1.3.0 | defect | 04/19/2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi After following the installation steps, the admin directory does not contain the header and footer.tpl.php files. When calling the admin in the browser error messages regarding missing files are generated. Joel |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #107 | Add "per-second" stats to xcache admin | admin | 1.4.0 | enhancement | 06/27/2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It would be useful in the admin pages to have the Hits, Misses, Clogs and OOMs shown both as totals like they are at the moment and additionally as per-second values. Also a column to show when each cache was last cleared would be nice. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

