[jira] [Commented] (TS-1114) Crash report: HttpTransactCache::SelectFromAlternates
[
https://issues.apache.org/jira/browse/TS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239294#comment-13239294
]
Conan Wang commented on TS-1114:
get Hunk #1 FAILED at 1491 when try to backport, because TS-1084 also has a
simple modify to the code.
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-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] [Resolved] (TS-768) [GSoc2011] content compression plugin (gzip plugin)
[ https://issues.apache.org/jira/browse/TS-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-768. -- Resolution: Duplicate Fix Version/s: (was: 3.1.5) Closing this as a duplicate, please reopen if not true. [GSoc2011] content compression plugin (gzip plugin) --- Key: TS-768 URL: https://issues.apache.org/jira/browse/TS-768 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Igor Galić Labels: compression, gsoc2011, plugin Traffic Server needs a plugin which will allow administrators (of reverse proxies, chiefly) to configure a single point at which content compression happens, thereby reducing the pressure on the back-ends even more Gzipped content SHOULD be cachable. Furthermore it MUST conform to RFC 2616, as well as the upcoming httpbis: see e.g.: http://tools.ietf.org/id/draft-ietf-httpbis-p3-payload-14.txt -- 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-796) Crash Report: mime_str_u16_set, possible
[
https://issues.apache.org/jira/browse/TS-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-796.
--
Resolution: Duplicate
Fix Version/s: (was: 3.1.5)
I'm fairly certain this is the same strack trace as from CVE 2012-0256, so
closing this. Please reopen if not the case.
Crash Report: mime_str_u16_set, possible
Key: TS-796
URL: https://issues.apache.org/jira/browse/TS-796
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 2.1.8
Reporter: Zhao Yongming
Labels: crash
report from user, may need more detail
{code}
/usr/local/ts/bin/traffic_server(mime_str_u16_set(HdrHeap*, char const*,
unsigned short, char const**, unsigned short*,
bool)+0x5d)[0x821b16d]/usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*,
URLImpl*, char const*, int, bool)+0x51)[0x82251c1]
/usr/local/ts/bin/traffic_server(HTTPHdr::set_url_target_from_host_field(URL*)+0x84)[0x8215a74]
/usr/local/ts/bin/traffic_server(RemapProcessor::setup_for_remap(HttpTransact::State*)+0x272)[0x81c6132]
/usr/local/ts/bin/traffic_server(HttpSM::do_remap_request(bool)+0x3a)[0x816bf8a]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0xad3)[0x81855b3]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0xab)[0x816903b]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x19f)[0x818278f]
/usr/local/ts/bin/traffic_server(HttpSM::state_api_callout(int,
void*)+0x340)[0x8178f60]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x160)[0x8184c40]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0xab)[0x816903b]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x19f)[0x818278f]
/usr/local/ts/bin/traffic_server(HttpSM::state_api_callout(int,
void*)+0x340)[0x8178f60]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x160)[0x8184c40]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0xab)[0x816903b]
/usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x31d)[0x817cf9d]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x1a4)[0x8181154]
/usr/local/ts/bin/traffic_server[0x82f6d4c]
/usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x515)[0x82eb295]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x1ff)[0x831fa9f]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x449)[0x8320249]
{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] [Created] (TS-1169) in enable-debug and pristine_host_hdr=0 mode, TS will crash when purge a cached object which is after TSCacheUrlSet
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.0.4, 3.1.3
Environment: configure --enable-debug
Reporter: Conan Wang
{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] [Commented] (TS-561) Origin-server side IPv6 support
[ https://issues.apache.org/jira/browse/TS-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239734#comment-13239734 ] Leif Hedstrom commented on TS-561: -- What's the status here, is this done in another bug? If so, please close as a duplicate. Origin-server side IPv6 support --- Key: TS-561 URL: https://issues.apache.org/jira/browse/TS-561 Project: Traffic Server Issue Type: New Feature Components: Network Environment: Linux 4.x Reporter: Anirban Roy Assignee: Alan M. Carroll Fix For: 3.1.5 raffic Server used as forward proxy in a number of places including web crawling and feed fetching applications. In those applications, (origin)server side IPv6 support is desirable. As the Internet running out of IPv4 addresses, the new sites will run on IPv6 stack. The applications pulling content using traffic server should be able to do so in the changing scenario. -- 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] [Commented] (TS-993) Add OpenBSD support.
[ https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239923#comment-13239923 ] Piotr Sikora commented on TS-993: - Hey Leif, unfortunately, work circumstances changed for me in the past few months and I won't be working on ATS in the foreseeable future... Someone should takeover this. 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] [Commented] (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:comment-tabpanelfocusedCommentId=13240026#comment-13240026 ] Leif Hedstrom commented on TS-1163: --- Will you land this already :P 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] [Assigned] (TS-1080) Assert under heavy load with logging enabled
[
https://issues.apache.org/jira/browse/TS-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1080:
-
Assignee: Leif Hedstrom
Assert under heavy load with logging enabled
Key: TS-1080
URL: https://issues.apache.org/jira/browse/TS-1080
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Critical
Fix For: 3.1.4
Given enough load (in the 100,000 QPS or more), we run out of some sort of
buffer space, with an assert of
{code}
#0 0x2ba719d50285 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x2ba719d51b9b in __GI_abort () at abort.c:91
#2 0x006b561a in ink_die_die_die (retval=optimized out) at
ink_error.cc:43
#3 ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *)
(return_code=optimized out, message_format=optimized out,
ap=0x7fff7275a7d8) at ink_error.cc:65
#4 0x006b56a7 in ink_fatal (return_code=optimized out,
message_format=optimized out) at ink_error.cc:73
#5 0x006b4970 in _ink_assert (a=0x6fd380
_num_flush_buffers[_open_flush_array] FLUSH_ARRAY_SIZE, f=optimized
out, l=96) at ink_assert.cc:44
#6 0x005a8b34 in add_to_flush_queue (buffer=0x2ba7443ca970,
this=0x22fb918) at LogObject.h:96
#7 LogObject::_checkout_write (this=0x22fb880, write_offset=0x7fff7275add8,
bytes_needed=152) at LogObject.cc:455
#8 0x005a8fd3 in LogObject::log (this=0x22fb880, lad=0x7fff7275b030,
text_entry=0x0) at LogObject.cc:580
#9 0x0058e956 in log (lad=0x7fff7275b030, this=optimized out) at
LogObject.h:475
#10 Log::access (lad=0x7fff7275b030) at Log.cc:1086
{code}
Increasing FLUSH_ARRAY_SIZE alleviates the problem, but really, we shouldn't
end up in this situation at all.
--
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-1106) redirect map generates multiple Via: header entries.
[
https://issues.apache.org/jira/browse/TS-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240041#comment-13240041
]
Leif Hedstrom commented on TS-1106:
---
It's actually kinda weird, sending a request shows this from the tracers on
http_hdrs:
{code}
+ Proxy's Response 2 +
-- State Machine Id: 0
HTTP/1.1 404 Not Found on Accelerator
Date: Tue, 27 Mar 2012 23:03:47 GMT
Connection: close
Via: http/1.1 loki.ogre.com (ApacheTrafficServer/3.1.4-unstable [u c s f p
eS:tNc i p s ])
Server: ATS/3.1.4-unstable
+ Proxy's Response 2 +
-- State Machine Id: 0
HTTP/1.1 301 Redirect
Date: Tue, 27 Mar 2012 23:03:47 GMT
Via: http/1.1 loki.ogre.com (ApacheTrafficServer/3.1.4-unstable [u c s f p
eS:tNc i p s ]), http/1.1 loki.ogre.com (ApacheTrafficServer/3.1.4-unstable [u
c s f p eS:tNc i p s ])
Server: ATS/3.1.4-unstable
Cache-Control: no-store
Content-Type: text/html
Content-Language: en
Connection: close
{code}
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.1.4
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] [Assigned] (TS-1036) Improve squid log compatibility
[ https://issues.apache.org/jira/browse/TS-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1036: - Assignee: Leif Hedstrom Improve squid log compatibility Key: TS-1036 URL: https://issues.apache.org/jira/browse/TS-1036 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.4 See https://github.com/mnot/squidpeek/commit/3874cb902f257974d16c8eae5fc5a77c6fafbf69 for some differences, from mnot as well: all of the ERR_* ones squid does TCP_REFRESH_FAIL_HIT, you do TCP_REF_FAIL_HIT squid does TCP_CLIENT_REFRESH_MISS, you do TCP_CLIENT_REFRESH squid does TCP_SWAPFAIL_MISS, you do TCP_SWAPFAIL -- 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] [Assigned] (TS-981) ATS as transparent proxy crashes under heavy load
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-981: Assignee: Leif Hedstrom ATS as transparent proxy crashes under heavy load - 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] [Commented] (TS-981) ATS as transparent proxy crashes under heavy load
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240096#comment-13240096 ] Leif Hedstrom commented on TS-981: -- I'll check with John, but I think we should just remove libev entirely from the source. ATS as transparent proxy crashes under heavy load - 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-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] [Resolved] (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
]
James Peach resolved TS-1162.
-
Resolution: Fixed
a6867032e9db6d308f3c508743f9e6669cf9f5e7 TS-1162: UnixNetVConnection.cc
assertion when accepting a TLS connection
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
Assignee: 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
[jira] [Resolved] (TS-1135) support wildcard certificates for ServerNameIndication (SNI)
[ https://issues.apache.org/jira/browse/TS-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1135. - Resolution: Fixed bb5402304c30b8b2107e1f845bb301f5a6a9b022 TS-1135: Remove std::distance to make Solaris happy ce8fb7ef1bc9a6e351ef160d51036e03cb7892c4 TS-1135: Fix signed/unsigned warning 0dcad6eaf692e6acee68685c08788bc42e8e15b3 TS-1135: index wildcard certificates for ServerNameIndication 313c224d66fd12800612986b0ad0c58b25a1392a TS-1135: add some const qualifiers to DFA::match() 9c1958ab49e3cd6a8f4fec785a033a204ea222bb TS-1135: minor Trie and Queue fixes 687fdbfee6d47c6d4d81f9458d69d23311f6f35d TS-1135: move Trie.h to libts support wildcard certificates for ServerNameIndication (SNI) Key: TS-1135 URL: https://issues.apache.org/jira/browse/TS-1135 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: James Peach Fix For: 3.1.4 The ServerNameIndication support added in TS-472 doesn't handle wildcard certificates. We need to add certificate parsing support to detect wildcard certificates and then (if there is not an exact match) choose the certificate with the longest wildcard 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-1147) deprecate records.config SSL configuration
[ https://issues.apache.org/jira/browse/TS-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1147: Fix Version/s: (was: 3.1.4) 3.1.5 Assignee: James Peach I'm going to investigate this for 3.1.5 (aka. 3.2). deprecate records.config SSL configuration -- Key: TS-1147 URL: https://issues.apache.org/jira/browse/TS-1147 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.5 Since ssl_multicert.config is a strict superset of the SSL certificate configuration in records.config, we should deprecate configuring SSL certificates in records.config and make ssl_multicert.config the One True Way. -- 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-669) [GSoC2011] ATS does not support SSL in IPv6
[ https://issues.apache.org/jira/browse/TS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-669. Resolution: Fixed Fix Version/s: (was: 3.3.0) 3.1.4 We believe that this is fixed in trunk by Alan's port configuration changes. Please test and let us know whether this problem is resolved. [GSoC2011] ATS does not support SSL in IPv6 --- Key: TS-669 URL: https://issues.apache.org/jira/browse/TS-669 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.0.0 Reporter: vijaya bhaskar mamidi Assignee: Alan M. Carroll Labels: gsoc2011, ipv6, ssl Fix For: 3.1.4 proxy.config.http.server_other_ports is used to support IPv6 but this only work for http ports and not secure ports. We should support IPv6 for secure ports as well. -- 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 ] Zhao Yongming updated TS-1154: -- Fix Version/s: (was: 3.1.4) 3.0.4 we do not need to fix the current git master, let us just fix it in 3.0.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.0.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] [Closed] (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 ] Zhao Yongming closed TS-1154. - Resolution: Fixed checked in to the git 3.0.x branch. 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.0.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
