[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.3.3) 3.5.0 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.5.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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-32) Fix ICP
[ https://issues.apache.org/jira/browse/TS-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-32: Fix Version/s: (was: 3.3.3) 3.5.0 Fix ICP --- Key: TS-32 URL: https://issues.apache.org/jira/browse/TS-32 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.0 Reporter: Miles Libbey Fix For: 3.5.0 http://icp.ircache.net/ The ICP implementation in Traffic Server broke when epoll() was introduced. Its still an interesting and used feature in caches: - when a caching layer of several boxes are used ICP helps to reduce disparities when a client is not routed to the same cache on subsequent requests - after a restart, it can help reduce the time spent in a cold cache situation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-219) Daemon should not rely on init script exclusively for pid/lock removal.
[ https://issues.apache.org/jira/browse/TS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-219. -- Resolution: Won't Fix Fix Version/s: (was: 3.3.3) Things have changed so much since this was filed, so closing this now. If this is still an issue, please reopen. Daemon should not rely on init script exclusively for pid/lock removal. --- Key: TS-219 URL: https://issues.apache.org/jira/browse/TS-219 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 2.0.0a Reporter: Jason Giedymin Priority: Minor Labels: daemon, init, linux, lock, pid, script Having the ts daemon remove it's PID will be useful. Init script can then do 'cleanup' if necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (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 resolved TS-343.
--
Resolution: Won't Fix
Fix Version/s: (was: 3.3.3)
Since we eliminated the support for the NewCacheVC, and hence, writing cache
plugins, I'm closing this down. Sorry about that.
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
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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-541) SplitDNS cleanup in project HostDBandDNS
[ https://issues.apache.org/jira/browse/TS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605202#comment-13605202 ] Leif Hedstrom commented on TS-541: -- Is this stuff still relevant? It's been sitting here forever. If not, please remove the Fix Version and close as won't fix. 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.3 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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-382) socket option cleanup (and bug fixes)
[ https://issues.apache.org/jira/browse/TS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-382: - Fix Version/s: (was: 3.3.3) 3.5.0 socket option cleanup (and bug fixes) --- Key: TS-382 URL: https://issues.apache.org/jira/browse/TS-382 Project: Traffic Server Issue Type: Bug Components: Network Reporter: Leif Hedstrom Fix For: 3.5.0 This is a bug moved from Y! Bugzilla, I'm posting the original bug description and a few comments separately. Note that the bug description is fairly limited, but while looking at this code, I noticed a lot of oddities with the socket option support (lots of hardcoded stuff, and most of it is not configurable). Note that the original bug should have been fixed already in Apache TS, but the other comments are still applicable. From Bugzilla (posted by Leif): We have two socket option config options in records.config: proxy.config.net.sock_option_flag_in proxy.config.net.sock_option_flag_out With accept thread enabled, at least the _in option isn't honored. There are possibly other cases in UnixNetAccept.cc that we don't honor these flags either. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-357) Compiling with -Wconversion generates a lot of errors
[ https://issues.apache.org/jira/browse/TS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-357: - Fix Version/s: (was: 3.3.3) 3.5.0 Compiling with -Wconversion generates a lot of errors - Key: TS-357 URL: https://issues.apache.org/jira/browse/TS-357 Project: Traffic Server Issue Type: Improvement Components: Cleanup Affects Versions: 2.1.0 Reporter: Bryan Call Fix For: 3.5.0 After adding -Wconversion to CFLAGS and CXXFLAGS I got 11k errors: [bcall@snowball traffic.git]$ gmake -k 2 /dev/stdout | grep -c ' error: ' 11432 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-219) Daemon should not rely on init script exclusively for pid/lock removal.
[ https://issues.apache.org/jira/browse/TS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-219: - Fix Version/s: 3.5.0 Daemon should not rely on init script exclusively for pid/lock removal. --- Key: TS-219 URL: https://issues.apache.org/jira/browse/TS-219 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 2.0.0a Reporter: Jason Giedymin Priority: Minor Labels: daemon, init, linux, lock, pid, script Fix For: 3.5.0 Having the ts daemon remove it's PID will be useful. Init script can then do 'cleanup' if necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-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.3.3) 3.5.0 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.5.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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-374) Potentially eliminate lock contention on HostDB
[ https://issues.apache.org/jira/browse/TS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-374: - Fix Version/s: (was: 3.3.3) 3.5.0 Potentially eliminate lock contention on HostDB --- Key: TS-374 URL: https://issues.apache.org/jira/browse/TS-374 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Fix For: 3.5.0 When using as a reverse proxy, when a single (or very few) HostDB entries are under pressure, the try-lock there could cause us to reschedule. John suggests we look at this as a first step towards reducing latencies under high load, by avoiding holding the lock over multiple callbacks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-464) Chunked response with bad Content-Length header to HTTP/1.0 clent is broken
[ https://issues.apache.org/jira/browse/TS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-464: - Fix Version/s: (was: 3.3.3) 3.5.0 Chunked response with bad Content-Length header to HTTP/1.0 clent is broken --- Key: TS-464 URL: https://issues.apache.org/jira/browse/TS-464 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: weijin Fix For: 3.5.0 A client sends an HTTP/1.0 request through ATS, which gets proxied with HTTP/1.1 to the origin. The origin (which is at fault here, but nonetheless) returns with both Content-Length: 10 Transfer-Encoding: chunked and a chunked body which is 10 bytes long. In this case, ATS should still respond with an HTTP/1.0 response, undoing the chunking, and return with an appropriate CL: header. We do everything, except set the correct Content-Length header, we simply return the erroneous CL header that the Origin provided. This is not allowed in the RFC. (Originally discovered using Coadvisor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-362) Create packaging scripts for TrafficServer
[ https://issues.apache.org/jira/browse/TS-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-362. -- Resolution: Duplicate Fix Version/s: (was: 3.3.3) I think we've covered a bunch of this already with RPM and debian support etc. Please file additional (specific) bugs where we are missing packaging. Create packaging scripts for TrafficServer -- Key: TS-362 URL: https://issues.apache.org/jira/browse/TS-362 Project: Traffic Server Issue Type: New Feature Components: Packaging Affects Versions: 3.0.0 Environment: Linux, Solaris Reporter: Mladen Turk Assignee: Mladen Turk Priority: Minor Original Estimate: 504h Remaining Estimate: 504h Create pkg directory build/pkg with sub-directories for rpm and pkg This will allow to create .rpm and Solaris .package.gz platform native installation packages -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-371) Add common process code
[ https://issues.apache.org/jira/browse/TS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-371. -- Resolution: Won't Fix Fix Version/s: (was: 3.3.3) Things have been significantly rewritten in the child / processes handling. I'm closing this out now, please open a new bug if there are still missing pieces. Add common process code --- Key: TS-371 URL: https://issues.apache.org/jira/browse/TS-371 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 2.1.2 Reporter: Mladen Turk Assignee: Mladen Turk Priority: Minor Attachments: ink_proc.diff Use the new ink_proc common API for allowing better child and daemon process control. The common task if daemonizing the process is abstracted into API making it available for multiple programs instead duplicating code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-391) Cleanup file header descriptions
[ https://issues.apache.org/jira/browse/TS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-391. -- Resolution: Won't Fix Fix Version/s: (was: 3.3.3) This should be done as part of Doxygen or other documentation bugs. Cleanup file header descriptions Key: TS-391 URL: https://issues.apache.org/jira/browse/TS-391 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: Leif Hedstrom Priority: Minor Most of our file headers has a Doxygen comment like /** @file A brief file description We should fix this, and properly describe each file. :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-563) Incorrectly returned 0 status code from startup script even when TS fails to start
[ https://issues.apache.org/jira/browse/TS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-563. -- Resolution: Invalid Fix Version/s: (was: 3.3.3) Things have changed a fair amount since this, but my first comment still is true I think. Closing for now, but feel free to reopen after testing with latest master. Incorrectly returned 0 status code from startup script even when TS fails to start -- Key: TS-563 URL: https://issues.apache.org/jira/browse/TS-563 Project: Traffic Server Issue Type: Bug Affects Versions: 2.1.5 Environment: Linux Reporter: Marcus Clyne Priority: Trivial When using proxy.config.log2 values in records.config rather than the new proxy.config.log values, TS fails to start (server/manager/cop), but a return code of 0 is returned rather than 1 or something more meaningful. I have also noticed instances when config errors have prevented server from starting, even though manager and cop do. It would probably make sense to have a non-zero error code for these two. Perhaps it might be useful to have different return codes for whether cop/manager/server start or not (e.g. 1=server not started, 2=manager not started, 3=cop not started? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-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 resolved TS-725.
--
Resolution: Duplicate
Fix Version/s: (was: 3.3.3)
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
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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13605222#comment-13605222
]
Leif Hedstrom commented on TS-803:
--
Is this still being worked on?
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.3
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;
+socksEntry-manual_parent_selection = true;
+
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13605220#comment-13605220
]
Leif Hedstrom commented on TS-725:
--
Is this still an issue? I'm going to close this for now, since it's not been
fixed nor reported in quite a while.
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.3
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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (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 resolved TS-877.
--
Resolution: Duplicate
Fix Version/s: (was: 3.3.3)
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
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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-877) Segfault caused by HTTPInfo::object_key_get
[
https://issues.apache.org/jira/browse/TS-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605225#comment-13605225
]
Leif Hedstrom commented on TS-877:
--
Presumably this was fixed in TS-1114, so closing for now.
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.3
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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-902) Crash report: invalid ip range in remap.config crash server
[
https://issues.apache.org/jira/browse/TS-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-902:
-
Fix Version/s: (was: 3.3.3)
3.3.2
Assignee: Leif Hedstrom
Crash report: invalid ip range in remap.config crash server
---
Key: TS-902
URL: https://issues.apache.org/jira/browse/TS-902
Project: Traffic Server
Issue Type: Bug
Components: Configuration, HTTP
Affects Versions: 3.1.0, 3.0.1
Environment: TS 3.0.1
Reporter: Zhao Yongming
Assignee: Leif Hedstrom
Labels: crash
Fix For: 3.3.2
when I put a strage ip range, ie: src_ip=128.0.0.0-121.14.89.0 in remap ip
filtering, it will cause the server crash:
{code}
[TrafficServer] using root directory '/usr'
[Aug 4 11:04:53.209] Manager {140564987967264} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '13'
[Aug 4 11:04:53.209] Manager {140564987967264} NOTE: [Alarms::signalAlarm]
Server Process born
[Aug 4 11:04:54.222] {46990117603664} STATUS: opened
/var/log/trafficserver/diags.log
[Aug 4 11:04:54.224] {46990117603664} NOTE: updated diags config
[Aug 4 11:04:54.225] Server {46990117603664} NOTE: cache clustering disabled
[Aug 4 11:04:54.239] Server {46990117603664} NOTE: cache clustering disabled
[Aug 4 11:04:54.343] Server {46990117603664} NOTE: logging initialized[7],
logging_mode = 1
[Aug 4 11:04:54.345] Server {46990117603664} NOTE: PrefetchProcessor:
Started the prefetch processor
[Aug 4 11:04:54.346] Server {46990117603664} WARNING: Could not add rule at
line #1; Aborting!
[Aug 4 11:04:54.346] Server {46990117603664} WARNING: [ReverseProxy] Unable
to parse IP value in src_ip=128.0.0.0-121.14.89.0 at line 1
FATAL: [ReverseProxy] Unable to parse IP value in
src_ip=128.0.0.0-121.14.89.0 at line 1
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal_va+0x9d)[0x3ab46127dd]
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ab4612938]
/usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x585)[0x580335]
/usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x2fa)[0x58219a]
/usr/bin/traffic_server(_Z18init_reverse_proxyv+0xec)[0x4de75c]
/usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x51ee7b]
/usr/bin/traffic_server(main+0xc07)[0x4bf177]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x389961d994]
/usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4793a9]
[Aug 4 11:04:54.506] Manager {140564987967264} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
{code}
and here is the rules defined in my remap.config:
{code}
.defflt tools @action=deny @src_ip=0.0.0.0-127.0.0.0
@src_ip=128.0.0.0-121.14.89.0 @src_ip=121.14.90.254-255.255.255.255
@method=PURGE
.useflt tools
{code}
well, it is invalid, but we should not crash, right?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-72) Records config review for update type behavior
[ https://issues.apache.org/jira/browse/TS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-72: Fix Version/s: (was: 3.3.3) 3.5.0 Records config review for update type behavior -- Key: TS-72 URL: https://issues.apache.org/jira/browse/TS-72 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 2.0.0a Environment: All Reporter: George Paul Priority: Minor Fix For: 3.5.0 The Records configuration variables need to be reviewed for proper intended update type behavior. The update types can be the following: RU_NULL, // default: don't know the behavior RU_REREAD,// config can be updated dynamically w/ traffic_line -x RU_RESTART_TS,// config requires TS to be restarted to take effect RU_RESTART_TM, // config requires TM/TS to be restarted to take effect RU_RESTART_TC // config requires TC/TM/TS to be restarted to take effect This will require review of the overall system and component configs. Possibly split this ticket into seperate tickets targeted to the various components. -George -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-659) Reduce cross dependencies in various modules
[
https://issues.apache.org/jira/browse/TS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-659:
-
Fix Version/s: (was: 3.3.3)
3.5.0
Reduce cross dependencies in various modules
Key: TS-659
URL: https://issues.apache.org/jira/browse/TS-659
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Fix For: 3.5.0
Right now, it's very difficult to build things (e.g. traffic_logcat) without
including pretty much the entire code base. This is because of cross
dependencies between various modules and libraries. So, where logging ought
to be fairly self sustained, it really isn't. In an attempt to decouple this
a little, I made a stub .cc file, which traffic_logcat and traffic_logstats
uses. Yes this is ugly. Yes, it should be fixed (hence this bug). But it
reduces the binary size for these binaries in the normal build from around
34MB to 4MB, each ...
As a help to isolate *some* of the cross dependencies, here's the ugly stub
code:
{code}
#include libts.h
#include LogObject.h
#if defined(solaris)
#include sys/types.h
#include unistd.h
#endif
#include P_Net.h
int fds_limit = 8000;
UDPNetProcessor udpNet;
ClassAllocatorUDPPacketInternal udpPacketAllocator(udpPacketAllocator);
void
UDPConnection::Release()
{
ink_release_assert(false);
}
void
UDPNetProcessor::FreeBandwidth(Continuation * udpConn)
{
ink_release_assert(false);
}
NetProcessor netProcessor;
Action *
UnixNetProcessor::connect_re_internal(Continuation * cont, unsigned int ip,
int port, NetVCOptions * opt)
{
ink_release_assert(false);
return NULL;
}
#include InkAPIInternal.h
ConfigUpdateCbTable *global_config_cbs = NULL;
void
ConfigUpdateCbTable::invoke(const char *name)
{
ink_release_assert(false);
}
const char *
event_int_to_string(int event, int blen, char *buffer)
{
ink_release_assert(false);
return NULL;
}
struct Machine;
Machine *
this_machine()
{
ink_release_assert(false);
return NULL;
}
#include LogConfig.h
void
LogConfig::setup_collation(LogConfig * prev_config)
{
ink_release_assert(false);
}
void
LogConfig::create_pre_defined_objects_with_filter(const
PreDefinedFormatInfoList pre_def_info_list, size_t num_filters,
LogFilter ** filter, const
char *filt_name, bool force_extension)
{
ink_release_assert(false);
}
int
LogHost::write(LogBuffer * lb, size_t * to_disk, size_t * to_net, size_t *
to_pipe)
{
ink_release_assert(false);
return 0;
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-309) Report OS Errors in Header
[ https://issues.apache.org/jira/browse/TS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-309: - Fix Version/s: (was: 3.3.3) 3.5.0 Report OS Errors in Header -- Key: TS-309 URL: https://issues.apache.org/jira/browse/TS-309 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Miles Libbey Fix For: 3.5.0 (from yahoo bug 1021194) Original description by Ryan Troll 3 years ago at 2007-01-17 13:20 Cleaning out my mailbox; and I didn't want this to disappear. Back on 12/12 Scott asked for a way to look at a YTS response and differentiate between a TS error, and an Origin server error. I *think* the general idea is that, whenever the origin server returns an error; we return it to the client. However, if there's a problem contacting the origin server, we should return the appropriate HTTP response: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5 including 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 505 HTTP Version Not Supported and specify what Origin Server triggered the error in the Warning header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46 I think we could define our own warn code and use it specify the origin server host (by name and IP): 504 Gateway Timeout Date: Wed, 17 Jan 2007 21:17:25 GMT Warning: 599 l1.ycs.s1s.yahoo.com:80 OS: us.yimg.com [66.218.71.81] But that's just a thought. Maybe mnot has a good suggestion -- he pointed us towards the Warning: header, and may know of good examples of it's use in the real world. Comment 1 by Chuck Neerdaels 3 years ago at 2007-01-18 16:33:15 There's a pretty cool feature in TS, where it embeds codes into a Via header (if those are turned on) where someone looking at the headers can see whether it was a cache hit, an IMS hit, etc. As it moves through the state machine, it appends characters to the string - and in the reply you get something like [uN l oS f pS eN] which would translate to a user issuing a no-cache pragma, that resulted in an origin server fetch, which was served without error. It's pretty useful, so we might want to consider enabling this. There's a cheat sheet at /dev/traffic/trunk/proxy/http2/README.via chuck -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-153: - Fix Version/s: (was: 3.3.3) 3.5.0 Dynamic keep-alive timeouts - Key: TS-153 URL: https://issues.apache.org/jira/browse/TS-153 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Priority: Minor Fix For: 3.5.0 (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally posted by Leif Hedstrom on 2008-03-19): Currently you have to set static keep-alive idle timeouts in TS, e.g. CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 even with epoll() in 1.17.x, this is difficult to configure, and put an appropriate timeout. The key here is that the settings above need to assure that you stay below the max configured number of connections, e.g.: CONFIG proxy.config.net.connections_throttle INT 75000 I'm suggesting that we add one (or two) new configuration options, and appropriate TS code support, to instead of specifying timeouts, we specify connection limits for idle KA connections. For example: CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 (one still has to be careful to leave head-room for active connections here, in the example above, 2 connections could be active, which is a lot of traffic). These would override the idle timeouts, so one could use the max_idle connections for incoming (client) connections, and the idle timeouts for outgoing (origin) connections for instance. The benefit here is that it makes configuration not only easier, but also a lot safer for many applications. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-641) WebUI: Kill it with fire.
[ https://issues.apache.org/jira/browse/TS-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-641: - Fix Version/s: (was: 3.3.3) 3.5.0 WebUI: Kill it with fire. - Key: TS-641 URL: https://issues.apache.org/jira/browse/TS-641 Project: Traffic Server Issue Type: Improvement Components: Web UI Reporter: Igor Galić Assignee: Igor Galić Fix For: 3.5.0 Original Estimate: 14m Remaining Estimate: 14m Get rid of proxy/mgmt/html2 Get rid of all code in proxy/mgmt/web2 that is not used Merge used code into proxy/mgmt/utils/WebMgmtUtils.* -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605243#comment-13605243 ] Leif Hedstrom commented on TS-1125: --- William: Any updates on this? Patches? :) POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Priority: Minor Fix For: 3.3.3 Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (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 resolved TS-1128.
---
Resolution: Invalid
Fix Version/s: (was: 3.3.3)
Is this still really an issue? Closing for now, reopen if still an issue.
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
{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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1177) Download mirrors and cache hits
[ https://issues.apache.org/jira/browse/TS-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1177. --- Resolution: Fixed Fix Version/s: (was: 3.3.3) 3.3.2 I believe this is already checked in and complete, right ? Download mirrors and cache hits --- Key: TS-1177 URL: https://issues.apache.org/jira/browse/TS-1177 Project: Traffic Server Issue Type: Improvement Reporter: Jack Bates Labels: gsoc2012 Fix For: 3.3.2 I just applied to GSoC with a proposal to use RFC 6249 (Metalink/HTTP: Mirrors and Hashes) to discover requests for the same files from different mirrors and redirect clients to mirrors that are already cached I am filing this JIRA ticket describing my proposal to cause the Apache organization to process it [2]. Thanks for considering this proposal [1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/nottheoilrig/4001 [2] http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201203.mbox/%3CF28ED27B-8224-4362-B98C-945530CADC7C%40me.com%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1183) issue with videos on yahoo website
[ https://issues.apache.org/jira/browse/TS-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1183. --- Resolution: Invalid Fix Version/s: (was: 3.3.3) Closing for now, since there's no feedback on this ticket. Please reopen, and provide more details, if this is still an issue. issue with videos on yahoo website -- Key: TS-1183 URL: https://issues.apache.org/jira/browse/TS-1183 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.4 Reporter: Luca Can't view yahoo videos (tested in forwarding mode). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1207) request for plugin cacheurl move into master tree
[ https://issues.apache.org/jira/browse/TS-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1207: - Assignee: Leif Hedstrom request for plugin cacheurl move into master tree - Key: TS-1207 URL: https://issues.apache.org/jira/browse/TS-1207 Project: Traffic Server Issue Type: New Feature Components: Plugins Affects Versions: 3.1.3 Reporter: Zhao Yongming Assignee: Leif Hedstrom Fix For: 3.3.3 from my testing, the cacheurl plugin is stable and usable in any version of 2.x 3.x, should we move into the meanline? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1207) request for plugin cacheurl move into master tree
[ https://issues.apache.org/jira/browse/TS-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1207: -- Fix Version/s: (was: 3.3.3) 3.3.2 request for plugin cacheurl move into master tree - Key: TS-1207 URL: https://issues.apache.org/jira/browse/TS-1207 Project: Traffic Server Issue Type: New Feature Components: Plugins Affects Versions: 3.1.3 Reporter: Zhao Yongming Assignee: Leif Hedstrom Fix For: 3.3.2 from my testing, the cacheurl plugin is stable and usable in any version of 2.x 3.x, should we move into the meanline? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1218) make TRACE_LOG_COP configurable
[
https://issues.apache.org/jira/browse/TS-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1218:
--
Fix Version/s: (was: 3.3.3)
3.3.2
Assignee: Leif Hedstrom
make TRACE_LOG_COP configurable
---
Key: TS-1218
URL: https://issues.apache.org/jira/browse/TS-1218
Project: Traffic Server
Issue Type: Task
Components: Build
Affects Versions: 3.1.3
Reporter: Zhao Yongming
Assignee: Leif Hedstrom
Fix For: 3.3.2
in TrafficCop.cc:
{code}
// For debugging, turn this on.
// #define TRACE_LOG_COP 1
{code}
can we make this a ink_config define make it known as configure ENV?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1255) Add more overridable records.config configurations
[
https://issues.apache.org/jira/browse/TS-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1255:
--
Fix Version/s: (was: 3.3.3)
3.3.2
Add more overridable records.config configurations
--
Key: TS-1255
URL: https://issues.apache.org/jira/browse/TS-1255
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.3.2
We should examine at least the following configs, and see which ones can (or
can not) be moved to be overridable:
{code}
MgmtInt server_max_connections;
MgmtInt origin_min_keep_alive_connections; // TODO: This one really ought
to be overridable, but difficult right now.
char *proxy_request_via_string;
int proxy_request_via_string_len;
char *proxy_response_via_string;
int proxy_response_via_string_len;
MgmtInt origin_server_pipeline;
MgmtInt user_agent_pipeline;
MgmtInt transaction_active_timeout_in;
MgmtInt accept_no_activity_timeout;
MgmtInt background_fill_active_timeout;
MgmtFloat background_fill_threshold;
MgmtInt parent_connect_attempts;
MgmtInt per_parent_connect_attempts;
MgmtInt parent_connect_timeout;
MgmtByte insert_age_in_response;
MgmtByte avoid_content_spoofing;
MgmtByte enable_http_stats;
MgmtInt max_cache_open_write_retries;
MgmtByte cache_enable_default_vary_headers;
MgmtByte cache_when_to_add_no_cache_to_msie_requests;
MgmtByte cache_range_lookup;
MgmtInt request_hdr_max_size;
MgmtInt response_hdr_max_size;
MgmtByte push_method_enabled;
MgmtByte referer_filter_enabled;
MgmtByte referer_format_redirect;
MgmtByte accept_encoding_filter_enabled;
// WTF!!! Bool ???
/// Accept connections on foreign addresses.
bool client_transparency_enabled;
/// Use client address to connect to origin server.
bool server_transparency_enabled;
MgmtByte negative_revalidating_enabled;
MgmtInt negative_revalidating_lifetime;
MgmtByte ignore_accept_mismatch;
MgmtByte ignore_accept_language_mismatch;
MgmtByte ignore_accept_encoding_mismatch;
MgmtByte ignore_accept_charset_mismatch;
// Optimize gzip alternates //
MgmtByte normalize_ae_gzip;
{code}
Marking this for v3.3.0, it'd be nice to get into 3.2, but I rather have us
just get 3.1.4/3.2 done sooner rather than later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1753) Cacheurl plugin improvements
[ https://issues.apache.org/jira/browse/TS-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-1753: --- Assignee: Phil Sorber Cacheurl plugin improvements Key: TS-1753 URL: https://issues.apache.org/jira/browse/TS-1753 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Mark Harrison Assignee: Phil Sorber I've made a couple of improvements to the cacheurl plugin: * parameter to take a location for the config file * ability to be called as a remap plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1207) request for plugin cacheurl move into master tree
[ https://issues.apache.org/jira/browse/TS-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-1207: --- Assignee: Phil Sorber (was: Leif Hedstrom) request for plugin cacheurl move into master tree - Key: TS-1207 URL: https://issues.apache.org/jira/browse/TS-1207 Project: Traffic Server Issue Type: New Feature Components: Plugins Affects Versions: 3.1.3 Reporter: Zhao Yongming Assignee: Phil Sorber Fix For: 3.3.2 from my testing, the cacheurl plugin is stable and usable in any version of 2.x 3.x, should we move into the meanline? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1305) unable to get a complete http response body each time using a extended state machine !
[ https://issues.apache.org/jira/browse/TS-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1305: -- Backport to Version: (was: sometime) unable to get a complete http response body each time using a extended state machine ! -- Key: TS-1305 URL: https://issues.apache.org/jira/browse/TS-1305 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.4 Environment: Ubuntu 10.10 Reporter: taoyunxing Labels: fullresponse, httptransaction Fix For: 3.3.3 I wrote a third state machine FetchPageSM by modifying the SimpleCont in trafficserver-3.0.4\proxy\SimpleHttp.cc, and I create a http request like this + Request Header created for ProxyFetchPageSM + -- State Machine Id: 0 GET http://www.cnbeta.com/articles/192944.htm HTTP/1.1 Host: www.cnbeta.com Proxy-Connection: close User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.83 Safari/535.11 Accept: \*/\* , then dns parse url, connect to os, send the above request, finally receive the resposne header and body, surprisely enough I couldn't get the complete response body sometime, because the actual length of response body don't match the Content-Length field in response header, but sometime I get the complete one. It seems random in this case, why ?? I'm very sad,and eager to get some help or hint from experts，help me! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1317) fail to build rpm with --enable-debug
[
https://issues.apache.org/jira/browse/TS-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1317.
---
Resolution: Invalid
Fix Version/s: (was: 3.3.3)
I'm not able to reproduce this on current master. Is this still a problem?
Please reopen if it is.
fail to build rpm with --enable-debug
-
Key: TS-1317
URL: https://issues.apache.org/jira/browse/TS-1317
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.3.0, 3.2.0
Reporter: Zhao Yongming
{code}
cc1plus: warnings being treated as errors
../../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
make[2]: *** [SSLNetProcessor.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
`/home/yonghao/rpmbuild/BUILD/trafficserver-3.2.0/iocore/net'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/yonghao/rpmbuild/BUILD/trafficserver-3.2.0/iocore'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.Lm4CVz (%build)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1355) Drop support for Unices which don't support 64bit time_t
[ https://issues.apache.org/jira/browse/TS-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1355. --- Resolution: Won't Fix Fix Version/s: (was: 3.3.3) Closing this as won't fix for now. If this is still on the radar, please reopen. Drop support for Unices which don't support 64bit time_t Key: TS-1355 URL: https://issues.apache.org/jira/browse/TS-1355 Project: Traffic Server Issue Type: Task Environment: Unix Reporter: Igor Galić Assignee: Igor Galić -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1382) jtest is not 64bit nice?
[
https://issues.apache.org/jira/browse/TS-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1382.
---
Resolution: Fixed
Fix Version/s: (was: 3.3.3)
3.3.2
Closing as fixed.
jtest is not 64bit nice?
Key: TS-1382
URL: https://issues.apache.org/jira/browse/TS-1382
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.3.0
Reporter: Zhao Yongming
Fix For: 3.3.2
{code}
[root@test223 ~]# jtest -S ts.cn -P 115.238.23.222
gethostbyname: Success
con newops 1byte lat bytes/per svrs new opstotal time
err
100 200.0 0 0 0/0 000 15224.1
0
100 221 1056.61516 15755542/157555 633 633 632 262114874.6
0
100 528 2605.11314 41197350/411973 1559 1559 1558 667285705.6
0
100 831 4131.11113 65919865/659198 2482 2482 2481 105312201
6.60
100 1117 5571.11012 87058878/870588 3342 3342 3341 139266339
7.60
100 1268 6325.8 911 98363651/983636 3787 3787 3787 -14692543
8.60
100 1389 6937.1 810 106898027/1068980 4162 4162 4161 33783077
9.60
100 1505 7519.1 710 114697045/1146970 4496 4496 4496 73836162
10.60
100 1663 8308.2 6 9 -44317582/-443175 4982 4982 4981 116560233
11.60
100 1770 8846.0 6 9 -1355348/-13553 5304 5304 5304 -23180093
12.60
100 1818 9086.4 6 9 30846878/308468 5436 5436 5437 31424752 13.6
0
100 1799 8999.7 6 9 48851217/488512 5393 5393 5393 65393728 14.6
0
100 1851 9258.2 6 9 69758095/697580 5560 5560 5560 100471603
15.60
100 1813 9063.9 6 9 80264043/802640 5453 5453 5452 118504186
16.60
100 1824 9117.8 6 9 94174620/941746 5484 5484 5484 -29646681
17.60
100 1836 9185.0 6 9 104651080/1046510 5530 5530 5530 22200325
18.60
100 1860 9303.6 6 9 111025678/1110256 5592 5592 5591 62519520
19.60
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1752) jtest doesn't compile on all platforms
[
https://issues.apache.org/jira/browse/TS-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1752:
--
Fix Version/s: 3.3.2
jtest doesn't compile on all platforms
--
Key: TS-1752
URL: https://issues.apache.org/jira/browse/TS-1752
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.3.2
jtest doesn't compile with gcc 4.7 on my platform.
{code}
../../../tools/jtest/jtest.cc: In constructor ‘UrlHashTable::UrlHashTable()’:
../../../tools/jtest/jtest.cc:3804:46: error: comparison between signed and
unsigned integer expressions [-Werror=sign-compare]
{code}
I have a patch, will commit soon.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-902) Crash report: invalid ip range in remap.config crash server
[
https://issues.apache.org/jira/browse/TS-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-902.
--
Resolution: Invalid
Fix Version/s: (was: 3.3.2)
I believe this is already fixed, probably a duplicate. When I try this now, I
get warnings / errors like:
{code}
[Mar 18 11:05:05.700] Server {0x7fe68f765840} WARNING: Could not add rule at
line #53; Aborting!
[Mar 18 11:05:05.700] Server {0x7fe68f765840} WARNING: [ReverseProxy] Unable to
parse IP value in src_ip=128.0.0.0-121.14.89.0 at line 53
[Mar 18 11:05:05.700] Server {0x7fe68f765840} WARNING: something failed during
BuildTable() -- check your remap plugins!
[Mar 18 11:05:05.700] Server {0x7fe68f765840} WARNING: Can not load the remap
table, exiting out!
{code}
Crash report: invalid ip range in remap.config crash server
---
Key: TS-902
URL: https://issues.apache.org/jira/browse/TS-902
Project: Traffic Server
Issue Type: Bug
Components: Configuration, HTTP
Affects Versions: 3.1.0, 3.0.1
Environment: TS 3.0.1
Reporter: Zhao Yongming
Assignee: Leif Hedstrom
Labels: crash
when I put a strage ip range, ie: src_ip=128.0.0.0-121.14.89.0 in remap ip
filtering, it will cause the server crash:
{code}
[TrafficServer] using root directory '/usr'
[Aug 4 11:04:53.209] Manager {140564987967264} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '13'
[Aug 4 11:04:53.209] Manager {140564987967264} NOTE: [Alarms::signalAlarm]
Server Process born
[Aug 4 11:04:54.222] {46990117603664} STATUS: opened
/var/log/trafficserver/diags.log
[Aug 4 11:04:54.224] {46990117603664} NOTE: updated diags config
[Aug 4 11:04:54.225] Server {46990117603664} NOTE: cache clustering disabled
[Aug 4 11:04:54.239] Server {46990117603664} NOTE: cache clustering disabled
[Aug 4 11:04:54.343] Server {46990117603664} NOTE: logging initialized[7],
logging_mode = 1
[Aug 4 11:04:54.345] Server {46990117603664} NOTE: PrefetchProcessor:
Started the prefetch processor
[Aug 4 11:04:54.346] Server {46990117603664} WARNING: Could not add rule at
line #1; Aborting!
[Aug 4 11:04:54.346] Server {46990117603664} WARNING: [ReverseProxy] Unable
to parse IP value in src_ip=128.0.0.0-121.14.89.0 at line 1
FATAL: [ReverseProxy] Unable to parse IP value in
src_ip=128.0.0.0-121.14.89.0 at line 1
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal_va+0x9d)[0x3ab46127dd]
/usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ab4612938]
/usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x585)[0x580335]
/usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x2fa)[0x58219a]
/usr/bin/traffic_server(_Z18init_reverse_proxyv+0xec)[0x4de75c]
/usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x51ee7b]
/usr/bin/traffic_server(main+0xc07)[0x4bf177]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x389961d994]
/usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4793a9]
[Aug 4 11:04:54.506] Manager {140564987967264} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
{code}
and here is the rules defined in my remap.config:
{code}
.defflt tools @action=deny @src_ip=0.0.0.0-127.0.0.0
@src_ip=128.0.0.0-121.14.89.0 @src_ip=121.14.90.254-255.255.255.255
@method=PURGE
.useflt tools
{code}
well, it is invalid, but we should not crash, right?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1593) replace hash_map with unordered_map in logstats
[ https://issues.apache.org/jira/browse/TS-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1593: -- Assignee: James Peach (was: Leif Hedstrom) replace hash_map with unordered_map in logstats --- Key: TS-1593 URL: https://issues.apache.org/jira/browse/TS-1593 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 3.3.0 Reporter: James Peach Assignee: James Peach C++11 has a standard hash container, std::unordered_map, so in C++11 mode we should replace the non-standard hash_map with unordered_map. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1593) replace hash_map with unordered_map in logstats
[ https://issues.apache.org/jira/browse/TS-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605367#comment-13605367 ] Leif Hedstrom commented on TS-1593: --- James, assigning this for you, since you said you had a patch. replace hash_map with unordered_map in logstats --- Key: TS-1593 URL: https://issues.apache.org/jira/browse/TS-1593 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 3.3.0 Reporter: James Peach Assignee: James Peach C++11 has a standard hash container, std::unordered_map, so in C++11 mode we should replace the non-standard hash_map with unordered_map. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1752) jtest doesn't compile on all platforms
[
https://issues.apache.org/jira/browse/TS-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1752:
--
Component/s: Build
jtest doesn't compile on all platforms
--
Key: TS-1752
URL: https://issues.apache.org/jira/browse/TS-1752
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.3.2
jtest doesn't compile with gcc 4.7 on my platform.
{code}
../../../tools/jtest/jtest.cc: In constructor ‘UrlHashTable::UrlHashTable()’:
../../../tools/jtest/jtest.cc:3804:46: error: comparison between signed and
unsigned integer expressions [-Werror=sign-compare]
{code}
I have a patch, will commit soon.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1754) Warnings from stats evaluation
Leif Hedstrom created TS-1754:
-
Summary: Warnings from stats evaluation
Key: TS-1754
URL: https://issues.apache.org/jira/browse/TS-1754
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
After 5bcc19e6, I'm seeing these warnings:
{code}
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type are
RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type are
RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type are
RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type are
RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type are
RECD_NULL.
...
{code}
There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1754) Warnings from stats evaluation
[
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1754:
--
Fix Version/s: 3.3.2
Warnings from stats evaluation
--
Key: TS-1754
URL: https://issues.apache.org/jira/browse/TS-1754
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Fix For: 3.3.2
After 5bcc19e6, I'm seeing these warnings:
{code}
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
...
{code}
There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1754) Warnings from stats evaluation
[
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605477#comment-13605477
]
Leif Hedstrom commented on TS-1754:
---
I'm fairly certain the first such warning is coming from:
{code}
statistics
interval=10
minimum=0
destinationproxy.node.http.user_agent_xacts_per_second/destination
destination
scope=clusterproxy.cluster.http.user_agent_xacts_per_second/destination
expression
#proxy.process.http.incoming_requests *
$HRTIME_SECOND /
_DIFFTIME
/expression
/statistics
{code}
I haven't looked at all the others (like I said, there are quite a few of them).
Warnings from stats evaluation
--
Key: TS-1754
URL: https://issues.apache.org/jira/browse/TS-1754
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Fix For: 3.3.2
After 5bcc19e6, I'm seeing these warnings:
{code}
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
...
{code}
There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1755) add basic logstats tests
James Peach created TS-1755: --- Summary: add basic logstats tests Key: TS-1755 URL: https://issues.apache.org/jira/browse/TS-1755 Project: Traffic Server Issue Type: Test Components: Logging Reporter: James Peach traffic_logstats was broken for a while, but no-one noticed. We should add some basic tests so that we can make sure that it's basically working. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1755) add basic logstats tests
[ https://issues.apache.org/jira/browse/TS-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1755: Fix Version/s: 3.3.2 add basic logstats tests Key: TS-1755 URL: https://issues.apache.org/jira/browse/TS-1755 Project: Traffic Server Issue Type: Test Components: Logging Reporter: James Peach Fix For: 3.3.2 traffic_logstats was broken for a while, but no-one noticed. We should add some basic tests so that we can make sure that it's basically working. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1755) add basic logstats tests
[ https://issues.apache.org/jira/browse/TS-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605721#comment-13605721 ] James Peach commented on TS-1755: - I have a patch ... let's schedule this for 3.3.2. add basic logstats tests Key: TS-1755 URL: https://issues.apache.org/jira/browse/TS-1755 Project: Traffic Server Issue Type: Test Components: Logging Reporter: James Peach Fix For: 3.3.2 traffic_logstats was broken for a while, but no-one noticed. We should add some basic tests so that we can make sure that it's basically working. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1184) Additional whitespace in proxy.config.admin.user_id value results in error
[
https://issues.apache.org/jira/browse/TS-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1184:
--
Fix Version/s: (was: 3.3.3)
3.3.2
Additional whitespace in proxy.config.admin.user_id value results in error
--
Key: TS-1184
URL: https://issues.apache.org/jira/browse/TS-1184
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 3.0.4
Reporter: Kurt Payne
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 3.3.2
Config looked like this:
{noformat}
CONFIG proxy.config.alarm_email STRING nobody
{noformat}
The username had a trailing space. ATS fails to start, and the following
messages appear in {{/var/log/messages:}}
{noformat}
Apr 3 10:46:33 blitz traffic_cop[5498]: --- Cop Starting [Version: Apache
Traffic Server - traffic_cop - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:46)] ---
Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
user
Apr 3 10:46:33 blitz traffic_cop[5498]: can't get passwd entry for the admin
user
Apr 3 10:46:33 blitz traffic_cop[5498]: traffic_manager not running, making
sure traffic_server is dead
Apr 3 10:46:33 blitz traffic_cop[5498]: spawning traffic_manager
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: --- Manager Starting ---
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:03)
Apr 3 10:46:33 blitz traffic_manager[5500]: NOTE:
RLIMIT_NOFILE(7):cur(3),max(3)
Apr 3 10:46:33 blitz traffic_manager[5500]: {140630387636192} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
Apr 3 10:46:35 blitz traffic_server[5509]: NOTE: --- Server Starting ---
Apr 3 10:46:35 blitz traffic_server[5509]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.0.4 - (build # 3310 on Apr 3 2012 at
10:16:30)
Apr 3 10:46:35 blitz traffic_server[5509]: {47289782682464} STATUS: opened
/usr/local/var/log/trafficserver/diags.log
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1496) Traffic Server with null-transform buffering large responses when client connection slow
[
https://issues.apache.org/jira/browse/TS-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-1496:
Attachment: (was: ts-1496.diff)
Traffic Server with null-transform buffering large responses when client
connection slow
Key: TS-1496
URL: https://issues.apache.org/jira/browse/TS-1496
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.0
Environment: Red Hat 6.3
Reporter: snf
Assignee: Alan M. Carroll
Fix For: 3.3.4
Attachments: ts-1496.diff, TS-1496.patch, TS-1496.patch
Scenario: Traffic Server started with the null-transform plugin. The link
between the client and Traffic Server is slower than the link between the
Traffic Server and the Origin Server.
Affect: If the client requests a large file from the Origin Server, the
whole file can be transmitted to, and buffered by, Traffic Server before
content is released to the client. This is a bigger issue if a large number
of clients request large files then the Traffic Server could end up buffering
very large amounts of content.
Expected behaviour: The Traffic Server should not download all the content
from the Origin Server. Instead, if the client is slow receiving from
Traffic Server, then Traffic Server should be slow receiving from the Origin
Server. Traffic Server should facilitate end to end flow control between
client and Origin Server.
Tools to replicate problem: Use Traffic Control to set a lower bandwidth on
the client machine.
Possible related area in the Traffic Server code: The following comment
appears in proxy/http/Httptunnel.cc
48 static void
49 chunked_reenable(HttpTunnelProducer * p, HttpTunnel * tunnel)
50 {
51
52 // FIX ME: still need to deal with huge chunk sizes. If a chunk
53 // is 1GB, we will currently buffer the whole thing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1496) Traffic Server with null-transform buffering large responses when client connection slow
[
https://issues.apache.org/jira/browse/TS-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-1496:
Attachment: ts-1496.diff
Updated patch. Better handling in some extreme cases, tested against cache
reads (flow controls correctly in that case).
Traffic Server with null-transform buffering large responses when client
connection slow
Key: TS-1496
URL: https://issues.apache.org/jira/browse/TS-1496
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.0
Environment: Red Hat 6.3
Reporter: snf
Assignee: Alan M. Carroll
Fix For: 3.3.4
Attachments: ts-1496.diff, TS-1496.patch, TS-1496.patch
Scenario: Traffic Server started with the null-transform plugin. The link
between the client and Traffic Server is slower than the link between the
Traffic Server and the Origin Server.
Affect: If the client requests a large file from the Origin Server, the
whole file can be transmitted to, and buffered by, Traffic Server before
content is released to the client. This is a bigger issue if a large number
of clients request large files then the Traffic Server could end up buffering
very large amounts of content.
Expected behaviour: The Traffic Server should not download all the content
from the Origin Server. Instead, if the client is slow receiving from
Traffic Server, then Traffic Server should be slow receiving from the Origin
Server. Traffic Server should facilitate end to end flow control between
client and Origin Server.
Tools to replicate problem: Use Traffic Control to set a lower bandwidth on
the client machine.
Possible related area in the Traffic Server code: The following comment
appears in proxy/http/Httptunnel.cc
48 static void
49 chunked_reenable(HttpTunnelProducer * p, HttpTunnel * tunnel)
50 {
51
52 // FIX ME: still need to deal with huge chunk sizes. If a chunk
53 // is 1GB, we will currently buffer the whole thing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
[
https://issues.apache.org/jira/browse/TS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605972#comment-13605972
]
Leif Hedstrom commented on TS-1606:
---
Yahov Markovitch: Any thoughts on my comments ?
Log buffers are not flushed periodically when TS is launched with
NO_REMOTE_MANAGEMENT flag
---
Key: TS-1606
URL: https://issues.apache.org/jira/browse/TS-1606
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.3.0, 3.2.0
Reporter: Yakov Markovitch
Assignee: Leif Hedstrom
Fix For: 3.3.2
Attachments: trafficserver-periodic-tasks.patch
When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when
launched not as a daemon but directly - this is extremely convenient for
debugging), the PeriodicWakeup event is not scheduled.
As a result, Log::flush_thread_main() does not wake up periodically, but only
on log buffer overflow. Coupled with a horribly wrong activation check in
Log::flush_thread_main():
{code}
if (now last_time) {
if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
// We run only when waken up at the moment which is exact
// multiple of PERIODIC_TASKS_INTERVAL!
{code}
this leads to that probability of any log output is low.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-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.3.3)
Assignee: (was: Leif Hedstrom)
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
{{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
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: 3.5.0
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.5.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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1754) Warnings from stats evaluation
[
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13605996#comment-13605996
]
Leif Hedstrom commented on TS-1754:
---
{code}
(gdb) print *left
$1 = {m_arith_symbol = 0 '\000', m_token_name = 0x77010e80
proxy.process.http.incoming_requests, m_token_type = RECD_NULL, m_token_value
= {rec_int = 0, rec_float = 0, rec_string = 0x0, rec_counter = 0},
m_token_value_max = {rec_int = 0, rec_float = 0, rec_string = 0x0, rec_counter
= 0}, m_token_value_min = {rec_int = 0, rec_float = 0, rec_string = 0x0,
rec_counter = 0}, m_token_value_delta = 0x77010e50, m_sum_var = false,
m_node_var = true, link = {SLinkStatExprToken = {next = 0x0}, prev = 0x0}}
(gdb) print *right
$2 = {m_arith_symbol = 0 '\000', m_token_name = 0x771539c0
$HRTIME_SECOND, m_token_type = RECD_CONST, m_token_value = {rec_int =
1315859240, rec_float = 1e+09, rec_string = 0x4e6e6b28 Address 0x4e6e6b28 out
of bounds, rec_counter = 1315859240}, m_token_value_max = {rec_int = 0,
rec_float = 0, rec_string = 0x0, rec_counter = 0}, m_token_value_min = {rec_int
= 0, rec_float = 0, rec_string = 0x0, rec_counter = 0}, m_token_value_delta =
0x0, m_sum_var = false, m_node_var = true, link = {SLinkStatExprToken =
{next = 0x0}, prev = 0x0}}
{code}
Warnings from stats evaluation
--
Key: TS-1754
URL: https://issues.apache.org/jira/browse/TS-1754
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Fix For: 3.3.2
After 5bcc19e6, I'm seeing these warnings:
{code}
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
...
{code}
There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Deleted] (TS-1754) Warnings from stats evaluation
[
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1754:
--
Comment: was deleted
(was: {code}
(gdb) print *left
$1 = {m_arith_symbol = 0 '\000', m_token_name = 0x77010e80
proxy.process.http.incoming_requests, m_token_type = RECD_NULL, m_token_value
= {rec_int = 0, rec_float = 0, rec_string = 0x0, rec_counter = 0},
m_token_value_max = {rec_int = 0, rec_float = 0, rec_string = 0x0, rec_counter
= 0}, m_token_value_min = {rec_int = 0, rec_float = 0, rec_string = 0x0,
rec_counter = 0}, m_token_value_delta = 0x77010e50, m_sum_var = false,
m_node_var = true, link = {SLinkStatExprToken = {next = 0x0}, prev = 0x0}}
(gdb) print *right
$2 = {m_arith_symbol = 0 '\000', m_token_name = 0x771539c0
$HRTIME_SECOND, m_token_type = RECD_CONST, m_token_value = {rec_int =
1315859240, rec_float = 1e+09, rec_string = 0x4e6e6b28 Address 0x4e6e6b28 out
of bounds, rec_counter = 1315859240}, m_token_value_max = {rec_int = 0,
rec_float = 0, rec_string = 0x0, rec_counter = 0}, m_token_value_min = {rec_int
= 0, rec_float = 0, rec_string = 0x0, rec_counter = 0}, m_token_value_delta =
0x0, m_sum_var = false, m_node_var = true, link = {SLinkStatExprToken =
{next = 0x0}, prev = 0x0}}
{code}
)
Warnings from stats evaluation
--
Key: TS-1754
URL: https://issues.apache.org/jira/browse/TS-1754
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Fix For: 3.3.2
After 5bcc19e6, I'm seeing these warnings:
{code}
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
...
{code}
There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Deleted] (TS-1754) Warnings from stats evaluation
[
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1754:
--
Comment: was deleted
(was: I'm fairly certain the first such warning is coming from:
{code}
statistics
interval=10
minimum=0
destinationproxy.node.http.user_agent_xacts_per_second/destination
destination
scope=clusterproxy.cluster.http.user_agent_xacts_per_second/destination
expression
#proxy.process.http.incoming_requests *
$HRTIME_SECOND /
_DIFFTIME
/expression
/statistics
{code}
I haven't looked at all the others (like I said, there are quite a few of them).
)
Warnings from stats evaluation
--
Key: TS-1754
URL: https://issues.apache.org/jira/browse/TS-1754
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Fix For: 3.3.2
After 5bcc19e6, I'm seeing these warnings:
{code}
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
...
{code}
There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1754) Warnings from stats evaluation
[
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606004#comment-13606004
]
Leif Hedstrom commented on TS-1754:
---
{code}
$1 = {m_arith_symbol = 0 '\000', m_token_name = 0x7700fdc0
proxy.process.hostdb.total_hits, m_token_type = RECD_NULL, m_token_value =
{rec_int = 0, rec_float = 0, rec_string = 0x0, rec_counter = 0},
m_token_value_max = {rec_int = 0, rec_float = 0, rec_string = 0x0, rec_counter
= 0}, m_token_value_min = {rec_int = 0, rec_float = 0, rec_string = 0x0,
rec_counter = 0}, m_token_value_delta = 0x0, m_sum_var = false, m_node_var =
true, link = {SLinkStatExprToken = {next = 0x0}, prev = 0x0}}
(gdb) print *right
$2 = {m_arith_symbol = 0 '\000', m_token_name = 0x77010ee0
proxy.process.hostdb.total_lookups, m_token_type = RECD_NULL, m_token_value =
{rec_int = 0, rec_float = 0, rec_string = 0x0, rec_counter = 0},
m_token_value_max = {rec_int = 0, rec_float = 0, rec_string = 0x0, rec_counter
= 0}, m_token_value_min = {rec_int = 0, rec_float = 0, rec_string = 0x0,
rec_counter = 0}, m_token_value_delta = 0x0, m_sum_var = false, m_node_var =
true, link = {SLinkStatExprToken = {next = 0x0}, prev = 0x0}}
{code}
Warnings from stats evaluation
--
Key: TS-1754
URL: https://issues.apache.org/jira/browse/TS-1754
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Fix For: 3.3.2
After 5bcc19e6, I'm seeing these warnings:
{code}
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
...
{code}
There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1754) Warnings from stats evaluation
[
https://issues.apache.org/jira/browse/TS-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606068#comment-13606068
]
Yunkai Zhang commented on TS-1754:
--
The warning could be triggered when on startup, as the proxy.process.* stats
have not been initialized.
Maybe we can remove the warning, I'll go back to dig it more after a while.
Warnings from stats evaluation
--
Key: TS-1754
URL: https://issues.apache.org/jira/browse/TS-1754
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
Fix For: 3.3.2
After 5bcc19e6, I'm seeing these warnings:
{code}
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
[Mar 18 12:52:05.669] Manager {0x77b70840} WARNING: Both two token type
are RECD_NULL.
...
{code}
There are quite a few of them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1750) cpu usage (cluster thread) will more high when some machine being down
[ https://issues.apache.org/jira/browse/TS-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13606085#comment-13606085 ] ASF subversion and git services commented on TS-1750: - Commit 11bfc1e183ce61e6ce4de7936faff7478e3f8441 in branch refs/heads/master from [~kuotai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=11bfc1e ] TS-1750 lower cpu usage when ts can't cleanup resoure about down machine cpu usage (cluster thread) will more high when some machine being down -- Key: TS-1750 URL: https://issues.apache.org/jira/browse/TS-1750 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Attachments: TS-1750.patch when some machine being down, cluster thread will handle clean Event(ClusterHandler::protoZombieEvent). If some cluster_vc isn't close, so the clean Event will be rescheduled. now this delay is CLUSTER_RETRY(HRTIME_MSECONDS(10)). this delay is so frequent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1750) cpu usage (cluster thread) will more high when some machine being down
[ https://issues.apache.org/jira/browse/TS-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1750. Resolution: Fixed Fix Version/s: 3.3.2 cpu usage (cluster thread) will more high when some machine being down -- Key: TS-1750 URL: https://issues.apache.org/jira/browse/TS-1750 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: Bin Chen Assignee: Bin Chen Fix For: 3.3.2 Attachments: TS-1750.patch when some machine being down, cluster thread will handle clean Event(ClusterHandler::protoZombieEvent). If some cluster_vc isn't close, so the clean Event will be rescheduled. now this delay is CLUSTER_RETRY(HRTIME_MSECONDS(10)). this delay is so frequent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
