[jira] [Updated] (TS-1127) Wrong assignment of incoming address
[ https://issues.apache.org/jira/browse/TS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yakov Kopel updated TS-1127: Description: The API TSHttpTxnClientIncomingPortGet has been changed in Wed Oct 5 19:14:07 2011 (TS-926) and it returns another value. in the old version it returned the incoming port of the TS(the port which the client connected to the TS). in the new version the returned value is the sending port of the user. The different is in the line: - return sm-t_state.client_info.port; + return ink_inet_get_port(sm-t_state.client_info.addr); The assignment of those two members (port, addr) are in the HttpSM.cc file ink_inet_copy(t_state.client_info.addr, netvc-get_remote_addr()); t_state.client_info.port = netvc-get_local_port(); The old code gave the right answer from the port member, and the new one gives us wrong answer from the remote address. I attached a patch to fix this returned value. was: There is a problem in the new version of trafficserverin the function (HttpSM.cc): TSHttpTxnClientIncomingPortGet The old code: return sm-t_state.client_info.port The new code: return ink_inet_get_port(sm-t_state.client_info.addr); The assignment of those two members (port, addr) are in the HttpSM.cc file (in attach_client_session function): ink_inet_copy(t_state.client_info.addr, netvc-get_remote_addr()); t_state.client_info.port = netvc-get_local_port(); the old code gave the right answer from the port member, and the new one gives us wrong answer fron the remote addr. I thought to fix it by rewrite the code get_remote_addr = get_local_addr (as in the patch that I attached to here) But it makes bugs in other places (redirect to another address). Or maybe it will be better to rewrite the TSHttpTxnClientIncomingPortGet function to the old version. Wrong assignment of incoming address Key: TS-1127 URL: https://issues.apache.org/jira/browse/TS-1127 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.1.2 Reporter: Yakov Kopel Fix For: 3.1.4 Attachments: fix.patch, fix.patch Original Estimate: 1m Remaining Estimate: 1m The API TSHttpTxnClientIncomingPortGet has been changed in Wed Oct 5 19:14:07 2011 (TS-926) and it returns another value. in the old version it returned the incoming port of the TS(the port which the client connected to the TS). in the new version the returned value is the sending port of the user. The different is in the line: - return sm-t_state.client_info.port; + return ink_inet_get_port(sm-t_state.client_info.addr); The assignment of those two members (port, addr) are in the HttpSM.cc file ink_inet_copy(t_state.client_info.addr, netvc-get_remote_addr()); t_state.client_info.port = netvc-get_local_port(); The old code gave the right answer from the port member, and the new one gives us wrong answer from the remote address. I attached a patch to fix this returned value. -- 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-1075) Port range bottleneck in transparent proxy mode
[ https://issues.apache.org/jira/browse/TS-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1075: -- Fix Version/s: 3.1.3 Assignee: B Wyatt Bart, putting this on you, can you take a look please? Port range bottleneck in transparent proxy mode --- Key: TS-1075 URL: https://issues.apache.org/jira/browse/TS-1075 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Environment: Centos 5.6, kernel 2.6.39.2 compiled with TPROXY support ATS compiled as: ./configure --enable-tproxy Reporter: Danny Shporer Assignee: B Wyatt Fix For: 3.1.3 Attachments: ports.patch The Linux TPROXY stack only takes into account the local addresses when using dynamic bind (bind without specifying a specific port). This limits the port range to only the local range (around 30K by default and can be extended to around 64K) - this together with the TIME-WAIT Linux method of releasing ports causes a bottleneck). One symptom of this is that traffic_cop cannot open a connection to the server to monitor it (it gets error 99 - address already in use) and kills it. Another issue is when opening the connection to the server. -- 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-1127) Wrong returned value of incoming port address
[ https://issues.apache.org/jira/browse/TS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1127: -- Fix Version/s: (was: 3.1.4) 3.1.3 amc, can you take a look at this? Wrong returned value of incoming port address - Key: TS-1127 URL: https://issues.apache.org/jira/browse/TS-1127 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.1.2 Reporter: Yakov Kopel Fix For: 3.1.3 Attachments: fix.patch Original Estimate: 1m Remaining Estimate: 1m The API TSHttpTxnClientIncomingPortGet has been changed in Wed Oct 5 19:14:07 2011 (TS-926) and it returns another value. in the old version it returned the incoming port of the TS(the port which the client connected to the TS). in the new version the returned value is the sending port of the user. The different is in the line: - return sm-t_state.client_info.port; + return ink_inet_get_port(sm-t_state.client_info.addr); The assignment of those two members (port, addr) are in the HttpSM.cc file ink_inet_copy(t_state.client_info.addr, netvc-get_remote_addr()); t_state.client_info.port = netvc-get_local_port(); The old code gave the right answer from the port member, and the new one gives us wrong answer from the remote address. I attached a patch to fix this returned value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1126) traffic_server is unable to bind 127.0.0.1:8084 (the default mgmt port) on OSX
[
https://issues.apache.org/jira/browse/TS-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1126.
---
Resolution: Fixed
Fixed with commit:
457f85b71de4776da461eae9ce8226a5b157321d
traffic_server is unable to bind 127.0.0.1:8084 (the default mgmt port) on OSX
--
Key: TS-1126
URL: https://issues.apache.org/jira/browse/TS-1126
Project: Traffic Server
Issue Type: Bug
Components: Management API
Affects Versions: 3.1.2
Reporter: Leif Hedstrom
Priority: Critical
Fix For: 3.1.3
When we start up, it errors out binding 8084:
[Mar 1 16:40:33.937] Server {0x7fff74cdb960} ERROR: Could not bind or listen
to port 8084 (error: -1)
[Mar 1 16:40:33.937] Server {0x7fff74cdb960} WARNING: unable to listen on
port 8084: -1 49, Can't assign requested address
--
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.3) 3.1.4 --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.1.4 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-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.3) 3.1.4 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.1.4 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] [Assigned] (TS-1127) Wrong returned value of incoming port address
[ https://issues.apache.org/jira/browse/TS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1127: - Assignee: Alan M. Carroll Wrong returned value of incoming port address - Key: TS-1127 URL: https://issues.apache.org/jira/browse/TS-1127 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.1.2 Reporter: Yakov Kopel Assignee: Alan M. Carroll Fix For: 3.1.3 Attachments: fix.patch Original Estimate: 1m Remaining Estimate: 1m The API TSHttpTxnClientIncomingPortGet has been changed in Wed Oct 5 19:14:07 2011 (TS-926) and it returns another value. in the old version it returned the incoming port of the TS(the port which the client connected to the TS). in the new version the returned value is the sending port of the user. The different is in the line: - return sm-t_state.client_info.port; + return ink_inet_get_port(sm-t_state.client_info.addr); The assignment of those two members (port, addr) are in the HttpSM.cc file ink_inet_copy(t_state.client_info.addr, netvc-get_remote_addr()); t_state.client_info.port = netvc-get_local_port(); The old code gave the right answer from the port member, and the new one gives us wrong answer from the remote address. I attached a patch to fix this returned value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1002) log unmapped HOST when pristine_host_hdr disabled
[
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223959#comment-13223959
]
Leif Hedstrom commented on TS-1002:
---
Also, I'm not seeing a note in CHANGES, is this code not committed ?
log unmapped HOST when pristine_host_hdr disabled
-
Key: TS-1002
URL: https://issues.apache.org/jira/browse/TS-1002
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Conan Wang
Assignee: Zhao Yongming
Priority: Minor
Fix For: 3.1.3
Attachments: TS-1002.patch
I want to log user request's Host in http header before remap. I write
logs_xml.config, like: %{Host}cqh
When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the
right Host which is not rewritten.
When disable the config, I always get the rewritten/mapped Host which is
not what I need.
logs_xml reference:
http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912
--
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-1002) log unmapped HOST when pristine_host_hdr disabled
[
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1002:
--
Issue Type: New Feature (was: Wish)
Can this bug be closed ?
log unmapped HOST when pristine_host_hdr disabled
-
Key: TS-1002
URL: https://issues.apache.org/jira/browse/TS-1002
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Conan Wang
Assignee: Zhao Yongming
Priority: Minor
Fix For: 3.1.3
Attachments: TS-1002.patch
I want to log user request's Host in http header before remap. I write
logs_xml.config, like: %{Host}cqh
When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the
right Host which is not rewritten.
When disable the config, I always get the rewritten/mapped Host which is
not what I need.
logs_xml reference:
http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912
--
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-1113) In case of caching smaller than 1k size of file, It shoud be increase concurrent users.
[ https://issues.apache.org/jira/browse/TS-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1113: -- Fix Version/s: (was: 3.2.0) 3.3.0 I'm moving this to 3.3.0, but can you please provide more information what exactly you are are suggesting? In case of caching smaller than 1k size of file, It shoud be increase concurrent users. - Key: TS-1113 URL: https://issues.apache.org/jira/browse/TS-1113 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 3.1.1 Reporter: Eric Ahn Priority: Minor Fix For: 3.3.0 If there are a lot 1k sized objects, It's not good performance. -- 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-844) ReadFromWriter fail in CacheRead.cc
[
https://issues.apache.org/jira/browse/TS-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-844:
-
Fix Version/s: (was: sometime)
ReadFromWriter fail in CacheRead.cc
---
Key: TS-844
URL: https://issues.apache.org/jira/browse/TS-844
Project: Traffic Server
Issue Type: Bug
Reporter: mohan_zl
Assignee: Zhao Yongming
Attachments: TS-844-2.patch, TS-844.patch
{code}
#6 0x006ab4d7 in CacheVC::openReadChooseWriter (this=0x2aaaf81523d0,
event=1, e=0x0) at CacheRead.cc:320
#7 0x006abdc9 in CacheVC::openReadFromWriter (this=0x2aaaf81523d0,
event=1, e=0x0) at CacheRead.cc:411
#8 0x004d302f in Continuation::handleEvent (this=0x2aaaf81523d0,
event=1, data=0x0) at I_Continuation.h:146
#9 0x006ae2b9 in Cache::open_read (this=0x2aaab0001c40,
cont=0x2aaab4472aa0, key=0x42100b10, request=0x2aaab44710f0,
params=0x2aaab4470928, type=CACHE_FRAG_TYPE_HTTP,
hostname=0x2aab09581049
js.tongji.linezing.comicon1.gifjs.tongji.linezing.com�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ�ï¿ï¿½Þ���...,
host_len=22) at CacheRead.cc:228
#10 0x0068da30 in Cache::open_read (this=0x2aaab0001c40,
cont=0x2aaab4472aa0, url=0x2aaab4471108, request=0x2aaab44710f0,
params=0x2aaab4470928,
type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1068
#11 0x0067d32f in CacheProcessor::open_read (this=0xf2c030,
cont=0x2aaab4472aa0, url=0x2aaab4471108, request=0x2aaab44710f0,
params=0x2aaab4470928, pin_in_cache=0,
type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3011
#12 0x0054e058 in HttpCacheSM::do_cache_open_read
(this=0x2aaab4472aa0) at HttpCacheSM.cc:220
#13 0x0054e1a7 in HttpCacheSM::open_read (this=0x2aaab4472aa0,
url=0x2aaab4471108, hdr=0x2aaab44710f0, params=0x2aaab4470928,
pin_in_cache=0) at HttpCacheSM.cc:252
#14 0x00568404 in HttpSM::do_cache_lookup_and_read
(this=0x2aaab4470830) at HttpSM.cc:3893
#15 0x005734b5 in HttpSM::set_next_state (this=0x2aaab4470830) at
HttpSM.cc:6436
#16 0x0056115a in HttpSM::call_transact_and_set_next_state
(this=0x2aaab4470830, f=0) at HttpSM.cc:6328
#17 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at
HttpSM.cc:1516
#18 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830,
event=0, data=0x0) at HttpSM.cc:1448
#19 0x0056de77 in HttpSM::do_api_callout_internal
(this=0x2aaab4470830) at HttpSM.cc:4345
#20 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at
HttpSM.cc:497
#21 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at
HttpSM.cc:6362
#22 0x0056115a in HttpSM::call_transact_and_set_next_state
(this=0x2aaab4470830, f=0) at HttpSM.cc:6328
#23 0x00572faf in HttpSM::set_next_state (this=0x2aaab4470830) at
HttpSM.cc:6378
#24 0x0056115a in HttpSM::call_transact_and_set_next_state
(this=0x2aaab4470830, f=0) at HttpSM.cc:6328
#25 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at
HttpSM.cc:1516
#26 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830,
event=0, data=0x0) at HttpSM.cc:1448
#27 0x0056de77 in HttpSM::do_api_callout_internal
(this=0x2aaab4470830) at HttpSM.cc:4345
#28 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at
HttpSM.cc:497
#29 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at
HttpSM.cc:6362
#30 0x0056115a in HttpSM::call_transact_and_set_next_state
(this=0x2aaab4470830, f=0) at HttpSM.cc:6328
#31 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at
HttpSM.cc:1516
#32 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830,
event=0, data=0x0) at HttpSM.cc:1448
#33 0x0056de77 in HttpSM::do_api_callout_internal
(this=0x2aaab4470830) at HttpSM.cc:4345
#34 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at
HttpSM.cc:497
#35 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at
HttpSM.cc:6362
#36 0x0056115a in HttpSM::call_transact_and_set_next_state
(this=0x2aaab4470830, f=0x59e52e
HttpTransact::ModifyRequest(HttpTransact::State*)) at HttpSM.cc:6328
#37 0x0057490c in HttpSM::state_read_client_request_header
(this=0x2aaab4470830, event=100, data=0x2049f5e8) at HttpSM.cc:780
#38 0x0056e49f in HttpSM::main_handler (this=0x2aaab4470830,
event=100, data=0x2049f5e8) at HttpSM.cc:2436
[jira] [Updated] (TS-821) memcached_remap plugin
[ https://issues.apache.org/jira/browse/TS-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-821: - Fix Version/s: (was: sometime) 3.1.3 memcached_remap plugin -- Key: TS-821 URL: https://issues.apache.org/jira/browse/TS-821 Project: Traffic Server Issue Type: Improvement Components: Plugins Environment: Fedora 15 Reporter: Opensource AT Navya Prabha Assignee: James Peach Priority: Minor Fix For: 3.1.3 Attachments: memcached_remap.tar.bz2 to make ASF own memcached_remap plugin -- 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-872) ATS 3.0 shows a http 502 error as a forward proxy server ！
[
https://issues.apache.org/jira/browse/TS-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-872:
-
Fix Version/s: (was: sometime)
ATS 3.0 shows a http 502 error as a forward proxy server ！
--
Key: TS-872
URL: https://issues.apache.org/jira/browse/TS-872
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.0.0
Environment: OS: Ubuntu 10.10, Traffic Server version:.3.0, Web
Browser：firefox 4.0.1，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk:
500G
Reporter: taoyunxing
Labels: patch
Original Estimate: 48h
Remaining Estimate: 48h
when I set up a forward proxy with ATS 3.0 and firefox 4.0.1 and start the
proxy server as a root, it shows me the following info:
root@tyx-System-Product-Name:/usr/local/bin# ./traffic_server
[TrafficServer] using root directory '/usr/local'
[Jul 6 08:56:36.765] {3077691088} STATUS: opened
/usr/local/var/log/trafficserver/diags.log
[Jul 6 08:56:36.765] {3077691088} NOTE: updated diags config
[Jul 6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Config:
/usr/local/etc/trafficserver/ae_ua.config
[Jul 6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Opening config
/usr/local/etc/trafficserver/ae_ua.config
[Jul 6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua)
[HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
[Jul 6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua)
[init_http_aeua_filter] - Total loaded 0 REGEXP for
Accept-Enconding/User-Agent filtering
[Jul 6 08:56:36.768] Server {3077691088} NOTE: cache clustering disabled
[Jul 6 08:56:36.768] Server {3077691088} NOTE: clearing statistics
[Jul 6 08:56:36.770] Server {3077691088} DEBUG: (dns) ink_dns_init: called
with init_called = 0
[Jul 6 08:56:36.779] Server {3077691088} DEBUG: (dns)
localhost=tyx-System-Product-Name
[Jul 6 08:56:36.779] Server {3077691088} DEBUG: (dns) Round-robin
nameservers = 0
[Jul 6 08:56:36.779] Server {3077691088} DEBUG: (hostdb) Storage path is
/usr/local/var/trafficserver
[Jul 6 08:56:36.779] Server {3077691088} DEBUG: (hostdb) Opening host.db,
size=20
[Jul 6 08:56:36.779] Server {3077691088} WARNING: configuration changed:
[hostdb.config] : reinitializing database
[Jul 6 08:56:36.779] Server {3077691088} NOTE: reconfiguring host database
[Jul 6 08:56:36.779] Server {3077691088} DEBUG: (hostdb) unable to unlink
/usr/local/etc/trafficserver/internal/hostdb.config
[Jul 6 08:56:36.779] Server {3077691088} WARNING: Configured store too
small, unable to reconfigure
[Jul 6 08:56:36.779] Server {3077691088} WARNING: unable to initialize
database (too little storage)
: [hostdb.config] : disabling database
You may need to 'reconfigure' your cache manually. Please refer to
the 'Configuration' chapter in the manual.
[Jul 6 08:56:36.779] Server {3077691088} WARNING: could not initialize host
database. Host database will be disabled
[Jul 6 08:56:36.779] Server {3077691088} WARNING: bad hostdb or storage
configuration, hostdb disabled
[Jul 6 08:56:36.780] Server {3077691088} NOTE: cache clustering disabled
[Jul 6 08:56:36.834] Server {3057408880} WARNING: disk header different for
disk /usr/local/var/trafficserver/cache.db: clearing the disk
[Jul 6 08:56:36.884] Server {3077691088} NOTE: logging initialized[7],
logging_mode = 3
[Jul 6 08:56:36.887] Server {3077691088} DEBUG: (http_init)
proxy.config.http.redirection_enabled = 0
[Jul 6 08:56:36.887] Server {3077691088} DEBUG: (http_init)
proxy.config.http.number_of_redirections = 1
[Jul 6 08:56:36.887] Server {3077691088} DEBUG: (http_init)
proxy.config.http.post_copy_size = 2048
[Jul 6 08:56:36.887] Server {3077691088} DEBUG: (http_tproxy) Primary listen
socket transparency is off
[Jul 6 08:56:36.890] Server {3077691088} NOTE: traffic server running
[Jul 6 08:56:36.890] Server {3077691088} DEBUG: (dns)
DNSHandler::startEvent: on thread 0
[Jul 6 08:56:36.890] Server {3077691088} DEBUG: (dns) open_con: opening
connection 8.8.8.8:53
[Jul 6 08:56:36.890] Server {3077691088} DEBUG: (dns) random port = 42595
[Jul 6 08:56:36.890] Server {3077691088} DEBUG: (dns) opening connection
8.8.8.8:53 SUCCEEDED for 0
[Jul 6 08:56:36.918] Server {3058461552} NOTE: Clearing Disk:
/usr/local/var/trafficserver/cache.db
[Jul 6 08:56:36.919] Server {3058461552} NOTE: clearing cache directory
'/usr/local/var/trafficserver/cache.db 16384:24575'
[Jul 6 08:56:37.056] Server {3055303536} NOTE: cache enabled
[Jul 6 08:56:45.632] Server {3002059632} DEBUG: (http_tproxy) Marking
accepted connect on b328c6e8 as not outbound transparent.
[Jul 6 08:56:45.632] Server
[jira] [Updated] (TS-838) [GSoC] Create a port of mod_security as Apache TrafficServer plugin
[ https://issues.apache.org/jira/browse/TS-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-838: --- Labels: (was: gsoc2011) [GSoC] Create a port of mod_security as Apache TrafficServer plugin --- Key: TS-838 URL: https://issues.apache.org/jira/browse/TS-838 Project: Traffic Server Issue Type: Wish Components: Plugins Reporter: Igor Galić ModSecurity is a Web Application Firewall (WAF), which is currently natively implemented as Apache httpd module. It is mostly used to protect multiple back-end applications from a single entry point on a proxy-server. This alone makes Traffic Server the ideal platform for a port. For reference, see https://www.modsecurity.org/tracker/browse/MODSEC-250 -- 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 ] James Peach updated TS-475: --- Component/s: Cache 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.1.5 Attachments: diff.out The cache has support for efficiently locate a particular range in the cached object, but the HTTP SM does not support this. In order to make Range: request efficient (particularly on large objects), the SM should support this new cache feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1087) TSHttpTxnOutgoingAddrSet forward declaration does not match implementation
[
https://issues.apache.org/jira/browse/TS-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223986#comment-13223986
]
James Peach commented on TS-1087:
-
Bart, maybe a better approach is to change the implementation to not need the
socklen_t parameter? It's implied by the address family, so should not be
necessary. This would fix the bug and not require plugin changes.
TSHttpTxnOutgoingAddrSet forward declaration does not match implementation
--
Key: TS-1087
URL: https://issues.apache.org/jira/browse/TS-1087
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.1.0
Reporter: B Wyatt
Assignee: B Wyatt
Priority: Trivial
Fix For: 3.1.5
Attachments: txn-outgoing-addr.patch
Original Estimate: 1m
Remaining Estimate: 1m
ts.h.in lists the following declaration:
{code}TSReturnCode TSHttpTxnOutgoingAddrSet(TSHttpTxn txnp, struct sockaddr
const* addr);{code}
However, the current implementation has this function sig:
{code}tsapi TSReturnCode TSHttpTxnOutgoingAddrSet(TSHttpTxn txnp, struct
sockaddr const* addr, socklen_t addrlen);{code}
Trafficserver is unable to load plugins which use this function due to the
unresolved symbol.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-406) manual for traffic shell not installed during make install
[ https://issues.apache.org/jira/browse/TS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223987#comment-13223987 ] James Peach commented on TS-406: traffic_shell online help was implemented in TS-1097. We still need a man page to close this out. manual for traffic shell not installed during make install Key: TS-406 URL: https://issues.apache.org/jira/browse/TS-406 Project: Traffic Server Issue Type: Task Components: Documentation Affects Versions: 2.1.2, 2.0.0 Environment: linux Reporter: Conan Wang Priority: Trivial Fix For: Doc 3.0 the command man traffic_shell returns No manual entry for traffic_line, in both release and trunk version. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-701) Remove mgmt/cli/script_configs.sh
[ https://issues.apache.org/jira/browse/TS-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-701. Resolution: Fixed Assignee: James Peach commit 6a79f69f6fd0b26f1af75236171b364cd329e7f7 Author: James Peach jpe...@apache.org Date: Tue Mar 6 21:40:08 2012 -0800 TS-701: Remove mgmt/cli/script_configs.sh Remove mgmt/cli/script_configs.sh - Key: TS-701 URL: https://issues.apache.org/jira/browse/TS-701 Project: Traffic Server Issue Type: Task Components: Cleanup Reporter: Igor Galić Assignee: James Peach Priority: Trivial Fix For: 3.1.5 mgmt/cli/script_configs.sh is not used or useful, it should be removed. -- 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-1107) dynamically scale the number of net threads
[ https://issues.apache.org/jira/browse/TS-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1107: Affects Version/s: 3.3.0 Push out to 3.3 dynamically scale the number of net threads --- Key: TS-1107 URL: https://issues.apache.org/jira/browse/TS-1107 Project: Traffic Server Issue Type: New Feature Components: Core, Performance Affects Versions: 3.3.0 Reporter: James Peach Priority: Minor The number of net threads is calculated once at startup, but we ought to consider dynamically scaling the number of threads a runtime based on load. zwoop: right, that's what I meant (keep a counter of how many times epoll had no events, and treat that as an idle thread) zwoop: probably a multiplier of some setting (thread_idle_seconds or some such) zwoop: this would be a cool feature, if you have the time for it ;) zwoop: can keep the original calculations / settings as the upper limit I think zwoop: (the calculations can also easily be configured in records.config, so that people can modify that upper limit) zwoop: an ideal solution (backward compatible) would be to just add one new setting, reap_idle_threads_seconds or some such, default to 0 (off). With it not set, our normal logic applies. With it set, your stuff takes effect, but cap it at whatever the other settings are. -- 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 ] James Peach updated TS-1015: Component/s: Cleanup Yes, this would be really helpful! 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.1.5 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] [Resolved] (TS-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed a
[ https://issues.apache.org/jira/browse/TS-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1061. - Resolution: Duplicate Looks like this got fixed in TS-1066 TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed as it is not used. - Key: TS-1061 URL: https://issues.apache.org/jira/browse/TS-1061 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.1.1, 3.0.1 Environment: Redhat Linux but it is not environment specific Reporter: Alistair Stevenson Assignee: Igor Galić Priority: Minor Labels: api-change Fix For: 3.1.2 Original Estimate: 1h Remaining Estimate: 1h The definitions are: ./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes) ./proxy/api/ts/ts.h.in: tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp); The int * bytes parameter is not used and means that the function does not resolve and so cannot be used. -- 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
