[jira] [Created] (TS-1189) Build problem on CentOS5
Build problem on CentOS5
Key: TS-1189
URL: https://issues.apache.org/jira/browse/TS-1189
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Critical
Fix For: 3.1.4
{code}
diff --git a/iocore/net/SSLNetVConnection.cc b/iocore/net/SSLNetVConnection.cc
index 33ebe64..0a41a08 100644
--- a/iocore/net/SSLNetVConnection.cc
+++ b/iocore/net/SSLNetVConnection.cc
@@ -673,9 +673,9 @@ SSLNetVConnection::registerNextProtocolSet(const
SSLNextProtocolSet * s)
}
int
-SSLNetVConnection::advertise_next_protocol(
-SSL *ssl, const unsigned char **out, unsigned int *outlen, void *arg)
+SSLNetVConnection::advertise_next_protocol(SSL *ssl, const unsigned char
**out, unsigned int *outlen, void *arg)
{
+#if TS_USE_TLS_NPN
SSLNetVConnection * netvc = (SSLNetVConnection *)SSL_get_app_data(ssl);
ink_release_assert(netvc != NULL);
@@ -686,4 +686,7 @@ SSLNetVConnection::advertise_next_protocol(
}
return SSL_TLSEXT_ERR_NOACK;
+#else
+ return 0;
+#endif
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1190) Change default for proxy.config.http.share_server_sessions
Change default for proxy.config.http.share_server_sessions -- Key: TS-1190 URL: https://issues.apache.org/jira/browse/TS-1190 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.4 We should enable session sharing with dedicated session pools per net-thread as the default. It has the best performance for a majority of our use cases. CONFIG proxy.config.http.share_server_sessions INT 2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1182) Add a flag to LogBuffer's for endian used
Add a flag to LogBuffer's for endian used - Key: TS-1182 URL: https://issues.apache.org/jira/browse/TS-1182 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Fix For: 3.3.0 After discussions with amc: To support reading logs (either via logcat or log collation) on a box with a different endian from where it was generated, we need to know which endian we generated the log in. Either that, or go back and do the htonl / ntohl conversions always. I favor the flag, since most sane platforms are little endian anyways (certainly all platforms we support are), so why take the cost of the conversions if they are rarely used. This would let us check the endian flag in e.g. the log collation server, and in logcat like tools, and do the conversions only when necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1175) The LogBuffer object is allocated with new (and deallocated with delete)
The LogBuffer object is allocated with new (and deallocated with delete) Key: TS-1175 URL: https://issues.apache.org/jira/browse/TS-1175 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Fix For: 3.3.0 We should at least use a class allocator for LogBuffer itself, and perhaps even its internal buffer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1176) Eliminate the delayed delete of LogBuffer
Eliminate the delayed delete of LogBuffer - Key: TS-1176 URL: https://issues.apache.org/jira/browse/TS-1176 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.4 There's a race condition in another place in the code, and it's obvious to me that this deferred delete was done to avoid this race condition. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1172) Remove remap/StringHash.{cc,h}
Remove remap/StringHash.{cc,h}
--
Key: TS-1172
URL: https://issues.apache.org/jira/browse/TS-1172
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.1.4
These files are not used, nuke.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1157) freelist for TSAPI's and plugin structs
freelist for TSAPI's and plugin structs - Key: TS-1157 URL: https://issues.apache.org/jira/browse/TS-1157 Project: Traffic Server Issue Type: New Feature Components: TS API Reporter: Leif Hedstrom Fix For: 3.3.0 It could be useful to expose a simple freelist APIs, which lets plugins allocate and free simple C structs on a freelist, instead of having to call TSmalloc / TSfree. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1156) Multiple time tags in a log format gets bad results
Multiple time tags in a log format gets bad results
-
Key: TS-1156
URL: https://issues.apache.org/jira/browse/TS-1156
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Fix For: 3.1.4
It seems putting two (or more) date time tags in a custom log generates bad
results. For example, with one such tag, I see:
{code}
[%cqtn]
[19/Mar/2012:14:30:51 -0600]
{code}
vs
{code}
[%cqts %cqtn]
[183876 07/Apr/2028:19:26:39 -0600]
{code}
This is obviously not the correct date now for either tags (the first is not
correct either). I'm guessing something in the marshalling code might be
corrupting the timestamp?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1150) Improve on some header handling functionality
Improve on some header handling functionality - Key: TS-1150 URL: https://issues.apache.org/jira/browse/TS-1150 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.4 There are a few performance and functionality improvements we can do around header handling. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1141) Server intercerpt performance problems.
Server intercerpt performance problems. --- Key: TS-1141 URL: https://issues.apache.org/jira/browse/TS-1141 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Fix For: 3.3.0 It seems server intercept plugins are fairly expensive. A very simple one, serving a few bytes out of RAM, can only do in the order of 20K QPS, whereas the same server serving out of RAM cache do wo 175k QPS. I know there will be overhead in plugin APIs, but almost 10x seems quite high. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1132) Clean up usage of HDR_BUF_RONLY_HEAPS
Clean up usage of HDR_BUF_RONLY_HEAPS - Key: TS-1132 URL: https://issues.apache.org/jira/browse/TS-1132 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Fix For: 3.1.4 We should clean up the usage of HDR_BUF_RONLY_HEAPS, and not assume it's always 3. In addition, we should consider making this configurable, via either records.config, or at least configure.ac. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1133) Make remap max-host length configure.ac configurable
Make remap max-host length configure.ac configurable Key: TS-1133 URL: https://issues.apache.org/jira/browse/TS-1133 Project: Traffic Server Issue Type: Improvement Components: Remap API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.3 Right now, we have a hardcoded limit of 256 bytes on the Host matching. We should make this configurable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1124) Move a few plugins into main repo.
Move a few plugins into main repo. -- Key: TS-1124 URL: https://issues.apache.org/jira/browse/TS-1124 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.3 Moving regex_remap, header_filter and stats_over_http into main git repo (in plugins). I've tried to preserve history, but it gets a little wonky due to the change in directory structure. But the history is there :). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1123) Problems building with editline/readline on OSX
Problems building with editline/readline on OSX --- Key: TS-1123 URL: https://issues.apache.org/jira/browse/TS-1123 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.3 There seems to be a conflict between editline and readline/history.h. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1116) Fix build issues with clang (particularly on OSX)
Fix build issues with clang (particularly on OSX) - Key: TS-1116 URL: https://issues.apache.org/jira/browse/TS-1116 Project: Traffic Server Issue Type: Improvement Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.3 We should get it to compile with clang again, specially since on OSX, clang is the 'future'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1115) Fix build issues with Intel ICC
Fix build issues with Intel ICC --- Key: TS-1115 URL: https://issues.apache.org/jira/browse/TS-1115 Project: Traffic Server Issue Type: Bug Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.3 Get it to compile cleanly, and run, with Intel ICC again. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1108) Allow to clear a particular cache volume
Allow to clear a particular cache volume -- Key: TS-1108 URL: https://issues.apache.org/jira/browse/TS-1108 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: Leif Hedstrom Today, you can clear the entire cache (either at startup, or via e.g. -Cclear_cache). This wipes the entire cache. For someone hosting a small number of sites, it might be reasonable to partition the cache (using volume.config and hosting.config), such that each site gets a fraction of the cache. In such a setup, it would also be reasonable (and usable) to be able to clear just a single volume (e..g -Cclear_cache_volume 1 or some such). Thoughts? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1106) redirect map generates multiple Via: header entries.
redirect map generates multiple Via: header entries.
Key: TS-1106
URL: https://issues.apache.org/jira/browse/TS-1106
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.2
Reporter: Leif Hedstrom
Fix For: 3.1.3
It seems using the redirect rule in remap.config, ends up duplicating the entry
in the Via: header, e.g.
{code}
Via: http/1.1 kramer.ogre.com (ApacheTrafficServer/3.1.3-unstable [u c s f p
eS:tNc i p s ]), http/1.1 kramer.ogre.com (ApacheTrafficServer/3.1.3-unstable
[u c s f p eS:tNc i p s ])
{code}
I'm not sure why this happens, if it's duplicating it, or if it's going through
the SM twice. I know i'm not proxying twice through the box.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1104) Build problem on solaris
Build problem on solaris
Key: TS-1104
URL: https://issues.apache.org/jira/browse/TS-1104
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.1.3
Reported and fixed by Igor Brezac
{code}
--- Store.cc.orig 2012-02-06 10:11:26.365180262 -0500
+++ Store.cc2012-02-06 10:11:56.035330329 -0500
@@ -629,7 +629,7 @@
blocks = size / STORE_BLOCK_SIZE;
file_pathname = !((s.st_mode S_IFMT) == S_IFDIR);
- Debug(cache_init, Span::init - %s hw_sector_size = %d size = %
PRId64 , blocks = % PRId64 , disk_id = %d, file_pathname = %d,
filename, hw_sector_size, size, blocks, disk_id, file_pathname);
+ Debug(cache_init, Span::init - %s hw_sector_size = % PRId64 ,
size = % PRId64 , blocks = % PRId64 , disk_id = %d, file_pathname
= %d, filename, hw_sector_size, size, blocks, disk_id,
file_pathname);
Lfail:
socketManager.close(fd);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1101) traffic_line -x doesn't seem to work
traffic_line -x doesn't seem to work Key: TS-1101 URL: https://issues.apache.org/jira/browse/TS-1101 Project: Traffic Server Issue Type: Bug Components: Management Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 traffic_line -x doesn't seem to work any more. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1098) Make RC script support Amazon EC2 Linux AMI
Make RC script support Amazon EC2 Linux AMI --- Key: TS-1098 URL: https://issues.apache.org/jira/browse/TS-1098 Project: Traffic Server Issue Type: Improvement Components: Packaging Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.2 Add support to detect the Amazon Linux flavor of RHEL/CentOS that runs in the default AMIs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1080) Assert under heavy load with logging enabled
Assert under heavy load with logging enabled
Key: TS-1080
URL: https://issues.apache.org/jira/browse/TS-1080
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Priority: Critical
Fix For: 3.1.2
Given enough load (in the 100,000 QPS or more), we run out of some sort of
buffer space, with an assert of
{code}
#0 0x2ba719d50285 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x2ba719d51b9b in __GI_abort () at abort.c:91
#2 0x006b561a in ink_die_die_die (retval=optimized out) at
ink_error.cc:43
#3 ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *)
(return_code=optimized out, message_format=optimized out,
ap=0x7fff7275a7d8) at ink_error.cc:65
#4 0x006b56a7 in ink_fatal (return_code=optimized out,
message_format=optimized out) at ink_error.cc:73
#5 0x006b4970 in _ink_assert (a=0x6fd380
_num_flush_buffers[_open_flush_array] FLUSH_ARRAY_SIZE, f=optimized out,
l=96) at ink_assert.cc:44
#6 0x005a8b34 in add_to_flush_queue (buffer=0x2ba7443ca970,
this=0x22fb918) at LogObject.h:96
#7 LogObject::_checkout_write (this=0x22fb880, write_offset=0x7fff7275add8,
bytes_needed=152) at LogObject.cc:455
#8 0x005a8fd3 in LogObject::log (this=0x22fb880, lad=0x7fff7275b030,
text_entry=0x0) at LogObject.cc:580
#9 0x0058e956 in log (lad=0x7fff7275b030, this=optimized out) at
LogObject.h:475
#10 Log::access (lad=0x7fff7275b030) at Log.cc:1086
{code}
Increasing FLUSH_ARRAY_SIZE alleviates the problem, but really, we shouldn't
end up in this situation at all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1081) Eliminate the additional internal copy of the pristine URL string
Eliminate the additional internal copy of the pristine URL string --- Key: TS-1081 URL: https://issues.apache.org/jira/browse/TS-1081 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.2 We have (at least) two copies of the pristine URL in the code. One is the actual URL object (as used by the APIs), and one is a string reference to the URL (char*). The latter is only used in a couple of places, primarily when the cquuc tag is used in a custom log format. I propose that we eliminate this additional string version of the pristine URL entirely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1067) Remove unused config (and code) for bandwidth management
Remove unused config (and code) for bandwidth management Key: TS-1067 URL: https://issues.apache.org/jira/browse/TS-1067 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.2 There's a configuration file, and code, related to bandwidth management for the old UDP based streaming media protocols, that were part of the core (it's long since gone). We should remove this for now, and possibly (for future plugins) add APIs appropriate for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1056) Lost UA connections can show up as 400 ERR_INVALID_REQ in logs
Lost UA connections can show up as 400 ERR_INVALID_REQ in logs
Key: TS-1056
URL: https://issues.apache.org/jira/browse/TS-1056
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Leif Hedstrom
Fix For: 3.1.2
So, it seems that with Firefox (it's the only one I've been able to reproduce
this with), we can end up getting a bunch of errors like
{code}
1324075013.826 0 216.239.45.4 ERR_INVALID_REQ/400 217 - / - NONE/- text/html -
{code}
Tracking this down, it seems the HTTP SM is getting a VC_EVENT_EOS (stream
closed) in state_read_client_request_header(). However, there is nothing in the
request_header (zero bytes), so when it tries to parse the (empty) request
header, it looks like a request error.
I'm not certain, yet at least, under what conditions we get this event (I'm
fairly certain that Firefox is somehow closing down the connection in some
weird state to us?). So, I'm suggesting we at least deal with this situation
earlier (before trying to parse the headers), which will instead cause an
UNKNOWN_ERROR (since we have no request nor response code. Suggested changes
attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1036) Improve squid log compatibility
Improve squid log compatibility Key: TS-1036 URL: https://issues.apache.org/jira/browse/TS-1036 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom See https://github.com/mnot/squidpeek/commit/3874cb902f257974d16c8eae5fc5a77c6fafbf69 for some differences, from mnot as well: all of the ERR_* ones squid does TCP_REFRESH_FAIL_HIT, you do TCP_REF_FAIL_HIT squid does TCP_CLIENT_REFRESH_MISS, you do TCP_CLIENT_REFRESH squid does TCP_SWAPFAIL_MISS, you do TCP_SWAPFAIL -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1033) Add some missing WKS's to HdrToken.
Add some missing WKS's to HdrToken. - Key: TS-1033 URL: https://issues.apache.org/jira/browse/TS-1033 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.2 And of course various other places (including InkAPI). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1028) Assert when enabling shared origin connections with a setting of 2
Assert when enabling shared origin connections with a setting of 2 -- Key: TS-1028 URL: https://issues.apache.org/jira/browse/TS-1028 Project: Traffic Server Issue Type: Bug Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.2 When you enable the 2 setting for sharing origin connections (which creates a connection pool per net-thread), we trigger an assert in Debug builds. I think it only triggers too with logging enabled, but not certain. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1012) Eliminate proxy.config.http.append_xforwards_header
Eliminate proxy.config.http.append_xforwards_header --- Key: TS-1012 URL: https://issues.apache.org/jira/browse/TS-1012 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.1 Attachments: TS-1012.diff The configuration proxy.config.http.append_xforwards_header is never used, instead we have proxy.config.http.insert_squid_x_forwarded_for. To avoid confusion, lets remove the (unused) append_xforwards_header configuration. We could argue that the first one is better named, but insert_squid_x_forwarded_for has been the setting to use since incubation, so lets not break everything, right ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1009) Don't start the ICP processor if ICP is disabled
Don't start the ICP processor if ICP is disabled Key: TS-1009 URL: https://issues.apache.org/jira/browse/TS-1009 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.1 If icp.enabled is 0, does it really make sense to still fire up the ICP processor? I'm suggesting we change this so that when disabled, we don't even start it up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-999) Deprecate TSUrlDestroy ?
Deprecate TSUrlDestroy ? Key: TS-999 URL: https://issues.apache.org/jira/browse/TS-999 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Fix For: 3.1.2 This API is a complete no-op as of quite a while ago. Should we just deprecate it? Or, does anyone foresee a future where we actually need to call TSUrlDestroy? Alan? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1000) Improve Remap plugin instantiation to send the parse From and To URL
Improve Remap plugin instantiation to send the parse From and To URL -- Key: TS-1000 URL: https://issues.apache.org/jira/browse/TS-1000 Project: Traffic Server Issue Type: New Feature Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Right now, when you instantiate a remap plugin (via TSRemapNewInstance), you always get the following parameters argv[0] == The FromURL from remap.config, as a string argv[1] == The ToURL from remap.config, as a string Even though this might be useful, it would be much more useful to also have the actual parsed URL objects passed to the instantiator. In fact, the strings for the above are simply created upon plugin instantiation, e.g. err = mp-fromURL.string_get(NULL)) I'm not sure how we can accomplish this without breaking the APIs. Well, without breaking the APIs, we'd have to create a new entry point for plugins to use, e.g. TSRemapNewInstanceWithUrls() which adds the from and to URLs as arguments. I'd then argue that argv[0] and argv[1] should not be populated, i.e. make it up to the plugin implementor if he wants to call the string_get() or not. Thoughts? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-985) ts/ts.h uses C++ comments, which are technically not C
ts/ts.h uses C++ comments, which are technically not C -- Key: TS-985 URL: https://issues.apache.org/jira/browse/TS-985 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.1 So, replace // with /* */ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-986) ts/experimental has a dependency on netinet/net.h (for struct in_addr)
ts/experimental has a dependency on netinet/net.h (for struct in_addr) -- Key: TS-986 URL: https://issues.apache.org/jira/browse/TS-986 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Fix For: 3.1.2 Alan seems to indicate this is wrong anyways, but just adding this bug so we remember it's probably a bad idea. The offending API is tsapi int TSNodeHandleToIPAddr(TSNodeHandle_t *h, struct in_addr *in); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-979) Some changes to stats pages can segfault the server
Some changes to stats pages can segfault the server --- Key: TS-979 URL: https://issues.apache.org/jira/browse/TS-979 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.1 Found a few places where we can segfault. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
