[jira] [Created] (TS-1955) read_while_writer sends wrong response for range request.
jaekyung oh created TS-1955: --- Summary: read_while_writer sends wrong response for range request. Key: TS-1955 URL: https://issues.apache.org/jira/browse/TS-1955 Project: Traffic Server Issue Type: Bug Reporter: jaekyung oh Basically read_while_writer works fine when ATS handles normal file. In progressive download and playback of mp4 in which moov atom is placed at the end of the file, ATS makes and returns wrong response for range request from unfulfilled cache when read_while_writer is 1. In origin, apache has h264 streaming module. Everything is ok whether the moov atom is placed at the beginning of the file or not in origin except a range request happens with read_while_writer. Mostly our customer’s contents placed moov atom at the end of the file and in the case movie player stops playing when it seek somewhere in the movie. to check if read_while_writer works fine, 1. prepare a mp4 file whose moov atom is placed at the end of the file. 2. curl --range - http://www.test.com/mp4/test.mp4 1 no_cache_from_origin 3. wget http://www.test.com/mp4/test.mp4 4. right after wget, execute “curl --range - http://www.test.com/mp4/test.mp4 1 from_read_while_writer” on other terminal (the point is sending range request while ATS is still downloading) 5. after wget gets done, curl --range - http://www.test.com/mp4/test.mp4 1 from_cache 6. you can check compare those files by bindiff. The response from origin(no_cache_from_origin) for the range request is exactly same to from_cache resulted from #5's range request. but from_read_while_writer from #4 is totally different from others. i think a range request should be forwarded to origin server if it can’t find the content with the offset in cache even if the read_while_writer is on, instead ATS makes(from where?) and sends wrong response. (In squid.log it indicates TCP_HIT) That’s why a movie player stops when it seeks right after the movie starts. Well. we turned off read_while_writer and movie play is ok but the problems is read_while_writer is global options. we can’t set it differently for each remap entry by conf_remap. So the downloading of Big file(not mp4 file) gives overhead to origin server because read_while_writer is off. -- 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-1955) read_while_writer sends wrong response for range request.
[ https://issues.apache.org/jira/browse/TS-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jaekyung oh updated TS-1955: Component/s: Core Affects Version/s: 3.2.4 read_while_writer sends wrong response for range request. - Key: TS-1955 URL: https://issues.apache.org/jira/browse/TS-1955 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.2.4 Reporter: jaekyung oh Basically read_while_writer works fine when ATS handles normal file. In progressive download and playback of mp4 in which moov atom is placed at the end of the file, ATS makes and returns wrong response for range request from unfulfilled cache when read_while_writer is 1. In origin, apache has h264 streaming module. Everything is ok whether the moov atom is placed at the beginning of the file or not in origin except a range request happens with read_while_writer. Mostly our customer’s contents placed moov atom at the end of the file and in the case movie player stops playing when it seek somewhere in the movie. to check if read_while_writer works fine, 1. prepare a mp4 file whose moov atom is placed at the end of the file. 2. curl --range - http://www.test.com/mp4/test.mp4 1 no_cache_from_origin 3. wget http://www.test.com/mp4/test.mp4 4. right after wget, execute “curl --range - http://www.test.com/mp4/test.mp4 1 from_read_while_writer” on other terminal (the point is sending range request while ATS is still downloading) 5. after wget gets done, curl --range - http://www.test.com/mp4/test.mp4 1 from_cache 6. you can check compare those files by bindiff. The response from origin(no_cache_from_origin) for the range request is exactly same to from_cache resulted from #5's range request. but from_read_while_writer from #4 is totally different from others. i think a range request should be forwarded to origin server if it can’t find the content with the offset in cache even if the read_while_writer is on, instead ATS makes(from where?) and sends wrong response. (In squid.log it indicates TCP_HIT) That’s why a movie player stops when it seeks right after the movie starts. Well. we turned off read_while_writer and movie play is ok but the problems is read_while_writer is global options. we can’t set it differently for each remap entry by conf_remap. So the downloading of Big file(not mp4 file) gives overhead to origin server because read_while_writer is off. -- 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-1923) 3.2.x - Fix resolve_logfield_string()
[ https://issues.apache.org/jira/browse/TS-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683341#comment-13683341 ] ASF subversion and git services commented on TS-1923: - Commit 71bbb07c79b2c2e6cb554473dd57caf25b88bb64 in branch refs/heads/3.2.x from [~i.galic] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=71bbb07 ] promote TS-1923 3.2.x - Fix resolve_logfield_string() - Key: TS-1923 URL: https://issues.apache.org/jira/browse/TS-1923 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.2.4 Reporter: Yunkai Zhang Assignee: Igor Galić Fix For: 3.2.5 Attachments: 0001-Fix-resolve_logfield_string.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(). === Now, we found the root cause which would lead to internal_msg_buffer_size to 0 while internal_msg_buffer is NOT NULL. That is resolve_logfiled_string() function. Let's fix it. -- 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-1923) 3.2.x - Fix resolve_logfield_string()
[ https://issues.apache.org/jira/browse/TS-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683340#comment-13683340 ] ASF subversion and git services commented on TS-1923: - Commit 9f8195f443e1e16862cbb7abc0497ec64dafd025 in branch refs/heads/3.2.x from [~yunkai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9f8195f ] TS-1923: Fix resolve_logfield_string() When bytes_resolved is 0, we should free result directly, or it will return the not-null result to the caller with the strlen(result) is 0, which will lead to ATS crash. Signed-off-by: Yunkai Zhang qiushu@taobao.com Signed-off-by: Zhao Yongming ming@gmail.com Conflicts: CHANGES test/review: igalic, sorber, zwoop backport: igalic 3.2.x - Fix resolve_logfield_string() - Key: TS-1923 URL: https://issues.apache.org/jira/browse/TS-1923 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.2.4 Reporter: Yunkai Zhang Assignee: Igor Galić Fix For: 3.2.5 Attachments: 0001-Fix-resolve_logfield_string.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(). === Now, we found the root cause which would lead to internal_msg_buffer_size to 0 while internal_msg_buffer is NOT NULL. That is resolve_logfiled_string() function. Let's fix it. -- 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-1956) Under Heavy Load TS 3.3.4-dev can't (re)start
[
https://issues.apache.org/jira/browse/TS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1956:
Fix Version/s: 3.3.6
Under Heavy Load TS 3.3.4-dev can't (re)start
-
Key: TS-1956
URL: https://issues.apache.org/jira/browse/TS-1956
Project: Traffic Server
Issue Type: Bug
Reporter: Tommy Lee
Fix For: 3.3.6
Hi,
We run TS in forward mode, under REALLY HEAVY load. Currently we run version
3.3.2-dev without problems.
But today, we tried to upgrade to version 3.3.4-dev without lucky.
We've noticed that, if TS restarts, it enters in this Segfault Loop.
Below are traffic.out logs with debug .*
I'll try to debug with GDB too, but I cannot stop this server for too long,
because of our operations.
Thanks in advance.
{code}
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fd9e0 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fdd00 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.81.5:46089 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.101.4:41361 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.156.38:59164 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5413700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c00] accepted connection from
10.202.81.5:46089 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.35.9:51533 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.201.20:10964 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5615700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015a80] accepted connection from
10.200.156.38:59164 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.148.2:44203 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fe020 on port 3128 as inbound transparent
[Jun 14 11:54:14.564] Server {0x2b06a5514700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015d20] accepted connection from
10.202.101.4:41361 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b06a5817700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015540] accepted connection from
10.200.201.20:10964 transport type = 0NOTE: Traffic Server received Sig 11:
Segmentation fault
/usr/local/cache-3.3.4/bin/traffic_server - STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
NOTE: Traffic Server received Sig 11: Segmentation fault
[Jun 14 11:54:14.564] Server {0x2b06a5716700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c0157e0] accepted connection from
10.200.35.9:51533 transport type = 0/usr/local/cache-3.3.4/bin/traffic_server
- STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b085c120700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.131.24:65434 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.157.26:52514 - *Not IP address [0]*:0
[Jun 14 11:54:14.565] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server].
[jira] [Updated] (TS-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1486: Fix Version/s: (was: 3.3.5) sometime drop solaris studio support --- Key: TS-1486 URL: https://issues.apache.org/jira/browse/TS-1486 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Igor Galić Fix For: sometime We should drop Solaris Studio support for the 3.4 release. -- 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-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1453: Fix Version/s: (was: 3.3.5) sometime remove InactivityCop and enable define INACTIVITY_TIMEOUT - Key: TS-1453 URL: https://issues.apache.org/jira/browse/TS-1453 Project: Traffic Server Issue Type: Sub-task Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Labels: A Fix For: sometime Attachments: TS-1453.patch when we have O(1), then we can be enable define INACTIVITY_TIMEOUT -- 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-1255) Add more overridable records.config configurations
[
https://issues.apache.org/jira/browse/TS-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1255:
Fix Version/s: (was: 3.3.5)
sometime
Add more overridable records.config configurations
--
Key: TS-1255
URL: https://issues.apache.org/jira/browse/TS-1255
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Labels: A
Fix For: sometime
We should examine at least the following configs, and see which ones can (or
can not) be moved to be overridable:
{code}
MgmtInt server_max_connections;
MgmtInt origin_min_keep_alive_connections; // TODO: This one really ought
to be overridable, but difficult right now.
char *proxy_request_via_string;
int proxy_request_via_string_len;
char *proxy_response_via_string;
int proxy_response_via_string_len;
MgmtInt origin_server_pipeline;
MgmtInt user_agent_pipeline;
MgmtInt transaction_active_timeout_in;
MgmtInt accept_no_activity_timeout;
MgmtInt background_fill_active_timeout;
MgmtFloat background_fill_threshold;
MgmtInt parent_connect_attempts;
MgmtInt per_parent_connect_attempts;
MgmtInt parent_connect_timeout;
MgmtByte insert_age_in_response;
MgmtByte avoid_content_spoofing;
MgmtByte enable_http_stats;
MgmtInt max_cache_open_write_retries;
MgmtByte cache_enable_default_vary_headers;
MgmtByte cache_when_to_add_no_cache_to_msie_requests;
MgmtByte cache_range_lookup;
MgmtInt request_hdr_max_size;
MgmtInt response_hdr_max_size;
MgmtByte push_method_enabled;
MgmtByte referer_filter_enabled;
MgmtByte referer_format_redirect;
MgmtByte accept_encoding_filter_enabled;
// WTF!!! Bool ???
/// Accept connections on foreign addresses.
bool client_transparency_enabled;
/// Use client address to connect to origin server.
bool server_transparency_enabled;
MgmtByte negative_revalidating_enabled;
MgmtInt negative_revalidating_lifetime;
MgmtByte ignore_accept_mismatch;
MgmtByte ignore_accept_language_mismatch;
MgmtByte ignore_accept_encoding_mismatch;
MgmtByte ignore_accept_charset_mismatch;
// Optimize gzip alternates //
MgmtByte normalize_ae_gzip;
{code}
Marking this for v3.3.0, it'd be nice to get into 3.2, but I rather have us
just get 3.1.4/3.2 done sooner rather than later.
--
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-1798) Crash report: UnixNetProcessor::connect_re_internal UnixNetProcessor::allocateThread
[
https://issues.apache.org/jira/browse/TS-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1798:
Fix Version/s: (was: 3.3.5)
sometime
Crash report: UnixNetProcessor::connect_re_internal
UnixNetProcessor::allocateThread
---
Key: TS-1798
URL: https://issues.apache.org/jira/browse/TS-1798
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Labels: crash
Fix For: sometime
here is a stack which occured in the current master tree
{code}
[root@localhost trafficserver]# cat traffic.out
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2afd236e5500]
/usr/bin/traffic_server(UnixNetProcessor::allocateThread(EThread*)+0x4)[0x66b404]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x2e)[0x66c27e]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x6a8)[0x5287f8]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4dd)[0x52fbad]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x52ac94]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x52c858]
/usr/bin/traffic_server[0x66ee21]
/usr/bin/traffic_server[0x6731b5]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x669ff2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2afd236dd851]
/lib64/libc.so.6(clone+0x6d)[0x2afd25d6f11d]
[TrafficServer] using root directory '/usr
{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] [Updated] (TS-1637) nodes as idle/dead if we have not heard from them in awhile
[ https://issues.apache.org/jira/browse/TS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1637: Fix Version/s: (was: 3.3.5) sometime nodes as idle/dead if we have not heard from them in awhile --- Key: TS-1637 URL: https://issues.apache.org/jira/browse/TS-1637 Project: Traffic Server Issue Type: Improvement Components: Clustering, Management Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Fix For: sometime Attachments: TS-1637.patch in ClusterCom::sendReliableMessageReadTillClose(), if we can't connect peer node quickly(if timeout, will 30s(default peer_timeout)), then won't send Shared date called by ClusterCom::sendSharedData. So peer node will marking me down. -- 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-1901) Update all build instructions in prep for v3.4.0
[ https://issues.apache.org/jira/browse/TS-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1901: Fix Version/s: (was: 3.3.5) sometime Update all build instructions in prep for v3.4.0 Key: TS-1901 URL: https://issues.apache.org/jira/browse/TS-1901 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: sometime We should update the README and INSTALL, as well as the CWIKI pages for all build instructions. -- 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-1280) cache control rule matching performance tweak
[ https://issues.apache.org/jira/browse/TS-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1280: Fix Version/s: (was: 3.3.5) sometime cache control rule matching performance tweak - Key: TS-1280 URL: https://issues.apache.org/jira/browse/TS-1280 Project: Traffic Server Issue Type: Improvement Components: Configuration, HTTP, Performance Affects Versions: 3.1.4 Reporter: Zhao Yongming Assignee: Bin Chen Fix For: sometime Attachments: url.patch in a big hosting env, you may create many rules in cache.config, the performance of the matching is critical, much liking remap, we need do some performance tweak: 1, how can we handle 1000+ rules? 2, can we handle the full URL match? 3, how to handle the path match, the better way ... place this issue as a track for all performance improvement -- 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-1821) AIO tests don't build with native AIO
[ https://issues.apache.org/jira/browse/TS-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1821: Fix Version/s: (was: 3.3.5) sometime AIO tests don't build with native AIO - Key: TS-1821 URL: https://issues.apache.org/jira/browse/TS-1821 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Assignee: weijin Fix For: sometime Attachments: ts-1821.wj.diff /opt/src/trafficserver.git/configure --prefix=/opt/ats --enable-linux-native-aio make -j 4 make check test_AIO-test_AIO.o: In function `main': /opt/src/trafficserver.git/iocore/aio/test_AIO.cc:498: undefined reference to `cache_config_threads_per_disk' collect2: error: ld returned 1 exit status -- 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-1707) FreeBSD disk calculations are wrong
[ https://issues.apache.org/jira/browse/TS-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1707: Fix Version/s: (was: 3.3.5) sometime FreeBSD disk calculations are wrong --- Key: TS-1707 URL: https://issues.apache.org/jira/browse/TS-1707 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.3.1, 3.2.4 Reporter: Ben Aitchison Assignee: Igor Galić Fix For: sometime FreeBSD miscalculates disk size based on config by 2x for file-based, and 16x for raw-based. -- 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-1405) apply time-wheel scheduler about event system
[ https://issues.apache.org/jira/browse/TS-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1405: Fix Version/s: (was: 3.3.5) sometime apply time-wheel scheduler about event system -- Key: TS-1405 URL: https://issues.apache.org/jira/browse/TS-1405 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Bin Chen Fix For: sometime Attachments: linux_time_wheel.patch, linux_time_wheel_v10jp.patch, linux_time_wheel_v11jp.patch, linux_time_wheel_v2.patch, linux_time_wheel_v3.patch, linux_time_wheel_v4.patch, linux_time_wheel_v5.patch, linux_time_wheel_v6.patch, linux_time_wheel_v7.patch, linux_time_wheel_v8.patch, linux_time_wheel_v9jp.patch when have more and more event in event system scheduler, it's worse. This is the reason why we use inactivecop to handler keepalive. the new scheduler is time-wheel. It's have better time complexity(O(1)) -- 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-1933) Uninformative warnings from traffic_manager on startup
[
https://issues.apache.org/jira/browse/TS-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1933:
Fix Version/s: (was: 3.3.5)
sometime
Uninformative warnings from traffic_manager on startup
--
Key: TS-1933
URL: https://issues.apache.org/jira/browse/TS-1933
Project: Traffic Server
Issue Type: Bug
Components: Management
Reporter: Leif Hedstrom
Fix For: sometime
During startup, traffic_manager always seems to produce these errors:
{code}
[Jun 1 14:59:46.577] Manager {0x7f9690c497e0} ERROR: [TrafficManager] ==
Cleaning up and reissuing signal #2
[Jun 1 14:59:46.578] Manager {0x7f9690c497e0} ERROR: (last system error 2:
No such file or directory)
[Jun 1 14:59:46.607] Manager {0x7f9690c497e0} ERROR: [TrafficManager] ==
signal #2
[Jun 1 14:59:46.607] Manager {0x7f9690c497e0} ERROR: (last system error 2:
No such file or directory)
{code}
They seem harmless, but annoying.
--
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-1711) Crash on NetHandler::mainNetEvent
[ https://issues.apache.org/jira/browse/TS-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1711: Fix Version/s: (was: 3.3.5) sometime Crash on NetHandler::mainNetEvent - Key: TS-1711 URL: https://issues.apache.org/jira/browse/TS-1711 Project: Traffic Server Issue Type: Bug Components: Clustering, Logging, Network Affects Versions: 3.2.4, 3.2.0 Reporter: Andrew Younan Fix For: sometime ATS 3.2.0 is installed on two RHEL6.2 nodes in cluster mode. IMHO, issue is not resolved in 3.2.4 as I can see. Two crashes are taking place: 1) One as described in Bug TS-1686 (https://issues.apache.org/jira/browse/TS-1686) and the other one below upon the mainNetEvent. For issue TS-1686, once logging was disabled the crashes did not reoccur. The below still occurs. Both are must fix. NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0[0x3caf80f4a0] /usr/bin/traffic_server[0x67697c] /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x66e0f2] /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696d04] /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697693] /usr/bin/traffic_server[0x695cd2] /lib64/libpthread.so.0[0x3caf8077f1] /lib64/libc.so.6(clone+0x6d)[0x3caf4e570d] Coredump currently being analyzed (cannot be provided at the moment - 9GB); your assistance is urgently needed. Thanks, Andrew -- 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-1660) Host field should not have c style terminator
[ https://issues.apache.org/jira/browse/TS-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1660: Fix Version/s: (was: 3.3.5) sometime Host field should not have c style terminator -- Key: TS-1660 URL: https://issues.apache.org/jira/browse/TS-1660 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin Assignee: Leif Hedstrom Labels: A Fix For: sometime Attachments: ts-1660.diff if host field of client has c style terminator, it may lead to serious problems (e.g. ats use c string to do hostdb lookup). -- 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-1330) Logging related segfault in 3.2.0
[
https://issues.apache.org/jira/browse/TS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1330:
Fix Version/s: (was: 3.3.5)
sometime
Logging related segfault in 3.2.0
-
Key: TS-1330
URL: https://issues.apache.org/jira/browse/TS-1330
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: ATS 3.2.0 on RHEL 6.2 64-bit
Reporter: David Carlin
Assignee: Leif Hedstrom
Priority: Critical
Labels: A, crash
Fix For: sometime
I observed the following crash once on one of our ATS boxes - possibly
related to TS-1240
Jul 2 13:56:56 l2 traffic_server[25853]: {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
Jul 2 13:59:56 l2 kernel: [ET_NET 1][25855]: segfault at c ip
0058e083 sp 2b0a2982b740 error 6
Jul 2 13:59:56 l2 kernel: [ET_NET 3][25857]: segfault at 84 ip
0058e083 sp 2b0a29a31740 error 6 in traffic_server[40+34]
Jul 2 13:59:56 l2 kernel: in traffic_server[40+34]
Jul 2 14:02:59 l2 traffic_cop[25901]: (test) read timeout [18 ]
Jul 2 14:02:59 l2 traffic_cop[25901]: server heartbeat failed [1]
Jul 2 14:03:08 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL: (last
system error 104: Connection reset by peer)
Jul 2 14:03:09 l2 traffic_cop[25901]: cannot find traffic_server [1]
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR: (last
system error 32: Broken pipe)
Jul 2 14:03:12 l2 traffic_cop[25901]: cop received child status signal
[25826 35584]
Jul 2 14:03:12 l2 traffic_cop[25901]: traffic_manager not running, making
sure traffic_server is dead
Jul 2 14:03:12 l2 traffic_cop[25901]: spawning traffic_manager
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: --- Manager Starting ---
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:12)
Jul 2 14:03:13 l2 traffic_manager[18267]: {0x7fe63de3f7e0} STATUS: opened
/home/y/logs/trafficserver/manager.log
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: --- Server Starting ---
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:31)
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} STATUS: opened
/home/y/logs/trafficserver/diags.log
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} ERROR: Cannot
insert duplicate!
Jul 2 14:03:22 l2 traffic_cop[25901]: server heartbeat succeeded
[Jul 2 13:56:56.304] Server {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
NOTE: Traffic Server received Sig 11: Segmentation fault
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x3b54e0f4a0]
/lib64/libpthread.so.0[0x3b54e0f4a0]
/home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
/home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
/home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
/home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xde)[0x56c3ee]
/home/y/bin/traffic_server[0x6736a1]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x675517]
/home/y/bin/traffic_server[0x672f81]
[jira] [Updated] (TS-1882) ATS doesn't warn about unknown config items
[ https://issues.apache.org/jira/browse/TS-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1882: Fix Version/s: (was: 3.3.5) sometime ATS doesn't warn about unknown config items --- Key: TS-1882 URL: https://issues.apache.org/jira/browse/TS-1882 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Ebrahim Mohammadi Assignee: Leif Hedstrom Fix For: sometime Apache Traffic Server doesn't warn about unknown configuration file items. It can cause huge confusions, specially in case of trying to get features of a newer version to work on an older installed version by mistake, as I found out the hard way! -- 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-1409) Add webdav methods to ip allow/quick filter
[ https://issues.apache.org/jira/browse/TS-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1409: Fix Version/s: (was: 3.3.5) sometime Add webdav methods to ip allow/quick filter --- Key: TS-1409 URL: https://issues.apache.org/jira/browse/TS-1409 Project: Traffic Server Issue Type: Bug Components: Security Affects Versions: 3.2.0 Reporter: Bryan Call Assignee: Bryan Call Fix For: sometime I know of PROPFIND and REPORT should be added. There might need to be more added. HTTP Extensions for Distributed Authoring -- WEBDAV http://www.ietf.org/rfc/rfc2518.txt -- 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-1344) url.cc doesn't terminate path correctly for malformed query strings
[ https://issues.apache.org/jira/browse/TS-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1344: Fix Version/s: (was: 3.3.5) sometime url.cc doesn't terminate path correctly for malformed query strings --- Key: TS-1344 URL: https://issues.apache.org/jira/browse/TS-1344 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.0, 3.0.5 Reporter: Brian Geffon Assignee: Brian Geffon Labels: A Fix For: sometime Malformed query strings can cause ATS to incorrectly take the query string as the path. -- 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-1757) core at LogUtils::escapify_url()
[
https://issues.apache.org/jira/browse/TS-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1757:
Fix Version/s: (was: 3.3.5)
sometime
core at LogUtils::escapify_url()
Key: TS-1757
URL: https://issues.apache.org/jira/browse/TS-1757
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Bin Chen
Assignee: Yunkai Zhang
Labels: crash
Fix For: sometime
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::e虽scapify_url(Arena*, char*, unsigned long,
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]虽
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]虽
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{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] [Updated] (TS-1432) API is missing TSMutexDestroy
[ https://issues.apache.org/jira/browse/TS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1432: Fix Version/s: (was: 3.3.5) sometime API is missing TSMutexDestroy - Key: TS-1432 URL: https://issues.apache.org/jira/browse/TS-1432 Project: Traffic Server Issue Type: Improvement Components: TS API Affects Versions: 3.3.4 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: sometime pthread_mutex_destory on a TSMutex would cause a leak, this API is really necessary. -- 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-1330) Logging related segfault in 3.2.0
[
https://issues.apache.org/jira/browse/TS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1330:
Fix Version/s: (was: sometime)
3.3.6
Logging related segfault in 3.2.0
-
Key: TS-1330
URL: https://issues.apache.org/jira/browse/TS-1330
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: ATS 3.2.0 on RHEL 6.2 64-bit
Reporter: David Carlin
Assignee: Leif Hedstrom
Priority: Critical
Labels: A, crash
Fix For: 3.3.6
I observed the following crash once on one of our ATS boxes - possibly
related to TS-1240
Jul 2 13:56:56 l2 traffic_server[25853]: {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
Jul 2 13:59:56 l2 kernel: [ET_NET 1][25855]: segfault at c ip
0058e083 sp 2b0a2982b740 error 6
Jul 2 13:59:56 l2 kernel: [ET_NET 3][25857]: segfault at 84 ip
0058e083 sp 2b0a29a31740 error 6 in traffic_server[40+34]
Jul 2 13:59:56 l2 kernel: in traffic_server[40+34]
Jul 2 14:02:59 l2 traffic_cop[25901]: (test) read timeout [18 ]
Jul 2 14:02:59 l2 traffic_cop[25901]: server heartbeat failed [1]
Jul 2 14:03:08 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL: (last
system error 104: Connection reset by peer)
Jul 2 14:03:09 l2 traffic_cop[25901]: cannot find traffic_server [1]
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR: (last
system error 32: Broken pipe)
Jul 2 14:03:12 l2 traffic_cop[25901]: cop received child status signal
[25826 35584]
Jul 2 14:03:12 l2 traffic_cop[25901]: traffic_manager not running, making
sure traffic_server is dead
Jul 2 14:03:12 l2 traffic_cop[25901]: spawning traffic_manager
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: --- Manager Starting ---
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:12)
Jul 2 14:03:13 l2 traffic_manager[18267]: {0x7fe63de3f7e0} STATUS: opened
/home/y/logs/trafficserver/manager.log
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: --- Server Starting ---
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:31)
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} STATUS: opened
/home/y/logs/trafficserver/diags.log
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} ERROR: Cannot
insert duplicate!
Jul 2 14:03:22 l2 traffic_cop[25901]: server heartbeat succeeded
[Jul 2 13:56:56.304] Server {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
NOTE: Traffic Server received Sig 11: Segmentation fault
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x3b54e0f4a0]
/lib64/libpthread.so.0[0x3b54e0f4a0]
/home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
/home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
/home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
/home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xde)[0x56c3ee]
/home/y/bin/traffic_server[0x6736a1]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x675517]
/home/y/bin/traffic_server[0x672f81]
[jira] [Commented] (TS-1510) Large files being purged from cache incorrectly
[ https://issues.apache.org/jira/browse/TS-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683433#comment-13683433 ] Kingsley Foreman commented on TS-1510: -- Greatings, Thank you for your email I'm curently on vacation and will return on the 12nd of June If technical assistance is required please contact Adam Fox a...@internode.com.au or Chris Rosenhain crose...@internode.com.au else I will try to respond to your email upon return. Kind regards Kingsley Large files being purged from cache incorrectly --- Key: TS-1510 URL: https://issues.apache.org/jira/browse/TS-1510 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.3.0 Environment: Ubuntu 10.04 and 12.04 Reporter: Kingsley Foreman Assignee: James Peach Labels: A Fix For: sometime With an empty cache of 120gb. I've added two files. 1. 2mb file 2. 3gb file. after 30min 2mb file remains in cache rechecks home (304) serves from cache 3gb file not i cache, and does a 200 request from the origin server like it has been cleared from cache. There is plenty of space so it isn't expiring, so really it should do a 304 not a 200 to the origin server. -- 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-1510) Large files being purged from cache incorrectly
[ https://issues.apache.org/jira/browse/TS-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1510: Fix Version/s: (was: sometime) 3.3.6 Large files being purged from cache incorrectly --- Key: TS-1510 URL: https://issues.apache.org/jira/browse/TS-1510 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.3.0 Environment: Ubuntu 10.04 and 12.04 Reporter: Kingsley Foreman Assignee: James Peach Labels: A Fix For: 3.3.6 With an empty cache of 120gb. I've added two files. 1. 2mb file 2. 3gb file. after 30min 2mb file remains in cache rechecks home (304) serves from cache 3gb file not i cache, and does a 200 request from the origin server like it has been cleared from cache. There is plenty of space so it isn't expiring, so really it should do a 304 not a 200 to the origin server. -- 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-1820) Cleanup UNUSED / INK_UNUSED / RELEASE_UNUSED
[ https://issues.apache.org/jira/browse/TS-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1820: Fix Version/s: (was: 3.3.5) sometime Cleanup UNUSED / INK_UNUSED / RELEASE_UNUSED Key: TS-1820 URL: https://issues.apache.org/jira/browse/TS-1820 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: sometime We have to many of these defines, and should clean this up and unify it. There are also plugins and core code defining their own versions of this, lets eliminate that as well. -- 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-1855) autoconf warning on older versions
[
https://issues.apache.org/jira/browse/TS-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1855:
Fix Version/s: (was: 3.3.5)
sometime
autoconf warning on older versions
--
Key: TS-1855
URL: https://issues.apache.org/jira/browse/TS-1855
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: James Peach
Fix For: sometime
{code}
checking dlfcn.h presence... yes
configure: WARNING: dlfcn.h: present but cannot be compiled
configure: WARNING: dlfcn.h: check for missing prerequisite headers?
configure: WARNING: dlfcn.h: see the Autoconf documentation
configure: WARNING: dlfcn.h: section Present But Cannot Be Compiled
configure: WARNING: dlfcn.h: proceeding with the preprocessor's result
configure: WARNING: dlfcn.h: in the future, the compiler will take precedence
configure: WARNING: ## --- ##
configure: WARNING: ## Report this to d...@trafficserver.apache.org ##
configure: WARNING: ## --- ##
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
{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] [Updated] (TS-1625) ATS doesn't support localhost services for full IPT connections
[ https://issues.apache.org/jira/browse/TS-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1625: Fix Version/s: (was: 3.3.5) sometime ATS doesn't support localhost services for full IPT connections --- Key: TS-1625 URL: https://issues.apache.org/jira/browse/TS-1625 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Aidan McGurn Assignee: Alan M. Carroll Fix For: sometime Attachments: CCOD-309-IPT_LocalServices.patch, INTD-1782-IPT_LocalServices.patch We have at least 2 use cases where we want to connect the backend (OS) connection to localhost. This currently won't work under full IPT as the backend connection socket is bound to the client src ip. It needs to be bound to localhost also otherwise e.g. client src ip --- 127.0.0.1 //this will fail needs to be: 127.0.0.1 127.0.0.1 (for ipv6: ::1 --- ::1) -- 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-1883) SSL origin connections do not support connection timeouts
[
https://issues.apache.org/jira/browse/TS-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1883:
Fix Version/s: (was: 3.3.5)
sometime
SSL origin connections do not support connection timeouts
-
Key: TS-1883
URL: https://issues.apache.org/jira/browse/TS-1883
Project: Traffic Server
Issue Type: Bug
Components: Core, SSL
Reporter: James Peach
Fix For: sometime
In {{proxy/http/HttpSM.cc}}, we can see that origin connections do not
support timeouts if the scheme is HTTPS:
{code}
void
HttpSM::do_http_server_open(bool raw)
{
...
if (t_state.scheme == URL_WKSIDX_HTTPS) {
DebugSM(http, calling sslNetProcessor.connect_re);
connect_action_handle = sslNetProcessor.connect_re(this,// state
machine
t_state.current.server-addr.sa,// addr + port
opt);
} else {
...
// Setup the timeouts
// Set the inactivity timeout to the connect timeout so that we
// we fail this server if it doesn't start sending the response
// header
MgmtInt connect_timeout;
if (t_state.method == HTTP_WKSIDX_POST || t_state.method ==
HTTP_WKSIDX_PUT) {
connect_timeout = t_state.txn_conf-post_connect_attempts_timeout;
} else if (t_state.current.server == t_state.parent_info) {
connect_timeout = t_state.http_config_param-parent_connect_timeout;
} else {
if (t_state.pCongestionEntry != NULL)
connect_timeout = t_state.pCongestionEntry-connect_timeout();
else
connect_timeout = t_state.txn_conf-connect_attempts_timeout;
}
DebugSM(http, calling netProcessor.connect_s);
connect_action_handle = netProcessor.connect_s(this, // state
machine
t_state.current.server-addr.sa,// addr + port
connect_timeout, opt);
...
}
{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] [Updated] (TS-1878) link libraries as needed on linux
[
https://issues.apache.org/jira/browse/TS-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1878:
Fix Version/s: (was: 3.3.5)
sometime
link libraries as needed on linux
-
Key: TS-1878
URL: https://issues.apache.org/jira/browse/TS-1878
Project: Traffic Server
Issue Type: Improvement
Components: Build
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: sometime
We should pass {{-Wl,-as-needed}} to the linker on Linux to get it to strip
unused libraries. The equivalent Darwin option is {{-Wl,-dead_strip_dylibs}}.
See also:
http://www.gentoo.org/proj/en/qa/asneeded.xml
http://sigquit.wordpress.com/2011/02/16/why-asneeded-doesnt-work-as-expected-for-your-libraries-on-your-autotools-project/
--
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-1660) Host field should not have c style terminator
[ https://issues.apache.org/jira/browse/TS-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1660: Fix Version/s: (was: sometime) 3.3.6 Host field should not have c style terminator -- Key: TS-1660 URL: https://issues.apache.org/jira/browse/TS-1660 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin Assignee: Leif Hedstrom Labels: A Fix For: 3.3.6 Attachments: ts-1660.diff if host field of client has c style terminator, it may lead to serious problems (e.g. ats use c string to do hostdb lookup). -- 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-1695) test_certlookup fails on FreeBSD
[
https://issues.apache.org/jira/browse/TS-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1695:
Fix Version/s: (was: sometime)
3.3.6
test_certlookup fails on FreeBSD
Key: TS-1695
URL: https://issues.apache.org/jira/browse/TS-1695
Project: Traffic Server
Issue Type: Bug
Components: Portability
Environment: FreeBSD 10, amd64
Reporter: Igor Galić
Assignee: James Peach
Labels: freebsd
Fix For: 3.3.6
{noformat}
Reading symbols from
/tmp/org.apache.trafficserver.2624/obj/iocore/net/.libs/test_certlookup...done.
[New process 100244]
[New Thread 803806400 (LWP 100244)]
Core was generated by `test_certlookup'.
Program terminated with signal 10, Bus error.
#0 0x000802cbc43b in ?? () from /lib/libc.so.7
(gdb) bt
#0 0x000802cbc43b in ?? () from /lib/libc.so.7
#1 0x000802cc8c74 in free () from /lib/libc.so.7
#2 0x00405ca6 in TrieSSLContextStorage::SSLEntry::Clear
(this=0x80382c800) at /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:213
#3 0x00405d21 in TrieSSLContextStorage::SSLEntry::~Trie
(this=0x80382c800, __in_chrg=optimized out) at
/home/igalic/src/asf/trafficserver/lib/ts/Trie.h:54
#4 0x00403c11 in SSLContextStorage::~SSLContextStorage
(this=0x80382c800, __in_chrg=optimized out) at
/home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:213
#5 0x00403d05 in SSLCertLookup::~SSLCertLookup (this=0x7fffd2e0,
__in_chrg=optimized out) at
/home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:102
#6 0x004036a8 in RegressionTest_SSLCertificateLookup (t=0x60daa0
regressionTest_SSLCertificateLookup, atype=0, pstatus=0x60dab8
regressionTest_SSLCertificateLookup+24)
at /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:78
#7 0x00080085eff6 in start_test (t=0x60daa0
regressionTest_SSLCertificateLookup) at
/home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:77
#8 0x00080085f404 in RegressionTest::run (atest=0x0) at
/home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:98
#9 0x00402ce0 in main (argc=1, argv=0x7fffd470) at
/home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:197
(gdb)
{noformat}
--
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-1956) Under Heavy Load TS 3.3.4-dev can't (re)start
[
https://issues.apache.org/jira/browse/TS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1956:
Priority: Blocker (was: Major)
Under Heavy Load TS 3.3.4-dev can't (re)start
-
Key: TS-1956
URL: https://issues.apache.org/jira/browse/TS-1956
Project: Traffic Server
Issue Type: Bug
Reporter: Tommy Lee
Priority: Blocker
Fix For: 3.3.6
Hi,
We run TS in forward mode, under REALLY HEAVY load. Currently we run version
3.3.2-dev without problems.
But today, we tried to upgrade to version 3.3.4-dev without lucky.
We've noticed that, if TS restarts, it enters in this Segfault Loop.
Below are traffic.out logs with debug .*
I'll try to debug with GDB too, but I cannot stop this server for too long,
because of our operations.
Thanks in advance.
{code}
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fd9e0 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fdd00 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.81.5:46089 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.101.4:41361 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.156.38:59164 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5413700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c00] accepted connection from
10.202.81.5:46089 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.35.9:51533 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.201.20:10964 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5615700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015a80] accepted connection from
10.200.156.38:59164 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.148.2:44203 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fe020 on port 3128 as inbound transparent
[Jun 14 11:54:14.564] Server {0x2b06a5514700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015d20] accepted connection from
10.202.101.4:41361 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b06a5817700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015540] accepted connection from
10.200.201.20:10964 transport type = 0NOTE: Traffic Server received Sig 11:
Segmentation fault
/usr/local/cache-3.3.4/bin/traffic_server - STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
NOTE: Traffic Server received Sig 11: Segmentation fault
[Jun 14 11:54:14.564] Server {0x2b06a5716700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c0157e0] accepted connection from
10.200.35.9:51533 transport type = 0/usr/local/cache-3.3.4/bin/traffic_server
- STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b085c120700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.131.24:65434 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.157.26:52514 - *Not IP address [0]*:0
[Jun 14 11:54:14.565] Server {0x2b0850514700} DEBUG: (iocore_net_server)
[jira] [Created] (TS-1957) if CacheContinuation timeout, timeout Event will be loop
Bin Chen created TS-1957: Summary: if CacheContinuation timeout, timeout Event will be loop Key: TS-1957 URL: https://issues.apache.org/jira/browse/TS-1957 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: Bin Chen -- 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] [Assigned] (TS-1957) if CacheContinuation timeout, timeout Event will be loop
[ https://issues.apache.org/jira/browse/TS-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-1957: Assignee: Bin Chen if CacheContinuation timeout, timeout Event will be loop - Key: TS-1957 URL: https://issues.apache.org/jira/browse/TS-1957 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: Bin Chen Assignee: Bin Chen -- 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-1957) if CacheContinuation timeout, timeout Event will be loop
[ https://issues.apache.org/jira/browse/TS-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683459#comment-13683459 ] James Peach commented on TS-1957: - Can this be reproduced? Is it possible to write a regression test? if CacheContinuation timeout, timeout Event will be loop - Key: TS-1957 URL: https://issues.apache.org/jira/browse/TS-1957 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: Bin Chen Assignee: Bin Chen -- 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-1923) 3.2.x - Fix resolve_logfield_string()
[ https://issues.apache.org/jira/browse/TS-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-1923. Resolution: Fixed 3.2.x - Fix resolve_logfield_string() - Key: TS-1923 URL: https://issues.apache.org/jira/browse/TS-1923 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.2.4 Reporter: Yunkai Zhang Assignee: Igor Galić Fix For: 3.2.5 Attachments: 0001-Fix-resolve_logfield_string.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(). === Now, we found the root cause which would lead to internal_msg_buffer_size to 0 while internal_msg_buffer is NOT NULL. That is resolve_logfiled_string() function. Let's fix it. -- 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-1957) if CacheContinuation timeout, timeout Event will be loop
[ https://issues.apache.org/jira/browse/TS-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683463#comment-13683463 ] Bin Chen commented on TS-1957: -- In cluster mode, if CacheContinuation timeout, the proxy.process.cluster.remote_op_timeouts in stat will be increase more and more. if CacheContinuation timeout, timeout Event will be loop - Key: TS-1957 URL: https://issues.apache.org/jira/browse/TS-1957 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: Bin Chen Assignee: Bin Chen -- 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-1956) Under Heavy Load TS 3.3.4-dev can't (re)start
[
https://issues.apache.org/jira/browse/TS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommy Lee updated TS-1956:
--
Attachment: backtrace.log
Backtrace from GDB with --enable-debug
Under Heavy Load TS 3.3.4-dev can't (re)start
-
Key: TS-1956
URL: https://issues.apache.org/jira/browse/TS-1956
Project: Traffic Server
Issue Type: Bug
Reporter: Tommy Lee
Priority: Blocker
Fix For: 3.3.6
Attachments: backtrace.log
Hi,
We run TS in forward mode, under REALLY HEAVY load. Currently we run version
3.3.2-dev without problems.
But today, we tried to upgrade to version 3.3.4-dev without lucky.
We've noticed that, if TS restarts, it enters in this Segfault Loop.
Below are traffic.out logs with debug .*
I'll try to debug with GDB too, but I cannot stop this server for too long,
because of our operations.
Thanks in advance.
{code}
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fd9e0 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fdd00 on port 3128 as inbound transparent
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
[Jun 14 11:54:14.563] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.81.5:46089 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.101.4:41361 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.156.38:59164 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5413700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c00] accepted connection from
10.202.81.5:46089 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.35.9:51533 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.201.20:10964 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b06a5615700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015a80] accepted connection from
10.200.156.38:59164 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
sockopt 0x0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.202.148.2:44203 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
accept server 0x20fe020 on port 3128 as inbound transparent
[Jun 14 11:54:14.564] Server {0x2b06a5514700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015d20] accepted connection from
10.202.101.4:41361 transport type = 0
[Jun 14 11:54:14.564] Server {0x2b06a5817700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c015540] accepted connection from
10.200.201.20:10964 transport type = 0NOTE: Traffic Server received Sig 11:
Segmentation fault
/usr/local/cache-3.3.4/bin/traffic_server - STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
port inbound transparency enabled.
[Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
Created accept thread #1 for port 3128
NOTE: Traffic Server received Sig 11: Segmentation fault
[Jun 14 11:54:14.564] Server {0x2b06a5716700} DEBUG: (http_seq)
[HttpAccept:mainEvent 0x2b085c0157e0] accepted connection from
10.200.35.9:51533 transport type = 0/usr/local/cache-3.3.4/bin/traffic_server
- STACK TRACE:
[Jun 14 11:54:14.564] Server {0x2b085c120700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.131.24:65434 - *Not IP address [0]*:0
[Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
Connection accepted [Server]. 10.200.157.26:52514 - *Not IP address
[jira] [Commented] (TS-1270) why can't we force local cache in clustering mode?
[ https://issues.apache.org/jira/browse/TS-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683955#comment-13683955 ] Zhao Yongming commented on TS-1270: --- the URL set for local, will have to fetch from the origin on each node, just like there is no cluster :D why can't we force local cache in clustering mode? -- Key: TS-1270 URL: https://issues.apache.org/jira/browse/TS-1270 Project: Traffic Server Issue Type: New Feature Components: Clustering Affects Versions: 3.1.4 Environment: cluster type 1 Reporter: Zhao Yongming Assignee: Bin Chen Fix For: 3.3.1 Attachments: cluster_cache_local.patch in cluster type 1, all content will be hashed in side cluster, you can not cache some very hot content locally, we definitely need a more short way to avoid the latency bandwidth or some very hot content may destroy the whole cluster. -- 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-1270) why can't we force local cache in clustering mode?
[ https://issues.apache.org/jira/browse/TS-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683958#comment-13683958 ] Peter Walsh commented on TS-1270: - Hello, I am not available until Monday morning. For APIM related emails, please send to #DTSS APIM Support. Thank you, why can't we force local cache in clustering mode? -- Key: TS-1270 URL: https://issues.apache.org/jira/browse/TS-1270 Project: Traffic Server Issue Type: New Feature Components: Clustering Affects Versions: 3.1.4 Environment: cluster type 1 Reporter: Zhao Yongming Assignee: Bin Chen Fix For: 3.3.1 Attachments: cluster_cache_local.patch in cluster type 1, all content will be hashed in side cluster, you can not cache some very hot content locally, we definitely need a more short way to avoid the latency bandwidth or some very hot content may destroy the whole cluster. -- 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-1957) if CacheContinuation timeout, timeout Event will be loop
[ https://issues.apache.org/jira/browse/TS-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-1957: -- Fix Version/s: 3.3.5 Affects Version/s: 3.3.4 3.2.4 if CacheContinuation timeout, timeout Event will be loop - Key: TS-1957 URL: https://issues.apache.org/jira/browse/TS-1957 Project: Traffic Server Issue Type: Bug Components: Clustering Affects Versions: 3.3.4, 3.2.4 Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.5 -- 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
