[jira] [Created] (TS-1911) enforce MIOBufferAccessor accessor API
James Peach created TS-1911: --- Summary: enforce MIOBufferAccessor accessor API Key: TS-1911 URL: https://issues.apache.org/jira/browse/TS-1911 Project: Traffic Server Issue Type: Bug Components: Core Reporter: James Peach We already have sensibly-named accessors for the MIOBufferAccessor members, so there's no need to access the internals directly. Make the members private and use the accessors wherever necessary. This exposes some places that don't use the proper APIs, so fix those too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1911) enforce MIOBufferAccessor accessor API
[ https://issues.apache.org/jira/browse/TS-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662030#comment-13662030 ] ASF subversion and git services commented on TS-1911: - Commit ff2fd580a9a0f49f7fe5e16cb79147b355655b71 in branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ff2fd58 ] TS-1911: make MIOBufferAccessor members private We already have sensibly-named accessors for the MIOBufferAccessor members, so there's no need to access the internals directly. Make the members private and use the accessors wherever necessary. This exposes some places that don't use the proper APIs, so fix those too. enforce MIOBufferAccessor accessor API -- Key: TS-1911 URL: https://issues.apache.org/jira/browse/TS-1911 Project: Traffic Server Issue Type: Bug Components: Core Reporter: James Peach We already have sensibly-named accessors for the MIOBufferAccessor members, so there's no need to access the internals directly. Make the members private and use the accessors wherever necessary. This exposes some places that don't use the proper APIs, so fix those too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1911) enforce MIOBufferAccessor accessor API
[ https://issues.apache.org/jira/browse/TS-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1911. - Resolution: Fixed Fix Version/s: 3.3.3 Assignee: James Peach enforce MIOBufferAccessor accessor API -- Key: TS-1911 URL: https://issues.apache.org/jira/browse/TS-1911 Project: Traffic Server Issue Type: Bug Components: Core Reporter: James Peach Assignee: James Peach Fix For: 3.3.3 We already have sensibly-named accessors for the MIOBufferAccessor members, so there's no need to access the internals directly. Make the members private and use the accessors wherever necessary. This exposes some places that don't use the proper APIs, so fix those too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1912) SSL hangs after origin handshake
[ https://issues.apache.org/jira/browse/TS-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1912: Component/s: SSL SSL hangs after origin handshake Key: TS-1912 URL: https://issues.apache.org/jira/browse/TS-1912 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1912) SSL hangs after origin handshake
James Peach created TS-1912: --- Summary: SSL hangs after origin handshake Key: TS-1912 URL: https://issues.apache.org/jira/browse/TS-1912 Project: Traffic Server Issue Type: Bug Reporter: James Peach -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1912) SSL hangs after origin handshake
[ https://issues.apache.org/jira/browse/TS-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1912. - Resolution: Fixed Fix Version/s: 3.3.3 Assignee: James Peach SSL hangs after origin handshake Key: TS-1912 URL: https://issues.apache.org/jira/browse/TS-1912 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach Assignee: James Peach Fix For: 3.3.3 When using SSL with a Netscaler origin, I'm seeing the handshake complete but ATS never issuing the HTTP request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1786) only enable -Werror for debug builds
[ https://issues.apache.org/jira/browse/TS-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662073#comment-13662073 ] James Peach commented on TS-1786: - Here's another idea. Leave -Werror on in the source tree, but always turn it off in the release tarballs. This protects the majority of casual users from spurious build failures. only enable -Werror for debug builds Key: TS-1786 URL: https://issues.apache.org/jira/browse/TS-1786 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Fix For: 3.3.4 It's very difficult to always build with -Werror on every platform we support. -Werror is only valuable to developers, not so much for users. We should consider only enabling -Werror if the build was configured with --enable-debug. This probably involves adding autoconf macros to test whether the compiler actually supports -Werror. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1912) SSL hangs after origin handshake
[ https://issues.apache.org/jira/browse/TS-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1912: Description: When using SSL with a Netscaler origin, I'm seeing the handshake complete but ATS never issuing the HTTP request. SSL hangs after origin handshake Key: TS-1912 URL: https://issues.apache.org/jira/browse/TS-1912 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach When using SSL with a Netscaler origin, I'm seeing the handshake complete but ATS never issuing the HTTP request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1786) only enable -Werror for debug builds
[ https://issues.apache.org/jira/browse/TS-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662152#comment-13662152 ] Bryan Call commented on TS-1786: I would like to see -Werror kept on for all builds in the source tree and turn it off in the release tarball (like James said). Most people don't do debug builds. I myself haven't done one in awhile. only enable -Werror for debug builds Key: TS-1786 URL: https://issues.apache.org/jira/browse/TS-1786 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Fix For: 3.3.4 It's very difficult to always build with -Werror on every platform we support. -Werror is only valuable to developers, not so much for users. We should consider only enabling -Werror if the build was configured with --enable-debug. This probably involves adding autoconf macros to test whether the compiler actually supports -Werror. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1891) Add double-free checking for reclaimable freelist
[ https://issues.apache.org/jira/browse/TS-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-1891: - Attachment: (was: 0001-Add-double-free-checking-for-reclaimable-freelist-V4.patch) Add double-free checking for reclaimable freelist - Key: TS-1891 URL: https://issues.apache.org/jira/browse/TS-1891 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Yunkai Zhang double-free checking is very useful for us to analyze memory issues. So, I introduce this feature to recalimable freelist. And，we found that this checking nearly don't affect the performance, so make the checking always. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1891) Add double-free checking for reclaimable freelist
[ https://issues.apache.org/jira/browse/TS-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-1891: - Attachment: 0001-Add-double-free-checking-for-reclaimable-freelist-V5.patch use magic code instead of refcnt for chunk item. Add double-free checking for reclaimable freelist - Key: TS-1891 URL: https://issues.apache.org/jira/browse/TS-1891 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Yunkai Zhang Attachments: 0001-Add-double-free-checking-for-reclaimable-freelist-V5.patch double-free checking is very useful for us to analyze memory issues. So, I introduce this feature to recalimable freelist. And，we found that this checking nearly don't affect the performance, so make the checking always. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1684) Reduce the usage of global allocation/free lists - switch to using local thread allocation/free lists
[ https://issues.apache.org/jira/browse/TS-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662180#comment-13662180 ] Bryan Call commented on TS-1684: ats results for 3.2.0_11 - without the proxy allocator patch included in this bug -bash-4.2$ cat out | http_load/merge_stats.pl Total runs: 13 4112097 fetches on 4764 conns, 1300 max parallell, 5.75693e+09 bytes in 30 seconds 1400 mean bytes/fetch 137069.90 fetches/sec, 1.91898e+08 bytes/sec msecs/connect: 0.180437538461538 mean, 0.662384615384615 max, 0.0604615384615384 min msecs/first-response: 9.47338384615385 mean, 162.386230769231 max, 0.152307692307692 min -bash-4.1$ dstat 10 total-cpu-usage -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 72 10 7 0 0 11| 026k| 31M 224M| 0 0 | 291k 20k 74 10 6 0 0 10| 024k| 31M 228M| 0 0 | 294k 20k 72 10 6 1 0 11| 041M| 31M 227M| 0 0 | 294k 23k 71 10 6 1 0 12| 410B 49M| 31M 223M| 0 0 | 295k 21k Samples: 2M of event 'cycles', Event count (approx.): 628623285644 23.47% libtsutil.so.3[.] ink_freelist_new 20.22% libtsutil.so.3[.] ink_freelist_free 2.85% [kernel] [k] _spin_lock_bh 1.51% traffic_server[.] HttpSM::_instantiate_func(HttpSM*, Ht 1.35% [kernel] [k] _spin_lock 1.03% traffic_server[.] HdrHeap::destroy() 0.72% libc-2.12.so [.] memcpy 0.72% traffic_server[.] HdrHeap::allocate_obj(int, int) 0.63% [bnx2x] [k] bnx2x_start_xmit 0.60% libpthread-2.12.so[.] pthread_mutex_trylock 0.56% [kernel] [k] copy_user_generic_string 0.50% libpthread-2.12.so[.] pthread_mutex_unlock 0.49% traffic_server[.] HdrHeap::duplicate_str(char const*, i 0.49% traffic_server[.] write_to_net_io(NetHandler*, UnixNetV 0.48% [kernel] [k] tcp_ack 0.47% traffic_server[.] PriorityEventQueue::check_ready(long, 0.46% traffic_server[.] HttpSM::cleanup() 0.46% traffic_server[.] IOBufferBlock::free() 0.44% traffic_server[.] mime_hdr_field_find(MIMEHdrImpl*, cha 0.43% [kernel] [k] skb_release_data 0.42% traffic_server[.] RamCacheCLFUS::get(INK_MD5*, PtrIOBu ats results for 3.2.0_12 - with the proxyallocator patch included in this bug -bash-4.2$ cat out | http_load/merge_stats.pl Total runs: 13 15551539 fetches on 16174 conns, 1300 max parallell, 2.17722e+10 bytes in 60 seconds 1400 mean bytes/fetch 259192.20 fetches/sec, 3.62869e+08 bytes/sec msecs/connect: 14.0116384615385 mean, 2503.94692307692 max, 0.0573846153846154 min msecs/first-response: 4.95988153846154 mean, 302.202153846154 max, 0.100384615384615 min -bash-4.1$ dstat 10 total-cpu-usage -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 62 16 8 0 0 14| 036k| 60M 438M| 0 0 | 335k 60k 60 16 9 0 0 15| 034k| 60M 432M| 0 0 | 337k 60k 61 16 8 0 0 15| 020M| 59M 430M| 0 0 | 336k 59k Samples: 1M of event 'cycles', Event count (approx.): 471148870436 8.83% libtsutil.so.3[.] ink_freelist_free 4.49% libtsutil.so.3[.] ink_freelist_new 2.24% traffic_server[.] HttpSM::_instantiate_func(HttpSM*, Ht 2.02% [kernel] [k] _spin_lock_bh 2.01% [kernel] [k] _spin_lock 1.27% libc-2.12.so [.] memcpy 1.09% [bnx2x] [k] bnx2x_start_xmit 1.06% traffic_server[.] PriorityEventQueue::check_ready(long, 1.03% traffic_server[.] this_ethread() 0.99% [kernel] [k] copy_user_generic_string 0.84% [kernel] [k] tcp_ack 0.78% traffic_server[.] HttpSM::cleanup() 0.78% traffic_server[.] mime_hdr_field_find(MIMEHdrImpl*, cha 0.71% traffic_server[.] HdrHeap::allocate_obj(int, int) 0.67% libpthread-2.12.so[.] pthread_getspecific 0.66% traffic_server[.] RamCacheCLFUS::get(INK_MD5*, PtrIOBu 0.63% traffic_server[.] HdrHeap::destroy() 0.63% libpthread-2.12.so[.] pthread_mutex_trylock 0.61% [kernel] [k] kfree 0.60% [bnx2x] [k] bnx2x_rx_int 0.58% traffic_server[.] HdrHeap::duplicate_str(char const*, i 0.52% traffic_server[.] read_from_net(NetHandler*, UnixNetVCo 0.52%
[jira] [Updated] (TS-1913) Fix MIOBuffer::append_xmalloced()
[ https://issues.apache.org/jira/browse/TS-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-1913: - Attachment: 0002-Fix-MIOBuffer-append_xmalloced.patch Fix MIOBuffer::append_xmalloced() - Key: TS-1913 URL: https://issues.apache.org/jira/browse/TS-1913 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Yunkai Zhang Attachments: 0002-Fix-MIOBuffer-append_xmalloced.patch When ATS receives a malicious request which URL is too long to hold by internal_msg_buffer, the internal_msg_buffer_size might be set to 0. As a result, the appended memory which allocated by ats_malloc() would be mistaken for the memory from ink_freelist, and would be free to ink_freelist finally. As this memory is larger than the one in ink_freelist, and all memory in the origin ink_freelist would not be reclaimed, so it wouldn't cause segment-fault, that is why we didn't notice it in the past. But after we use reclaimabe-freelist, this bug would cause segment-fault when it was free-back to OS by unmmap(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1728) Need a way to assign storage entries to volumes
[ https://issues.apache.org/jira/browse/TS-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662185#comment-13662185 ] ASF subversion and git services commented on TS-1728: - Commit 6a071eb4d204bc99fb4202d05b0eb04c1cbc9257 in branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6a071eb ] Merge branch 'issues/TS-1728' into 'master' Need a way to assign storage entries to volumes --- Key: TS-1728 URL: https://issues.apache.org/jira/browse/TS-1728 Project: Traffic Server Issue Type: Wish Components: Cache Reporter: Jan van Doorn Assignee: Phil Sorber Priority: Minor Fix For: 3.3.3 Attachments: vol.patch See http://www.knutsel.com/vol/compare/ for a write up and some test results on this. We are proposing a simple way to hard link storage.config entries to volume.config and thus hosting.config entries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1728) Need a way to assign storage entries to volumes
[ https://issues.apache.org/jira/browse/TS-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662186#comment-13662186 ] ASF subversion and git services commented on TS-1728: - Commit 1d8179df5bfbde4331ee94519c7a7a9d45f2ebe3 in branch refs/heads/master from Phil Sorber sor...@apache.org [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1d8179d ] TS-1728: Assign storage entries to volumes Introduces the volume assignment in storage.config, on an optional basis. No change is needed in the config if you don't want to use this feature. * Add an optional reference to the volume number in storage.config, and the Span object, in Store.h and Store.cc * Add the volume reference to DiskVol, CacheProcessor::start_internal (in Cache.cc) * Change cplist_reconfigure (in Cache.cc) to constrain mapping * Fix bytes_used and percent_used per volume stats Need a way to assign storage entries to volumes --- Key: TS-1728 URL: https://issues.apache.org/jira/browse/TS-1728 Project: Traffic Server Issue Type: Wish Components: Cache Reporter: Jan van Doorn Assignee: Phil Sorber Priority: Minor Fix For: 3.3.3 Attachments: vol.patch See http://www.knutsel.com/vol/compare/ for a write up and some test results on this. We are proposing a simple way to hard link storage.config entries to volume.config and thus hosting.config entries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1914) configured socket buffer sizes not applied
James Peach created TS-1914: --- Summary: configured socket buffer sizes not applied Key: TS-1914 URL: https://issues.apache.org/jira/browse/TS-1914 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, Network Reporter: James Peach The settings specified in proxy.config.net.sock_recv_buffer_size_in and proxy.config.net.sock_send_buffer_size_in are never applied. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1786) only enable -Werror for debug builds
[ https://issues.apache.org/jira/browse/TS-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662189#comment-13662189 ] Uri Shachar commented on TS-1786: - +1 for turning it off in the release tarball -- good idea. only enable -Werror for debug builds Key: TS-1786 URL: https://issues.apache.org/jira/browse/TS-1786 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Fix For: 3.3.4 It's very difficult to always build with -Werror on every platform we support. -Werror is only valuable to developers, not so much for users. We should consider only enabling -Werror if the build was configured with --enable-debug. This probably involves adding autoconf macros to test whether the compiler actually supports -Werror. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1684) Reduce the usage of global allocation/free lists - switch to using local thread allocation/free lists
[ https://issues.apache.org/jira/browse/TS-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662193#comment-13662193 ] Bryan Call commented on TS-1684: In the comment above I saw a 1.89x improvement in the throughput in the benchmark I ran using the patch in the bug. The test consisted of: - 1 dual cpu server 12/24 cores/hyper-threaded box with a broadcom 10gig nic, running rhel 6.4 - 13 clients running http_load - 100% cache hit rate - 1.6KB response from the proxy (1400 byte body) - 4 volumes in the proxy cache to reduce lock contention - 100 different objects/urls used by the client Reduce the usage of global allocation/free lists - switch to using local thread allocation/free lists - Key: TS-1684 URL: https://issues.apache.org/jira/browse/TS-1684 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Bryan Call Assignee: Bryan Call Fix For: 3.3.4 Attachments: ts-1684.patch When running benchmarks ink_freelist_new() normally shows up as one of if not the number one function in the code using the most CPU. Currently ATS uses global free lists (via ClassAllocator, Allocator, and SparceClassAllocator) for memory allocation for some of its memory allocation. Here is a list of how frequently the type of allocations are used and the name given to the allocator. This is a benchmark for a small object in cache fetched 100k times. 40 ink_freelist_new: hdrHeap 30 ink_freelist_new: hdrStrHeap 203541 ink_freelist_new: ioBlockAllocator 199616 proxy allocator thread_alloc: eventAllocator 103554 ink_freelist_new: ioDataAllocator 103554 ink_freelist_new: ioBufAllocator[5] 100100 ink_freelist_new: ioAllocator 10 proxy allocator thread_alloc: hdrHeap 10 proxy allocator thread_alloc: cacheVConnection 10 ink_freelist_new: httpSMAllocator 10 ink_freelist_new: ArenaBlock 18507 ink_freelist_new: mutexAllocator 4772 ink_freelist_new: eventAllocator 162 ink_freelist_new: cacheVConnection 102 ink_freelist_new: netVCAllocator 100 proxy allocator init thread_alloc: httpClientSessionAllocator 100 ink_freelist_new: httpClientSessionAllocator 1 proxy allocator thread_alloc: RamCacheCLFUSEntry 1 ink_freelist_new: RamCacheCLFUSEntry 1 ink_freelist_new: hostDBContAllocator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1914) configured socket buffer sizes not applied
[ https://issues.apache.org/jira/browse/TS-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662195#comment-13662195 ] ASF subversion and git services commented on TS-1914: - Commit ef5a9f3fa45ef0ebc418545b3b00d426b35acbda in branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ef5a9f3 ] TS-1914: configured socket buffer sizes not applied configured socket buffer sizes not applied -- Key: TS-1914 URL: https://issues.apache.org/jira/browse/TS-1914 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, Network Reporter: James Peach The settings specified in proxy.config.net.sock_recv_buffer_size_in and proxy.config.net.sock_send_buffer_size_in are never applied. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1914) configured socket buffer sizes not applied
[ https://issues.apache.org/jira/browse/TS-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach closed TS-1914. --- Resolution: Fixed Fix Version/s: 3.3.3 Assignee: James Peach configured socket buffer sizes not applied -- Key: TS-1914 URL: https://issues.apache.org/jira/browse/TS-1914 Project: Traffic Server Issue Type: Bug Components: Configuration, Core, Network Reporter: James Peach Assignee: James Peach Fix For: 3.3.3 The settings specified in proxy.config.net.sock_recv_buffer_size_in and proxy.config.net.sock_send_buffer_size_in are never applied. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1913) Fix MIOBuffer::append_xmalloced()
[ https://issues.apache.org/jira/browse/TS-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-1913: - Description: When ATS receives a malicious request which URL is too long to hold by internal_msg_buffer, the internal_msg_buffer_size might be set to 0. As a result, the appended memory which allocated by ats_malloc() would be mistaken for the memory from ink_freelist, and would be free to ink_freelist finally. As this memory is larger than the one in ink_freelist, and all memory in the origin ink_freelist would not be reclaimed, so it wouldn't cause segment-fault, that is why we didn't notice it in the past. But after we use reclaimabe-freelist, this bug would cause segment-fault when use it to get inner meta-data or free it back to OS by unmmap(). was: When ATS receives a malicious request which URL is too long to hold by internal_msg_buffer, the internal_msg_buffer_size might be set to 0. As a result, the appended memory which allocated by ats_malloc() would be mistaken for the memory from ink_freelist, and would be free to ink_freelist finally. As this memory is larger than the one in ink_freelist, and all memory in the origin ink_freelist would not be reclaimed, so it wouldn't cause segment-fault, that is why we didn't notice it in the past. But after we use reclaimabe-freelist, this bug would cause segment-fault when it was free-back to OS by unmmap(). Fix MIOBuffer::append_xmalloced() - Key: TS-1913 URL: https://issues.apache.org/jira/browse/TS-1913 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Yunkai Zhang Attachments: 0002-Fix-MIOBuffer-append_xmalloced.patch When ATS receives a malicious request which URL is too long to hold by internal_msg_buffer, the internal_msg_buffer_size might be set to 0. As a result, the appended memory which allocated by ats_malloc() would be mistaken for the memory from ink_freelist, and would be free to ink_freelist finally. As this memory is larger than the one in ink_freelist, and all memory in the origin ink_freelist would not be reclaimed, so it wouldn't cause segment-fault, that is why we didn't notice it in the past. But after we use reclaimabe-freelist, this bug would cause segment-fault when use it to get inner meta-data or free it back to OS by unmmap(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1684) Reduce the usage of global allocation/free lists - switch to using local thread allocation/free lists
[ https://issues.apache.org/jira/browse/TS-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662206#comment-13662206 ] Leif Hedstrom commented on TS-1684: --- Lets land this, perhaps with a configure option for now? There might be some unforeseen downsides to this much proxy allocation (i.e. bigger memory foot prints). Also, did you change the setup to allow more than the 512 objects that each proxy allocator is allowed to retain? I see two possible ways to change this: 1) Add a new config option (records.config) to allow it to be more (or less) than 512, with a value of '0' meaning no limits. 2) Somehow combine the reclaimable freelist code with the proxy allocators, which combined with a high (or '0') setting above can be used to reclaim objects from the freelist. I haven't checked the patches above, but I think #1 above is a good requirement to control this in some way (and continue to let it fall back to the global allocators as necessary). Exciting results indeed, a huge step towards NUMA awareness! Reduce the usage of global allocation/free lists - switch to using local thread allocation/free lists - Key: TS-1684 URL: https://issues.apache.org/jira/browse/TS-1684 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Bryan Call Assignee: Bryan Call Fix For: 3.3.4 Attachments: ts-1684.patch When running benchmarks ink_freelist_new() normally shows up as one of if not the number one function in the code using the most CPU. Currently ATS uses global free lists (via ClassAllocator, Allocator, and SparceClassAllocator) for memory allocation for some of its memory allocation. Here is a list of how frequently the type of allocations are used and the name given to the allocator. This is a benchmark for a small object in cache fetched 100k times. 40 ink_freelist_new: hdrHeap 30 ink_freelist_new: hdrStrHeap 203541 ink_freelist_new: ioBlockAllocator 199616 proxy allocator thread_alloc: eventAllocator 103554 ink_freelist_new: ioDataAllocator 103554 ink_freelist_new: ioBufAllocator[5] 100100 ink_freelist_new: ioAllocator 10 proxy allocator thread_alloc: hdrHeap 10 proxy allocator thread_alloc: cacheVConnection 10 ink_freelist_new: httpSMAllocator 10 ink_freelist_new: ArenaBlock 18507 ink_freelist_new: mutexAllocator 4772 ink_freelist_new: eventAllocator 162 ink_freelist_new: cacheVConnection 102 ink_freelist_new: netVCAllocator 100 proxy allocator init thread_alloc: httpClientSessionAllocator 100 ink_freelist_new: httpClientSessionAllocator 1 proxy allocator thread_alloc: RamCacheCLFUSEntry 1 ink_freelist_new: RamCacheCLFUSEntry 1 ink_freelist_new: hostDBContAllocator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1728) Need a way to assign storage entries to volumes
[ https://issues.apache.org/jira/browse/TS-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662221#comment-13662221 ] ASF subversion and git services commented on TS-1728: - Commit 1dd14ab9679032d2a6f3a959d9f8da691917c9bf in branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1dd14ab ] TS-1728: Cast float to int64_t Need a way to assign storage entries to volumes --- Key: TS-1728 URL: https://issues.apache.org/jira/browse/TS-1728 Project: Traffic Server Issue Type: Wish Components: Cache Reporter: Jan van Doorn Assignee: Phil Sorber Priority: Minor Fix For: 3.3.3 Attachments: vol.patch See http://www.knutsel.com/vol/compare/ for a write up and some test results on this. We are proposing a simple way to hard link storage.config entries to volume.config and thus hosting.config entries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (TS-1684) Reduce the usage of global allocation/free lists - switch to using local thread allocation/free lists
On Tue, May 21, 2013 at 1:51 AM, Leif Hedstrom (JIRA) j...@apache.orgwrote: [ https://issues.apache.org/jira/browse/TS-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662206#comment-13662206] Leif Hedstrom commented on TS-1684: --- Lets land this, perhaps with a configure option for now? There might be some unforeseen downsides to this much proxy allocation (i.e. bigger memory foot prints). Yes, I hope this feature could enable/disable by an option. Now, reclaimable-freelist are satisfy for us with good speed and controlled usage of memory. But too much proxy allocation may lead to the old problem again. Also, did you change the setup to allow more than the 512 objects that each proxy allocator is allowed to retain? I see two possible ways to change this: 1) Add a new config option (records.config) to allow it to be more (or less) than 512, with a value of '0' meaning no limits. 2) Somehow combine the reclaimable freelist code with the proxy allocators, which combined with a high (or '0') setting above can be used to reclaim objects from the freelist. I haven't checked the patches above, but I think #1 above is a good requirement to control this in some way (and continue to let it fall back to the global allocators as necessary). Exciting results indeed, a huge step towards NUMA awareness! Reduce the usage of global allocation/free lists - switch to using local thread allocation/free lists - Key: TS-1684 URL: https://issues.apache.org/jira/browse/TS-1684 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Bryan Call Assignee: Bryan Call Fix For: 3.3.4 Attachments: ts-1684.patch When running benchmarks ink_freelist_new() normally shows up as one of if not the number one function in the code using the most CPU. Currently ATS uses global free lists (via ClassAllocator, Allocator, and SparceClassAllocator) for memory allocation for some of its memory allocation. Here is a list of how frequently the type of allocations are used and the name given to the allocator. This is a benchmark for a small object in cache fetched 100k times. 40 ink_freelist_new: hdrHeap 30 ink_freelist_new: hdrStrHeap 203541 ink_freelist_new: ioBlockAllocator 199616 proxy allocator thread_alloc: eventAllocator 103554 ink_freelist_new: ioDataAllocator 103554 ink_freelist_new: ioBufAllocator[5] 100100 ink_freelist_new: ioAllocator 10 proxy allocator thread_alloc: hdrHeap 10 proxy allocator thread_alloc: cacheVConnection 10 ink_freelist_new: httpSMAllocator 10 ink_freelist_new: ArenaBlock 18507 ink_freelist_new: mutexAllocator 4772 ink_freelist_new: eventAllocator 162 ink_freelist_new: cacheVConnection 102 ink_freelist_new: netVCAllocator 100 proxy allocator init thread_alloc: httpClientSessionAllocator 100 ink_freelist_new: httpClientSessionAllocator 1 proxy allocator thread_alloc: RamCacheCLFUSEntry 1 ink_freelist_new: RamCacheCLFUSEntry 1 ink_freelist_new: hostDBContAllocator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- Yunkai Zhang Work at Taobao
[jira] [Comment Edited] (TS-1684) Reduce the usage of global allocation/free lists - switch to using local thread allocation/free lists
[
https://issues.apache.org/jira/browse/TS-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662180#comment-13662180
]
Bryan Call edited comment on TS-1684 at 5/20/13 6:05 PM:
-
ats results for 3.2.0_11 - without the proxy allocator patch included in this
bug
{code}
-bash-4.2$ cat out | http_load/merge_stats.pl
Total runs: 13
4112097 fetches on 4764 conns, 1300 max parallell, 5.75693e+09 bytes in 30
seconds
1400 mean bytes/fetch
137069.90 fetches/sec, 1.91898e+08 bytes/sec
msecs/connect: 0.180437538461538 mean, 0.662384615384615 max,
0.0604615384615384 min
msecs/first-response: 9.47338384615385 mean, 162.386230769231 max,
0.152307692307692 min
-bash-4.1$ dstat 10
total-cpu-usage -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
72 10 7 0 0 11| 026k| 31M 224M| 0 0 | 291k 20k
74 10 6 0 0 10| 024k| 31M 228M| 0 0 | 294k 20k
72 10 6 1 0 11| 041M| 31M 227M| 0 0 | 294k 23k
71 10 6 1 0 12| 410B 49M| 31M 223M| 0 0 | 295k 21k
Samples: 2M of event 'cycles', Event count (approx.): 628623285644
23.47% libtsutil.so.3[.] ink_freelist_new
20.22% libtsutil.so.3[.] ink_freelist_free
2.85% [kernel] [k] _spin_lock_bh
1.51% traffic_server[.] HttpSM::_instantiate_func(HttpSM*, Ht
1.35% [kernel] [k] _spin_lock
1.03% traffic_server[.] HdrHeap::destroy()
0.72% libc-2.12.so [.] memcpy
0.72% traffic_server[.] HdrHeap::allocate_obj(int, int)
0.63% [bnx2x] [k] bnx2x_start_xmit
0.60% libpthread-2.12.so[.] pthread_mutex_trylock
0.56% [kernel] [k] copy_user_generic_string
0.50% libpthread-2.12.so[.] pthread_mutex_unlock
0.49% traffic_server[.] HdrHeap::duplicate_str(char const*, i
0.49% traffic_server[.] write_to_net_io(NetHandler*, UnixNetV
0.48% [kernel] [k] tcp_ack
0.47% traffic_server[.] PriorityEventQueue::check_ready(long,
0.46% traffic_server[.] HttpSM::cleanup()
0.46% traffic_server[.] IOBufferBlock::free()
0.44% traffic_server[.] mime_hdr_field_find(MIMEHdrImpl*, cha
0.43% [kernel] [k] skb_release_data
0.42% traffic_server[.] RamCacheCLFUS::get(INK_MD5*, PtrIOBu
{code}
ats results for 3.2.0_12 - with the proxyallocator patch included in this bug
{code}
-bash-4.2$ cat out | http_load/merge_stats.pl Total runs: 13
15551539 fetches on 16174 conns, 1300 max parallell, 2.17722e+10 bytes in 60
seconds
1400 mean bytes/fetch
259192.20 fetches/sec, 3.62869e+08 bytes/sec
msecs/connect: 14.0116384615385 mean, 2503.94692307692 max, 0.0573846153846154
min
msecs/first-response: 4.95988153846154 mean, 302.202153846154 max,
0.100384615384615 min
-bash-4.1$ dstat 10
total-cpu-usage -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
62 16 8 0 0 14| 036k| 60M 438M| 0 0 | 335k 60k
60 16 9 0 0 15| 034k| 60M 432M| 0 0 | 337k 60k
61 16 8 0 0 15| 020M| 59M 430M| 0 0 | 336k 59k
Samples: 1M of event 'cycles', Event count (approx.): 471148870436
8.83% libtsutil.so.3[.] ink_freelist_free
4.49% libtsutil.so.3[.] ink_freelist_new
2.24% traffic_server[.] HttpSM::_instantiate_func(HttpSM*, Ht
2.02% [kernel] [k] _spin_lock_bh
2.01% [kernel] [k] _spin_lock
1.27% libc-2.12.so [.] memcpy
1.09% [bnx2x] [k] bnx2x_start_xmit
1.06% traffic_server[.] PriorityEventQueue::check_ready(long,
1.03% traffic_server[.] this_ethread()
0.99% [kernel] [k] copy_user_generic_string
0.84% [kernel] [k] tcp_ack
0.78% traffic_server[.] HttpSM::cleanup()
0.78% traffic_server[.] mime_hdr_field_find(MIMEHdrImpl*, cha
0.71% traffic_server[.] HdrHeap::allocate_obj(int, int)
0.67% libpthread-2.12.so[.] pthread_getspecific
0.66% traffic_server[.] RamCacheCLFUS::get(INK_MD5*, PtrIOBu
0.63% traffic_server[.] HdrHeap::destroy()
0.63% libpthread-2.12.so[.] pthread_mutex_trylock
0.61% [kernel] [k] kfree
0.60% [bnx2x] [k] bnx2x_rx_int
0.58% traffic_server[.] HdrHeap::duplicate_str(char const*, i
0.52% traffic_server
Re: [jira] [Commented] (TS-1684) Reduce the usage of global allocation/free lists - switch to using local thread allocation/free lists
On Tue, May 21, 2013 at 2:04 AM, Yunkai Zhang yunkai...@gmail.com wrote: On Tue, May 21, 2013 at 1:51 AM, Leif Hedstrom (JIRA) j...@apache.orgwrote: [ https://issues.apache.org/jira/browse/TS-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662206#comment-13662206] Leif Hedstrom commented on TS-1684: --- Lets land this, perhaps with a configure option for now? There might be some unforeseen downsides to this much proxy allocation (i.e. bigger memory foot prints). Yes, I hope this feature could enable/disable by an option. Now, reclaimable-freelist are satisfy for us with good speed and controlled usage of memory. But too much proxy allocation may lead to the old problem again. And actually, reclaimable-freelist is based on thread-local list. Also, did you change the setup to allow more than the 512 objects that each proxy allocator is allowed to retain? I see two possible ways to change this: 1) Add a new config option (records.config) to allow it to be more (or less) than 512, with a value of '0' meaning no limits. 2) Somehow combine the reclaimable freelist code with the proxy allocators, which combined with a high (or '0') setting above can be used to reclaim objects from the freelist. I haven't checked the patches above, but I think #1 above is a good requirement to control this in some way (and continue to let it fall back to the global allocators as necessary). Exciting results indeed, a huge step towards NUMA awareness! Reduce the usage of global allocation/free lists - switch to using local thread allocation/free lists - Key: TS-1684 URL: https://issues.apache.org/jira/browse/TS-1684 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Bryan Call Assignee: Bryan Call Fix For: 3.3.4 Attachments: ts-1684.patch When running benchmarks ink_freelist_new() normally shows up as one of if not the number one function in the code using the most CPU. Currently ATS uses global free lists (via ClassAllocator, Allocator, and SparceClassAllocator) for memory allocation for some of its memory allocation. Here is a list of how frequently the type of allocations are used and the name given to the allocator. This is a benchmark for a small object in cache fetched 100k times. 40 ink_freelist_new: hdrHeap 30 ink_freelist_new: hdrStrHeap 203541 ink_freelist_new: ioBlockAllocator 199616 proxy allocator thread_alloc: eventAllocator 103554 ink_freelist_new: ioDataAllocator 103554 ink_freelist_new: ioBufAllocator[5] 100100 ink_freelist_new: ioAllocator 10 proxy allocator thread_alloc: hdrHeap 10 proxy allocator thread_alloc: cacheVConnection 10 ink_freelist_new: httpSMAllocator 10 ink_freelist_new: ArenaBlock 18507 ink_freelist_new: mutexAllocator 4772 ink_freelist_new: eventAllocator 162 ink_freelist_new: cacheVConnection 102 ink_freelist_new: netVCAllocator 100 proxy allocator init thread_alloc: httpClientSessionAllocator 100 ink_freelist_new: httpClientSessionAllocator 1 proxy allocator thread_alloc: RamCacheCLFUSEntry 1 ink_freelist_new: RamCacheCLFUSEntry 1 ink_freelist_new: hostDBContAllocator -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- Yunkai Zhang Work at Taobao -- Yunkai Zhang Work at Taobao
[jira] [Commented] (TS-1910) Backport to make 3.2.x compile with Clang
[
https://issues.apache.org/jira/browse/TS-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662283#comment-13662283
]
Leif Hedstrom commented on TS-1910:
---
Also portions of 5f65a55.
Backport to make 3.2.x compile with Clang
-
Key: TS-1910
URL: https://issues.apache.org/jira/browse/TS-1910
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Fix For: 3.2.5
Attachments: TS-1910.diff
There are too many bugs to clone for this, so I'm combining it all into one.
The commits to backport, so far, are:
{code}
b216afa3
58205af1
dc3f8ffa
81f9f418
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1910) Backport to make 3.2.x compile with Clang
[
https://issues.apache.org/jira/browse/TS-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662283#comment-13662283
]
Leif Hedstrom edited comment on TS-1910 at 5/20/13 7:02 PM:
Also portions of 043815e7a7a67b79a2ca6fdc3f6d6751e5150411
was (Author: zwoop):
Also portions of 5f65a55.
Backport to make 3.2.x compile with Clang
-
Key: TS-1910
URL: https://issues.apache.org/jira/browse/TS-1910
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Fix For: 3.2.5
Attachments: TS-1910.diff
There are too many bugs to clone for this, so I'm combining it all into one.
The commits to backport, so far, are:
{code}
b216afa3
58205af1
dc3f8ffa
81f9f418
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1910) Backport to make 3.2.x compile with Clang
[
https://issues.apache.org/jira/browse/TS-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662283#comment-13662283
]
Leif Hedstrom edited comment on TS-1910 at 5/20/13 7:06 PM:
Also the getby() portions of a8168127957dbdfcb0aec9ec9d873f7e18304db0
was (Author: zwoop):
Also portions of 043815e7a7a67b79a2ca6fdc3f6d6751e5150411
Backport to make 3.2.x compile with Clang
-
Key: TS-1910
URL: https://issues.apache.org/jira/browse/TS-1910
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Fix For: 3.2.5
Attachments: TS-1910.diff
There are too many bugs to clone for this, so I'm combining it all into one.
The commits to backport, so far, are:
{code}
b216afa3
58205af1
dc3f8ffa
81f9f418
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1910) Backport to make 3.2.x compile with Clang
[
https://issues.apache.org/jira/browse/TS-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662289#comment-13662289
]
ASF subversion and git services commented on TS-1910:
-
Commit d64b863257046024a1228f5337e86478e0f690a8 in branch refs/heads/3.2.x from
[~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d64b863 ]
Added TS-1910 to backport a few select patches to make clang happier.
Backport to make 3.2.x compile with Clang
-
Key: TS-1910
URL: https://issues.apache.org/jira/browse/TS-1910
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Fix For: 3.2.5
Attachments: TS-1910.diff
There are too many bugs to clone for this, so I'm combining it all into one.
The commits to backport, so far, are:
{code}
b216afa3
58205af1
dc3f8ffa
81f9f418
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662551#comment-13662551 ] Zhao Yongming commented on TS-745: -- yeah, I'd like that too, then we don't have to enable that by configure :D Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: weijin Fix For: 3.3.5 Attachments: 0001-TS-745-support-interim-caching-in-storage.patch, ts-745.diff, TS-ssd-2.patch, TS-ssd.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1912) SSL hangs after origin handshake
[ https://issues.apache.org/jira/browse/TS-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662633#comment-13662633 ] ASF subversion and git services commented on TS-1912: - Commit 9db8e0dace509214c59b9c433f2b3eaffab96136 in branch refs/heads/3.2.x from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9db8e0d ] Propose TS-1912 for backport SSL hangs after origin handshake Key: TS-1912 URL: https://issues.apache.org/jira/browse/TS-1912 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach Assignee: James Peach Fix For: 3.3.3 When using SSL with a Netscaler origin, I'm seeing the handshake complete but ATS never issuing the HTTP request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1756) Crash report: kill_tunnel
[
https://issues.apache.org/jira/browse/TS-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662678#comment-13662678
]
Richard Hesse commented on TS-1756:
---
I'm seeing this, too. Similar OS CentOS 5.6 with updates (basically 5.9).
{quote}
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x378480eca0]
/usr/local/bin/traffic_server(_ZN10HttpTunnel15chain_abort_allEP18HttpTunnelProducer+0xaa)[0x56dd5a]
/usr/local/bin/traffic_server(_ZN10HttpTunnel11kill_tunnelEv+0x22)[0x571702]
/usr/local/bin/traffic_server(_ZN6HttpSM28state_watch_for_client_abortEiPv+0x11a)[0x52890a]
/usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xdc)[0x530a3c]
/usr/local/bin/traffic_server[0x694897]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x479)[0x689ed9]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x22f)[0x6b993f]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x5bc)[0x6ba24c]
/usr/local/bin/traffic_server[0x6b8d8e]
/lib64/libpthread.so.0[0x378480683d]
/lib64/libc.so.6(clone+0x6d)[0x37840d4fad]
{quote}
Crash report: kill_tunnel
-
Key: TS-1756
URL: https://issues.apache.org/jira/browse/TS-1756
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Core, HTTP
Affects Versions: 3.2.4
Reporter: helaku
Fix For: 3.3.3
centos 5.9 x64 ts3.2.4 debug log
{code}
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466] State
Transition: API_CACHE_LOOKUP_COMPLETE - SERVE_FROM_CACHE
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http) [3466]
perform_cache_write_action CACHE_DO_SERVE
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect)
[HttpSM::do_redirect]
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding
producer 'cache read'
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) [3466] adding
consumer 'user agent'
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_tunnel) tunnel_run
started, p_arg is NULL
[Mar 19 14:55:40.687] Server {0x4286a940} DEBUG: (http_cs) tcp_init_cwnd_set 1
[Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466]
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Mar 19 14:55:40.687] Server {0x42769940} DEBUG: (http_tunnel) [3466]
consumer_handler [user agent VC_EVENT_WRITE_READY]
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
[SelectFromAlternates] # alternates = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
[SelectFromAlternates] 1 alternates for this cached doc
[alts] There are 1 alternates for this request header.
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match
for ACCEPT CHARSET
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Exact match
for ACCEPT ENCODING
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
[calculate_quality_accept_language_match]: response hdr does not have
content-language.
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: Accept match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: Accept match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Type and Accept 1.00
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: AcceptCharset match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: AcceptCharset match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Type and Accept-Charset 1.001000
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: AcceptEncoding match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: AcceptEncoding match = 1.001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Encoding and Accept-Encoding 1.001000
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_match)
CalcQualityOfMatch: AcceptLanguage match = 1
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_seq)
CalcQualityOfMatch: AcceptLanguage match = 1
[Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021]
[HttpSM::main_handler, VC_EVENT_EOS]
[Mar 19 14:55:40.691] Server {0x42466940} DEBUG: (http) [2021]
[HttpSM::state_watch_for_client_abort, VC_EVENT_EOS]
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate)
Content-Language and Accept-Language 1.00
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG: (http_alternate) Mult's
Quality Factor: 1.002001
[Mar 19 14:55:40.691] Server {0x45294940} DEBUG:
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13662684#comment-13662684 ] John Plevyak commented on TS-745: - I think the idea of stealing bits from the directory which are hard coded to point off device (off the hard disk which the directory is a part of) is a huge design departure and a problem. When the cache was first built, it was limited to 8GB disks which seemed HUGE. For Apache I extended it to .5PB as by then 8GB was far too small. Currently disks are at 4TB and this patch would decrease the limit from .5PB to 32TB which gives us only a few years headroom, not a good idea. Furthermore, the current design let's you unplug any cache disk from any machine, move it to another machine and have your cache back. This change stores SSD information in the HDD directory! why? Changing the configuration, a disk or machine failure, etc. invalidates that information corrupting the cache. Why not store that information in a side structure and either store it only in memory only or on the SSD? The idea of storing the SSD configuration in a string in records.config is also a bad idea. Overall, a stacked cache seems like a better idea or a minimally invasive extension would be great. This patch is pretty invasive, duplicates code and generally touches many bits of the code. The ram cache for example uses no bits in the HDD directory and only a couple entry points at well defined places (insert, lookup and delete/invalidate). This patch looks to incur more technical depth at a time when I think we would like to decrease the technical debt. For example, it would be nice to have more smaller locks, move the HTTP support out of the core via a well defined interface, add layering, etc. Adding yet another set of core code paths is going to make those changes harder. my 2 cents. Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: weijin Fix For: 3.3.5 Attachments: 0001-TS-745-support-interim-caching-in-storage.patch, ts-745.diff, TS-ssd-2.patch, TS-ssd.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1915) header_rewrite uses TSUrlHostSet() when using set-destination PATH
Nick Berry created TS-1915: -- Summary: header_rewrite uses TSUrlHostSet() when using set-destination PATH Key: TS-1915 URL: https://issues.apache.org/jira/browse/TS-1915 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Nick Berry I noticed when using set-destination PATH value that the origin host would be value in the logs. After looking through operators.cc, seems like there was a bad copy/paste where case URL_QUAL_PATH should have used TSUrlPathSet() instead of TSUrlHostSet(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1915) header_rewrite uses TSUrlHostSet() when using set-destination PATH
[ https://issues.apache.org/jira/browse/TS-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Berry updated TS-1915: --- Attachment: TS-1915.patch header_rewrite uses TSUrlHostSet() when using set-destination PATH -- Key: TS-1915 URL: https://issues.apache.org/jira/browse/TS-1915 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Nick Berry Attachments: TS-1915.patch I noticed when using set-destination PATH value that the origin host would be value in the logs. After looking through operators.cc, seems like there was a bad copy/paste where case URL_QUAL_PATH should have used TSUrlPathSet() instead of TSUrlHostSet(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1915) header_rewrite uses TSUrlHostSet() when using set-destination PATH
[ https://issues.apache.org/jira/browse/TS-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Berry updated TS-1915: --- Labels: experimental (was: ) header_rewrite uses TSUrlHostSet() when using set-destination PATH -- Key: TS-1915 URL: https://issues.apache.org/jira/browse/TS-1915 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Nick Berry Labels: experimental Attachments: TS-1915.patch I noticed when using set-destination PATH value that the origin host would be value in the logs. After looking through operators.cc, seems like there was a bad copy/paste where case URL_QUAL_PATH should have used TSUrlPathSet() instead of TSUrlHostSet(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
