[jira] [Commented] (TS-1209) background_fill values don't seem to be working
[ https://issues.apache.org/jira/browse/TS-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261351#comment-13261351 ] Robert Logue commented on TS-1209: -- If you point me in the direction of the documentation of the submission process I will gladly submit a patch, I was looking about for a while and couldn't find what I was looking for background_fill values don't seem to be working --- Key: TS-1209 URL: https://issues.apache.org/jira/browse/TS-1209 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.0.4 Reporter: Robert Logue Priority: Minor Fix For: 3.1.4 If I request a 57 MB file TS caches the fill no problem and on subsequent requests the file gets served from cache. If I cut the request early, about 40MB downloaded and I have proxy.config.http.background_fill_completed_threshold = 0.5 and proxy.config.http.background_fill_active_timeout is suitably high, the file is not cached. I am of the understanding that the background fill values should keep the OS connection open and allow the full item to be cached though this is not happening. I have tried various values for proxy.config.http.background_fill_completed_threshold ranging from 0.0 - 0.5, none seem to work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1209) background_fill values don't seem to be working
[ https://issues.apache.org/jira/browse/TS-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Logue updated TS-1209: - Attachment: TS-1209.patch Affected file : trafficserver-3.0.4/proxy/http/HttpSM.cc. The issue here was that the HttpSM::is_bg_fill_necessary method checks that the connection type on the producer is HT_HTTP_SERVER I have added an OR for this so the connection can now be HT_HTTP_SERVER or HT_TRANSFORM. background_fill values don't seem to be working --- Key: TS-1209 URL: https://issues.apache.org/jira/browse/TS-1209 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.0.4 Reporter: Robert Logue Priority: Minor Fix For: 3.1.4 Attachments: TS-1209.patch If I request a 57 MB file TS caches the fill no problem and on subsequent requests the file gets served from cache. If I cut the request early, about 40MB downloaded and I have proxy.config.http.background_fill_completed_threshold = 0.5 and proxy.config.http.background_fill_active_timeout is suitably high, the file is not cached. I am of the understanding that the background fill values should keep the OS connection open and allow the full item to be cached though this is not happening. I have tried various values for proxy.config.http.background_fill_completed_threshold ranging from 0.0 - 0.5, none seem to work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1209) background_fill values don't seem to be working
[ https://issues.apache.org/jira/browse/TS-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261392#comment-13261392 ] Robert Logue commented on TS-1209: -- I have attached a patch file. I am not sure what else to do with this ticket. background_fill values don't seem to be working --- Key: TS-1209 URL: https://issues.apache.org/jira/browse/TS-1209 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.0.4 Reporter: Robert Logue Priority: Minor Fix For: 3.1.4 Attachments: TS-1209.patch If I request a 57 MB file TS caches the fill no problem and on subsequent requests the file gets served from cache. If I cut the request early, about 40MB downloaded and I have proxy.config.http.background_fill_completed_threshold = 0.5 and proxy.config.http.background_fill_active_timeout is suitably high, the file is not cached. I am of the understanding that the background fill values should keep the OS connection open and allow the full item to be cached though this is not happening. I have tried various values for proxy.config.http.background_fill_completed_threshold ranging from 0.0 - 0.5, none seem to work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1223) Crash report: http_ui show network connections
Zhao Yongming created TS-1223: - Summary: Crash report: http_ui show network connections Key: TS-1223 URL: https://issues.apache.org/jira/browse/TS-1223 Project: Traffic Server Issue Type: Bug Components: HTTP, Management, Network Affects Versions: 3.1.3 Environment: git master with http_ui enabled Reporter: Zhao Yongming Fix For: 3.1.4 {code} (gdb) bt #0 0x0032ee248097 in vfprintf () from /lib64/libc.so.6 #1 0x0032ee26f052 in vsnprintf () from /lib64/libc.so.6 #2 0x005ef411 in ShowCont::show(char const*, ...) () #3 0x00699d67 in ShowNet::showConnectionsOnThread(int, Event*) () #4 0x006a8104 in handleEvent (this=0x2abe3bafb010, e=0x2abee001cb70, calling_code=1) at I_Continuation.h:146 #5 EThread::process_event (this=0x2abe3bafb010, e=0x2abee001cb70, calling_code=1) at UnixEThread.cc:142 #6 0x006a8b7b in EThread::execute (this=0x2abe3bafb010) at UnixEThread.cc:191 #7 0x006a7042 in spawn_thread_internal (a=0x188e600) at Thread.cc:88 #8 0x0032eea077e1 in start_thread () from /lib64/libpthread.so.0 #9 0x0032ee2e68ed in clone () from /lib64/libc.so.6 {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1205) Crash report: double free when RecDataSet in cluster mode
[ https://issues.apache.org/jira/browse/TS-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261482#comment-13261482 ] Zhao Yongming commented on TS-1205: --- here is a quick fix for this: {code} diff --git a/lib/records/RecUtils.cc b/lib/records/RecUtils.cc index b47310f..a337efc 100644 --- a/lib/records/RecUtils.cc +++ b/lib/records/RecUtils.cc @@ -86,7 +86,7 @@ RecDataSet(RecDataT data_type, RecData * data_dst, RecData * data_src) } } else if (((data_dst-rec_string) (strcmp(data_dst-rec_string, data_src-rec_string) != 0)) || ((data_dst-rec_string == NULL) (data_src-rec_string != NULL))) { - ats_free(data_dst-rec_string); + if (data_dst-rec_string) ats_free(data_dst-rec_string); data_dst-rec_string = ats_strdup(data_src-rec_string); rec_set = true; } lines 1-13/13 (END) {code} Crash report: double free when RecDataSet in cluster mode - Key: TS-1205 URL: https://issues.apache.org/jira/browse/TS-1205 Project: Traffic Server Issue Type: Bug Components: Clustering, Configuration Affects Versions: 3.1.3 Environment: v3.0.x, with cluster mode 2 Reporter: Zhao Yongming Assignee: kuotai Fix For: 3.3.0 we have seen some config system syncing config files in cluster mode. {code} *** glibc detected *** /usr/bin/traffic_server: double free or corruption (fasttop): 0x2b639c0009a0 *** === Backtrace: = /lib64/libc.so.6[0x3f8f0750c6] /usr/bin/traffic_server(RecDataSet(RecDataT, RecData*, RecData*)+0xb8)[0x65dd58] /usr/bin/traffic_server(RecForceInsert(RecRecord*)+0x74)[0x6584b4] /usr/bin/traffic_server[0x65cd62] /usr/bin/traffic_server(RecMessageRecvThis(void*, char*, int)+0x16)[0x65ed46] /usr/bin/traffic_server(BaseManager::executeMgmtCallback(int, char*, int)+0x3d)[0x5b562d] /usr/bin/traffic_server(ProcessManager::processEventQueue()+0x29)[0x5b5d49] /usr/bin/traffic_server(startProcessManager(void*)+0x8d)[0x5b633d] /lib64/libpthread.so.0[0x3f8f4077f1] /lib64/libc.so.6(clone+0x6d)[0x3f8f0e570d] === Memory map: {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1223) Crash report: http_ui show network connections
[ https://issues.apache.org/jira/browse/TS-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261589#comment-13261589 ] Zhao Yongming commented on TS-1223: --- {code} [Switching to Thread 0x2b156eb6a700 (LWP 7239)] Breakpoint 1, 0x00699a90 in ShowNet::showConnectionsOnThread(int, Event*) () (gdb) Single stepping until exit from function _ZN7ShowNet23showConnectionsOnThreadEiP5Event, which has no line number information. [Switching to Thread 0x2b156e867700 (LWP 7236)] Breakpoint 1, 0x00699a90 in ShowNet::showConnectionsOnThread(int, Event*) () (gdb) Single stepping until exit from function _ZN7ShowNet23showConnectionsOnThreadEiP5Event, which has no line number information. [Switching to Thread 0x2b156ec6b700 (LWP 7240)] Breakpoint 1, 0x00699a90 in ShowNet::showConnectionsOnThread(int, Event*) () (gdb) Single stepping until exit from function _ZN7ShowNet23showConnectionsOnThreadEiP5Event, which has no line number information. [Switching to Thread 0x2b156e968700 (LWP 7237)] Breakpoint 1, 0x00699a90 in ShowNet::showConnectionsOnThread(int, Event*) () (gdb) Single stepping until exit from function _ZN7ShowNet23showConnectionsOnThreadEiP5Event, which has no line number information. EThread::process_event (this=0x2b1568909010, e=0x2b15a801dc60, calling_code=1) at UnixEThread.cc:145 145 MUTEX_RELEASE(lock); (gdb) 146 if (e-period) { (gdb) 158 } else if (!e-in_the_prot_queue !e-in_the_priority_queue) (gdb) 159 free_event(e); (gdb) 160 } (gdb) 161 } (gdb) EThread::execute (this=0x2b1568909010) at UnixEThread.cc:188 188 while ((e = EventQueueExternal.dequeue_local())) { (gdb) 211 EventQueue.check_ready(cur_time, this); (gdb) [Switching to Thread 0x2b156ea69700 (LWP 7238)] Breakpoint 1, 0x00699a90 in ShowNet::showConnectionsOnThread(int, Event*) () (gdb) Single stepping until exit from function _ZN7ShowNet23showConnectionsOnThreadEiP5Event, which has no line number information. Program received signal SIGSEGV, Segmentation fault. {code} Crash report: http_ui show network connections -- Key: TS-1223 URL: https://issues.apache.org/jira/browse/TS-1223 Project: Traffic Server Issue Type: Bug Components: HTTP, Management, Network Affects Versions: 3.1.3 Environment: git master with http_ui enabled Reporter: Zhao Yongming Fix For: 3.1.4 {code} (gdb) bt #0 0x0032ee248097 in vfprintf () from /lib64/libc.so.6 #1 0x0032ee26f052 in vsnprintf () from /lib64/libc.so.6 #2 0x005ef411 in ShowCont::show(char const*, ...) () #3 0x00699d67 in ShowNet::showConnectionsOnThread(int, Event*) () #4 0x006a8104 in handleEvent (this=0x2abe3bafb010, e=0x2abee001cb70, calling_code=1) at I_Continuation.h:146 #5 EThread::process_event (this=0x2abe3bafb010, e=0x2abee001cb70, calling_code=1) at UnixEThread.cc:142 #6 0x006a8b7b in EThread::execute (this=0x2abe3bafb010) at UnixEThread.cc:191 #7 0x006a7042 in spawn_thread_internal (a=0x188e600) at Thread.cc:88 #8 0x0032eea077e1 in start_thread () from /lib64/libpthread.so.0 #9 0x0032ee2e68ed in clone () from /lib64/libc.so.6 {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1205) Crash report: double free when RecDataSet in cluster mode
[ https://issues.apache.org/jira/browse/TS-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming resolved TS-1205. --- Resolution: Fixed Fix Version/s: (was: 3.3.0) 3.1.4 Assignee: Zhao Yongming (was: kuotai) in d1b18044c473dd0c8d1964084d7ca66968fc0551 Crash report: double free when RecDataSet in cluster mode - Key: TS-1205 URL: https://issues.apache.org/jira/browse/TS-1205 Project: Traffic Server Issue Type: Bug Components: Clustering, Configuration Affects Versions: 3.1.3 Environment: v3.0.x, with cluster mode 2 Reporter: Zhao Yongming Assignee: Zhao Yongming Fix For: 3.1.4 we have seen some config system syncing config files in cluster mode. {code} *** glibc detected *** /usr/bin/traffic_server: double free or corruption (fasttop): 0x2b639c0009a0 *** === Backtrace: = /lib64/libc.so.6[0x3f8f0750c6] /usr/bin/traffic_server(RecDataSet(RecDataT, RecData*, RecData*)+0xb8)[0x65dd58] /usr/bin/traffic_server(RecForceInsert(RecRecord*)+0x74)[0x6584b4] /usr/bin/traffic_server[0x65cd62] /usr/bin/traffic_server(RecMessageRecvThis(void*, char*, int)+0x16)[0x65ed46] /usr/bin/traffic_server(BaseManager::executeMgmtCallback(int, char*, int)+0x3d)[0x5b562d] /usr/bin/traffic_server(ProcessManager::processEventQueue()+0x29)[0x5b5d49] /usr/bin/traffic_server(startProcessManager(void*)+0x8d)[0x5b633d] /lib64/libpthread.so.0[0x3f8f4077f1] /lib64/libc.so.6(clone+0x6d)[0x3f8f0e570d] === Memory map: {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1213) Crash report: update will crash at HttpTransact::process_quick_http_filter
[ https://issues.apache.org/jira/browse/TS-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming reassigned TS-1213: - Assignee: Zhao Yongming Crash report: update will crash at HttpTransact::process_quick_http_filter -- Key: TS-1213 URL: https://issues.apache.org/jira/browse/TS-1213 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.1.3 Environment: git master with update enabled. Reporter: Zhao Yongming Assignee: Zhao Yongming Fix For: 3.1.4 the new ip_allow quick filter may affect the scheduled update functions: {code} NOTE: Traffic Server received Sig 11: Segmentation fault /opt/ats/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0x10bc0)[0x2ab9e4318bc0] /opt/ats/bin/traffic_server(HttpTransact::process_quick_http_filter(HttpTransact::State*, int)+0x3b)[0x5501db] /opt/ats/bin/traffic_server(HttpTransact::EndRemapRequest(HttpTransact::State*)+0x3a1)[0x55ed91] /opt/ats/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void (*)(HttpTransact::State*))+0x62)[0x530202] /opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x54a)[0x54031a] /opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x41c)[0x5401ec] /opt/ats/bin/traffic_server(HttpSM::set_next_state()+0x41c)[0x5401ec] /opt/ats/bin/traffic_server(HttpSM::state_add_to_list(int, void*)+0x18f)[0x53b2df] /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x53c288] /opt/ats/bin/traffic_server(HttpUpdateSM::start_scheduled_update(Continuation*, HTTPHdr*)+0x1c7)[0x576d97] /opt/ats/bin/traffic_server(UpdateSM::http_scheme(UpdateSM*)+0x197)[0x4fbd77] /opt/ats/bin/traffic_server(UpdateSM::HandleSMEvent(int, Event*)+0x378)[0x4f7198] /opt/ats/bin/traffic_server(EThread::process_event(Event*, int)+0x90)[0x6b0250] /opt/ats/bin/traffic_server(EThread::execute()+0x5eb)[0x6b0e0b] /opt/ats/bin/traffic_server[0x6af042] /lib64/libpthread.so.0(+0x8e2c)[0x2ab9e4310e2c] /lib64/libc.so.6(clone+0x6d)[0x2ab9e6beb35d] {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-475) HTTP SM should support efficient byte range requests
[ https://issues.apache.org/jira/browse/TS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261695#comment-13261695 ] bruce lysik commented on TS-475: I have servers which currently receive regular 512k byte range downloads of large files. Let me know if you'd like me to test your patch in this environment. HTTP SM should support efficient byte range requests Key: TS-475 URL: https://issues.apache.org/jira/browse/TS-475 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Leif Hedstrom Assignee: Alan M. Carroll Priority: Critical Fix For: 3.3.0 Attachments: diff.out The cache has support for efficiently locate a particular range in the cached object, but the HTTP SM does not support this. In order to make Range: request efficient (particularly on large objects), the SM should support this new cache feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1219) Crash report: ink_freelist_new causing core dumps
[ https://issues.apache.org/jira/browse/TS-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261813#comment-13261813 ] Leif Hedstrom commented on TS-1219: --- Any chance you can test either 3.0.4 or better, trunk ? I don't know that this has been fixed, but I know there's been a number of fixes on the freelist code since 3.0. Crash report: ink_freelist_new causing core dumps - Key: TS-1219 URL: https://issues.apache.org/jira/browse/TS-1219 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.2 Reporter: Manjesh Nilange Our TS based production boxes are seeing a couple of crashes per day with stack traces ending in #3 0x004c85ea in signal_handler (sig=11) at signals.cc:225 #4 signal handler called #5 0x003312414160 in ink_freelist_new (f=0x3312629ce0) at ink_queue.cc:326 #6 0x00331240d47a in alloc_void (this=0x7fff80173cd8, size=511, alignment=1) at Allocator.h:208 #7 blk_alloc (this=0x7fff80173cd8, size=511, alignment=1) at Arena.cc:45 #8 Arena::alloc (this=0x7fff80173cd8, size=511, alignment=1) at Arena.cc:118 #9 0x00569b93 in str_alloc (arena=value optimized out, url=0x31be6a8 *..., len_in=value optimized out, len_out=0x7fff80173d20) at ../../lib/ts/Arena.h:123 #10 LogUtils::escapify_url (arena=value optimized out, url=0x31be6a8 *..., len_in=value optimized out, len_out=0x7fff80173d20) at LogUtils.cc:392 #11 0x005482e9 in LogAccessHttp::init (this=0x7fff80173cc0) at LogAccessHttp.cc:98 #12 0x0054b436 in Log::access (lad=0x7fff80173cc0) at Log.cc:1055 #13 0x004f3085 in HttpSM::update_stats (this=0x2ae5480651e0) at HttpSM.cc:6044 #14 0x004f8918 in HttpSM::kill_this (this=0x2ae5480651e0) at HttpSM.cc:6005 #15 0x004f8c08 in HttpSM::main_handler (this=0x2ae5480651e0, event=2301, data=0x2ae548066ec8) at HttpSM.cc:2452 The URL was valid, I just anonymized it. This is our environment $ uname -a Linux xxx.prod 2.6.32-131.4.1.el6.x86_64 #1 SMP Fri Jun 10 10:54:26 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux $ file /usr/bin/traffic_server /usr/bin/traffic_server: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped There doesn't seem to be more useful information in the frame: (gdb) f 5 #5 0x003312414160 in ink_freelist_new (f=0x3312629ce0) at ink_queue.cc:326 326 FREELIST_VERSION(item) + 1); (gdb) list 321 fastalloc_mem_in_use += f-chunk_size * f-type_size; 322 #endif 323 324 } else { 325 SET_FREELIST_POINTER_VERSION(next, *ADDRESS_OF_NEXT(TO_PTR(FREELIST_POINTER(item)), f-offset), 326 FREELIST_VERSION(item) + 1); 327 #if !defined(INK_USE_MUTEX_FOR_FREELISTS) 328 result = ink_atomic_cas64((int64_t *) f-head.data, item.data, next.data); 329 #else 330 f-head.data = next.data; (gdb) p next $2 = value optimized out (gdb) p f $3 = (InkFreeList *) 0x3312629ce0 (gdb) p *f $4 = {head = {data = -8941773651046140890}, name = 0x331241e92f ArenaBlock, type_size = 1024, chunk_size = 128, count = 519, allocated = 1536, offset = 0, alignment = 8, allocated_base = 0, count_base = 0} (gdb) p item $5 = {data = -8953314125091277786} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1225) doc_size still gets casted to int in a few places
Leif Hedstrom created TS-1225: - Summary: doc_size still gets casted to int in a few places Key: TS-1225 URL: https://issues.apache.org/jira/browse/TS-1225 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.4 This was also discussed on TS-475, and discovered by bwyatt. I'm filing a separate bug, since I think this should be fixed independent of TS-475. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1225) doc_size still gets casted to int in a few places
[ https://issues.apache.org/jira/browse/TS-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1225: - Assignee: John Plevyak (was: Leif Hedstrom) Giving to john :). doc_size still gets casted to int in a few places - Key: TS-1225 URL: https://issues.apache.org/jira/browse/TS-1225 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Leif Hedstrom Assignee: John Plevyak Fix For: 3.1.4 This was also discussed on TS-475, and discovered by bwyatt. I'm filing a separate bug, since I think this should be fixed independent of TS-475. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1226) header_filter does not allow for e.g. '=' in header values.
Leif Hedstrom created TS-1226: - Summary: header_filter does not allow for e.g. '=' in header values. Key: TS-1226 URL: https://issues.apache.org/jira/browse/TS-1226 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.4 E.g. a rule like {code} [READ_RESPONSE_HDR] Cache-Control =max-age=123= {code} does not work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1225) doc_size still gets casted to int in a few places
[ https://issues.apache.org/jira/browse/TS-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Plevyak updated TS-1225: - Attachment: ts-1225.diff Remove cast to 32bits of doc_len. doc_size still gets casted to int in a few places - Key: TS-1225 URL: https://issues.apache.org/jira/browse/TS-1225 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Leif Hedstrom Assignee: John Plevyak Fix For: 3.1.4 Attachments: ts-1225.diff This was also discussed on TS-475, and discovered by bwyatt. I'm filing a separate bug, since I think this should be fixed independent of TS-475. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1130) ink_time_t is 64bit on x86_64
[ https://issues.apache.org/jira/browse/TS-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom closed TS-1130. - Resolution: Fixed Assignee: (was: weijin) I believe this is fixed, so closing it. ink_time_t is 64bit on x86_64 - Key: TS-1130 URL: https://issues.apache.org/jira/browse/TS-1130 Project: Traffic Server Issue Type: Sub-task Components: Core Reporter: Zhao Yongming Fix For: 3.1.4 Attachments: TS-1130.diff, TS-1130.try2.diff, TS-1130.try3.diff Weijin: paste your patch here, :D -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1221) Not able to query Dead hosts
[ https://issues.apache.org/jira/browse/TS-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262252#comment-13262252 ] Leif Hedstrom commented on TS-1221: --- I'm not sure, but I think congestion control code is missing vital parts that was never open sourced (such as the ARM kernel module). But again, I'm not 100% sure. Does anyone know? If it's crippled, we should make sure to clean up the configs and traffic_line etc. Not able to query Dead hosts Key: TS-1221 URL: https://issues.apache.org/jira/browse/TS-1221 Project: Traffic Server Issue Type: Bug Components: Stats Affects Versions: 3.0.2 Environment: RHEL 6.1 Reporter: Sachin Balan I have enabled the congestion control feature in traffic server using following configurations. CONFIG proxy.config.http.congestion_control.enabled INT 1 CONFIG proxy.config.raf.enabled INT 1 CONFIG proxy.config.raf.port INT 9000 When I query deadhosts using following command I get following error. # ./traffic_line -q Query Deadhosts is not implemented, it requires support for congestion control. For more details, examine the old code in cli/CLI.cc: QueryDeadhosts() error: the requested command failed Is there any other configuration that I am missing out on? Thanks in advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1185) fails to build from source with gcc 4.7
[ https://issues.apache.org/jira/browse/TS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-1185: Assignee: Brian Geffon (was: Leif Hedstrom) fails to build from source with gcc 4.7 --- Key: TS-1185 URL: https://issues.apache.org/jira/browse/TS-1185 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.3, 3.0.4 Environment: Debian Unstable with gcc 4.7 Reporter: Arno Toell Assignee: Brian Geffon Fix For: 3.1.4 Attachments: trafficserver-gcc47.patch Using gcc 4.7, ATS fails to build from source. See Debian bug 667396 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667396) for further information. gcc 4.7 fails with {code} g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem -I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb -I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils -I../../iocore/dns -I../../proxy -I../../lib/records -I../../mgmt -I../../mgmt/preparse -I../../mgmt/utils -I../../proxy/hdrs -I../../proxy/http/remap -I../../proxy/logging -D_FORTIFY_SOURCE=2 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -Dlinux -I/usr/include/tcl8.5 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -pipe -Wall -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof -MT HttpClientSession.o -MD -MP -MF .deps/HttpClientSession.Tpo -c -o HttpClientSession.o HttpClientSession.cc In file included from ../../lib/ts/libts.h:96:0, from HttpClientSession.h:35, from HttpClientSession.cc:35: ../../lib/ts/Map.h: In instantiation of 'C MapK, C, A::get(K) [with K = unsigned int; C = int; A = DefaultAlloc]': HttpConnectionCount.h:51:34: required from here ../../lib/ts/Map.h:240:29: error: 'set_in' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../lib/ts/Map.h:240:29: note: declarations in dependent base 'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified lookup ../../lib/ts/Map.h:240:29: note: use 'this-set_in' instead ../../lib/ts/Map.h: In instantiation of 'MapElemK, C* MapK, C, A::put(K, C) [with K = unsigned int; C = int; A = DefaultAlloc]': HttpConnectionCount.h:64:37: required from here ../../lib/ts/Map.h:258:29: error: 'set_in' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../lib/ts/Map.h:258:29: note: declarations in dependent base 'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified lookup ../../lib/ts/Map.h:258:29: note: use 'this-set_in' instead ../../lib/ts/Map.h:263:21: error: 'set_add' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../lib/ts/Map.h:263:21: note: declarations in dependent base 'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified lookup ../../lib/ts/Map.h:263:21: note: use 'this-set_add' instead make[4]: *** [HttpClientSession.o] Error 1 {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1185) fails to build from source with gcc 4.7
[ https://issues.apache.org/jira/browse/TS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-1185: - Backport to Version: 3.0.5 fails to build from source with gcc 4.7 --- Key: TS-1185 URL: https://issues.apache.org/jira/browse/TS-1185 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.3, 3.0.4 Environment: Debian Unstable with gcc 4.7 Reporter: Arno Toell Assignee: Brian Geffon Fix For: 3.1.4 Attachments: trafficserver-gcc47.patch Using gcc 4.7, ATS fails to build from source. See Debian bug 667396 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667396) for further information. gcc 4.7 fails with {code} g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem -I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb -I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils -I../../iocore/dns -I../../proxy -I../../lib/records -I../../mgmt -I../../mgmt/preparse -I../../mgmt/utils -I../../proxy/hdrs -I../../proxy/http/remap -I../../proxy/logging -D_FORTIFY_SOURCE=2 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -Dlinux -I/usr/include/tcl8.5 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -pipe -Wall -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof -MT HttpClientSession.o -MD -MP -MF .deps/HttpClientSession.Tpo -c -o HttpClientSession.o HttpClientSession.cc In file included from ../../lib/ts/libts.h:96:0, from HttpClientSession.h:35, from HttpClientSession.cc:35: ../../lib/ts/Map.h: In instantiation of 'C MapK, C, A::get(K) [with K = unsigned int; C = int; A = DefaultAlloc]': HttpConnectionCount.h:51:34: required from here ../../lib/ts/Map.h:240:29: error: 'set_in' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../lib/ts/Map.h:240:29: note: declarations in dependent base 'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified lookup ../../lib/ts/Map.h:240:29: note: use 'this-set_in' instead ../../lib/ts/Map.h: In instantiation of 'MapElemK, C* MapK, C, A::put(K, C) [with K = unsigned int; C = int; A = DefaultAlloc]': HttpConnectionCount.h:64:37: required from here ../../lib/ts/Map.h:258:29: error: 'set_in' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../lib/ts/Map.h:258:29: note: declarations in dependent base 'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified lookup ../../lib/ts/Map.h:258:29: note: use 'this-set_in' instead ../../lib/ts/Map.h:263:21: error: 'set_add' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../lib/ts/Map.h:263:21: note: declarations in dependent base 'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified lookup ../../lib/ts/Map.h:263:21: note: use 'this-set_add' instead make[4]: *** [HttpClientSession.o] Error 1 {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1116) Fix build issues with clang (particularly on OSX)
[ https://issues.apache.org/jira/browse/TS-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon resolved TS-1116. -- Resolution: Fixed Fix Version/s: 3.0.5 Backported to 3.0.x in commit 944d5babae425706e6238904ee2df621a68ef010 Fix build issues with clang (particularly on OSX) - Key: TS-1116 URL: https://issues.apache.org/jira/browse/TS-1116 Project: Traffic Server Issue Type: Improvement Affects Versions: 3.0.4, 3.0.3 Reporter: Leif Hedstrom Assignee: Brian Geffon Fix For: 3.0.5, 3.1.3 Attachments: TS-1116.diff We should get it to compile with clang again, specially since on OSX, clang is the 'future'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1185) fails to build from source with gcc 4.7
[ https://issues.apache.org/jira/browse/TS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon resolved TS-1185. -- Resolution: Fixed Fix Version/s: 3.0.5 Backported to 3.0.x in commit 944d5babae425706e6238904ee2df621a68ef010 fails to build from source with gcc 4.7 --- Key: TS-1185 URL: https://issues.apache.org/jira/browse/TS-1185 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.3, 3.0.4 Environment: Debian Unstable with gcc 4.7 Reporter: Arno Toell Assignee: Brian Geffon Fix For: 3.1.4, 3.0.5 Attachments: trafficserver-gcc47.patch Using gcc 4.7, ATS fails to build from source. See Debian bug 667396 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667396) for further information. gcc 4.7 fails with {code} g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem -I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb -I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils -I../../iocore/dns -I../../proxy -I../../lib/records -I../../mgmt -I../../mgmt/preparse -I../../mgmt/utils -I../../proxy/hdrs -I../../proxy/http/remap -I../../proxy/logging -D_FORTIFY_SOURCE=2 -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -Dlinux -I/usr/include/tcl8.5 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -pipe -Wall -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof -MT HttpClientSession.o -MD -MP -MF .deps/HttpClientSession.Tpo -c -o HttpClientSession.o HttpClientSession.cc In file included from ../../lib/ts/libts.h:96:0, from HttpClientSession.h:35, from HttpClientSession.cc:35: ../../lib/ts/Map.h: In instantiation of 'C MapK, C, A::get(K) [with K = unsigned int; C = int; A = DefaultAlloc]': HttpConnectionCount.h:51:34: required from here ../../lib/ts/Map.h:240:29: error: 'set_in' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../lib/ts/Map.h:240:29: note: declarations in dependent base 'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified lookup ../../lib/ts/Map.h:240:29: note: use 'this-set_in' instead ../../lib/ts/Map.h: In instantiation of 'MapElemK, C* MapK, C, A::put(K, C) [with K = unsigned int; C = int; A = DefaultAlloc]': HttpConnectionCount.h:64:37: required from here ../../lib/ts/Map.h:258:29: error: 'set_in' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../lib/ts/Map.h:258:29: note: declarations in dependent base 'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified lookup ../../lib/ts/Map.h:258:29: note: use 'this-set_in' instead ../../lib/ts/Map.h:263:21: error: 'set_add' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../lib/ts/Map.h:263:21: note: declarations in dependent base 'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by unqualified lookup ../../lib/ts/Map.h:263:21: note: use 'this-set_add' instead make[4]: *** [HttpClientSession.o] Error 1 {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1210) remove 3.0.x deprecated APIs
[ https://issues.apache.org/jira/browse/TS-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1210. - Resolution: Fixed commit 2cee56fc75f537a52d2695d7d2322feec4acdf27 Author: James Peach jpe...@apache.org Date: Wed Apr 18 20:47:10 2012 -0700 TS-1210: remove 3.0.x deprecated APIs remove 3.0.x deprecated APIs Key: TS-1210 URL: https://issues.apache.org/jira/browse/TS-1210 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: James Peach Assignee: James Peach Fix For: 3.1.4 We should remove the following APIs that were deprecated in 3.0: tsapi TSReturnCode TSUrlDestroy(TSMBuffer bufp, TSMLoc offset); tsapi TS_DEPRECATED unsigned int TSHttpTxnClientIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED TSReturnCode TSHttpTxnClientRemotePortGet(TSHttpTxn txnp, int* portp); tsapi TS_DEPRECATED int TSHttpTxnClientIncomingPortGet(TSHttpTxn txnp); tsapi TS_DEPRECATED unsigned int TSHttpTxnServerIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED unsigned int TSHttpTxnNextHopIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED int TSHttpTxnNextHopPortGet(TSHttpTxn txnp); tsapi TS_DEPRECATED int TSHttpTxnMaxArgCntGet(void); tsapi TS_DEPRECATED unsigned int TSNetVConnRemoteIPGet(TSVConn vc); tsapi TS_DEPRECATED int TSNetVConnRemotePortGet(TSVConn vc); tsapi TS_DEPRECATED unsigned int TSHostLookupResultIPGet(TSHostLookupResult lookup_result); tsapi TS_DEPRECATED void TSOSIpSet(TSHttpTxn txnp, unsigned int ip); tsapi TS_DEPRECATED void TSIOBufferAppend(TSIOBuffer bufp, TSIOBufferBlock blockp); tsapi TS_DEPRECATED TSIOBufferData TSIOBufferDataCreate(void* data, int size, TSIOBufferDataFlags flags); tsapi TS_DEPRECATED TSIOBufferBlock TSIOBufferBlockCreate(TSIOBufferData datap, int size, int offset); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira