[jira] [Updated] (TS-1204) Crash report: HttpSM::main_handler HttpSM.cc:2412: failed assert `magic == HTTP_SM_MAGIC_ALIVE`
[
https://issues.apache.org/jira/browse/TS-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1204:
--
Fix Version/s: 3.1.4
Crash report: HttpSM::main_handler HttpSM.cc:2412: failed assert `magic ==
HTTP_SM_MAGIC_ALIVE`
---
Key: TS-1204
URL: https://issues.apache.org/jira/browse/TS-1204
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.3
Environment: git master Sat Apr 7 03:29:50 2012. forwarding proxy on
centos 6.2 x86_64, with cacheurl plugin
Reporter: Zhao Yongming
Fix For: 3.1.4
{code}
FATAL: HttpSM.cc:2412: failed assert `magic == HTTP_SM_MAGIC_ALIVE`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ddba14368]
/usr/lib64/trafficserver/libtsutil.so.3(_ink_assert+0x1f)[0x3ddba12c6f]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x2e)[0x5163fe]
/usr/bin/traffic_server[0x628b4b]
/usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x353)[0x62c7a3]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x2fe)[0x624cce]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6494f4]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x649e83]
/usr/bin/traffic_server[0x648832]
/lib64/libpthread.so.0[0x380dc077f1]
/lib64/libc.so.6(clone+0x6d)[0x380d0e592d]
{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-1201) Crash report: hostdb multicache, double free
[
https://issues.apache.org/jira/browse/TS-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1201:
--
Fix Version/s: 3.1.4
Crash report: hostdb multicache, double free
Key: TS-1201
URL: https://issues.apache.org/jira/browse/TS-1201
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: weijin
Fix For: 3.1.4
{code}
*** glibc detected *** /usr/bin/traffic_server: corrupted double-linked list:
0x1fe10ef0 ***
=== Backtrace: =
/lib64/libc.so.6[0x3db2072555]
/lib64/libc.so.6(cfree+0x4b)[0x3db20728bb]
/usr/bin/traffic_server(MultiCacheSync::mcEvent(int, Event*)+0xa4)[0x5dae04]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x22f)[0x691c8f]
/usr/bin/traffic_server(EThread::execute()+0x6a1)[0x692681]
/usr/bin/traffic_server[0x69115e]
/lib64/libpthread.so.0[0x3db280673d]
/lib64/libc.so.6(clone+0x6d)[0x3db20d44bd]
=== 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] [Updated] (TS-1203) Crash report: HdrHeap::duplicate_str, in host_set
[
https://issues.apache.org/jira/browse/TS-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1203:
--
Priority: Critical (was: Major)
Fix Version/s: 3.1.4
Crash report: HdrHeap::duplicate_str, in host_set
-
Key: TS-1203
URL: https://issues.apache.org/jira/browse/TS-1203
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.3
Environment: 3.0.x, new crashes
Reporter: Zhao Yongming
Assignee: weijin
Priority: Critical
Fix For: 3.1.4
we get some new crashes in the production:
{code}
warning: no loadable sections found in added symbol-file system-supplied DSO
at 0x727fd000
Core was generated by `/usr/bin/traffic_server -M -A,12:X,13:X'.
Program terminated with signal 11, Segmentation fault.
#0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
(gdb) bt
#0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
#1 0x005aab68 in HdrHeap::duplicate_str (this=value optimized out,
str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds,
nbytes=21) at HdrHeap.cc:344
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds, s_len=21,
d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
MIME.cc:3034
#3 0x005aef28 in host_set (this=0x2aae268f8c18, url=value optimized
out) at URL.h:541
#4 HTTPHdr::set_url_target_from_host_field (this=0x2aae268f8c18, url=value
optimized out) at HTTP.cc:1484
#5 0x0055dc69 in RemapProcessor::setup_for_remap (this=value
optimized out, s=0x2aae268f83c8) at RemapProcessor.cc:130
#6 0x005165d9 in HttpSM::do_remap_request (this=0x2aae268f8360,
run_inline=true) at HttpSM.cc:3666
#7 0x00526cbb in HttpSM::set_next_state (this=0x2aaabd62be12) at
HttpSM.cc:6392
#8 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=value optimized out) at HttpSM.cc:6345
#9 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
HttpSM.cc:6553
#10 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=value optimized out) at HttpSM.cc:6345
#11 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
HttpSM.cc:6553
#12 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=value optimized out) at HttpSM.cc:6345
#13 0x00520f21 in HttpSM::state_read_client_request_header
(this=0x2aae268f8360, event=100, data=value optimized out)
at HttpSM.cc:783
#14 0x005259b9 in HttpSM::main_handler (this=0x2aae268f8360,
event=100, data=0x2aae68aee6e0) at HttpSM.cc:2456
#15 0x0066d1fb in handleEvent (nh=0x2b105668, vc=0x2aae68aee520,
thread=0x2b104010)
at ../../iocore/eventsystem/I_Continuation.h:146
#16 read_signal_and_update (nh=0x2b105668, vc=0x2aae68aee520,
thread=0x2b104010) at UnixNetVConnection.cc:138
#17 read_from_net (nh=0x2b105668, vc=0x2aae68aee520,
thread=0x2b104010) at UnixNetVConnection.cc:320
#18 0x00666579 in NetHandler::mainNetEvent (this=0x2b105668,
event=value optimized out, e=0x2b8ed028) at UnixNet.cc:389
#19 0x00691c8f in EThread::process_event (this=0x2b104010,
e=0x35681c0, calling_code=5) at I_Continuation.h:146
#20 0x0069259c in EThread::execute (this=0x2b104010) at
UnixEThread.cc:263
#21 0x0069115e in spawn_thread_internal (a=0x35621b0) at Thread.cc:88
#22 0x003e5b80673d in start_thread () from /lib64/libpthread.so.0
#23 0x003e5b0d44bd in clone () from /lib64/libc.so.6
(gdb) f 1
#1 0x005aab68 in HdrHeap::duplicate_str (this=value optimized out,
str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds,
nbytes=21) at HdrHeap.cc:344
344 memcpy(new_str, str, nbytes);
(gdb) p str
$1 = 0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds
(gdb) p nbytes
$2 = 21
(gdb) f 2
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds, s_len=21,
d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
MIME.cc:3034
3034 s_str = heap-duplicate_str(s_str, s_len);
(gdb) p s_str
$3 = 0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds
(gdb) f 3
#3 0x005aef28 in host_set (this=0x2aae268f8c18, url=value optimized
out) at URL.h:541
541 url_host_set(m_heap, m_url_impl, value, length, true);
(gdb) p value
$4 = value optimized out
(gdb) p length
$5 = value optimized out
(gdb) f 2
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds, s_len=21,
d_str=0x2aae3656f348,
[jira] [Updated] (TS-1118) Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM.
[ https://issues.apache.org/jira/browse/TS-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1118: -- Fix Version/s: (was: 3.1.4) 3.3.0 Modify how we manage the cache key / MD5 / lookup_url in the CacheSM / HttpSM. -- Key: TS-1118 URL: https://issues.apache.org/jira/browse/TS-1118 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.0 I'd like to make the core simpler, and more efficient, dealing with the cache keys. We have APIs today to modify the cache URL (lookup_url), but it's incredibly inefficient. I'll post more details on my ideas here when I have it all written down. -- 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-975) server-transform.c broken
[ https://issues.apache.org/jira/browse/TS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-975: - Fix Version/s: (was: 3.1.4) 3.3.0 Moving out to 3.3.0, please move back if you will have a new patch soon. There's no urgency here, we can land this any time you have the patch ready. server-transform.c broken - Key: TS-975 URL: https://issues.apache.org/jira/browse/TS-975 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.0.0 Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Priority: Minor Fix For: 3.3.0 Attachments: server-transform.c.diff While playing around with the server-transform plugin example, i noticed it was broken. After some meddling around, i got it working again. The changes are mainly that in some cases content-length was passed in network-byte order where it shouldn't be. Another fix was handling the TS_EVENT_IMMEDIATE event in transform_write_event(). i currently perform a TSVIOReenable(data-server_vio); on that event, and it seems to work. However, I'm not sure at all if that is the correct thing to do, so if anybody could help me out on that? :-). I have tested the changed code with a custom echo server, and confirmed that the plugin is actually sending and receiving to the echo server. I added the working 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-935) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-935: - Fix Version/s: (was: 3.1.4) 3.3.0 Moving out to 3.3.0, please move back if there will be a fix soon for v3.1.4. Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT Key: TS-935 URL: https://issues.apache.org/jira/browse/TS-935 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.3.0 When trying to use TSContCall with event = TS_EVENT_TIMEOUT I stumbled upon the fact that the API will decrement the event count for EVENT_INTERNAL or EVENT_IMMEDIATE (see INKContInternal::handle_event_count), but shouldn't we be able to do a TSContCall with TS_EVENT_IMMEDIAITE or TS_EVENT_TIMEOUT because as of now doing so would cause m_event_count to become -1 or shouldn't these defined values be something different? -- 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-1200) DOAP file reference incorrect
[ https://issues.apache.org/jira/browse/TS-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1200: -- Assignee: Igor Galić (was: Leif Hedstrom) DOAP file reference incorrect - Key: TS-1200 URL: https://issues.apache.org/jira/browse/TS-1200 Project: Traffic Server Issue Type: Bug Reporter: Sebb Assignee: Igor Galić Priority: Critical The DOAP file for the project needs to be available for the projects.a.o website to function correctly. Currently the build is looking for http://svn.apache.org/repos/asf/trafficserver/traffic/trunk/doc/doap.rdf However this does not exist, so the build is reporting an error. Please update the file https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml with the new location ASAP. -- 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-1196) the via metrix in PURGE response should be documented
[
https://issues.apache.org/jira/browse/TS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1196:
--
Fix Version/s: 3.3.0
the via metrix in PURGE response should be documented
-
Key: TS-1196
URL: https://issues.apache.org/jira/browse/TS-1196
Project: Traffic Server
Issue Type: Task
Components: Documentation
Affects Versions: 3.1.3
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Minor
Fix For: 3.3.0
{code}
[yonghao@cache161.cn50 trafficserver]$ echo -ne PURGE
http://img01.taobaocdn.com/bao/uploaded/i1/000/160/T1RoNcXn5Qj0JX.jpg_60x60.jpg
HTTP/1.0\r\n\r\n | nc -i 1 cache162.cn50 81
HTTP/1.0 200 Ok
Date: Tue, 10 Apr 2012 07:10:30 GMT
Via: http/1.1 cn50 (ApacheTrafficServer/3.0.2 [cRs f ])
Content-Length: 0
{code}
what does the cR mean? we should document it down!
--
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-1184) Additional whitespace in proxy.config.admin.user_id value results in error
[
https://issues.apache.org/jira/browse/TS-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1184:
--
Fix Version/s: 3.3.0
Assignee: Leif Hedstrom
Kurt, I'm targeting this for 3.3.0. We're trying to close in on 3.2.0 :).
Thanks for the bug report. Fwiw, I think we should modify the config parser to
ignore trailing white spaces. It seems like an easy fix, but we have to make
sure there are no configs that actually needs a trailing space in the value.
Additional whitespace in proxy.config.admin.user_id value results in error
--
Key: TS-1184
URL: https://issues.apache.org/jira/browse/TS-1184
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 3.0.4
Reporter: Kurt Payne
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 3.3.0
Config looked like this:
{noformat}
CONFIG proxy.config.alarm_email STRING nobody
{noformat}
The username had a trailing space. ATS fails to start, and the following
messages appear in {{/var/log/messages:}}
{noformat}
Apr 3 10:46:33 blitz traffic_cop[5498]: --- Cop Starting [Version: Apache
Traffic Server - traffic_cop - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:46)] ---
Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
user
Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
user
Apr 3 10:46:33 blitz traffic_cop[5498]: traffic_manager not running, making
sure traffic_server is dead
Apr 3 10:46:33 blitz traffic_cop[5498]: spawning traffic_manager
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: --- Manager Starting ---
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:03)
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE:
RLIMIT_NOFILE(7):cur(3),max(3)
Apr 3 10:46:33 blitz traffic_manager[5500]: {140630387636192} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
Apr 3 10:46:35 blitz traffic_server[5509]: NOTE: --- Server Starting ---
Apr 3 10:46:35 blitz traffic_server[5509]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:30)
Apr 3 10:46:35 blitz traffic_server[5509]: {47289782682464} STATUS: opened
/usr/local/var/log/trafficserver/diags.log
{noformat}
--
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-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1187: -- Fix Version/s: (was: 3.1.4) 3.3.0 TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) - Key: TS-1187 URL: https://issues.apache.org/jira/browse/TS-1187 Project: Traffic Server Issue Type: Bug Components: MIME Affects Versions: 3.0.2 Environment: Redhat linux with plugin that wants to rename a header read from the client. Reporter: Alistair Stevenson Labels: api-change Fix For: 3.3.0 TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) The name appears set (and the function returns SUCCESS) but when the data is sent to the origin Server it is corrupted at the point where the header is set. i.e the header name is sent but the header is corrupted after this. I am having to create a new header and copy the values and then destroy the original header which is not as efficient. -- 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-1114) Crash report: HttpTransactCache::SelectFromAlternates
[
https://issues.apache.org/jira/browse/TS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1114:
--
Backport to Version: 3.0.5 (was: 3.0.4)
Crash report: HttpTransactCache::SelectFromAlternates
-
Key: TS-1114
URL: https://issues.apache.org/jira/browse/TS-1114
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: weijin
Fix For: 3.1.4
Attachments: cache_crash.diff
it may or may not be the upstream issue, let us open it for tracking.
{code}
#0 0x0053075e in HttpTransactCache::SelectFromAlternates
(cache_vector=0x2aaab80ff500, client_request=0x2aaab80ff4c0,
http_config_params=0x2aaab547b800) at ../../proxy/hdrs/HTTP.h:1375
1375((int32_t *) val)[0] = m_alt-m_object_key[0];
{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-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1187: -- Backport to Version: (was: 3.0.4) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) - Key: TS-1187 URL: https://issues.apache.org/jira/browse/TS-1187 Project: Traffic Server Issue Type: Bug Components: MIME Affects Versions: 3.0.2 Environment: Redhat linux with plugin that wants to rename a header read from the client. Reporter: Alistair Stevenson Labels: api-change Fix For: 3.1.4 TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) The name appears set (and the function returns SUCCESS) but when the data is sent to the origin Server it is corrupted at the point where the header is set. i.e the header name is sent but the header is corrupted after this. I am having to create a new header and copy the values and then destroy the original header which is not as efficient. -- 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-1119) fatal error when uploading gzip-transform plugin
[
https://issues.apache.org/jira/browse/TS-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1119:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
fatal error when uploading gzip-transform plugin
Key: TS-1119
URL: https://issues.apache.org/jira/browse/TS-1119
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.0.2
Reporter: angela asher
Priority: Blocker
Fix For: 3.3.0
Attachments: gzip-transform.diff
getting the following error on traffic.out when running the traffic server
with gzip-transform plugin:
[Feb 23 16:28:15.509] Server {47392853811680} DEBUG: (http) [13] calling
plugin on hook TS_HTTP_READ_RESPONSE_HDR_HOOK at hook 0x35BBEE0
FATAL: InkAPI.cc:3036: failed assert `sdk_sanity_check_null_ptr((void*)
value_len_ptr) == TS_SUCCESS`
/usr/local/bin/traffic_server - STACK TRACE:
/usr/local/lib/libtsutil.so.3(ink_fatal_va+0x9d)[0x2b1a7ecca37d]
/usr/local/lib/libtsutil.so.3(ink_fatal+0x88)[0x2b1a7ecca4d8]
/usr/local/lib/libtsutil.so.3(_ink_assert+0x85)[0x2b1a7ecc8af5]
/usr/local/bin/traffic_server(TSMimeHdrFieldValueStringGet+0x124)[0x4a9144]
/usr/local/libexec/trafficserver/gzip-transform.so(+0x1bde)[0x2b1a8b3c7bde]
/usr/local/libexec/trafficserver/gzip-transform.so(+0x27c4)[0x2b1a8b3c87c4]
/usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52cfa5]
/usr/local/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x420)[0x52f1c0]
/usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x530568]
/usr/local/bin/traffic_server[0x681dcb]
/usr/local/bin/traffic_server[0x6848f1]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x2e2)[0x67d402]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6a9ce4]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x6aa673]
/usr/local/bin/traffic_server(main+0x1128)[0x4c07e8]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x2b1a81092c5d]
/usr/local/bin/traffic_server[0x47e0e9]
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR: (last system error 2:
No such file or directory)
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR: (last system error 2:
No such file or directory)
[Feb 23 16:28:16.522] Manager {140400187066336} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr/local'
[Feb 23 16:28:16.527] Manager {140400187066336} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '11'
[Feb 23 16:28:16.527] Manager {140400187066336} NOTE: [Alarms::signalAlarm]
Server Process born
[Feb 23 16:28:17.539] {47668265021920} STATUS: opened
/usr/local/var/log/trafficserver/diags.log
[Feb 23 16:28:17.539] {47668265021920} NOTE: updated diags config
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Config:
/usr/local/etc/trafficserver/ae_ua.config
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Opening config
/usr/local/etc/trafficserver/ae_ua.config
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[init_http_aeua_filter] - Total loaded 0 REGEXP for
Accept-Enconding/User-Agent filtering
[Feb 23 16:28:17.542] Server {47668265021920} NOTE: cache clustering disabled
[Feb 23 16:28:17.543] Server {47668265021920} DEBUG: (dns) ink_dns_init:
called with init_called = 0
[Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns)
localhost=isk-vsrv227
[Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns) Round-robin
nameservers = 0
[Feb 23 16:28:17.547] Server {47668265021920} NOTE: cache clustering disabled
[Feb 23 16:28:17.568] Server {47668265021920} NOTE: logging initialized[7],
logging_mode = 3
[Feb 23 16:28:17.569] Server {47668265021920} NOTE: loading plugin
'/usr/local/libexec/trafficserver/gzip-transform.so'
[Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
proxy.config.http.redirection_enabled = 0
[Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
proxy.config.http.number_of_redirections = 1
[Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
proxy.config.http.post_copy_size = 2048
[Feb 23 16:28:17.570] Server
[jira] [Updated] (TS-1058) Intercept an HTTP client's request
[
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1058:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
Intercept an HTTP client's request
--
Key: TS-1058
URL: https://issues.apache.org/jira/browse/TS-1058
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.1.1
Reporter: Yakov Kopel
Labels: patch
Fix For: 3.3.0
Attachments: patch.diff
Original Estimate: 24h
Remaining Estimate: 24h
I want that the trafficserver will give the client the response instead of
the server.
The trafficserver offers the INKHttpTxnIntercept api to do so, but it is not
so convenience to use it.
I want to use the regular flow of the trafficserver, and its regular parsing
commands.
The trafficserver's plugins examples also aren't using the
INKHttpTxnIntercept , but they rather using the rasing error method, and
then they response the request at the response hook.
So, this is whta i did.
On the global-hook at the TS_EVENT_HTTP_READ_REQUEST_HDR i raised
TS_EVENT_HTTP_ERROR.
I also added TS_HTTP_SEND_RESPONSE_HDR_HOOK and there i returned http
response with the KEEP-ALIVE header.
The problem is that the trafficserver is closing the connection although i
added to the response the KEEP-ALIVE header.
When the Trafficserver is trying to send response to the client, it terminate
the session after it.
Although I added the KEEP-ALIVE mime field - it didn't work.
The debug dump is looking like this:
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::state_api_callback, HTTP_API_CONTINUE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::state_api_callout, HTTP_API_CONTINUE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
[HttpSM::do_redirect]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
adding producer 'internal msg'
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
adding consumer 'user agent'
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel)
tunnel_run started, p_arg is NULL
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
closed
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
destroy
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] calling
plugin on hook TS_HTTP_TXN_CLOSE_HOOK at hook 0x3B97610
The Solution:
I'm adding a patch of functino that rasing the internal flag of KEEP-ALIVE,
so the trafficserver will realy believe us that we want to keep this
connection alive :)
Example for the usage of the new function:
// Tell the trafficserver to not close this connection (keep-alive)
TSHttpTxnCloseAfterResponse(txnp, 0);
--
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-1069) better handle of the gzipped content
[ https://issues.apache.org/jira/browse/TS-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1069: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. better handle of the gzipped content Key: TS-1069 URL: https://issues.apache.org/jira/browse/TS-1069 Project: Traffic Server Issue Type: Sub-task Reporter: Zhao Yongming Fix For: 3.3.0 when the triggered URL is gzipped, prefetch engine will skip that request, while not put that URL in the prefetch url list, and start another request without accept gzip encodes? -- 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-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1125: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Priority: Minor Fix For: 3.3.0 Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- 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-801) Crash Report: enable update will triger Segmentation fault
[
https://issues.apache.org/jira/browse/TS-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-801:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
Crash Report: enable update will triger Segmentation fault
--
Key: TS-801
URL: https://issues.apache.org/jira/browse/TS-801
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 2.1.8
Environment: v2.1.8 and update function enabled.
Reporter: Zhao Yongming
Labels: update
Fix For: 3.3.0
{code}
b13621367...@hotmail.com: NOTE: Traffic Server received Sig 11: Segmentation
fault
/usr/local/ts/bin/traffic_server - STACK TRACE:
b13621367...@hotmail.com:
/usr/local/ts/bin/traffic_server[0x5260c9]
/lib64/libpthread.so.0[0x3088e0f4c0]
[0x6e]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x6e)[0x57e0e2]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x18b)[0x57e369]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x138)[0x56d9aa]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x13b13621367...@hotmail.com:
8)[0x56d9aa]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x15e)[0x57e1d2]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x36)[0x5b5cb0]
/usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
/usr/local/ts/bin/traffic_server(HttpSM::state_add_to_list(int,
void*)+0x2aa)[0x56a51c]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x2cb)[0x570c13]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x6c)[0x4e0486]
/usr/local/ts/bin/traffic_server(HttpUpdateSM::start_scheduled_update(Continuation*,
HTTPHdr*)+0x168)[0x5b5c1c]
/usr/local/ts/bin/traffic_server(UpdateSM::http_scheme(UpdateSM*)+0x335)[0x53599f]
/usr/local/ts/bin/traffic_server(UpdateSM::HandleSMEvent(int,
Event*)+0x1ab)[0x535437]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x6c)[0x4e0486]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x12c)[0x6fa9dc]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x9b)[0x6fabef]
/usr/local/ts/bin/traffic_server[0x6f9b4c]
/lib64/libpthread.so.0[0x3088e077e1]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
/lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
[May 26 16:25:14.569] Manager {140030245394400} ERROR:
[LocalManager::-PollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[May 26 16:25:14.569] Manager {140030245394400} ERROR: (last system error
32: Broken pipe)
[[May 26 16:25:14.569] Manager {140030245394400} ERROR:
[Alarms::-SignalAlarm] Server Process was reset
[May 26 16:25:14.569] Manager {140030245394400} ERROR: (last system error
32: Broken pipe)
[May 26 16:25:15.577] Manager {140030245394400} NOTE:
[LocalManager::-StartProxy] Launching ts process
{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-923) traffic_logstats: critical: cannot parse log files
[ https://issues.apache.org/jira/browse/TS-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-923: - Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. traffic_logstats: critical: cannot parse log files -- Key: TS-923 URL: https://issues.apache.org/jira/browse/TS-923 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 3.0.1 Environment: Centos 5.6 2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 16:12:36 EST 2009 x86_64 x86_64 x86_64 GNU/Linux Reporter: Hung Nguyen Fix For: 3.3.0 After running for about 3 days, traffic_logstats stop working with following error: traffic_logstats critical: can't parse log file I tried to set Logging to various parameter in record.config, but still cannot get traffic_logstats works. When this problem happens, TS uses less resource. In my setup, I use ram cache only. -- 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-891) Crash report: mime_hdr_sanity_check in mime_parser_parse during
[
https://issues.apache.org/jira/browse/TS-891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-891:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
Crash report: mime_hdr_sanity_check in mime_parser_parse during
Key: TS-891
URL: https://issues.apache.org/jira/browse/TS-891
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.0.1
Environment: v3.0.1, submit from user
Reporter: Zhao Yongming
Labels: crash
Fix For: 3.3.0
no other information, place holding first.
{code}
zym@zym6400 ~ $ c++filt /tmp/a
FATAL: MIME.cc:576: failed assert `strncasecmp(field-m_ptr_name, wks,
field-m_len_name) == 0`
/usr/local/ts/bin/traffic_server - STACK TRACE:
/usr/local/ts/lib/libtsutil.so.3(ink_fatal_va+0xc7)[0x4003109b]
/usr/local/ts/lib/libtsutil.so.3(ink_fatal+0x2b)[0x400310ed]
/usr/local/ts/lib/libtsutil.so.3(_ink_assert+0xc4)[0x4002fd54]
/usr/local/ts/bin/traffic_server(mime_hdr_sanity_check(MIMEHdrImpl*)+0x323)[0x823f5c8]
/usr/local/ts/bin/traffic_server(mime_hdr_field_attach(MIMEHdrImpl*,
MIMEField*, int, MIMEField*)+0x36[0x8241e17]
/usr/local/ts/bin/traffic_server(mime_parser_parse(MIMEParser*, HdrHeap*,
MIMEHdrImpl*, char const**, char const*, bool, bool)+0x2b5)[0x82442b6]
/usr/local/ts/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x801)[0x823ae17]
/usr/local/ts/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x126)[0x82380f4]
/usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x2f0)[0x819b87c]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x1f[0x81a0cc0]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x47)[0x81154f9]
/usr/local/ts/bin/traffic_server[0x82f644c]
/usr/local/ts/bin/traffic_server[0x82f6e43]
/usr/local/ts/bin/traffic_server(UnixNetVConnection::net_read_io(NetHandler*,
EThread*)+0x17)[0x82f8c6d]
/usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x62a)[0x82f2ea4]
/usr/local/ts/bin/traffic_server(Continuation::handleEvent(int,
void*)+0x47)[0x81154f9]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x114)[0x831af5a]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x425)[0x831b529]
/usr/local/ts/bin/traffic_server(main+0x1245)[0x813f233]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0x40476450]
/usr/local/ts/bin/traffic_server[0x80f60e1]
{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-921) TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the Transfer Encoding: chunked http header !
[
https://issues.apache.org/jira/browse/TS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-921:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
TSIOBufferBlockReadStart() could'nt return the corresponding chunk data
length when original server using the Transfer Encoding: chunked http
header !
Key: TS-921
URL: https://issues.apache.org/jira/browse/TS-921
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.0.1
Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1,
Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G,
HardDisk: 500G
Reporter: taoyunxing
Labels: transfer_encoding_chunded
Fix For: 3.3.0
Original Estimate: 672h
Remaining Estimate: 672h
Recently I meet with a strange proble when I manage to get the server
response body in the Transfer Encoding: chunked mode:
I couldn't get the corresponding chunk length in hexdecimal ! The details as
follows:
I use the null-transform plugin modified to just output the server response
body, when the web server uses the Transfer Encoding: chunked header
to transfer chunked data to user agent, eg, I request the web page:
http://www.qq.com/;, I just get the chunk body data, but get no chunk length
in
the hexdecimal format 383cb\r\n before the chunk body data. the chunk body
data is uncompressed and like as !DOCTYPE html PUBLIC -//W3C//DTD XHTML
1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;\r\n...
In addition, I capture the data packet using the Wireshark software, I sure
that I see the chunk length 383cb\r\n before the chunk body data
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;\r\n..., it is
a complete chunk response !
I continue to check the code of null-transform.c, set a breakpoint at the
function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at
the breakpoint TSIOBufferBlockReadStart(), I print the return string of
TSIOBufferBlockReadStart(), there is no chunk data length at the head of
output string, which implies the api TSIOBufferBlockReadStart() has bug！
Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330,
avail=0xb6c8e288) at InkIOCoreAPI.cc:659
659 {
(gdb) s
660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
(gdb) n
667 p = blk-start();
(gdb)
668 if (avail)
(gdb) p p
$3 = 0xb1312000 !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0
Transitional//EN\
\http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml
xmlns=\http://www.w3.org/1999/xhtml\;\r\nhead\r\nmeta
http-equiv=\Conten...
(gdb)
--
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-902) Crash report: invalid ip range in remap.config crash server
[
https://issues.apache.org/jira/browse/TS-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-902:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
Crash report: invalid ip range in remap.config crash server
---
Key: TS-902
URL: https://issues.apache.org/jira/browse/TS-902
Project: Traffic Server
Issue Type: Bug
Components: Configuration, HTTP
Affects Versions: 3.1.0, 3.0.1
Environment: TS 3.0.1
Reporter: Zhao Yongming
Labels: crash
Fix For: 3.3.0
when I put a strage ip range, ie: src_ip=128.0.0.0-121.14.89.0 in remap ip
filtering, it will cause the server crash:
{code}
[TrafficServer] using root directory '/usr'
[Aug 4 11:04:53.209] Manager {140564987967264} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '13'
[Aug 4 11:04:53.209] Manager {140564987967264} NOTE: [Alarms::signalAlarm]
Server Process born
[Aug 4 11:04:54.222] {46990117603664} STATUS: opened
/var/log/trafficserver/diags.log
[Aug 4 11:04:54.224] {46990117603664} NOTE: updated diags config
[Aug 4 11:04:54.225] Server {46990117603664} NOTE: cache clustering disabled
[Aug 4 11:04:54.239] Server {46990117603664} NOTE: cache clustering disabled
[Aug 4 11:04:54.343] Server {46990117603664} NOTE: logging initialized[7],
logging_mode = 1
[Aug 4 11:04:54.345] Server {46990117603664} NOTE: PrefetchProcessor:
Started the prefetch processor
[Aug 4 11:04:54.346] Server {46990117603664} WARNING: Could not add rule at
line #1; Aborting!
[Aug 4 11:04:54.346] Server {46990117603664} WARNING: [ReverseProxy] Unable
to parse IP value in src_ip=128.0.0.0-121.14.89.0 at line 1
FATAL: [ReverseProxy] Unable to parse IP value in
src_ip=128.0.0.0-121.14.89.0 at line 1
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal_va+0x9d)[0x3ab46127dd]
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ab4612938]
/usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x585)[0x580335]
/usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x2fa)[0x58219a]
/usr/bin/traffic_server(_Z18init_reverse_proxyv+0xec)[0x4de75c]
/usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x51ee7b]
/usr/bin/traffic_server(main+0xc07)[0x4bf177]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x389961d994]
/usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4793a9]
[Aug 4 11:04:54.506] Manager {140564987967264} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
{code}
and here is the rules defined in my remap.config:
{code}
.defflt tools @action=deny @src_ip=0.0.0.0-127.0.0.0
@src_ip=128.0.0.0-121.14.89.0 @src_ip=121.14.90.254-255.255.255.255
@method=PURGE
.useflt tools
{code}
well, it is invalid, but we should not crash, right?
--
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-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1146: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. RFC 5077 TLS Session tickets Key: TS-1146 URL: https://issues.apache.org/jira/browse/TS-1146 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Fix For: 3.3.0 For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the machines need to have the same server ticket. See https://github.com/apache/httpd rev 967d943b93498233f0ec81a5b48706fdb6892dfd -- 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-1128) gcc don't like break strict-aliasing in I_ProxyAllocator.h
[
https://issues.apache.org/jira/browse/TS-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1128:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
gcc don't like break strict-aliasing in I_ProxyAllocator.h
--
Key: TS-1128
URL: https://issues.apache.org/jira/browse/TS-1128
Project: Traffic Server
Issue Type: Improvement
Components: Cleanup
Affects Versions: 3.1.4
Reporter: Zhao Yongming
Priority: Minor
Fix For: 3.3.0
{code}
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* SSLNetAccept::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* UnixNetProcessor::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* SSLNetProcessor::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* NetAccept::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
make[2]: *** [SSLUnixNet.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [UnixNetProcessor.o] Error 1
mv -f .deps/NetVConnection.Tpo .deps/NetVConnection.Po
mv -f .deps/Net.Tpo .deps/Net.Po
mv -f .deps/UDPIOEvent.Tpo .deps/UDPIOEvent.Po
make[2]: *** [UnixNetAccept.o] Error 1
mv -f .deps/Connection.Tpo .deps/Connection.Po
mv -f .deps/SSLCertLookup.Tpo .deps/SSLCertLookup.Po
mv -f .deps/UnixConnection.Tpo .deps/UnixConnection.Po
mv -f .deps/SSLConfig.Tpo .deps/SSLConfig.Po
mv -f .deps/SSLNet.Tpo .deps/SSLNet.Po
mv -f .deps/UnixNet.Tpo .deps/UnixNet.Po
mv -f .deps/UnixNetPages.Tpo .deps/UnixNetPages.Po
mv -f .deps/Socks.Tpo .deps/Socks.Po
mv -f .deps/SSLNetVConnection.Tpo .deps/SSLNetVConnection.Po
mv -f .deps/UnixNetVConnection.Tpo .deps/UnixNetVConnection.Po
make[2]: Leaving directory
`/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore/net'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.VFqSxi (%build)
{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-1152) http_ui error,when i get http://localhost/cache/
[
https://issues.apache.org/jira/browse/TS-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1152:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
http_ui error,when i get http://localhost/cache/
Key: TS-1152
URL: https://issues.apache.org/jira/browse/TS-1152
Project: Traffic Server
Issue Type: Bug
Components: Web UI
Affects Versions: 3.0.4
Environment: centos 6 x86_64
Reporter: bettydramit
Fix For: 3.3.0
When i enable http_ui ，I got follow error (get http://xxx.xxx.xxx.xxx/cache/)
[Mar 19 16:46:17.778] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:17.778] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:46:19.089] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:19.090] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:46:20.763] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:20.763] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:58:21.906] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /robots.txt not valid autoconf file
[Mar 19 16:58:21.906] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 17:01:43.703] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 17:01:43.703] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
--
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-1106) redirect map generates multiple Via: header entries.
[
https://issues.apache.org/jira/browse/TS-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1106:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
redirect map generates multiple Via: header entries.
Key: TS-1106
URL: https://issues.apache.org/jira/browse/TS-1106
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.2
Reporter: Leif Hedstrom
Fix For: 3.3.0
It seems using the redirect rule in remap.config, ends up duplicating the
entry in the Via: header, e.g.
{code}
Via: http/1.1 kramer.ogre.com (ApacheTrafficServer/3.1.3-unstable [u c s f p
eS:tNc i p s ]), http/1.1 kramer.ogre.com
(ApacheTrafficServer/3.1.3-unstable [u c s f p eS:tNc i p s ])
{code}
I'm not sure why this happens, if it's duplicating it, or if it's going
through the SM twice. I know i'm not proxying twice through the box.
--
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-1169) in enable-debug and pristine_host_hdr=0 mode, TS will crash when purge a cached object which is after TSCacheUrlSet
[
https://issues.apache.org/jira/browse/TS-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1169:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
in enable-debug and pristine_host_hdr=0 mode, TS will crash when purge a
cached object which is after TSCacheUrlSet
---
Key: TS-1169
URL: https://issues.apache.org/jira/browse/TS-1169
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.3, 3.0.4
Environment: configure --enable-debug
Reporter: Conan Wang
Fix For: 3.3.0
{code}
#6 0x000100d269af in _ink_assert (a=0x1003c6be0 md5a == md5b ||
t_state.txn_conf-maintain_pristine_host_hdr, f=0x1003c514e HttpSM.cc,
l=3921) at ink_assert.cc:44
#7 0x000100123e59 in HttpSM::do_cache_delete_all_alts (this=0x109d41190,
cont=0x0) at HttpSM.cc:3921
{code}
in HttpSM::do_cache_delete_all_alts debug code, if a object key is rewritten
by TSCacheUrlSet, md5a will not equal md5b, and it will crash because
maintain_pristine_host_hdr = 0 ( when disable pristine_host_hdr ).
Anyway, the cached object is purged successfully. Maybe it's just a wrong
assert which didn't consider TSCacheUrlSet case.
{code}
#ifdef DEBUG
INK_MD5 md5a;
INK_MD5 md5b;
t_state.hdr_info.client_request.url_get()-MD5_get(md5a);
t_state.cache_info.lookup_url-MD5_get(md5b);
ink_assert(md5a == md5b || t_state.txn_conf-maintain_pristine_host_hdr);
#endif
{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-1155) POST requests that are chunked encoding hang when going forward to origin over SSL
[ https://issues.apache.org/jira/browse/TS-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1155: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary. POST requests that are chunked encoding hang when going forward to origin over SSL -- Key: TS-1155 URL: https://issues.apache.org/jira/browse/TS-1155 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Reporter: William Bardwell Fix For: 3.3.0 If you make a chunked encoded POST request, e.g.: curl -H Transfer-Encoding: chunked -d@/etc/ca-certificates.conf http://example.com/cgi-bin/cgi.pl Where ATS is going forward to the origin over SSL, it junk hangs for a little while and ends up returning a 502 response. The problem seems to be code at proxy/http/HttpTransact.cc:5273 which only checks for chunked encoding when the scheme is http. Just removing the extra scheme check makes it work for me. I don't know why it has that check, especially since it is checking for http or https right before that. -- 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-1053) get combo_handler compiled
[
https://issues.apache.org/jira/browse/TS-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1053:
--
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
get combo_handler compiled
--
Key: TS-1053
URL: https://issues.apache.org/jira/browse/TS-1053
Project: Traffic Server
Issue Type: Task
Components: Plugins
Reporter: Conan Wang
Fix For: 3.3.0
Attachments: Makefile, combo_handler.diff, fetcher.diff
combo_handler require ESI's code. Before make ESI work as a lib, you can try
it this way:
make esi/lib and esi/fetcher the subdir of combo_handler and use the
makefile.
{noformat}
combo_handler
|combo_handler.cc
|fetcher
|lib
|LICENSE
|Makefile
|README
{noformat}
--
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-832) Crash Report: RecMessageMarshal_Realloc in cluster mode 2
[
https://issues.apache.org/jira/browse/TS-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-832:
-
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
Crash Report: RecMessageMarshal_Realloc in cluster mode 2
-
Key: TS-832
URL: https://issues.apache.org/jira/browse/TS-832
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Core
Affects Versions: 3.1.0
Environment: version trunk, aka v3.0 after, cluster mode set to 2(
management cluster ), --enable-debug
Reporter: Zhao Yongming
Labels: cluster, realloc
Fix For: 3.3.0
here is two core dumps:
{code}
#0 0x003c33030265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x003c33030265 in raise () from /lib64/libc.so.6
#1 0x003c33031d10 in abort () from /lib64/libc.so.6
#2 0x003c3306a84b in __libc_message () from /lib64/libc.so.6
#3 0x003c33075421 in realloc () from /lib64/libc.so.6
#4 0x2acf28ff4e01 in ink_realloc (ptr=Could not find the frame base
for ink_realloc.
) at ink_memory.cc:88
#5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
record=0x2acf29248f50) at RecMessage.cc:350
#6 0x006eced8 in send_push_message () at P_RecCore.i:154
#7 0x006efef9 in sync_cont::sync (this=0x20034150, event=1,
e=0x20033d30) at RecProcess.cc:263
#8 0x004d2c5f in Continuation::handleEvent (this=0x20034150,
event=1, data=0x20033d30) at I_Continuation.h:146
#9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
UnixEThread.cc:287
#10 0x006f5181 in spawn_thread_internal (a=0x200441b0) at
Thread.cc:88
#11 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
#12 0x003c330d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x41f4c3e0:
rip = 0x3c33030265 in raise; saved rip 0x3c33031d10
called by frame at 0x41f4c520
Arglist at 0x41f4c3d0, args:
Locals at 0x41f4c3d0, Previous frame's sp is 0x41f4c3e0
Saved registers:
rip at 0x41f4c3d8
{code}
{code}
#0 0x0038aa230265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0038aa230265 in raise () from /lib64/libc.so.6
#1 0x0038aa231d10 in abort () from /lib64/libc.so.6
#2 0x0038aa26a84b in __libc_message () from /lib64/libc.so.6
#3 0x0038aa275421 in realloc () from /lib64/libc.so.6
#4 0x2ab28042ce01 in ink_realloc (ptr=Could not find the frame base
for ink_realloc.
) at ink_memory.cc:88
#5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
record=0x2ab280680f50) at RecMessage.cc:350
#6 0x006eced8 in send_push_message () at P_RecCore.i:154
#7 0x006efef9 in sync_cont::sync (this=0x16a6f150, event=1,
e=0x16a6ed30) at RecProcess.cc:263
#8 0x004d2c5f in Continuation::handleEvent (this=0x16a6f150,
event=1, data=0x16a6ed30) at I_Continuation.h:146
#9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
UnixEThread.cc:287
#10 0x006f5181 in spawn_thread_internal (a=0x16a7f1b0) at
Thread.cc:88
#11 0x0038aae064a7 in start_thread () from /lib64/libpthread.so.0
#12 0x0038aa2d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x406b03e0:
rip = 0x38aa230265 in raise; saved rip 0x38aa231d10
called by frame at 0x406b0520
Arglist at 0x406b03d0, args:
Locals at 0x406b03d0, Previous frame's sp is 0x406b03e0
Saved registers:
rip at 0x406b03d8
{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-1158) Race on mutex switching for NetVConnections in UnixNetVConnection::mainEvent
[ https://issues.apache.org/jira/browse/TS-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1158: -- Backport to Version: 3.0.5 (was: 3.0.4) Race on mutex switching for NetVConnections in UnixNetVConnection::mainEvent Key: TS-1158 URL: https://issues.apache.org/jira/browse/TS-1158 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.3 Environment: ALL Reporter: John Plevyak Assignee: John Plevyak Fix For: 3.1.4 Attachments: ts-1158-jp1.patch Because of the way session management works, the vio.mutex must be re-verified to be identical to the one the lock was taken on after the lock is acquired. Otherwise there is a race when the mutex is switched allowing such that the old lock is held while the new lock is in not held. -- 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-981) Remove libev support (it's not well support, and might crash)
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-981: - Summary: Remove libev support (it's not well support, and might crash) (was: ATS as transparent proxy crashes under heavy load) Changing the summary on this one, as we'll remove libev support (I checked with John on this). Remove libev support (it's not well support, and might crash) - Key: TS-981 URL: https://issues.apache.org/jira/browse/TS-981 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.0 Environment: 4 core desktop. Centos 5.6, kernel 2.6.39.2 compiled with TPROXY support. ATS compiled as: ./configure --enable-tproxy --enable-libev Reporter: Danny Shporer Assignee: Leif Hedstrom Priority: Critical Fix For: 3.1.4 Attachments: records.config ATS crashes under heavy load testing - around 25,000 HTTP transactions per second. I have tested it on both vesions 3.0.0 and 3.0.1 and the same happens. GDB info: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42174940 (LWP 6663)] 0x0068fd4b in modify (this=0x2b12c628, event=value optimized out, e=value optimized out) at P_UnixNet.h:536 536 fd_change(event_loop-eio, eio.fd, 0); (gdb) bt #0 0x0068fd4b in modify (this=0x2b12c628, event=value optimized out, e=value optimized out) at P_UnixNet.h:536 #1 NetHandler::mainNetEvent (this=0x2b12c628, event=value optimized out, e=value optimized out) at UnixNet.cc:432 #2 0x006bfc4f in EThread::process_event (this=0x2b12b010, e=0xf44570, calling_code=5) at I_Continuation.h:146 #3 0x006c055c in EThread::execute (this=0x2b12b010) at UnixEThread.cc:262 #4 0x006bef8e in spawn_thread_internal (a=0xf35c90) at Thread.cc:88 #5 0x003e9dc0673d in start_thread () from /lib64/libpthread.so.0 #6 0x003e9d0d44bd in clone () from /lib64/libc.so.6 (gdb) info f Stack level 0, frame at 0x42174030: rip = 0x68fd4b in modify (P_UnixNet.h:536); saved rip 0x6bfc4f inlined into frame 1 source language c++. Arglist at unknown address. Locals at unknown address, Previous frame's sp in rsp -- 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-61) multiple do_io_pread on a CacheVConnection
[ https://issues.apache.org/jira/browse/TS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-61: Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. multiple do_io_pread on a CacheVConnection -- Key: TS-61 URL: https://issues.apache.org/jira/browse/TS-61 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 3.0.0 Reporter: John Plevyak Assignee: John Plevyak Fix For: 3.3.0 Attachments: pread-2.patch Original Estimate: 48h Remaining Estimate: 48h The current TS-46 patch includes do_io_pread support but allows only a single do_io_pread. In order to efficiently support range requests with multiple ranges it would be helpful to be able to do multiple do_io_pread's on a single open CacheVConnection. -- 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-904) when doing custom logging, it would be nice if we can set dedicate sampling rate for each rule
[ https://issues.apache.org/jira/browse/TS-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-904: - Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. when doing custom logging, it would be nice if we can set dedicate sampling rate for each rule -- Key: TS-904 URL: https://issues.apache.org/jira/browse/TS-904 Project: Traffic Server Issue Type: New Feature Components: Logging Affects Versions: 3.0.0 Reporter: Zhao Yongming Priority: Minor Fix For: 3.3.0 the sampling is a global config in logging, we want to get it custom-able. -- 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-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
[
https://issues.apache.org/jira/browse/TS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-871:
-
Fix Version/s: (was: 3.1.6)
3.3.0
Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.
Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
---
Key: TS-871
URL: https://issues.apache.org/jira/browse/TS-871
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.0.0
Reporter: Igor Galić
Assignee: Leif Hedstrom
Fix For: 3.3.0
Attachments: TS-871.diff, ats_Thttp.debug.notime.txt,
ats_Thttp.debug.txt, revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt,
serf_proxy.cap, serf_revproxy.cap, stats.diff
When accessing a remote subversion repository via http or https with svn 1.7,
it will currently timeout:
{noformat}
igalic@tynix ~/src/asf % svn co
http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
svn: E020014: Unable to connect to a repository at URL
'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
svn: E020014: Unspecified error message: 504 Connection Timed Out
1 igalic@tynix ~/src/asf %
{noformat}
I have started traffic_server -Thttp and captured the output, which I'm
attaching.
There's also a capture from the network.
--
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-343) The cache lookup and add operation use different key in plugin
[
https://issues.apache.org/jira/browse/TS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-343:
-
Fix Version/s: (was: 3.1.6)
3.3.0
Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.
The cache lookup and add operation use different key in plugin
--
Key: TS-343
URL: https://issues.apache.org/jira/browse/TS-343
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.0.0
Reporter: Flier Lu
Priority: Critical
Fix For: 3.3.0
I'm developing a cache plugin base on the redis,
http://code.google.com/p/rediscache/
The plugin could be loaded and hook the cache read/write operations
[May 9 16:25:05.012] Server {3079476928} NOTE: loading plugin
'libexec/trafficserver/redis_cache.so'
[May 9 16:25:05.014] Server {3079476928} DIAG: (cache_plugin)
[INKPluginInit] Starting redis cache plugin
But the cache lookup and add operation use different key, it seems use the
url as lookup key
[May 9 16:25:13.149] Server {3066555280} DEBUG: (cache_plugin)
[CacheProcessor::open_read] Cache hooks are set
[May 9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin)
[NewCacheVC::alloc] new B33B1EE0
[May 9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin)
[NewCacheVC::set_cache_http_hdr]
[May 9 16:25:13.153] Server {3066555280} DIAG: (cache_plugin) [cache_read]
[May 9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin)
[INKCacheKeyGet] vc get cache key
[May 9 16:25:13.158] Server {3066555280} DIAG: (cache_plugin) cache hitted
for key: http://www.baidu.com/ w/ 0 bytes value
[May 9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin)
[INKHttpCacheReenable] event id: 1133 data: 0 size: 0
[May 9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin)
[INKHttpCacheReenable] cache_lookup_complete
[May 9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin)
[INKHttpCacheReenable] open read failed
but store the cache item with a random MD5 as key
[May 9 16:25:13.334] Server {3079476928} DEBUG: (cache_plugin)
[NewCacheVC::handleWrite] event=1
[May 9 16:25:13.334] Server {3079476928} DIAG: (cache_plugin) [cache_write]
[May 9 16:25:13.334] Server {3079476928} DEBUG: (cache_plugin)
[INKCacheKeyGet] vc get cache key
[May 9 16:25:13.346] Server {3079476928} DIAG: (cache_plugin) put 3571 bytes
value to redis w/ 16 bytes key: 0xb33b1fb0
[May 9 16:25:13.346] Server {3079476928} DEBUG: (cache_plugin)
[INKHttpCacheReenable] event id: 1129 data: 0 size: 3571
[May 9 16:25:13.346] Server {3079476928} DEBUG: (cache_plugin)
[INKHttpCacheReenable] cache_write
I'm not sure whether it is a design issue or bug ? and the cache lookup
always has 0 size buffer ?
--
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-378) FIx the strict-aliasing rules warnings
[
https://issues.apache.org/jira/browse/TS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-378:
-
Fix Version/s: (was: 3.1.6)
3.3.0
Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.
FIx the strict-aliasing rules warnings
--
Key: TS-378
URL: https://issues.apache.org/jira/browse/TS-378
Project: Traffic Server
Issue Type: Improvement
Components: Cleanup
Affects Versions: 3.0.0
Reporter: Mladen Turk
Assignee: Mladen Turk
Priority: Minor
Fix For: 3.3.0
Currently the compile fails with -fstrict-aliasing.
The reason is mostly using int pointers to read or write 64 bit numbers
Eg. INK_MD5.cc has
struct INK_MD5
{
uint64 b[2];
uint32 word(int i)
{
uint32 *p = (uint32 *) b[0];
return p[i];
}
...
};
Such things can be easily fixed and properly handled using unions
(they are invented for that)
struct INK_MD5
{
union {
uint64 q[2];
uint32 u[4];
unsigned char b[16];
} s;
uint32 word(int i)
{
return s.w[i];
}
...
};
--
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-110) Improve regex remap to allow substitutions in path field
[ https://issues.apache.org/jira/browse/TS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-110: - Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. Improve regex remap to allow substitutions in path field Key: TS-110 URL: https://issues.apache.org/jira/browse/TS-110 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.0.0 Reporter: Manjesh Nilange Priority: Minor Fix For: 3.3.0 Currently, regex support covers only the host field of the remap rules. It'd be nice to extend this to allow substitutions into the path field as well. This will allow rules like: regex_map http://www.example-(.*).com/ http://real-example.com/$1 -- 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-879) Seek on cached file
[ https://issues.apache.org/jira/browse/TS-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-879: - Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. Seek on cached file --- Key: TS-879 URL: https://issues.apache.org/jira/browse/TS-879 Project: Traffic Server Issue Type: Bug Components: Cache, TS API Affects Versions: 3.0.0 Reporter: Nelson Pérez Labels: api-addition, cache, trafficserver Fix For: 3.3.0 I want a custom written plugin to be able to seek to any point in a cached file. According to John Plevyak (http://www.mail-archive.com/dev@trafficserver.apache.org/msg02785.html) this feature is new in the cache, but not yet available to the API. -- 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-817) TSFetchUrl/TSFetchPages does not work with HTTP/1.1 requests
[ https://issues.apache.org/jira/browse/TS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-817: - Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. TSFetchUrl/TSFetchPages does not work with HTTP/1.1 requests Key: TS-817 URL: https://issues.apache.org/jira/browse/TS-817 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.0 Reporter: Naveen Labels: api-change, function Fix For: 3.3.0 The API calls TSFetchUrl/TSFetchPages do not work with HTTP/1.1 requests. The implementation seems to use the end of the connection to signal the user callback function, which is not the case on persistent connections. -- 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-725) Crash Report: url_host_set in 2.1.6
[
https://issues.apache.org/jira/browse/TS-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-725:
-
Fix Version/s: (was: 3.1.6)
3.3.0
Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.
Crash Report: url_host_set in 2.1.6
---
Key: TS-725
URL: https://issues.apache.org/jira/browse/TS-725
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 2.1.6
Reporter: Zhao Yongming
Labels: crash
Fix For: 3.3.0
reported by user:
{code:none}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/ts/bin/traffic_server - STACK TRACE:
[0x4001c420]
/lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
[0xf]
/usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char
const*, int, bool)+0x51)[0x8229631]
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/ts/bin/traffic_server - STACK TRACE:
[0x4001c420]
/lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
[0xf]
/usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char
const*, int, bool)+0x51)[0x8229631]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0xab)[0x816a8eb]
/usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x321)[0x817acc1]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x1a4)[0x8184894]
/usr/local/ts/bin/traffic_server[0x82f880c]
/usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x4ce)[0x82edffe]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x1ff)[0x83226bf]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x449)[0x8322e69]
/usr/local/ts/bin/traffic_server[0x8321abc]
/lib/tls/i686/cmov/libpthread.so.0[0x400284fb]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
[Mar 8 11:02:52.960] Manager {3080226496} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmenta
tion fault
[Mar 8 11:02:52.960] Manager {3080226496} ERROR: (last system error 2: No
such file or directory)
[Mar 8 11:02:52.961] Manager {3080226496} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Mar 8 11:02:52.961] Manager {3080226496} ERROR: (last system error 2: No
such file or directory)
[Mar 8 11:02:53.964] Manager {3080226496} NOTE: [LocalManager::startProxy]
Launching ts process
[TrafficServer] using root directory '/usr/local/ts'
[Mar 8 11:02:53.973] Manager {3080226496} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '12'
[Mar 8 11:02:53.973] Manager {3080226496} NOTE: [Alarms::signalAlarm] Server
Process born
[Mar 8 11:02:55.015] {1079500240} STATUS: opened
/usr/local/ts/var/log/trafficserver/diags.log
[Mar 8 11:02:55.015] {1079500240} NOTE: updated diags config
[Mar 8 11:02:55.024] Server {1079500240} NOTE: cache clustering disabled
[Mar 8 11:02:55.069] Server {1079500240} NOTE: cache clustering disabled
[Mar 8 11:02:55.274] Server {1079500240} STATUS: Rolling disabled for
/usr/local/ts/var/log/trafficserver/access.log.pipe
[Mar 8 11:02:55.325] Server {1079500240} NOTE: logging initialized[7],
logging_mode = 3
[Mar 8 11:02:55.368] Server {1079500240} NOTE: traffic server running
[Mar 8 11:02:58.584] Server {1096645520} NOTE: cache enabled
{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-60) support writing large buffers via zero-copy
[ https://issues.apache.org/jira/browse/TS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-60: Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. support writing large buffers via zero-copy --- Key: TS-60 URL: https://issues.apache.org/jira/browse/TS-60 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 3.0.0 Environment: all Reporter: John Plevyak Assignee: John Plevyak Fix For: 3.3.0 Original Estimate: 48h Remaining Estimate: 48h Currently all write data is written from the aggregation buffer. In order to support large buffer writes efficiently it would be nice to be able to write directly from page aligned memory. This would be bother more efficient and would help support large objects. -- 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-829) socks stats cleanup - some stats are registered, but not used
[ https://issues.apache.org/jira/browse/TS-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-829: - Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. socks stats cleanup - some stats are registered, but not used - Key: TS-829 URL: https://issues.apache.org/jira/browse/TS-829 Project: Traffic Server Issue Type: Bug Components: Network Affects Versions: 3.0.0 Reporter: Bryan Call Priority: Minor Fix For: 3.3.0 From reviewing TS-818 I noticed that the stats that were being double resisted are not used. Some cleanup work should be done for the socks stats. Stats that are registered, but not used in the code: [bcall@snowball traffic.git]$ grep -r proxy.process.socks iocore/net/Net.cc proxy.process.socks.connections_successful, proxy.process.socks.connections_unsuccessful, proxy.process.socks.connections_currently_open, These stats are used some tests, so maybe they should be added back into the code. [bcall@snowball traffic.git]$ grep -rl --binary-files=without-match proxy.process.socks.connections_ * iocore/net/Net.cc mgmt/api/remote/APITestCliRemote.cc test/plugin/test-mgmt/test-mgmt.c I did however see these stats being used: [bcall@snowball traffic.git]$ grep -r SOCKSPROXY_ * proxy/SocksProxy.cc:#define SOCKSPROXY_INC_STAT(x) \ proxy/SocksProxy.cc: SOCKSPROXY_INC_STAT(socksproxy_http_connections_stat); proxy/SocksProxy.cc: SOCKSPROXY_INC_STAT(socksproxy_tunneled_connections_stat); -- 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-654) request for support of Layer7 http health checking for Origin Servers
[ https://issues.apache.org/jira/browse/TS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-654: - Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. request for support of Layer7 http health checking for Origin Servers - Key: TS-654 URL: https://issues.apache.org/jira/browse/TS-654 Project: Traffic Server Issue Type: New Feature Components: HTTP Affects Versions: 3.0.0 Reporter: Zhao Yongming Assignee: mohan_zl Fix For: 3.3.0 Attachments: HCUtil.cc, hc.patch this ticket is for the L7 health checking project: https://cwiki.apache.org/confluence/display/TS/HttpHealthCheck -- 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-803) Fix SOCKS breakage and allow for setting next-hop SOCKS
[
https://issues.apache.org/jira/browse/TS-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-803:
-
Fix Version/s: (was: 3.1.6)
3.3.0
Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.
Fix SOCKS breakage and allow for setting next-hop SOCKS
---
Key: TS-803
URL: https://issues.apache.org/jira/browse/TS-803
Project: Traffic Server
Issue Type: New Feature
Components: Network
Affects Versions: 3.0.0
Environment: Wherever ATS might run
Reporter: M. Nunberg
Fix For: 3.3.0
Here is a patch I drew up a few months ago against a snapshot of ATS/2.1.7
unstable/git. There are some quirks here, and I'm not that sure any more what
this patch does exactly. However it:
1) Does fix SOCKS connections in general
2) Allows setting next-hop SOCKS proxy via the API
Problems:
See https://issues.apache.org/jira/browse/TS-802
This has no effect on connections which are drawn from the connection pool,
as it seems ATS currently doesn't maintain unique identities for peripheral
connection params (source IP, SOCKS etc); i.e. this only affects new TCP
connections to an OS.
diff -x '*.o' -ru tsorig/iocore/net/I_NetVConnection.h
tsgit217/iocore/net/I_NetVConnection.h
--- tsorig/iocore/net/I_NetVConnection.h2011-03-09 21:43:58.0
+
+++ tsgit217/iocore/net/I_NetVConnection.h2011-03-17 14:37:18.0
+
@@ -120,6 +120,13 @@
/// Version of SOCKS to use.
unsigned char socks_version;
+ struct {
+ unsigned int ip;
+ int port;
+ char *username;
+ char *password;
+ } socks_override;
+
int socket_recv_bufsize;
int socket_send_bufsize;
Only in tsgit217/iocore/net: Makefile
Only in tsgit217/iocore/net: Makefile.in
diff -x '*.o' -ru tsorig/iocore/net/P_Socks.h tsgit217/iocore/net/P_Socks.h
--- tsorig/iocore/net/P_Socks.h2011-03-09 21:43:58.0 +
+++ tsgit217/iocore/net/P_Socks.h2011-03-17 13:17:20.0 +
@@ -126,7 +126,7 @@
unsigned char version;
bool write_done;
-
+ bool manual_parent_selection;
SocksAuthHandler auth_handler;
unsigned char socks_cmd;
@@ -145,7 +145,8 @@
SocksEntry():Continuation(NULL), netVConnection(0),
ip(0), port(0), server_ip(0), server_port(0), nattempts(0),
-lerrno(0), timeout(0), version(5), write_done(false),
auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
+lerrno(0), timeout(0), version(5), write_done(false),
manual_parent_selection(false),
+auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
{
}
};
diff -x '*.o' -ru tsorig/iocore/net/Socks.cc tsgit217/iocore/net/Socks.cc
--- tsorig/iocore/net/Socks.cc2011-03-09 21:43:58.0 +
+++ tsgit217/iocore/net/Socks.cc2011-03-17 13:46:07.0 +
@@ -73,7 +73,8 @@
nattempts = 0;
findServer();
- timeout = this_ethread()-schedule_in(this,
HRTIME_SECONDS(netProcessor.socks_conf_stuff-server_connect_timeout));
+// timeout = this_ethread()-schedule_in(this,
HRTIME_SECONDS(netProcessor.socks_conf_stuff-server_connect_timeout));
+ timeout = this_ethread()-schedule_in(this, HRTIME_SECONDS(5));
write_done = false;
}
@@ -81,6 +82,15 @@
SocksEntry::findServer()
{
nattempts++;
+ if(manual_parent_selection) {
+ if(nattempts 1) {
+ //Nullify IP and PORT
+ server_ip = -1;
+ server_port = 0;
+ }
+ Debug(mndebug(Socks), findServer() is a noop with manual socks
selection);
+ return;
+ }
#ifdef SOCKS_WITH_TS
if (nattempts == 1) {
@@ -187,7 +197,6 @@
}
Debug(Socks, Failed to connect to %u.%u.%u.%u:%d,
PRINT_IP(server_ip), server_port);
-
findServer();
if (server_ip == (uint32_t) - 1) {
diff -x '*.o' -ru tsorig/iocore/net/UnixNetProcessor.cc
tsgit217/iocore/net/UnixNetProcessor.cc
--- tsorig/iocore/net/UnixNetProcessor.cc2011-03-09 21:43:58.0
+
+++ tsgit217/iocore/net/UnixNetProcessor.cc2011-03-17 15:48:38.0
+
@@ -228,6 +228,11 @@
!socks_conf_stuff-ip_range.match(ip))
#endif
);
+ if(opt-socks_override.ip = 1) {
+ using_socks = true;
+ Debug(mndebug, trying to set using_socks to true);
+ }
+
SocksEntry *socksEntry = NULL;
#endif
NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, 1);
@@ -242,6 +247,16 @@
if (using_socks) {
Debug(Socks, Using Socks ip: %u.%u.%u.%u:%d\n, PRINT_IP(ip), port);
socksEntry = socksAllocator.alloc();
+
+if (opt-socks_override.ip) {
+//Needs to be done before socksEntry-init()
+socksEntry-server_ip = opt-socks_override.ip;
+socksEntry-server_port = opt-socks_override.port;
+
[jira] [Updated] (TS-1063) prefetch resource leak
[
https://issues.apache.org/jira/browse/TS-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1063:
--
Fix Version/s: (was: 3.1.6)
3.3.0
Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.
prefetch resource leak
---
Key: TS-1063
URL: https://issues.apache.org/jira/browse/TS-1063
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.0.2
Environment: linux（ubuntu）
Reporter: yunfei chen
Fix For: 3.3.0
configuration：
records.config
CONFIG proxy.config.prefetch.prefetch_enabled INT 1
CONFIG proxy.config.prefetch.default_url_proto STRING udp
CONFIG proxy.config.prefetch.default_data_proto STRING udp
prefetch.config
prefetch child
[Dec 26 10:07:44.129] Server {2964810608} WARNING: too many connections,
throttling
[Dec 26 10:17:44.176] Server {2964810608} WARNING: too many connections,
throttling
FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
insufficient memory
/usr/local/bin/traffic_server - STACK TRACE:
FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
insufficient memory
FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
insufficient memory
/usr/local/bin/traffic_server - STACK TRACE:
/usr/local/bin/traffic_server - STACK TRACE:
FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
insufficient memory
/usr/local/bin/traffic_server - STACK TRACE:
FATAL: ink_memalign: couldn't allocate 524288 bytes at alignment 4096 -
insufficient memory
/usr/local/bin/traffic_server - STACK TRACE:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
#0 0x0012e416 in __kernel_vsyscall ()
#1 0x005c9941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x005cce42 in abort () at abort.c:92
#3 0x00520055 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib/libstdc++.so.6
#4 0x0051df35 in ?? () from /usr/lib/libstdc++.so.6
#5 0x0051df72 in std::terminate() () from /usr/lib/libstdc++.so.6
#6 0x0051e0e1 in __cxa_throw () from /usr/lib/libstdc++.so.6
#7 0x0051e677 in operator new(unsigned int) () from /usr/lib/libstdc++.so.6
#8 0x0051e74d in operator new[](unsigned int) () from /usr/lib/libstdc++.so.6
#9 0x081488fd in DynArraychar::resize (this=0x748ff4c, new_size=64) at
../lib/ts/DynArray.h:174
#10 0x0815d5da in DynArraychar::operator() (this=0x748ff4c, idx=0) at
../lib/ts/DynArray.h:122
#11 0x0815a9bb in HtmlParser::ScanHtmlForURL (this=0x748ff3c, r=0xbabb3ac0,
url=0xb70921ec, url_end=0xb70921e8) at Update.cc:1874
#12 0x0815a86a in HtmlParser::ParseHtml (this=0x748ff3c, r=0xbabb3ac0,
url=0xb70921ec, url_end=0xb70921e8) at Update.cc:1820
#13 0x08140816 in PrefetchTransform::parse_data (this=0x748fe88,
reader=0xbabb3ac0) at Prefetch.cc:543
#14 0x0813ffe8 in PrefetchTransform::handle_event (this=0x748fe88, event=1,
edata=0x5991b530) at Prefetch.cc:435
#15 0x08104ba5 in Continuation::handleEvent (this=0x748fe88, event=1,
data=0x5991b530)
at ../iocore/eventsystem/I_Continuation.h:146
#16 0x0830a9f5 in EThread::process_event (this=0xb7497008, e=0x5991b530,
calling_code=1) at UnixEThread.cc:140
#17 0x0830ac38 in EThread::execute (this=0xb7497008) at UnixEThread.cc:189
#18 0x0830900e in spawn_thread_internal (a=0x895df28) at Thread.cc:88
#19 0x00165cc9 in start_thread (arg=0xb7092b70) at pthread_create.c:304
#20 0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
--
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-959) ae filtering code need to get clean clever
[ https://issues.apache.org/jira/browse/TS-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-959: - Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. ae filtering code need to get clean clever Key: TS-959 URL: https://issues.apache.org/jira/browse/TS-959 Project: Traffic Server Issue Type: Improvement Components: Configuration, HTTP Affects Versions: 3.0.0 Reporter: Zhao Yongming Assignee: Zhao Yongming Priority: Minor Fix For: 3.3.0 I think the codes for aeua filter is ugly placed into httpconfig main.cc, and can not get live updated with traffic_line, that is not acceptable for our config system. the codes need to be move out into one dedicate file or at least get cleanup, and setup the callbacks for config file changes. -- 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-983) prefetch: the documents
[ https://issues.apache.org/jira/browse/TS-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-983: - Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. prefetch: the documents --- Key: TS-983 URL: https://issues.apache.org/jira/browse/TS-983 Project: Traffic Server Issue Type: Sub-task Reporter: Zhao Yongming Assignee: Zhao Yongming Fix For: 3.3.0 -- 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-1068) we should not wait all the prefetch clients finish
[ https://issues.apache.org/jira/browse/TS-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1068: -- Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. we should not wait all the prefetch clients finish -- Key: TS-1068 URL: https://issues.apache.org/jira/browse/TS-1068 Project: Traffic Server Issue Type: Sub-task Components: HTTP Affects Versions: 3.1.1 Reporter: Zhao Yongming Fix For: 3.3.0 when one request is on prefetching, we should not wait for all the prefetch clients, as there will be minutes or even hours. -- 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-893) the prefetch function in codes need more love to show up
[ https://issues.apache.org/jira/browse/TS-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-893: - Fix Version/s: (was: 3.1.6) 3.3.0 Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*. the prefetch function in codes need more love to show up Key: TS-893 URL: https://issues.apache.org/jira/browse/TS-893 Project: Traffic Server Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Zhao Yongming Assignee: Zhao Yongming Fix For: 3.3.0 the prefetch function in proxy is a good solution when you really need to faster up your user download time, it can parse any allowed plean html file, get all resource tags out and do batch loading from OS. I am going to preload my site before we put it online, as it will get about 1 month to get the disk full and hit rate stable. it is a cool feature but it have the following issues: 1, the prefetch config file is not managed well. ie, it is not managed by cluster 2, the it does not any document in the admin guide or old pdf file. 3, prefetching just care plean html file, without compressing, should we do some decompressing? is that possible? hopes this is the starting of make prefetch really useful for some cutting edge situation. -- 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-986) ts/experimental has a dependency on netinet/net.h (for struct in_addr)
[ https://issues.apache.org/jira/browse/TS-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-986: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! ts/experimental has a dependency on netinet/net.h (for struct in_addr) -- Key: TS-986 URL: https://issues.apache.org/jira/browse/TS-986 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Fix For: 3.3.0 Alan seems to indicate this is wrong anyways, but just adding this bug so we remember it's probably a bad idea. The offending API is tsapi int TSNodeHandleToIPAddr(TSNodeHandle_t *h, struct in_addr *in); -- 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-892) request for bulk setting in remap.config for refer filter
[
https://issues.apache.org/jira/browse/TS-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-892:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
request for bulk setting in remap.config for refer filter
-
Key: TS-892
URL: https://issues.apache.org/jira/browse/TS-892
Project: Traffic Server
Issue Type: Improvement
Components: Configuration, HTTP
Affects Versions: 3.1.0
Reporter: Zhao Yongming
Labels: remap
Fix For: 3.3.0
when we put our TS online, we find out we are complex when handling squid's
default filter rule such as:
{code}
acl ctoc referer_regex -i XXXa\.com\/ XXXb\.com\/ XXXc\.com\/
http_access deny ctoc
{code}
we have to convert every map rule to map_with_referer, and get very ugly. if
we can get the referer filter config in the bulk way as IP based filter in
the remap.config, it will make the config file clear and clean
--
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-972) traffic_line should warn if a command didn't succeed
[
https://issues.apache.org/jira/browse/TS-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-972:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
traffic_line should warn if a command didn't succeed
Key: TS-972
URL: https://issues.apache.org/jira/browse/TS-972
Project: Traffic Server
Issue Type: Improvement
Components: Management API
Affects Versions: 3.1.0, 3.0.1
Reporter: Arno Toell
Fix For: 3.3.0
{{traffic_line}} is a handy tool to manage a traffic server instance. For
example it is possible to retrieve and set configuration settings through
command line like this:
{code}
root@wv-tmp2:/home/at# traffic_line -r proxy.config.http.server_port ; echo $?
81
0
{code}
However, some commans can be set, but aren't effective until the server is
restarted, despite of ATS offering the _-x_ option to flush configuration and
reread new settings:
{code}
root@wv-tmp2:/home/at# traffic_line -s proxy.config.http.server_port -v 80 ;
echo $?
0
root@wv-tmp2:/home/at# traffic_line -x ; echo $?
0
{code}
Trafficserver should possibly warn when setting such settings which aren't
effective until the server is restarted and leave with a non-zero exit status
for _-x_ in such cases.
Moreover {{traffic_line}} does not work at all if the manager is not running:
{code}
# traffic_line -r proxy.config.http.server_port ; echo $?
traffic_line: Variable Not Found
1
{code}
That's all right, but the error message shall be improved telling that. :)
--
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-208) OSX: Add raw disk support for the cache
[ https://issues.apache.org/jira/browse/TS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-208: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! OSX: Add raw disk support for the cache --- Key: TS-208 URL: https://issues.apache.org/jira/browse/TS-208 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 2.1.0 Environment: OSX(10.5,10.6) Reporter: George Paul Assignee: Dan Mercer Fix For: 3.3.0 Currently only a file cache is supported on OSX. It would be nice to have Raw Disk support before 2.1 release. -George -- 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-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-745: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.3.0 Attachments: TS-ssd-2.patch, TS-ssd.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1007) SSN Close called before TXN Close
[ https://issues.apache.org/jira/browse/TS-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1007: -- Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! SSN Close called before TXN Close - Key: TS-1007 URL: https://issues.apache.org/jira/browse/TS-1007 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.1 Reporter: Nick Kew Priority: Critical Fix For: 3.3.0 Where a plugin implements both SSN_CLOSE_HOOK and TXN_CLOSE_HOOK, the SSN_CLOSE_HOOK is called first of the two. This messes up normal cleanups! Details: Register a SSN_START event globally In the SSN START, add a TXN_START and a SSN_CLOSE In the TXN START, add a TXN_CLOSE Stepping through, I see the order of events actually called, for the simple case of a one-off HTTP request with no keepalive: SSN_START TXN_START SSN_END TXN_END Whoops, SSN_END cleaned up the SSN context, leaving dangling pointers in the TXN! -- 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-895) Unable to compile trafficserver 3.0.1 with WCCP support on ubuntu lucid (10.04)
[
https://issues.apache.org/jira/browse/TS-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-895:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
Unable to compile trafficserver 3.0.1 with WCCP support on ubuntu lucid
(10.04)
---
Key: TS-895
URL: https://issues.apache.org/jira/browse/TS-895
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.1
Environment: Ubuntu lucid (10.04) LTS, 64bit
Reporter: Brane F. Gračnar
Assignee: Alan M. Carroll
Fix For: 3.3.0
I'm unable to compile ATS 3.0.1 on my 64bit ubuntu lucid server.
Configure flags:
./configure --prefix=/usr --sysconfdir=/etc/trafficserver --enable-wccp
--enable-tproxy=auto --with-pic
make dies with the following error:
make[2]: Entering directory `/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig'
/bin/bash ../../build/aux/ylwrap TsConfigGrammar.y y.tab.c TsConfigGrammar.c
y.tab.h TsConfigGrammar.h y.output TsConfigGrammar.output -- byacc -d -p
tsconfig
byacc: e - line 1 of
/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig/TsConfigGrammar.y, syntax
error
%code top {
^
make[2]: *** [TsConfigGrammar.c] Error 1
make[2]: Leaving directory `/export/tmp/ats/trafficserver-3.0.1/lib/tsconfig'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/export/tmp/ats/trafficserver-3.0.1/lib'
make: *** [all-recursive] Error 1
--
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-1051) Updating logs_xml.config requires full restart
[
https://issues.apache.org/jira/browse/TS-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1051:
--
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
Updating logs_xml.config requires full restart
--
Key: TS-1051
URL: https://issues.apache.org/jira/browse/TS-1051
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.1.2
Reporter: Billy Vierra
Assignee: Zhao Yongming
Fix For: 3.3.0
Using SVN Rev: 1214051
URL: http://svn.apache.org/repos/asf/trafficserver/traffic/trunk
upon adding a new LogObject and doing traffic_line -x you get the following
in traffic.out
[Dec 14 12:31:48.533] Manager {0x7f2f2abef700} NOTE: User has changed config
file logs_xml.config
However it does not go into effect (new log is not created). Upon full
restart: trafficserver stop, trafficserver start it will add the new log file
as expected.
Not sure if it is a bug with docs or in 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-802) Unique KA pools for SOCKS/src IP parameters
[ https://issues.apache.org/jira/browse/TS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-802: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! Unique KA pools for SOCKS/src IP parameters --- Key: TS-802 URL: https://issues.apache.org/jira/browse/TS-802 Project: Traffic Server Issue Type: Wish Components: HTTP Reporter: M. Nunberg Fix For: 3.3.0 From what I've observed, ATS' keepalive/connection cache only indexes by the OS server or next proxy server, but not by other types of connection/transport/socket parameters, specifically in my case, negotiated SOCKS connections and outgoing connections which are bound to a specific source IP Is it possible to have such functionality in the near future? Currently I've been forced to write my own 'KA gateway' which pretends to be an HTTP server (to which ATS can maintain unique connections) and have that do SOCKS/source ip bind()ing for me. -- 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-207) [Gsoc2011] FreeBSD: Add raw disk support for the cache
[ https://issues.apache.org/jira/browse/TS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-207: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! [Gsoc2011] FreeBSD: Add raw disk support for the cache -- Key: TS-207 URL: https://issues.apache.org/jira/browse/TS-207 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 2.1.0 Environment: FreeBSD Reporter: George Paul Assignee: Dan Mercer Labels: gsoc2011 Fix For: 3.3.0 Currently only a file cache is supported on FreeBSD. Raw Disk support should be added before 2.1 release. -George -- 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-346) ATS does not verify server certificate
[ https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-346: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! ATS does not verify server certificate -- Key: TS-346 URL: https://issues.apache.org/jira/browse/TS-346 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: vijaya bhaskar mamidi Assignee: Igor Galić Priority: Critical Fix For: 3.3.0 ATS does not verify the certificates correctly. -- 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-1003) prefetch: the config file
[ https://issues.apache.org/jira/browse/TS-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1003: -- Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! prefetch: the config file - Key: TS-1003 URL: https://issues.apache.org/jira/browse/TS-1003 Project: Traffic Server Issue Type: Sub-task Components: Configuration Reporter: Zhao Yongming Assignee: Zhao Yongming Fix For: 3.3.0 Attachments: TS-1003.patch PreFetch and Update is the most strange plugin that keep in the proxy dir. and we have some PreFetch API that should make some usage, but the config file for prefetch and configs not managed live other config files in the tree. we should make PreFetch a big feature for TS, and smooth all the ugly coded issue. -- 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-228) Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit, we shoud not use long anywhere in TS
[ https://issues.apache.org/jira/browse/TS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-228: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit, we shoud not use long anywhere in TS Key: TS-228 URL: https://issues.apache.org/jira/browse/TS-228 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 2.1.0 Reporter: John Plevyak Assignee: John Plevyak Priority: Critical Fix For: 3.3.0 Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit. This is a potential can of worms which at the least is making records.snap incompatible but at worse could be the cause of other bugs. In any case we should not be using long in the TS code, but instead use either int which is always 32-bits or inkXXX of a particular size. -- 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-877) Segfault caused by HTTPInfo::object_key_get
[
https://issues.apache.org/jira/browse/TS-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-877:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
Segfault caused by HTTPInfo::object_key_get
Key: TS-877
URL: https://issues.apache.org/jira/browse/TS-877
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.0.0
Environment: Ubuntu 10.04tls 64bit
Reporter: Kingsley Foreman
Labels: crash
Fix For: 3.3.0
Segfault caused by HTTPInfo::object_key_get
Reading symbols from /usr/lib/libtsutil.so.3...done.
Loaded symbols for /usr/lib/libtsutil.so.3
Reading symbols from /lib/libpthread.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libresolv.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libpcre.so.3
Reading symbols from /lib/libssl.so.0.9.8...(no debugging symbols
found)...done.
Loaded symbols for /lib/libssl.so.0.9.8
Reading symbols from /lib/libcrypto.so.0.9.8...(no debugging symbols
found)...done.
Loaded symbols for /lib/libcrypto.so.0.9.8
Reading symbols from /usr/lib/libtcl8.4.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libtcl8.4.so.0
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libexpat.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libexpat.so.1
Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnss_dns.so.2
Reading symbols from /usr/libexec/trafficserver/header_filter.so...done.
Loaded symbols for /usr/libexec/trafficserver/header_filter.so
Core was generated by `/usr/bin/traffic_server -M -A,9:X'.
Program terminated with signal 11, Segmentation fault.
#0 0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at
../../proxy/hdrs/HTTP.h:1375
1375 ((int32_t *) val)[0] = m_alt-m_object_key[0];
(gdb) bt
#0 0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at
../../proxy/hdrs/HTTP.h:1375
#1 0x00592c72 in HttpTransactCache::SelectFromAlternates
(cache_vector=0x1c96568, client_request=0x1c96528,
http_config_params=0x2ae66c4b5228)
at HttpTransactCache.cc:213
#2 0x006cb4f1 in CacheVC::openReadChooseWriter (this=0x1c96460,
event=2, e=0x1e6d6d0) at CacheRead.cc:262
#3 0x006cbc82 in CacheVC::openReadFromWriter (this=0x1c96460,
event=2, e=0x1e6d6d0) at CacheRead.cc:332
#4 0x004e63e8 in Continuation::handleEvent (this=0x1c96460, event=2,
data=0x1e6d6d0) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x0072055d in EThread::process_event (this=0x2ae646b46010,
e=0x1e6d6d0, calling_code=2) at UnixEThread.cc:140
#6 0x0072090d in EThread::execute (this=0x2ae646b46010) at
UnixEThread.cc:217
#7 0x0071ec32 in spawn_thread_internal (a=0x1a14380) at Thread.cc:88
#8 0x2ae643f639ca in start_thread () from /lib/libpthread.so.0
#9 0x2ae64616970d in clone () from /lib/libc.so.6
#10 0x in ?? ()
(gdb) print *this
$1 = {m_alt = 0x0}
--
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
[jira] [Updated] (TS-942) Assert in HttpTransact::HandleCacheOpenReadMiss
[
https://issues.apache.org/jira/browse/TS-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-942:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
Assert in HttpTransact::HandleCacheOpenReadMiss
---
Key: TS-942
URL: https://issues.apache.org/jira/browse/TS-942
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.1
Reporter: Leif Hedstrom
Priority: Critical
Fix For: 3.3.0
I'm seeing a crasher (see below), and it happens in code like this:
{code}
if (s-current.server-ip == 0) {
ink_release_assert(s-current.request_to == PARENT_PROXY ||
s-http_config_param-no_dns_forward_to_parent != 0);
if (s-current.request_to == PARENT_PROXY) {
{code}
What happens is that .server-ip is indeed 0, but current.request_to is !=
PARENT_PROXY (it is instead ORIGIN_SERVER). I've not seen this before, and it
reproduces rarely, so wondering if it could be IPv6 related.
Crasher:
{code}
(gdb) bt
#0 0x003f2de327f5 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x003f2de33fd5 in abort () at abort.c:92
#2 0x006407a1 in ink_die_die_die (return_code=value optimized out,
message_format=value optimized out, ap=0x2b0756137600) at ink_error.cc:43
#3 ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *)
(return_code=value optimized out, message_format=value optimized out,
ap=0x2b0756137600) at ink_error.cc:65
#4 0x006408d6 in ink_fatal (return_code=value optimized out,
message_format=value optimized out) at ink_error.cc:73
#5 0x0063f761 in _ink_assert (a=0x668400 s-current.request_to ==
PARENT_PROXY || s-http_config_param-no_dns_forward_to_parent != 0,
f=value optimized out, l=2952) at ink_assert.cc:44
#6 0x00516d5c in HttpTransact::HandleCacheOpenReadMiss
(s=0x2b0763638018) at HttpTransact.cc:2952
#7 0x004f08e2 in HttpSM::call_transact_and_set_next_state
(this=0x2b0763637fb0, f=value optimized out) at HttpSM.cc:6339
#8 0x004fffda in HttpSM::handle_api_return (this=0x2b0763637fb0) at
HttpSM.cc:1520
#9 0x004f2d42 in HttpSM::state_hostdb_lookup (this=value optimized
out, event=value optimized out, data=value optimized out) at
HttpSM.cc:2064
#10 0x00503de0 in HttpSM::main_handler (this=0x2b0763637fb0,
event=500, data=0x2b0760231860) at HttpSM.cc:2454
#11 0x0058d07b in handleEvent (cont=0x2b0763637fb0,
ar=0x2b0760231860) at ../../iocore/eventsystem/I_Continuation.h:146
#12 reply_to_cont (cont=0x2b0763637fb0, ar=0x2b0760231860) at HostDB.cc:552
#13 0x0058e939 in HostDBContinuation::dnsEvent (this=value optimized
out, event=value optimized out, e=value optimized out) at HostDB.cc:1504
#14 0x0059d281 in handleEvent (this=0x2a1c340, event=value optimized
out, e=value optimized out) at
../../iocore/eventsystem/I_Continuation.h:146
#15 DNSEntry::postEvent (this=0x2a1c340, event=value optimized out,
e=value optimized out) at DNS.cc:1265
#16 0x00638204 in handleEvent (this=0x2b0755e36010, e=0x2a61090,
calling_code=1) at I_Continuation.h:146
#17 EThread::process_event (this=0x2b0755e36010, e=0x2a61090, calling_code=1)
at UnixEThread.cc:140
#18 0x00638c7b in EThread::execute (this=0x2b0755e36010) at
UnixEThread.cc:189
#19 0x00637052 in spawn_thread_internal (a=0x1b206b0) at Thread.cc:88
#20 0x003f2e6068e0 in start_thread (arg=0x2b0756138710) at
pthread_create.c:297
#21 0x003f2dee0c9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#22 0x in ?? ()
(gdb) frame 6
#6 0x00516d5c in HttpTransact::HandleCacheOpenReadMiss
(s=0x2b0763638018) at HttpTransact.cc:2952
2952s-http_config_param-no_dns_forward_to_parent != 0);
(gdb) print s-current.request_to
$1 = ORIGIN_SERVER
(gdb) print s-current.server-ip
$2 = 0
{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-541) SplitDNS cleanup in project HostDBandDNS
[ https://issues.apache.org/jira/browse/TS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-541: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! SplitDNS cleanup in project HostDBandDNS Key: TS-541 URL: https://issues.apache.org/jira/browse/TS-541 Project: Traffic Server Issue Type: Improvement Components: Cleanup, DNS Reporter: Zhao Yongming Priority: Minor Fix For: 3.3.0 Attachments: TS-541.patch as per https://cwiki.apache.org/confluence/display/TS/HostDBandDNS, we will need to cleanup SplitDNS, make it out of HostDB codes, merge with common dns processor. this may be another fix for TS-435. -- 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-977) RecCore usage cleanup
[
https://issues.apache.org/jira/browse/TS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-977:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
RecCore usage cleanup
-
Key: TS-977
URL: https://issues.apache.org/jira/browse/TS-977
Project: Traffic Server
Issue Type: Task
Components: Cleanup
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Minor
Fix For: 3.3.0
in RecCore.*
{code}
int RecGetRecordInt(const char *name, RecInt * rec_int, bool lock = true);
//-
// RecGetRecordXXX
//-
int
RecGetRecordInt(const char *name, RecInt *rec_int, bool lock)
{
int err;
RecData data;
if ((err = RecGetRecord_Xmalloc(name, RECD_INT, data, lock)) ==
REC_ERR_OKAY)
*rec_int = data.rec_int;
return err;
}
{code}
and there is something heavy used:
{code}
//-
// Backwards Compatibility Items (REC_ prefix)
//-
#define REC_ReadConfigInt32(_var,_config_var_name) do { \
RecInt tmp = 0; \
RecGetRecordInt(_config_var_name, (RecInt*) tmp); \
_var = (int32_t)tmp; \
} while (0)
#define REC_ReadConfigInteger(_var,_config_var_name) do { \
RecInt tmp = 0; \
RecGetRecordInt(_config_var_name, tmp); \
_var = tmp; \
} while (0)
{code}
and a real case, the REC_ReadConfigInteger is renamed to
IOCORE_ReadConfigInteger:
{code}
RecInt cache_config_threads_per_disk = 12;
#define IOCORE_ReadConfigIntegerREC_ReadConfigInteger
IOCORE_ReadConfigInteger(cache_config_threads_per_disk,
proxy.config.cache.threads_per_disk);
{code}
my question is, why it is so complex in all these renaming? why not just:
{code}
RecGetRecordInt(proxy.config.cache.threads_per_disk,
cache_config_threads_per_disk);
{code}
brief talk with Leif, we may need to cleanup the use of REC_*. make it a
small task here
--
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-709) proxy.config.output.logfile is not configurable
[ https://issues.apache.org/jira/browse/TS-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-709: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! proxy.config.output.logfile is not configurable --- Key: TS-709 URL: https://issues.apache.org/jira/browse/TS-709 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Igor Galić Priority: Minor Fix For: 3.3.0 The code suggests that proxy.config.output.logfile can be set to stdout, stderr, syslog, diagslog or an arbitrary file (if relative, then relative to $logdir). Setting it however, has no effect, the debug output always goes to stderr. -- 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-1019) clean up access to librecords and remove wrappers
[
https://issues.apache.org/jira/browse/TS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1019:
--
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
clean up access to librecords and remove wrappers
-
Key: TS-1019
URL: https://issues.apache.org/jira/browse/TS-1019
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Bryan Call
Assignee: Igor Galić
Priority: Minor
Fix For: 3.3.0
There are unneeded define wrappers around the librecord function calls:
{noformat}
[bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger
* | grep define
iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger
REC_ConfigReadInteger
proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger
REC_ConfigReadInteger
proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger
REC_ConfigReadInteger
proxy/logging/LogConfig.h:#define LOG_LocalReadInteger
REC_ConfigReadInteger
proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger
{noformat}
--
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-475) HTTP SM should support efficient byte range requests
[ https://issues.apache.org/jira/browse/TS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-475: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! 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 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] [Updated] (TS-1001) reload the changes in dns.resolv_conf
[ https://issues.apache.org/jira/browse/TS-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1001: -- Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! reload the changes in dns.resolv_conf - Key: TS-1001 URL: https://issues.apache.org/jira/browse/TS-1001 Project: Traffic Server Issue Type: Wish Components: DNS Reporter: Conan Wang Priority: Trivial Fix For: 3.3.0 a trivial wish: ATS can reload (traffic_line -x) resolv.conf if nameserver changed. -- 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-1059) prefetch segment fault
[ https://issues.apache.org/jira/browse/TS-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1059: -- Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! prefetch segment fault -- Key: TS-1059 URL: https://issues.apache.org/jira/browse/TS-1059 Project: Traffic Server Issue Type: Sub-task Components: HTTP Affects Versions: 3.0.2 Environment: linux(ubuntu) Reporter: yunfei chen Labels: crash Fix For: 3.3.0 I encountered a segment faut when I was testing Prefetch module。 ab -n 1 -c 1 -X 192.168.16.198:8080 -d http://club.baobao.sohu.com/r-mmbb-3954004-0-29-900.html configuration in records.config CONFIG proxy.config.prefetch.prefetch_enabled INT 1 configuration in prefetch.config prefetch_children 192.168.16.198 html_tag img src #0 0x08124f17 in VIO::reenable (this=0x0) at ../iocore/eventsystem/P_VIO.h:123 #1 0x08147fe3 in KeepAliveConn::append (this=0xab9aef20, rdr=0x9c91b794) at Prefetch.cc:1984 #2 0x08145fd7 in KeepAliveConnTable::append (this=0xb2393608, ip=16777343, buf=0x9c91b780, reader=0x9c91b794) at Prefetch.cc:2039 #3 0x0814679b in KeepAliveLockHandler::handleEvent (this=0xb23e0b30, event=2, data=0x8ab2f60) at Prefetch.cc:2168 #4 0x08104ba5 in Continuation::handleEvent (this=0xb23e0b30, event=2, data=0x8ab2f60) at ../iocore/eventsystem/I_Continuation.h:146 #5 0x0830a9f5 in EThread::process_event (this=0xb7396008, e=0x8ab2f60, calling_code=2) at UnixEThread.cc:140 #6 0x0830add5 in EThread::execute (this=0xb7396008) at UnixEThread.cc:217 #7 0x0830900e in spawn_thread_internal (a=0x895eed8) at Thread.cc:88 #8 0x00165cc9 in start_thread (arg=0xb6f91b70) at pthread_create.c:304 #9 0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 #0 0x08124f17 in VIO::reenable (this=0x0) at ../iocore/eventsystem/P_VIO.h:123 #1 0x08147fe3 in KeepAliveConn::append (this=0xa5736888, rdr=0x8d0b2f4) at Prefetch.cc:1984 #2 0x08145fd7 in KeepAliveConnTable::append (this=0xb2393608, ip=16777343, buf=0x8d0b2e0, reader=0x8d0b2f4) at Prefetch.cc:2039 #3 0x08141db3 in PrefetchUrlBlaster::udpUrlBlaster (this=0x8abd3e0, event=3300, data=0x0) at Prefetch.cc:885 #4 0x0813e4ea in PrefetchUrlBlaster::init (this=0x8abd3e0, list_head=0xabc59ac0, u_proto=TCP_BLAST) at Prefetch.h:280 #5 0x08147806 in BlasterUrlList::invokeUrlBlaster (this=0xa7c22260) at Prefetch.h:287 #6 0x08141ac8 in BlasterUrlList::handleEvent (this=0xa7c22260, event=3302, data=0xabc59ac0) at Prefetch.cc:803 #7 0x08143c89 in PrefetchBlaster::handleEvent (this=0xa5739920, event=2, data=0x0) at Prefetch.cc:1420 #8 0x08144f42 in PrefetchBlaster::invokeBlaster (this=0xa5739920) at Prefetch.cc:1769 #9 0x08143e22 in PrefetchBlaster::handleEvent (this=0xa5739920, event=1102, data=0xb23cdca0) at Prefetch.cc:1448 #10 0x08104ba5 in Continuation::handleEvent (this=0xa5739920, event=1102, data=0xb23cdca0) at ../iocore/eventsystem/I_Continuation.h:146 #11 0x082c1abf in CacheVC::callcont (this=0xb23cdca0, event=1102) at P_CacheInternal.h:629 #12 0x082c1487 in CacheVC::openReadStartHead (this=0xb23cdca0, event=3900, e=0x0) at CacheRead.cc:1115 #13 0x08104ba5 in Continuation::handleEvent (this=0xb23cdca0, event=3900, data=0x0) at ../iocore/eventsystem/I_Continuation.h:146 #14 0x082c1431 in CacheVC::openReadStartHead (this=0xb23cdca0, event=2, e=0x8ab48a0) at CacheRead.cc:1112 #15 0x08104ba5 in Continuation::handleEvent (this=0xb23cdca0, event=2, data=0x8ab48a0) at ../iocore/eventsystem/I_Continuation.h:146 #16 0x0830a9f5 in EThread::process_event (this=0xb7295008, e=0x8ab48a0, calling_code=2) at UnixEThread.cc:140 #17 0x0830add5 in EThread::execute (this=0xb7295008) at UnixEThread.cc:217 #18 0x0830900e in spawn_thread_internal (a=0x895dd00) at Thread.cc:88 #19 0x00165cc9 in start_thread (arg=0xb6e90b70) at pthread_create.c:304 #20 0x0066f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 -- 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-910) log collation in custom log will make dedicate connection to the same collation server
[ https://issues.apache.org/jira/browse/TS-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-910: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! log collation in custom log will make dedicate connection to the same collation server -- Key: TS-910 URL: https://issues.apache.org/jira/browse/TS-910 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 3.1.0 Reporter: Zhao Yongming Assignee: Zhao Yongming Fix For: 3.3.0 when you define LogObject in logs_xml.config, and set CollationHosts, it will open connections for each LogObject, despite you put the same host in CollationHosts. it will affect the default squid logging too. -- 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-718) can not reuse SSL connections on RHEL5/CentOS5
[
https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-718:
-
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
can not reuse SSL connections on RHEL5/CentOS5
--
Key: TS-718
URL: https://issues.apache.org/jira/browse/TS-718
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 2.1.7
Environment: RHEL5 system with TS 2.1.6 2.1.7
compared with Apache httpd
Reporter: Zhao Yongming
Assignee: qianshi
Fix For: 3.3.0
Attachments: TS-718-v2.patch, TS-718.patch
when with apache httpd default mod_ssl:
{noformat}
[root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443
21
CONNECTED(0003)
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify error:num=18:self signed certificate
verify return:1
depth=0
/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
verify return:1
---
Certificate chain
0
s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
Server certificate
-BEGIN CERTIFICATE-
MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG
9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw
Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT
b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p
emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD
DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA
dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8
hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC
cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd
BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka
RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1
qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s
6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl
weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA==
-END CERTIFICATE-
subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com
---
No client certificate CA names sent
---
SSL handshake has read 1418 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
Krb5 Principal: None
Start Time: 1300962675
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
drop connection and then reconnect
CONNECTED(0003)
---
Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID:
8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B
Session-ID-ctx:
Master-Key:
42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA
Key-Arg : None
Krb5 Principal: None
Compression: 1 (zlib compression)
Start Time: 1300962675
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
drop connection and then reconnect
CONNECTED(0003)
---
Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Secure Renegotiation IS supported
Compression: zlib compression
Expansion:
[jira] [Updated] (TS-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1006:
--
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.3.0
Attachments: memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common system
waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 | 0 |128 |
memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 |
memory/INKVConnAllocator
0 | 0 | 96 |
memory/INKContAllocator
4096 | 0 | 32 |
memory/apiHookAllocator
0 | 0 |288 |
memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 |
memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 9856 |
memory/httpUpdateSMAllocator
0 | 0 |128 |
memory/RemapPluginsAlloc
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 | 0 |128 |
memory/CongestionDBContAllocator
5767168 | 704512 | 2048 | memory/hdrStrHeap
18350080 |1153024 | 2048 | memory/hdrHeap
53248 | 2912 |208 |
memory/httpCacheAltAllocator
0 | 0 |112 |
[jira] [Updated] (TS-920) HTTP CONNECT gives bad request line
[ https://issues.apache.org/jira/browse/TS-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-920: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! HTTP CONNECT gives bad request line --- Key: TS-920 URL: https://issues.apache.org/jira/browse/TS-920 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: M. Nunberg Fix For: 3.3.0 An HTTP CONNECT tunnel request such as: CONNECT foo.com:443 HTTP/1.1 is translated into: CONNECT https://foo.com:443/ HTTP/1.1 and is sent as such to a parent proxy when ATS is configured to forward requests to parent proxy. This can break the parent proxy in some (all?) cases, since the semi-standard for CONNECT is a host specification, not a URI. In practice, for most applications, this issue is quite rare since it is often pointless to forward CONNECT requests, unless the parent proxy does some special handling or man-in-the-middle operations etc. -- 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-966) cache.config dest_domain= dest_hostname= dest_ip= do not match anything
[ https://issues.apache.org/jira/browse/TS-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-966: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! cache.config dest_domain= dest_hostname= dest_ip= do not match anything --- Key: TS-966 URL: https://issues.apache.org/jira/browse/TS-966 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0, 3.0.1 Reporter: Igor Galić Fix For: 3.3.0 Caching policies are not applied when using these options to match targets. It is also not very clear *what* dest_domain= vs dest_hostname= can match. -- 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-645) Hard restart in the mgmt APIs is totally busted
[ https://issues.apache.org/jira/browse/TS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-645: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! Hard restart in the mgmt APIs is totally busted --- Key: TS-645 URL: https://issues.apache.org/jira/browse/TS-645 Project: Traffic Server Issue Type: Bug Components: Management API Reporter: Leif Hedstrom Fix For: 3.3.0 In CoreAPIRemote.cc, in HardRestart(), we assume to find some start / stop scripts that no longer exists: Layout::relative_to(start_path, sizeof(start_path), Layout::get()-bindir, start_traffic_server); Layout::relative_to(stop_path, sizeof(stop_path), Layout::get()-bindir, stop_traffic_server); I don't know if / when this would be used (probably only in the deprecated Web GUI at this point), but we should fix this. -- 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-998) Broken ClientReq in TSAPI
[ https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-998: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! Broken ClientReq in TSAPI - Key: TS-998 URL: https://issues.apache.org/jira/browse/TS-998 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.1 Environment: any Reporter: Nick Kew Assignee: Nick Kew Fix For: 3.3.0 Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request line. Expected behaviour: In a PRE_REMAP hook it should return the client request line and headers, ideally verbatim. Observed behaviour: http://; is prepended to the request URL: GET /path/ HTTP/1.1 becomes GET http:///path/ HTTP/1.1 (yes, that's three slashes) Pseudo-code to reproduce from a PRE_REMAP hook: TSHttpTxnClientReqGet(txnp, buf, hdr); TSHttpHdrPrint(buf, hdr, iobuf); reader = TSIOBufferReaderAlloc(iobuf); block = TSIOBufferReaderStart(reader); len = TSIOBufferBlockReadAvail(block, reader); data = TSIOBufferBlockReadStart(block, reader, len); Now examine the contents of data. Assigned to AMC as suggested yesterday on-list. -- 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-767) Make the cluster interface configurable
[ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-767: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! Make the cluster interface configurable --- Key: TS-767 URL: https://issues.apache.org/jira/browse/TS-767 Project: Traffic Server Issue Type: Improvement Components: Configuration, Network Affects Versions: 2.1.8 Reporter: Arno Toell Priority: Minor Fix For: 3.3.0 I consider the way how Traffic Server opens listening ports dangerous, or at least more risky than necessary. Currently ATS allows to configure port numbers for the related services, but not the listening interface. Instead it binds to 0.0.0.0. Therefore I'd like to suggest * -Allow the user to specify a listening interface, don't assume 0.0.0.0 suits for all setups.- * -Disable the autoconfiguration port (i.e. 8083 by default) unless proxy.local.cluster.type is set to enable clustering (!= 3). I think _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS locally. If so it should be bound to the loop back at least or using Unix Domain Sockets or whatever local socket method you prefer.- * Disable the reliable service port (i.e. 8088 by default) unless proxy.local.cluster.type enables clustering. Similar to the autoconfiguration port. If _traffic_cop_ (or something else on the local machine) is using this port, the same suggestions apply as above. * -The internal communication port (8084) should not open a public socket at all. Instead use Unix Domain Sockets or something similar.- n.b. striked through issues are obsolete or tracked in TS-765. For the remaining issue is worth to be added the comment from TS-765: 8088 is no problem anymore until clustering is enabled, so there is only the TS-766 improvement left there. However if enabled, I think it is still fairly useful to allow the user to bind to a specific IP. Say, you run a public facing proxy in cluster mode where you want to communicate in between on private IPs between cluster peers. -- 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-993) Add OpenBSD support.
[ https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-993: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! Add OpenBSD support. Key: TS-993 URL: https://issues.apache.org/jira/browse/TS-993 Project: Traffic Server Issue Type: Improvement Environment: OpenBSD Reporter: Piotr Sikora Fix For: 3.3.0 Attachments: 0001-Add-OpenBSD-support.patch Add OpenBSD support. -- 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-1058) Intercept an HTTP client's request
[
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1058:
--
Fix Version/s: (was: 3.1.5)
3.3.0
Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on
*soon*. Also, take a look at what can be closed here please!
Intercept an HTTP client's request
--
Key: TS-1058
URL: https://issues.apache.org/jira/browse/TS-1058
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.1.1
Reporter: Yakov Kopel
Labels: patch
Fix For: 3.3.0
Attachments: patch.diff
Original Estimate: 24h
Remaining Estimate: 24h
I want that the trafficserver will give the client the response instead of
the server.
The trafficserver offers the INKHttpTxnIntercept api to do so, but it is not
so convenience to use it.
I want to use the regular flow of the trafficserver, and its regular parsing
commands.
The trafficserver's plugins examples also aren't using the
INKHttpTxnIntercept , but they rather using the rasing error method, and
then they response the request at the response hook.
So, this is whta i did.
On the global-hook at the TS_EVENT_HTTP_READ_REQUEST_HDR i raised
TS_EVENT_HTTP_ERROR.
I also added TS_HTTP_SEND_RESPONSE_HDR_HOOK and there i returned http
response with the KEEP-ALIVE header.
The problem is that the trafficserver is closing the connection although i
added to the response the KEEP-ALIVE header.
When the Trafficserver is trying to send response to the client, it terminate
the session after it.
Although I added the KEEP-ALIVE mime field - it didn't work.
The debug dump is looking like this:
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::state_api_callback, HTTP_API_CONTINUE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::state_api_callout, HTTP_API_CONTINUE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
[HttpSM::do_redirect]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
adding producer 'internal msg'
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
adding consumer 'user agent'
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel)
tunnel_run started, p_arg is NULL
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
closed
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
destroy
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
[HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
[HttpTunnel::deallocate_postdata_copy_buffers]
[Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] calling
plugin on hook TS_HTTP_TXN_CLOSE_HOOK at hook 0x3B97610
The Solution:
I'm adding a patch of functino that rasing the internal flag of KEEP-ALIVE,
so the trafficserver will realy believe us that we want to keep this
connection alive :)
Example for the usage of the new function:
// Tell the trafficserver to not close this connection (keep-alive)
TSHttpTxnCloseAfterResponse(txnp, 0);
--
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-1015) TSEvent is widely declared as int
[ https://issues.apache.org/jira/browse/TS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1015: -- Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! TSEvent is widely declared as int - Key: TS-1015 URL: https://issues.apache.org/jira/browse/TS-1015 Project: Traffic Server Issue Type: Bug Components: Cleanup Reporter: Nick Kew Priority: Minor Fix For: 3.3.0 TSEvent is an enum, defined in ts.h. But in much of the code, TSEvent is declared as type int. This makes it harder to follow/debug using tools like *trace or gdb. This may usefully be fixed as and when people encounter instances of it. -- 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-808) INACTIVE_TIMEOUT for *.channel.facebook.com
[ https://issues.apache.org/jira/browse/TS-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-808: - Fix Version/s: (was: 3.1.5) 3.3.0 Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on *soon*. Also, take a look at what can be closed here please! INACTIVE_TIMEOUT for *.channel.facebook.com --- Key: TS-808 URL: https://issues.apache.org/jira/browse/TS-808 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.1.8 Environment: Linux 2.6.35.10 x86_64 Reporter: Alvin Alexander Priority: Critical Fix For: 3.3.0 error.log : 20110528.13h06m13s CONNECT:[5] could not connect [INACTIVE_TIMEOUT] to 66.220.151.83 for 'http://0.164.channel.facebook.com/x/324863553/1802403183/false/p_11790027719=1' 20110528.13h06m13s CONNECT:[6] could not connect [INACTIVE_TIMEOUT] to 66.220.151.76 for 'http://0.122.channel.facebook.com/x/461720327/101899065/false/p_1523748988=22' 20110528.13h06m13s CONNECT:[3] could not connect [INACTIVE_TIMEOUT] to 66.220.151.77 for 'http://0.128.channel.facebook.com/x/2800423340/1779706821/false/p_10277560566=6' -- 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-1161) insafe raw device in storage.config
[ https://issues.apache.org/jira/browse/TS-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1161: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving to 3.3.0 insafe raw device in storage.config --- Key: TS-1161 URL: https://issues.apache.org/jira/browse/TS-1161 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Zhao Yongming Fix For: 3.3.0 if you system is on /dev/sda and you put /dev/sda into storage.config, TS will destroy the data on /dev/sda without any hesitate. this is proved to be true, please do not try, trust me. -- 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-1121) --disable-diags configuration option does not do anything
[ https://issues.apache.org/jira/browse/TS-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1121: -- Fix Version/s: (was: 3.1.4) 3.3.0 Moving to 3.3.0 --disable-diags configuration option does not do anything - Key: TS-1121 URL: https://issues.apache.org/jira/browse/TS-1121 Project: Traffic Server Issue Type: Bug Components: Build, Core Affects Versions: 3.0.3 Environment: any Reporter: Uri Shachar Priority: Minor Fix For: 3.3.0 Original Estimate: 2h Remaining Estimate: 2h The --disable-diags flag sets TS_USE_DIAGS to 0 but Diags.h tests if it is defined or not -- 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-1128) gcc don't like break strict-aliasing in I_ProxyAllocator.h
[
https://issues.apache.org/jira/browse/TS-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1128:
--
Fix Version/s: 3.1.4
gcc don't like break strict-aliasing in I_ProxyAllocator.h
--
Key: TS-1128
URL: https://issues.apache.org/jira/browse/TS-1128
Project: Traffic Server
Issue Type: Improvement
Components: Cleanup
Affects Versions: 3.1.4
Reporter: Zhao Yongming
Priority: Minor
Fix For: 3.1.4
{code}
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* SSLNetAccept::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* UnixNetProcessor::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* SSLNetProcessor::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
cc1plus: warnings being treated as errors
../../iocore/eventsystem/I_ProxyAllocator.h: In member function 'virtual
UnixNetVConnection* NetAccept::allocateThread(EThread*)':
../../iocore/eventsystem/I_ProxyAllocator.h:54: error: dereferencing pointer
'anonymous' does break strict-aliasing rules
../../iocore/eventsystem/I_ProxyAllocator.h:54: note: initialized from here
make[2]: *** [SSLUnixNet.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [UnixNetProcessor.o] Error 1
mv -f .deps/NetVConnection.Tpo .deps/NetVConnection.Po
mv -f .deps/Net.Tpo .deps/Net.Po
mv -f .deps/UDPIOEvent.Tpo .deps/UDPIOEvent.Po
make[2]: *** [UnixNetAccept.o] Error 1
mv -f .deps/Connection.Tpo .deps/Connection.Po
mv -f .deps/SSLCertLookup.Tpo .deps/SSLCertLookup.Po
mv -f .deps/UnixConnection.Tpo .deps/UnixConnection.Po
mv -f .deps/SSLConfig.Tpo .deps/SSLConfig.Po
mv -f .deps/SSLNet.Tpo .deps/SSLNet.Po
mv -f .deps/UnixNet.Tpo .deps/UnixNet.Po
mv -f .deps/UnixNetPages.Tpo .deps/UnixNetPages.Po
mv -f .deps/Socks.Tpo .deps/Socks.Po
mv -f .deps/SSLNetVConnection.Tpo .deps/SSLNetVConnection.Po
mv -f .deps/UnixNetVConnection.Tpo .deps/UnixNetVConnection.Po
make[2]: Leaving directory
`/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore/net'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/rpmbuild/BUILD/trafficserver-3.0.2/iocore'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.VFqSxi (%build)
{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-1169) in enable-debug and pristine_host_hdr=0 mode, TS will crash when purge a cached object which is after TSCacheUrlSet
[
https://issues.apache.org/jira/browse/TS-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1169:
--
Fix Version/s: 3.1.4
in enable-debug and pristine_host_hdr=0 mode, TS will crash when purge a
cached object which is after TSCacheUrlSet
---
Key: TS-1169
URL: https://issues.apache.org/jira/browse/TS-1169
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.3, 3.0.4
Environment: configure --enable-debug
Reporter: Conan Wang
Fix For: 3.1.4
{code}
#6 0x000100d269af in _ink_assert (a=0x1003c6be0 md5a == md5b ||
t_state.txn_conf-maintain_pristine_host_hdr, f=0x1003c514e HttpSM.cc,
l=3921) at ink_assert.cc:44
#7 0x000100123e59 in HttpSM::do_cache_delete_all_alts (this=0x109d41190,
cont=0x0) at HttpSM.cc:3921
{code}
in HttpSM::do_cache_delete_all_alts debug code, if a object key is rewritten
by TSCacheUrlSet, md5a will not equal md5b, and it will crash because
maintain_pristine_host_hdr = 0 ( when disable pristine_host_hdr ).
Anyway, the cached object is purged successfully. Maybe it's just a wrong
assert which didn't consider TSCacheUrlSet case.
{code}
#ifdef DEBUG
INK_MD5 md5a;
INK_MD5 md5b;
t_state.hdr_info.client_request.url_get()-MD5_get(md5a);
t_state.cache_info.lookup_url-MD5_get(md5b);
ink_assert(md5a == md5b || t_state.txn_conf-maintain_pristine_host_hdr);
#endif
{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-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1146: -- Fix Version/s: 3.1.4 RFC 5077 TLS Session tickets Key: TS-1146 URL: https://issues.apache.org/jira/browse/TS-1146 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Fix For: 3.1.4 For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the machines need to have the same server ticket. See https://github.com/apache/httpd rev 967d943b93498233f0ec81a5b48706fdb6892dfd -- 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-1034) reduce futex locking period
[
https://issues.apache.org/jira/browse/TS-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1034:
--
Fix Version/s: 3.1.4
reduce futex locking period
---
Key: TS-1034
URL: https://issues.apache.org/jira/browse/TS-1034
Project: Traffic Server
Issue Type: Improvement
Components: Core, HTTP
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.4
we need to reduce futex locking period, here is a simple testing in my
24cores HP380 system, with 24 ab, all cached in memory:
{code}
#!/bin/sh
for i in {1..24}
do
ab -n 1 -c 16 -X 127.0.0.$i:8080
http://img02.taobaocdn.com/tps/i2/T1o0ypXk4w-1000-40.png?$i
done
{code}
result:
{code}
Every 2.0s: echo show:proxy-stats | traffic_shell
Mon Nov 28 16:06:42 2011
Successfully Initialized MgmtAPI in /var/run/trafficserver
Document Hit Rate 100.00 % *
Bandwidth Saving - 100.00 % *
Cache Percent Free --- 99.999619 %
Open Server Connections -- 0
Open Client Connections -- 9
Open Cache Connections --- 2
Client Throughput 6824.747070 MBit/Sec
Transaction Per Second --- 53914.925781
* Value represents 10 second average.
strace -c -p 11712
Process 11712 attached - interrupt to quit
^CProcess 11712 detached
% time seconds usecs/call callserrors syscall
-- --- --- - -
26.850.890335 15 58920 writev
24.450.810866 7118147 epoll_ctl
22.270.738451 13 58920 close
11.500.381362 6 59227 getsockname
9.860.326843 3119192 59228 read
3.530.117058 16 7100 1931 futex
1.530.050884 58 884 epoll_wait
0.000.37 0 404 rt_sigprocmask
0.000.00 0 3 write
0.000.00 0 2 brk
0.000.00 010 msync
-- --- --- - -
100.003.315836422809 61159 total
{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-1155) POST requests that are chunked encoding hang when going forward to origin over SSL
[ https://issues.apache.org/jira/browse/TS-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1155: -- Fix Version/s: 3.1.4 POST requests that are chunked encoding hang when going forward to origin over SSL -- Key: TS-1155 URL: https://issues.apache.org/jira/browse/TS-1155 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Reporter: William Bardwell Fix For: 3.1.4 If you make a chunked encoded POST request, e.g.: curl -H Transfer-Encoding: chunked -d@/etc/ca-certificates.conf http://example.com/cgi-bin/cgi.pl Where ATS is going forward to the origin over SSL, it junk hangs for a little while and ends up returning a 502 response. The problem seems to be code at proxy/http/HttpTransact.cc:5273 which only checks for chunked encoding when the scheme is http. Just removing the extra scheme check makes it work for me. I don't know why it has that check, especially since it is checking for http or https right before that. -- 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-1067) Remove unused config (and code) for bandwidth management
[ https://issues.apache.org/jira/browse/TS-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1067: -- Fix Version/s: (was: 3.1.4) 3.3.0 Remove unused config (and code) for bandwidth management Key: TS-1067 URL: https://issues.apache.org/jira/browse/TS-1067 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.0 There's a configuration file, and code, related to bandwidth management for the old UDP based streaming media protocols, that were part of the core (it's long since gone). We should remove this for now, and possibly (for future plugins) add APIs appropriate for this. -- 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-1153) On Solaris, link with libumem by default
[ https://issues.apache.org/jira/browse/TS-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1153: -- Fix Version/s: (was: 3.1.4) 3.3.0 On Solaris, link with libumem by default Key: TS-1153 URL: https://issues.apache.org/jira/browse/TS-1153 Project: Traffic Server Issue Type: Improvement Components: Performance Environment: Solaris Reporter: Igor Galić Labels: memory Fix For: 3.3.0 http://developers.sun.com/solaris/articles/multiproc/multiproc.html Maybe we should make use of that and link to libumem by default. -- 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-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1125: -- Fix Version/s: 3.1.4 POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Priority: Minor Fix For: 3.1.4 Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- 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-1161) insafe raw device in storage.config
[ https://issues.apache.org/jira/browse/TS-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1161: -- Fix Version/s: 3.1.4 insafe raw device in storage.config --- Key: TS-1161 URL: https://issues.apache.org/jira/browse/TS-1161 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Zhao Yongming Fix For: 3.1.4 if you system is on /dev/sda and you put /dev/sda into storage.config, TS will destroy the data on /dev/sda without any hesitate. this is proved to be true, please do not try, trust me. -- 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-1154) quick_filter on HEAD does not work
[ https://issues.apache.org/jira/browse/TS-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1154: -- Fix Version/s: 3.1.4 quick_filter on HEAD does not work -- Key: TS-1154 URL: https://issues.apache.org/jira/browse/TS-1154 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Zhao Yongming Assignee: weijin Fix For: 3.1.4 Attachments: head_method.diff we take quick filter as a good solution for some security concern, but when I set it to 0x0733, it does not allow HEAD in, but setting as 0x0723 does that. Weijin have the patch in our tree: https://gitorious.org/trafficserver/taobao/commit/cb23b87d167da4074e047fabc94786003ee94e9a/diffs/db7d0e5be69988b531e8d1e4eea717e6d46df5cd I will commit if no one complain in 2 days. -- 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-1119) fatal error when uploading gzip-transform plugin
[
https://issues.apache.org/jira/browse/TS-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1119:
--
Fix Version/s: 3.1.4
fatal error when uploading gzip-transform plugin
Key: TS-1119
URL: https://issues.apache.org/jira/browse/TS-1119
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Affects Versions: 3.0.2
Reporter: angela asher
Priority: Blocker
Fix For: 3.1.4
Attachments: gzip-transform.diff
getting the following error on traffic.out when running the traffic server
with gzip-transform plugin:
[Feb 23 16:28:15.509] Server {47392853811680} DEBUG: (http) [13] calling
plugin on hook TS_HTTP_READ_RESPONSE_HDR_HOOK at hook 0x35BBEE0
FATAL: InkAPI.cc:3036: failed assert `sdk_sanity_check_null_ptr((void*)
value_len_ptr) == TS_SUCCESS`
/usr/local/bin/traffic_server - STACK TRACE:
/usr/local/lib/libtsutil.so.3(ink_fatal_va+0x9d)[0x2b1a7ecca37d]
/usr/local/lib/libtsutil.so.3(ink_fatal+0x88)[0x2b1a7ecca4d8]
/usr/local/lib/libtsutil.so.3(_ink_assert+0x85)[0x2b1a7ecc8af5]
/usr/local/bin/traffic_server(TSMimeHdrFieldValueStringGet+0x124)[0x4a9144]
/usr/local/libexec/trafficserver/gzip-transform.so(+0x1bde)[0x2b1a8b3c7bde]
/usr/local/libexec/trafficserver/gzip-transform.so(+0x27c4)[0x2b1a8b3c87c4]
/usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52cfa5]
/usr/local/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x420)[0x52f1c0]
/usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x530568]
/usr/local/bin/traffic_server[0x681dcb]
/usr/local/bin/traffic_server[0x6848f1]
/usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x2e2)[0x67d402]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6a9ce4]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x6aa673]
/usr/local/bin/traffic_server(main+0x1128)[0x4c07e8]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x2b1a81092c5d]
/usr/local/bin/traffic_server[0x47e0e9]
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR: (last system error 2:
No such file or directory)
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Feb 23 16:28:15.512] Manager {140400187066336} ERROR: (last system error 2:
No such file or directory)
[Feb 23 16:28:16.522] Manager {140400187066336} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr/local'
[Feb 23 16:28:16.527] Manager {140400187066336} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '11'
[Feb 23 16:28:16.527] Manager {140400187066336} NOTE: [Alarms::signalAlarm]
Server Process born
[Feb 23 16:28:17.539] {47668265021920} STATUS: opened
/usr/local/var/log/trafficserver/diags.log
[Feb 23 16:28:17.539] {47668265021920} NOTE: updated diags config
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Config:
/usr/local/etc/trafficserver/ae_ua.config
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Opening config
/usr/local/etc/trafficserver/ae_ua.config
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
[Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
[init_http_aeua_filter] - Total loaded 0 REGEXP for
Accept-Enconding/User-Agent filtering
[Feb 23 16:28:17.542] Server {47668265021920} NOTE: cache clustering disabled
[Feb 23 16:28:17.543] Server {47668265021920} DEBUG: (dns) ink_dns_init:
called with init_called = 0
[Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns)
localhost=isk-vsrv227
[Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns) Round-robin
nameservers = 0
[Feb 23 16:28:17.547] Server {47668265021920} NOTE: cache clustering disabled
[Feb 23 16:28:17.568] Server {47668265021920} NOTE: logging initialized[7],
logging_mode = 3
[Feb 23 16:28:17.569] Server {47668265021920} NOTE: loading plugin
'/usr/local/libexec/trafficserver/gzip-transform.so'
[Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
proxy.config.http.redirection_enabled = 0
[Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
proxy.config.http.number_of_redirections = 1
[Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
proxy.config.http.post_copy_size = 2048
[Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_tproxy) Primary
listen socket transparency is off
[Feb 23 16:28:17.573] Server {47668424926976} DEBUG:
[jira] [Updated] (TS-1151) in some strange situation, cop will crash
[
https://issues.apache.org/jira/browse/TS-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1151:
--
Fix Version/s: 3.1.4
in some strange situation, cop will crash
-
Key: TS-1151
URL: https://issues.apache.org/jira/browse/TS-1151
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Fix For: 3.1.4
we get some strange crash, the manager cop may die, we are not sure what
that is, but I'd like to start one Issue here if we have other same issue.
here is the log in /var/log/messages
{code}
Mar 19 10:08:24 cache172.cn77 kernel:: [1553138.961401] [ET_NET 2][17949]:
segfault at 2aadf1387937 ip 003c5bc7bdbe sp 410f3188 error 4 in
libc-2.5.so[3c5bc0+14d000]
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} FATAL:
(last system error 104: Connection reset by peer)
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} ERROR:
(last system error 32: Broken pipe)
Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: cop received child status
signal [17935 2816]
Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: traffic_manager not
running, making sure traffic_server is dead
Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: spawning traffic_manager
Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: NOTE: --- Manager
Starting ---
Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: NOTE: Manager Version:
Apache Traffic Server - traffic_manager - 3.0.2 - (build # 299 on Mar 9 2012
at 09:55:44)
Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} STATUS:
opened /var/log/trafficserver/manager.log
Mar 19 10:08:46 cache172.cn77 traffic_cop[17933]: (cli test) unable to
retrieve manager_binary
Mar 19 10:08:54 cache172.cn77 traffic_server[2789]: NOTE: --- Server Starting
---
Mar 19 10:08:54 cache172.cn77 traffic_server[2789]: NOTE: Server Version:
Apache Traffic Server - traffic_server - 3.0.2 - (build # 299 on Mar 9 2012
at 09:56:00)
Mar 19 10:09:00 cache172.cn77 traffic_server[2789]: {0x2b5a8ef03970} STATUS:
opened /var/log/trafficserver/diags.log
Mar 19 10:14:02 cache172.cn77 kernel:: [1553476.364204] [ET_NET 0][2789]:
segfault at 2aab1fa99ce3 ip 003c5bc7bdbe sp 7fff39743fa8 error 4 in
libc-2.5.so[3c5bc0+14d000]
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} FATAL:
(last system error 104: Connection reset by peer)
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} ERROR:
(last system error 32: Broken pipe)
{code}
here is the message in traffic.out
{code}
Mar 19 10:11:06 cache162.cn77 kernel:: [2510081.212455] [ET_NET 3][319]:
segfault at 2aaae6e986bc ip 003f7f27bdbe sp 40be2188 error 4 in
libc-2.5.so[3f7f20+14d000]
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL:
(last system error 104: Connection reset by peer)
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR:
(last system error 32: Broken pipe)
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: cop received child status
signal [305 2816]
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: traffic_manager not running,
making sure traffic_server is dead
Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: spawning traffic_manager
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: --- Manager
Starting ---
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: Manager Version:
Apache Traffic Server - traffic_manager - 3.0.2 - (build # 299 on Mar 9 2012
at 09:55:44)
Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: {0x7f8ae2f48720} STATUS:
opened /var/log/trafficserver/manager.log
Mar 19 10:11:23 cache162.cn77 traffic_cop[303]: (cli test) unable to retrieve
manager_binary
Mar 19 10:11:39 cache162.cn77 traffic_server[1260]: NOTE: --- Server Starting
---
Mar 19 10:11:39
[jira] [Updated] (TS-1152) http_ui error,when i get http://localhost/cache/
[
https://issues.apache.org/jira/browse/TS-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1152:
--
Fix Version/s: 3.1.4
http_ui error,when i get http://localhost/cache/
Key: TS-1152
URL: https://issues.apache.org/jira/browse/TS-1152
Project: Traffic Server
Issue Type: Bug
Components: Web UI
Affects Versions: 3.0.4
Environment: centos 6 x86_64
Reporter: bettydramit
Fix For: 3.1.4
When i enable http_ui ，I got follow error (get http://xxx.xxx.xxx.xxx/cache/)
[Mar 19 16:46:17.778] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:17.778] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:46:19.089] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:19.090] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:46:20.763] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:20.763] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:58:21.906] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /robots.txt not valid autoconf file
[Mar 19 16:58:21.906] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 17:01:43.703] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 17:01:43.703] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
--
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-1163) Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux
[ https://issues.apache.org/jira/browse/TS-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1163: -- Fix Version/s: 3.1.4 Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux -- Key: TS-1163 URL: https://issues.apache.org/jira/browse/TS-1163 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: B Wyatt Assignee: B Wyatt Fix For: 3.1.4 Attachments: blkgetsize64.bwyatt.patch Due to 32bit integers in both the trafficersever code and the ioctl used to determine raw disk size, the number of sectors reported to the cache storage system is bound to 0-0x. If a disk has 512 byte sectors and is larger than 2TB it will report (num_sectors % 0x) * 512 bytes avaliable. -- 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-1162) UnixNetVConnection.cc assertion when accepting a TLS connection
[
https://issues.apache.org/jira/browse/TS-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1162:
--
Fix Version/s: 3.1.4
UnixNetVConnection.cc assertion when accepting a TLS connection
---
Key: TS-1162
URL: https://issues.apache.org/jira/browse/TS-1162
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.4
Reporter: James Peach
Fix For: 3.1.4
Trunk always crashes when accepting a TLS connection:
FATAL: UnixNetVConnection.cc:801: failed assert `vio-mutex-thread_holding
== this_ethread()`
/opt/ats/bin/traffic_server - STACK TRACE:
0 libtsutil.3.dylib 0x00010c3e7ee7 ink_fatal + 359
1 libtsutil.3.dylib 0x00010c3e6e22 _ink_assert + 66
2 traffic_server 0x00010b9e6d9a
_ZN18UnixNetVConnection11set_enabledEP3VIO + 90
3 traffic_server 0x00010b9e681d
_ZN18UnixNetVConnection8reenableEP3VIO + 93
4 traffic_server 0x00010b7bfcd6 _ZN3VIO8reenableEv
+ 54
5 traffic_server 0x00010b9e5cd9
_ZN18UnixNetVConnection10do_io_readEP12ContinuationxP9MIOBuffer + 297
6 traffic_server 0x00010b792611
_ZN11VConnection5do_ioEiP12ContinuationxP9MIOBufferi + 129
7 traffic_server 0x00010b9d6da9
_ZN21SSLNextProtocolAccept9mainEventEiPv + 329
8 traffic_server 0x00010b792229
_ZN12Continuation11handleEventEiPv + 121
9 traffic_server 0x00010b9e89bd
_ZN18UnixNetVConnection11acceptEventEiP5Event + 829
10 traffic_server 0x00010b792229
_ZN12Continuation11handleEventEiPv + 121
11 traffic_server 0x00010ba0905d
_ZN7EThread13process_eventEP5Eventi + 349
12 traffic_server 0x00010ba09367
_ZN7EThread7executeEv + 215
13 traffic_server 0x00010ba080ed
_ZL21spawn_thread_internalPv + 109
14 libsystem_c.dylib 0x7fff8fcb78bf _pthread_start +
335
15 libsystem_c.dylib 0x7fff8fcbab75 thread_start + 13
[Mar 22 21:58:45.009] Manager {0x7fff79b01960} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Abort trap: 6
--
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
