[jira] [Commented] (TS-1130) ink_time_t is 64bit on x86_64
[ https://issues.apache.org/jira/browse/TS-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257996#comment-13257996 ] Leif Hedstrom commented on TS-1130: --- Looks good to me. I couldn't see any other places where we use the atomic CAS on an ink_time_t, so this should be fine. Wei Jin, I'd say commit it! (Assuming you've tested it). ink_time_t is 64bit on x86_64 - Key: TS-1130 URL: https://issues.apache.org/jira/browse/TS-1130 Project: Traffic Server Issue Type: Sub-task Components: Core Reporter: Zhao Yongming Assignee: weijin Fix For: 3.1.4 Attachments: TS-1130.diff Weijin: paste your patch here, :D -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1202) install traffic_shell man/doc pages in a more appropriate location
[ https://issues.apache.org/jira/browse/TS-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255935#comment-13255935 ] Leif Hedstrom commented on TS-1202: --- Yeah, I agree with Arno, why does the cache have to move? install traffic_shell man/doc pages in a more appropriate location -- Key: TS-1202 URL: https://issues.apache.org/jira/browse/TS-1202 Project: Traffic Server Issue Type: Improvement Affects Versions: 3.1.4 Reporter: Igor Brezac Assignee: Igor Galić Priority: Minor Fix For: 3.1.4 Attachments: doc.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1200) DOAP file reference incorrect
[
https://issues.apache.org/jira/browse/TS-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251682#comment-13251682
]
Leif Hedstrom commented on TS-1200:
---
{code}
Index: files.xml
===
--- files.xml (revision 1324820)
+++ files.xml (working copy)
@@ -143,7 +143,7 @@
locationhttp://svn.apache.org/repos/asf/tiles/site/doap_Tiles.rdf/location
locationhttp://svn.apache.org/repos/asf/tomcat/site/trunk/docs/doap_Tomcat.rdf/location
locationhttp://svn.apache.org/repos/asf/tomcat/taglibs/rdc/trunk/doap_rdc.rdf/location
-
locationhttp://svn.apache.org/repos/asf/trafficserver/traffic/trunk/doc/doap.rdf/location
+
locationhttps://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blob_plain;f=doc/doap.rdf;hb=HEAD/location
locationhttp://svn.apache.org/repos/asf/turbine/site/doap/doap_Turbine.rdf/location
locationhttp://svn.apache.org/repos/asf/uima/site/trunk/uima-website/docs/doap/uima.rdf/location
locationhttp://svn.apache.org/repos/asf/velocity/site/site/doap_anakia.rdf/location
{code}
Is that the correct URL to use for the git repo?
DOAP file reference incorrect
-
Key: TS-1200
URL: https://issues.apache.org/jira/browse/TS-1200
Project: Traffic Server
Issue Type: Bug
Reporter: Sebb
Assignee: Leif Hedstrom
Priority: Critical
The DOAP file for the project needs to be available for the projects.a.o
website to function correctly.
Currently the build is looking for
http://svn.apache.org/repos/asf/trafficserver/traffic/trunk/doc/doap.rdf
However this does not exist, so the build is reporting an error.
Please update the file
https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml
with the new location ASAP.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1200) DOAP file reference incorrect
[ https://issues.apache.org/jira/browse/TS-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251701#comment-13251701 ] Leif Hedstrom commented on TS-1200: --- I committed the above, except, using http:// . Let me know if this is what you expected or not. Thanks! DOAP file reference incorrect - Key: TS-1200 URL: https://issues.apache.org/jira/browse/TS-1200 Project: Traffic Server Issue Type: Bug Reporter: Sebb Assignee: Leif Hedstrom Priority: Critical The DOAP file for the project needs to be available for the projects.a.o website to function correctly. Currently the build is looking for http://svn.apache.org/repos/asf/trafficserver/traffic/trunk/doc/doap.rdf However this does not exist, so the build is reporting an error. Please update the file https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml with the new location ASAP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1200) DOAP file reference incorrect
[ https://issues.apache.org/jira/browse/TS-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252103#comment-13252103 ] Leif Hedstrom commented on TS-1200: --- Fwiw, the content as served by the git HTTP server / URL is chunked encoded. So it sounds like your script does not deal with that (which is bad mojo honestly, you could break for any number of reasons, since chunking is part of the HTTP/1.1 standard). bb2 is hex for the content length, and 0 is the end of the last chunk. I'm not sure why it would be duplicated though, I can not see that. To simulate what your client does, try e.g. curl -s --raw 'http://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blob_plain;f=doc/doap.rdf;hb=HEAD' I hope that helps. DOAP file reference incorrect - Key: TS-1200 URL: https://issues.apache.org/jira/browse/TS-1200 Project: Traffic Server Issue Type: Bug Reporter: Sebb Assignee: Igor Galić Priority: Critical The DOAP file for the project needs to be available for the projects.a.o website to function correctly. Currently the build is looking for http://svn.apache.org/repos/asf/trafficserver/traffic/trunk/doc/doap.rdf However this does not exist, so the build is reporting an error. Please update the file https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml with the new location ASAP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1185) fails to build from source with gcc 4.7
[
https://issues.apache.org/jira/browse/TS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251234#comment-13251234
]
Leif Hedstrom commented on TS-1185:
---
I installed Fedora Core 17, with gcc-4.7, and it builds without problem Any
more details you can share? Special configure options, compiler options,
platform (32-bit vs 64-bit etc.).
It seems the fixes ought to be trivial, but it'd be nice to be able to
reproduce it.
fails to build from source with gcc 4.7
---
Key: TS-1185
URL: https://issues.apache.org/jira/browse/TS-1185
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.3, 3.0.4
Environment: Debian Unstable with gcc 4.7
Reporter: Arno Toell
Assignee: Leif Hedstrom
Fix For: 3.1.4
Using gcc 4.7, ATS fails to build from source. See Debian bug 667396
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667396) for further
information. gcc 4.7 fails with
{code}
g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem
-I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb
-I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils
-I../../iocore/dns -I../../proxy -I../../lib/records -I../../mgmt
-I../../mgmt/preparse -I../../mgmt/utils -I../../proxy/hdrs
-I../../proxy/http/remap -I../../proxy/logging -D_FORTIFY_SOURCE=2
-D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT
-Dlinux -I/usr/include/tcl8.5 -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
-pipe -Wall -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof -MT HttpClientSession.o -MD -MP -MF
.deps/HttpClientSession.Tpo -c -o HttpClientSession.o HttpClientSession.cc
In file included from ../../lib/ts/libts.h:96:0,
from HttpClientSession.h:35,
from HttpClientSession.cc:35:
../../lib/ts/Map.h: In instantiation of 'C MapK, C, A::get(K) [with K =
unsigned int; C = int; A = DefaultAlloc]':
HttpConnectionCount.h:51:34: required from here
../../lib/ts/Map.h:240:29: error: 'set_in' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:240:29: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:240:29: note: use 'this-set_in' instead
../../lib/ts/Map.h: In instantiation of 'MapElemK, C* MapK, C, A::put(K,
C) [with K = unsigned int; C = int; A = DefaultAlloc]':
HttpConnectionCount.h:64:37: required from here
../../lib/ts/Map.h:258:29: error: 'set_in' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:258:29: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:258:29: note: use 'this-set_in' instead
../../lib/ts/Map.h:263:21: error: 'set_add' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:263:21: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:263:21: note: use 'this-set_add' instead
make[4]: *** [HttpClientSession.o] Error 1
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1185) fails to build from source with gcc 4.7
[
https://issues.apache.org/jira/browse/TS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251237#comment-13251237
]
Leif Hedstrom commented on TS-1185:
---
Eh, I checked the code, and this was changed by Igor in February:
commit fe1da80b94d368343174ada8b137a0c4ae1c387e
Author: Igor Galić iga...@apache.org
Commit: Igor Galić iga...@apache.org
TS-1116 fix clang warnings and errors, especially with make check
Are you sure this is still a problem on trunk?
fails to build from source with gcc 4.7
---
Key: TS-1185
URL: https://issues.apache.org/jira/browse/TS-1185
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.3, 3.0.4
Environment: Debian Unstable with gcc 4.7
Reporter: Arno Toell
Assignee: Leif Hedstrom
Fix For: 3.1.4
Using gcc 4.7, ATS fails to build from source. See Debian bug 667396
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667396) for further
information. gcc 4.7 fails with
{code}
g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem
-I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb
-I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils
-I../../iocore/dns -I../../proxy -I../../lib/records -I../../mgmt
-I../../mgmt/preparse -I../../mgmt/utils -I../../proxy/hdrs
-I../../proxy/http/remap -I../../proxy/logging -D_FORTIFY_SOURCE=2
-D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT
-Dlinux -I/usr/include/tcl8.5 -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security
-pipe -Wall -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof -MT HttpClientSession.o -MD -MP -MF
.deps/HttpClientSession.Tpo -c -o HttpClientSession.o HttpClientSession.cc
In file included from ../../lib/ts/libts.h:96:0,
from HttpClientSession.h:35,
from HttpClientSession.cc:35:
../../lib/ts/Map.h: In instantiation of 'C MapK, C, A::get(K) [with K =
unsigned int; C = int; A = DefaultAlloc]':
HttpConnectionCount.h:51:34: required from here
../../lib/ts/Map.h:240:29: error: 'set_in' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:240:29: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:240:29: note: use 'this-set_in' instead
../../lib/ts/Map.h: In instantiation of 'MapElemK, C* MapK, C, A::put(K,
C) [with K = unsigned int; C = int; A = DefaultAlloc]':
HttpConnectionCount.h:64:37: required from here
../../lib/ts/Map.h:258:29: error: 'set_in' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:258:29: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:258:29: note: use 'this-set_in' instead
../../lib/ts/Map.h:263:21: error: 'set_add' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../../lib/ts/Map.h:263:21: note: declarations in dependent base
'VecMapElemunsigned int, int, DefaultAlloc, 2' are not found by
unqualified lookup
../../lib/ts/Map.h:263:21: note: use 'this-set_add' instead
make[4]: *** [HttpClientSession.o] Error 1
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1193) Traffic Server building on OpenBSD
[ https://issues.apache.org/jira/browse/TS-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249836#comment-13249836 ] Leif Hedstrom commented on TS-1193: --- There was at least one other bug related to building on OpenBSD,so please make sure we don't have duplications. Traffic Server building on OpenBSD -- Key: TS-1193 URL: https://issues.apache.org/jira/browse/TS-1193 Project: Traffic Server Issue Type: Improvement Affects Versions: 3.1.3 Reporter: Brian Geffon Assignee: Brian Geffon This is a parent issue for the task of getting traffic server building on OpenBSD. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1193) Traffic Server building on OpenBSD
[ https://issues.apache.org/jira/browse/TS-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249837#comment-13249837 ] Leif Hedstrom commented on TS-1193: --- Also, please mark bugs with a fix version, to avoid flooding the bucket of untargeted bugs :). Traffic Server building on OpenBSD -- Key: TS-1193 URL: https://issues.apache.org/jira/browse/TS-1193 Project: Traffic Server Issue Type: Improvement Affects Versions: 3.1.3 Reporter: Brian Geffon Assignee: Brian Geffon This is a parent issue for the task of getting traffic server building on OpenBSD. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1187) TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server)
[ https://issues.apache.org/jira/browse/TS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250159#comment-13250159 ] Leif Hedstrom commented on TS-1187: --- Not sure I follow here, can you show some code example that doesn't work ? I'm assuming you are setting the appropriate header buffer? Remember there are four different headers, some of which are not available in all hooks. I'm going to move this out to 3.3.0, unless you feel it's a bug that needs to be fixed for 3.2. TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) - Key: TS-1187 URL: https://issues.apache.org/jira/browse/TS-1187 Project: Traffic Server Issue Type: Bug Components: MIME Affects Versions: 3.0.2 Environment: Redhat linux with plugin that wants to rename a header read from the client. Reporter: Alistair Stevenson Labels: api-change Fix For: 3.1.4 TSMimeHdrFieldNameSet does not work for headers read from the client or origin server (but does work for headers added by traffic server) The name appears set (and the function returns SUCCESS) but when the data is sent to the origin Server it is corrupted at the point where the header is set. i.e the header name is sent but the header is corrupted after this. I am having to create a new header and copy the values and then destroy the original header which is not as efficient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1130) ink_time_t is 64bit on x86_64
[ https://issues.apache.org/jira/browse/TS-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250221#comment-13250221 ] Leif Hedstrom commented on TS-1130: --- yes, where's the patch? :) ink_time_t is 64bit on x86_64 - Key: TS-1130 URL: https://issues.apache.org/jira/browse/TS-1130 Project: Traffic Server Issue Type: Sub-task Components: Core Reporter: Zhao Yongming Assignee: weijin Fix For: 3.1.4 Weijin: paste your patch here, :D -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249594#comment-13249594 ] Leif Hedstrom commented on TS-1079: --- Igor: I would stay away from stdbool for now honestly. Plus, making one API use bool and everything else use int is poor interface design. I'm totally fine revisiting this for v4.0, and do another round of (large) API improvements and changes. Add an API function to turn debugging on for specific transactions/sessions --- Key: TS-1079 URL: https://issues.apache.org/jira/browse/TS-1079 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Attachments: debug_specific.patch, debug_specific_2.patch, debug_specific_3.patch, debug_specific_4.patch Original Estimate: 72h Remaining Estimate: 72h When attempting to troubleshoot issues on a production ATS system, it is often impossible/difficult to turn on any of the 'high-volume' debug tags like http due to the performance impact. This enhancement allows a plugin to set a debug flag for a specific txn/ssn, and replaces some of the internal Debug calls with a new function that checks if the flag is turned on, and outputs the debug line regardless of the tag if it is (The diags enable/disable flag is still taken into account). The API will also have TSDebugSpecific in order to allow plugins to use the same functionality. In addition, we might consider adding an internal config file (remap-like) to allow turning this flag on without plugin intervention. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248161#comment-13248161 ] Leif Hedstrom commented on TS-1079: --- If I understand the original design correctly, the idea was that DebugSpecific() would work just like the old Debug() when not being specific. But when enabled e.g. in a transaction or session, it would override the global defaults. So when the flag is true, it will always print the debug info, but when false it depends on whatever the global diags flag is. The public TSDebugSpecific() API follows the same pattern as the core version I assume. Meaning, a plugin can now call TSDebugSpecific() in a way that it uses the global diagnostics settings when false, but forcing the Debug() when true. This seems generally useful to me. Add an API function to turn debugging on for specific transactions/sessions --- Key: TS-1079 URL: https://issues.apache.org/jira/browse/TS-1079 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Attachments: debug_specific.patch, debug_specific_2.patch, debug_specific_3.patch, debug_specific_4.patch Original Estimate: 72h Remaining Estimate: 72h When attempting to troubleshoot issues on a production ATS system, it is often impossible/difficult to turn on any of the 'high-volume' debug tags like http due to the performance impact. This enhancement allows a plugin to set a debug flag for a specific txn/ssn, and replaces some of the internal Debug calls with a new function that checks if the flag is turned on, and outputs the debug line regardless of the tag if it is (The diags enable/disable flag is still taken into account). The API will also have TSDebugSpecific in order to allow plugins to use the same functionality. In addition, we might consider adding an internal config file (remap-like) to allow turning this flag on without plugin intervention. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1189) Build problem on CentOS5
[
https://issues.apache.org/jira/browse/TS-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247744#comment-13247744
]
Leif Hedstrom commented on TS-1189:
---
Reported to me by Christopher Eckhardt.
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] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241886#comment-13241886 ] Leif Hedstrom commented on TS-1079: --- Is the last patch missing a ts/ts.h.in change set? Also, what are the expectations on performance here? Add an API function to turn debugging on for specific transactions/sessions --- Key: TS-1079 URL: https://issues.apache.org/jira/browse/TS-1079 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Attachments: debug_specific.patch, debug_specific_2.patch, debug_specific_3.patch Original Estimate: 72h Remaining Estimate: 72h When attempting to troubleshoot issues on a production ATS system, it is often impossible/difficult to turn on any of the 'high-volume' debug tags like http due to the performance impact. This enhancement allows a plugin to set a debug flag for a specific txn/ssn, and replaces some of the internal Debug calls with a new function that checks if the flag is turned on, and outputs the debug line regardless of the tag if it is (The diags enable/disable flag is still taken into account). The API will also have TSDebugSpecific in order to allow plugins to use the same functionality. In addition, we might consider adding an internal config file (remap-like) to allow turning this flag on without plugin intervention. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241974#comment-13241974 ] Leif Hedstrom commented on TS-1079: --- Fwiw, I measure about 4% slowdown or so. Add an API function to turn debugging on for specific transactions/sessions --- Key: TS-1079 URL: https://issues.apache.org/jira/browse/TS-1079 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Attachments: debug_specific.patch, debug_specific_2.patch, debug_specific_3.patch Original Estimate: 72h Remaining Estimate: 72h When attempting to troubleshoot issues on a production ATS system, it is often impossible/difficult to turn on any of the 'high-volume' debug tags like http due to the performance impact. This enhancement allows a plugin to set a debug flag for a specific txn/ssn, and replaces some of the internal Debug calls with a new function that checks if the flag is turned on, and outputs the debug line regardless of the tag if it is (The diags enable/disable flag is still taken into account). The API will also have TSDebugSpecific in order to allow plugins to use the same functionality. In addition, we might consider adding an internal config file (remap-like) to allow turning this flag on without plugin intervention. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-561) Origin-server side IPv6 support
[ https://issues.apache.org/jira/browse/TS-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239734#comment-13239734 ] Leif Hedstrom commented on TS-561: -- What's the status here, is this done in another bug? If so, please close as a duplicate. Origin-server side IPv6 support --- Key: TS-561 URL: https://issues.apache.org/jira/browse/TS-561 Project: Traffic Server Issue Type: New Feature Components: Network Environment: Linux 4.x Reporter: Anirban Roy Assignee: Alan M. Carroll Fix For: 3.1.5 raffic Server used as forward proxy in a number of places including web crawling and feed fetching applications. In those applications, (origin)server side IPv6 support is desirable. As the Internet running out of IPv4 addresses, the new sites will run on IPv6 stack. The applications pulling content using traffic server should be able to do so in the changing scenario. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1163) Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux
[ https://issues.apache.org/jira/browse/TS-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240026#comment-13240026 ] Leif Hedstrom commented on TS-1163: --- Will you land this already :P Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux -- Key: TS-1163 URL: https://issues.apache.org/jira/browse/TS-1163 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: B Wyatt Assignee: B Wyatt Fix For: 3.1.4 Attachments: blkgetsize64.bwyatt.patch Due to 32bit integers in both the trafficersever code and the ioctl used to determine raw disk size, the number of sectors reported to the cache storage system is bound to 0-0x. If a disk has 512 byte sectors and is larger than 2TB it will report (num_sectors % 0x) * 512 bytes avaliable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1106) redirect map generates multiple Via: header entries.
[
https://issues.apache.org/jira/browse/TS-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240041#comment-13240041
]
Leif Hedstrom commented on TS-1106:
---
It's actually kinda weird, sending a request shows this from the tracers on
http_hdrs:
{code}
+ Proxy's Response 2 +
-- State Machine Id: 0
HTTP/1.1 404 Not Found on Accelerator
Date: Tue, 27 Mar 2012 23:03:47 GMT
Connection: close
Via: http/1.1 loki.ogre.com (ApacheTrafficServer/3.1.4-unstable [u c s f p
eS:tNc i p s ])
Server: ATS/3.1.4-unstable
+ Proxy's Response 2 +
-- State Machine Id: 0
HTTP/1.1 301 Redirect
Date: Tue, 27 Mar 2012 23:03:47 GMT
Via: http/1.1 loki.ogre.com (ApacheTrafficServer/3.1.4-unstable [u c s f p
eS:tNc i p s ]), http/1.1 loki.ogre.com (ApacheTrafficServer/3.1.4-unstable [u
c s f p eS:tNc i p s ])
Server: ATS/3.1.4-unstable
Cache-Control: no-store
Content-Type: text/html
Content-Language: en
Connection: close
{code}
redirect map generates multiple Via: header entries.
Key: TS-1106
URL: https://issues.apache.org/jira/browse/TS-1106
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.2
Reporter: Leif Hedstrom
Fix For: 3.1.4
It seems using the redirect rule in remap.config, ends up duplicating the
entry in the Via: header, e.g.
{code}
Via: http/1.1 kramer.ogre.com (ApacheTrafficServer/3.1.3-unstable [u c s f p
eS:tNc i p s ]), http/1.1 kramer.ogre.com
(ApacheTrafficServer/3.1.3-unstable [u c s f p eS:tNc i p s ])
{code}
I'm not sure why this happens, if it's duplicating it, or if it's going
through the SM twice. I know i'm not proxying twice through the box.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-981) ATS as transparent proxy crashes under heavy load
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240096#comment-13240096 ] Leif Hedstrom commented on TS-981: -- I'll check with John, but I think we should just remove libev entirely from the source. ATS as transparent proxy crashes under heavy load - Key: TS-981 URL: https://issues.apache.org/jira/browse/TS-981 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.0 Environment: 4 core desktop. Centos 5.6, kernel 2.6.39.2 compiled with TPROXY support. ATS compiled as: ./configure --enable-tproxy --enable-libev Reporter: Danny Shporer Assignee: Leif Hedstrom Priority: Critical Fix For: 3.1.4 Attachments: records.config ATS crashes under heavy load testing - around 25,000 HTTP transactions per second. I have tested it on both vesions 3.0.0 and 3.0.1 and the same happens. GDB info: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42174940 (LWP 6663)] 0x0068fd4b in modify (this=0x2b12c628, event=value optimized out, e=value optimized out) at P_UnixNet.h:536 536 fd_change(event_loop-eio, eio.fd, 0); (gdb) bt #0 0x0068fd4b in modify (this=0x2b12c628, event=value optimized out, e=value optimized out) at P_UnixNet.h:536 #1 NetHandler::mainNetEvent (this=0x2b12c628, event=value optimized out, e=value optimized out) at UnixNet.cc:432 #2 0x006bfc4f in EThread::process_event (this=0x2b12b010, e=0xf44570, calling_code=5) at I_Continuation.h:146 #3 0x006c055c in EThread::execute (this=0x2b12b010) at UnixEThread.cc:262 #4 0x006bef8e in spawn_thread_internal (a=0xf35c90) at Thread.cc:88 #5 0x003e9dc0673d in start_thread () from /lib64/libpthread.so.0 #6 0x003e9d0d44bd in clone () from /lib64/libc.so.6 (gdb) info f Stack level 0, frame at 0x42174030: rip = 0x68fd4b in modify (P_UnixNet.h:536); saved rip 0x6bfc4f inlined into frame 1 source language c++. Arglist at unknown address. Locals at unknown address, Previous frame's sp in rsp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1161) insafe raw device in storage.config
[ https://issues.apache.org/jira/browse/TS-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13235647#comment-13235647 ] Leif Hedstrom commented on TS-1161: --- Yeah, don't use e.g. /dev/sda. Use /dev/disk/by-uuid/... or /dev/disk/by-path/... or some such, and make sure you get it right. :) I guess we could try to detect if a disk is in use, I don't know if there are any portable and reliable ways to detect that (but, I haven't looked). It's not as easy as looking via mount etc., you have to take into account various other disk managers, such as LLVM, or even just the software raid layers. insafe raw device in storage.config --- Key: TS-1161 URL: https://issues.apache.org/jira/browse/TS-1161 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Zhao Yongming if you system is on /dev/sda and you put /dev/sda into storage.config, TS will destroy the data on /dev/sda without any hesitate. this is proved to be true, please do not try, trust me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1152) http_ui error,when i get http://localhost/cache/
[
https://issues.apache.org/jira/browse/TS-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233406#comment-13233406
]
Leif Hedstrom commented on TS-1152:
---
Yes, the WebUI itself is dead and gone (and it won't be missed). What's
somewhat confusing (and part of what makes it difficult to remove all remnants
of the UI), is that the setting also controls various internal stats pages.
To enable stats pages (e.g. the cache inspector), you should set records.config
to e.g.
{code}
CONFIG proxy.config.http_ui_enabled INT 3
{code}
This should be properly documented I'm fairly certain ;). With this, you can
now add remap rules (probably with specific ACLs), to add support for the
various stats pages. E.g.
{code}
map https://www.ogre.com/__pimp_my_cache/ http://{cache}/ @src_ip=192.168.1.1
@action=allow
{code}
I'm not sure why we get those errors and warnings above though, we should keep
this bug open, and fix that (assuming they show up with just the setting above).
http_ui error,when i get http://localhost/cache/
Key: TS-1152
URL: https://issues.apache.org/jira/browse/TS-1152
Project: Traffic Server
Issue Type: Bug
Components: Web UI
Affects Versions: 3.0.4
Environment: centos 6 x86_64
Reporter: bettydramit
When i enable http_ui ，I got follow error (get http://xxx.xxx.xxx.xxx/cache/)
[Mar 19 16:46:17.778] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:17.778] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:46:19.089] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:19.090] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:46:20.763] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 16:46:20.763] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 16:58:21.906] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /robots.txt not valid autoconf file
[Mar 19 16:58:21.906] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
[Mar 19 17:01:43.703] Manager {13989191624} ERROR:
[WebHttpHandleConnection] /favicon.ico not valid autoconf file
[Mar 19 17:01:43.703] Manager {13989191624} ERROR: (last system error
11: Resource temporarily unavailable)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1154) quick_filter on HEAD does not work
[ https://issues.apache.org/jira/browse/TS-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233407#comment-13233407 ] Leif Hedstrom commented on TS-1154: --- Yeah, I'd suggest just fixing this for 3.0.4 honestly. quick_filter on HEAD does not work -- Key: TS-1154 URL: https://issues.apache.org/jira/browse/TS-1154 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Zhao Yongming Assignee: weijin Attachments: head_method.diff we take quick filter as a good solution for some security concern, but when I set it to 0x0733, it does not allow HEAD in, but setting as 0x0723 does that. Weijin have the patch in our tree: https://gitorious.org/trafficserver/taobao/commit/cb23b87d167da4074e047fabc94786003ee94e9a/diffs/db7d0e5be69988b531e8d1e4eea717e6d46df5cd I will commit if no one complain in 2 days. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1153) On Solaris, link with libumem by default
[ https://issues.apache.org/jira/browse/TS-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232608#comment-13232608 ] Leif Hedstrom commented on TS-1153: --- Probably won't make any difference at all on most setups. :) However, it could make it easier for plugins to improve performance, so I'd suggest you do what we do with tcmalloc / jemalloc; Add another option to configure.ac, e.g. --with-libumem. On Solaris, link with libumem by default Key: TS-1153 URL: https://issues.apache.org/jira/browse/TS-1153 Project: Traffic Server Issue Type: Improvement Components: Performance Environment: Solaris Reporter: Igor Galić Labels: memory http://developers.sun.com/solaris/articles/multiproc/multiproc.html Maybe we should make use of that and link to libumem by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1154) quick_filter on HEAD does not work
[ https://issues.apache.org/jira/browse/TS-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232716#comment-13232716 ] Leif Hedstrom commented on TS-1154: --- We should make sure TS-1140 also gets this fix, if it's broken there. quick_filter on HEAD does not work -- Key: TS-1154 URL: https://issues.apache.org/jira/browse/TS-1154 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Zhao Yongming Assignee: weijin we take quick filter as a good solution for some security concern, but when I set it to 0x0733, it does not allow HEAD in, but setting as 0x0723 does that. Weijin have the patch in our tree: https://gitorious.org/trafficserver/taobao/commit/cb23b87d167da4074e047fabc94786003ee94e9a/diffs/db7d0e5be69988b531e8d1e4eea717e6d46df5cd I will commit if no one complain in 2 days. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1154) quick_filter on HEAD does not work
[ https://issues.apache.org/jira/browse/TS-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232714#comment-13232714 ] Leif Hedstrom commented on TS-1154: --- Not sure what happened here, but with TS-1140, quick filter will die (finally). Unless this is also broken on 3.0.x, I'd suggest we won't bother fixing this. quick_filter on HEAD does not work -- Key: TS-1154 URL: https://issues.apache.org/jira/browse/TS-1154 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Zhao Yongming Assignee: weijin we take quick filter as a good solution for some security concern, but when I set it to 0x0733, it does not allow HEAD in, but setting as 0x0723 does that. Weijin have the patch in our tree: https://gitorious.org/trafficserver/taobao/commit/cb23b87d167da4074e047fabc94786003ee94e9a/diffs/db7d0e5be69988b531e8d1e4eea717e6d46df5cd I will commit if no one complain in 2 days. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1156) Multiple time tags in a log format gets bad results
[
https://issues.apache.org/jira/browse/TS-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232988#comment-13232988
]
Leif Hedstrom commented on TS-1156:
---
It might actually be the cqts marshalling that's broken, even logging just cqts
shows bad reqults (compared to e.g. cqtq)
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] [Commented] (TS-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232150#comment-13232150 ] Leif Hedstrom commented on TS-1146: --- https://github.com/apache/httpd/commit/967d943b93498233f0ec81a5b48706fdb6892dfd RFC 5077 TLS Session tickets Key: TS-1146 URL: https://issues.apache.org/jira/browse/TS-1146 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the machines need to have the same server ticket. See https://github.com/apache/httpd rev 967d943b93498233f0ec81a5b48706fdb6892dfd -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1136) Expose Configuration API such that config files can be written (or scripted) in a glue-language such as Lua
[
https://issues.apache.org/jira/browse/TS-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230241#comment-13230241
]
Leif Hedstrom commented on TS-1136:
---
Well, the existing admin API (which I'm shockingly familiar with ...) only
works on a running system. What we need is a system that can hook up a DSL
config system at startup. I've been thinking a lot about this, what I've been
meaning to do is to make a Lua system that generates records.config,
remap.config, parent.config, cache.config etc. That would be step one towards
profit I think. E.g. Lua code like
{code}
domain{
name = { ogre.com, www.ogre.com},
path = { /, function
local rec = rec
rec.url_remap.pristine_host_hdr = 0
{code}
or some such, I need to think some more about how this actually works in Lua
:). But it's syntax of passing tables are function parameters without requiring
() makes for neat DSL syntax I think.
This could easily include support for different plugins (regex_remap,
header_filter, remap_conf etc.), and generate those plugin config files as well.
Expose Configuration API such that config files can be written (or scripted)
in a glue-language such as Lua
---
Key: TS-1136
URL: https://issues.apache.org/jira/browse/TS-1136
Project: Traffic Server
Issue Type: New Feature
Components: Configuration
Reporter: Igor Galić
To unify and simplify our configuration it would be great to have them in a
script language.
Lua is an ideal candidate as it is easy to embed and it would make for a
wonderful - and powerful DSL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-838) [GSoC] Create a port of mod_security as Apache TrafficServer plugin
[ https://issues.apache.org/jira/browse/TS-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224302#comment-13224302 ] Leif Hedstrom commented on TS-838: -- Is this even necessary now, since there's an Ironbee plugin? [GSoC] Create a port of mod_security as Apache TrafficServer plugin --- Key: TS-838 URL: https://issues.apache.org/jira/browse/TS-838 Project: Traffic Server Issue Type: Wish Components: Documentation, Plugins, Web site Reporter: Igor Galić Assignee: Igor Galić ModSecurity is a Web Application Firewall (WAF), which is currently natively implemented as Apache httpd module. It is mostly used to protect multiple back-end applications from a single entry point on a proxy-server. This alone makes Traffic Server the ideal platform for a port. For reference, see https://www.modsecurity.org/tracker/browse/MODSEC-250 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1002) log unmapped HOST when pristine_host_hdr disabled
[
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223959#comment-13223959
]
Leif Hedstrom commented on TS-1002:
---
Also, I'm not seeing a note in CHANGES, is this code not committed ?
log unmapped HOST when pristine_host_hdr disabled
-
Key: TS-1002
URL: https://issues.apache.org/jira/browse/TS-1002
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Conan Wang
Assignee: Zhao Yongming
Priority: Minor
Fix For: 3.1.3
Attachments: TS-1002.patch
I want to log user request's Host in http header before remap. I write
logs_xml.config, like: %{Host}cqh
When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the
right Host which is not rewritten.
When disable the config, I always get the rewritten/mapped Host which is
not what I need.
logs_xml reference:
http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-462) Support TLS Server Name Indication (SNI) negotiation
[ https://issues.apache.org/jira/browse/TS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220069#comment-13220069 ] Leif Hedstrom commented on TS-462: -- Igor, not sure I understand, but my point is, if there's no way to configure the domain in ssl_multicert.config, we might have issues with certain types of certificates. Sure, we can punt on it for now, but at some point, it'd have to be dealt with, no? Support TLS Server Name Indication (SNI) negotiation Key: TS-462 URL: https://issues.apache.org/jira/browse/TS-462 Project: Traffic Server Issue Type: New Feature Components: SSL Affects Versions: 3.0.0 Reporter: Leif Hedstrom Assignee: Igor Galić Priority: Minor Labels: ssl Fix For: 3.1.5 We should support TLS Server Name Indication (SNI). This would allow for well behaved TLS clients to negotiate the certificate, without requiring a new IP for every site / certificate used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1124) Move a few plugins into main repo.
[ https://issues.apache.org/jira/browse/TS-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220438#comment-13220438 ] Leif Hedstrom commented on TS-1124: --- Commits include: eee2913090d40fed0d0398fe872b95c95d6b3c23 1f38e9e3a0b298f2c72a570fd1232c9adb2992d5 a5044fcc5266018cd1ba2d9700ebfc429c148921 8cfc3b71a0c557b50464945768e7d832723bebe1 fdebccc1d58a7c8ec30e54302963bfe4cdd89340 a6a83eef0ba3adaf88e42b0613d6774ea1232a75 199219146227957b5d8101440c32c755c2a2e727 0c89201b4dc3cb2686420565e41adfc3ee04d762 901ff98a5860d133f2a7db383bc1d074dad3a950 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] [Commented] (TS-462) Support TLS Server Name Indication (SNI) negotiation
[ https://issues.apache.org/jira/browse/TS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219806#comment-13219806 ] Leif Hedstrom commented on TS-462: -- Remember the CN/SN can have wildcards too. I suspect those could make it difficult to use an efficient hash table :-/. If so, perhaps you need to have an optional domain name at least? [I think a hash table lookup is going to be required for efficient lookups with thousands / millions of certs]. Cheers! Support TLS Server Name Indication (SNI) negotiation Key: TS-462 URL: https://issues.apache.org/jira/browse/TS-462 Project: Traffic Server Issue Type: New Feature Components: SSL Affects Versions: 3.0.0 Reporter: Leif Hedstrom Assignee: Igor Galić Priority: Minor Labels: ssl Fix For: 3.1.5 We should support TLS Server Name Indication (SNI). This would allow for well behaved TLS clients to negotiate the certificate, without requiring a new IP for every site / certificate used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1122) Make regex_remap plugin understand redirect directives
[ https://issues.apache.org/jira/browse/TS-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217021#comment-13217021 ] Leif Hedstrom commented on TS-1122: --- This should be fixed in 8a5e0f7b373c4cd82706895730373c88cc998acf. Make regex_remap plugin understand redirect directives -- Key: TS-1122 URL: https://issues.apache.org/jira/browse/TS-1122 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.3 Fix the code to support the new APIs, for dealing with redirects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1102) Cleanup obsolete debugging code
[ https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13216015#comment-13216015 ] Leif Hedstrom commented on TS-1102: --- Uri, should we try to fix --disable-diags too? And with we, I mean you ;). I committed everything else, thanks for the fixes. Cleanup obsolete debugging code --- Key: TS-1102 URL: https://issues.apache.org/jira/browse/TS-1102 Project: Traffic Server Issue Type: Bug Components: Core, Logging, Performance Affects Versions: 3.0.2 Environment: Any Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.3 Attachments: ats.benchmark, diags_cleanup.patch, diags_perf_and_remove_debugon.patch, diags_remove_debugon.patch, remove_prefix_arg.patch, remove_prefix_arg_v2.patch, remove_prefix_arg_v3.patch Original Estimate: 24h Remaining Estimate: 24h The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc = 4.1 for all compilation environments, and it includes variadic argument macro support with ##_VA_ARGS_ that deletes the final comma if no arguments are provided. Removing the added layer should also improve performance when high volume debugging is turned on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1115) Fix build issues with Intel ICC
[ https://issues.apache.org/jira/browse/TS-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211172#comment-13211172 ] Leif Hedstrom commented on TS-1115: --- Commit: 03d858fce9a5a028a61fd976c5062c2bd39956b0 I really wish git would post this automatically :/ 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] [Commented] (TS-1116) Fix build issues with clang (particularly on OSX)
[
https://issues.apache.org/jira/browse/TS-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211200#comment-13211200
]
Leif Hedstrom commented on TS-1116:
---
I got most of it to compile, with the exception of this in IpMap.cc:
{code}
IpMap.cc:850:11: error: call to function 'operator' that is neither visible in
the template definition nor found by argument-dependent lookup
if (x n-_min) n = left(n);
^
IpMap.cc:1236:24: note: in instantiation of member function
'ts::detail::IpMapBasets::detail::Ip6Node::contains' requested here
zret = _m6 _m6-contains(ink_inet_ip6_cast(target), ptr);
^
IpMap.cc:1164:13: note: 'operator' should be declared prior to the call site
or in the global namespace
inline bool operator(sockaddr_in6 const* lhs, sockaddr_in6 const rhs) {
^
IpMap.cc:665:17: error: call to function 'operator==' that is neither visible
in the template definition nor found by argument-dependent lookup
if (n-_min == min) {
^
IpMap.cc:1260:21: note: in instantiation of member function
'ts::detail::IpMapBasets::detail::Ip6Node::mark' requested here
this-force6()-mark(ink_inet_ip6_cast(min), ink_inet_ip6_cast(max), data);
^
IpMap.cc:1172:13: note: 'operator==' should be declared prior to the call site
or in the global namespace
inline bool operator==(sockaddr_in6 const lhs, sockaddr_in6 const* rhs) {
^
IpMap.cc:736:19: error: call to function 'operator=' that is neither visible
in the template definition nor found by argument-dependent lookup
if (n-_max = max_plus) { // completely covered, drop span, continue
^
IpMap.cc:1188:13: note: 'operator=' should be declared prior to the call site
or in the global namespace
inline bool operator=(sockaddr_in6 const lhs, sockaddr_in6 const rhs) {
^
IpMap.cc:514:16: error: call to function 'operator' that is neither visible in
the template definition nor found by argument-dependent lookup
if (target n-_min) n = left(n);
^
IpMap.cc:640:16: note: in instantiation of member function
'ts::detail::IpMapBasets::detail::Ip6Node::lowerBound' requested here
N* n = this-lowerBound(min); // current node.
^
IpMap.cc:1260:21: note: in instantiation of member function
'ts::detail::IpMapBasets::detail::Ip6Node::mark' requested here
this-force6()-mark(ink_inet_ip6_cast(min), ink_inet_ip6_cast(max), data);
^
IpMap.cc:1164:13: note: 'operator' should be declared prior to the call site
or in the global namespace
inline bool operator(sockaddr_in6 const* lhs, sockaddr_in6 const rhs) {
^
4 errors generated.
{code}
I'll commit the other changes (after I test them on Linux), but I'll need
assistant from some C++ propeller head with the template madness above :).
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] [Commented] (TS-1102) Cleanup obsolete debugging code
[ https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13209770#comment-13209770 ] Leif Hedstrom commented on TS-1102: --- We might need to back this out. Not only is it breaking Solaris builds, it actually segfaults the OSX gcc-llvm compiler (not our fault obviously, but still annoying). Uri, what do you think ? Cleanup obsolete debugging code --- Key: TS-1102 URL: https://issues.apache.org/jira/browse/TS-1102 Project: Traffic Server Issue Type: Bug Components: Core, Logging, Performance Affects Versions: 3.0.2 Environment: Any Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.3 Attachments: diags_cleanup.patch, remove_prefix_arg.patch, remove_prefix_arg_v2.patch, remove_prefix_arg_v3.patch Original Estimate: 24h Remaining Estimate: 24h The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc = 4.1 for all compilation environments, and it includes variadic argument macro support with ##_VA_ARGS_ that deletes the final comma if no arguments are provided. Removing the added layer should also improve performance when high volume debugging is turned on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1102) Cleanup obsolete debugging code
[ https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13203624#comment-13203624 ] Leif Hedstrom commented on TS-1102: --- Yeah, sorry. What it really means is that we don't support e.g gcc 3.x and earlier. We still want to support as many modern compilers as possible, eg Intel icc and clang/llvm. If you could, fixing this would be great. Cleanup obsolete debugging code --- Key: TS-1102 URL: https://issues.apache.org/jira/browse/TS-1102 Project: Traffic Server Issue Type: Bug Components: Core, Logging, Performance Affects Versions: 3.0.2 Environment: Any Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.3 Attachments: diags_cleanup.patch, remove_prefix_arg.patch, remove_prefix_arg_v2.patch, remove_prefix_arg_v3.patch Original Estimate: 24h Remaining Estimate: 24h The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc = 4.1 for all compilation environments, and it includes variadic argument macro support with ##_VA_ARGS_ that deletes the final comma if no arguments are provided. Removing the added layer should also improve performance when high volume debugging is turned on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1102) Cleanup obsolete debugging code
[ https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13203647#comment-13203647 ] Leif Hedstrom commented on TS-1102: --- Yeah, all other build-bots are happy. And yes, icc is generally gcc 4.x compatible, and I think llvm tries to be as well. Solaris is well, Solaris, so no big surprise there ... I have a Solaris build box I can test it on as well, but, this is why we have the buildbots in the first place. :) I'll probably spend some time next to get both icc and llvm to compile again, and then we should aim to get buildbots for those as well. Thanks for taking the time to work on this, we really appreciate it, and of course, we welcome all new (and old :) committers to work with the project. Cleanup obsolete debugging code --- Key: TS-1102 URL: https://issues.apache.org/jira/browse/TS-1102 Project: Traffic Server Issue Type: Bug Components: Core, Logging, Performance Affects Versions: 3.0.2 Environment: Any Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.3 Attachments: diags_cleanup.patch, remove_prefix_arg.patch, remove_prefix_arg_v2.patch, remove_prefix_arg_v3.patch Original Estimate: 24h Remaining Estimate: 24h The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc = 4.1 for all compilation environments, and it includes variadic argument macro support with ##_VA_ARGS_ that deletes the final comma if no arguments are provided. Removing the added layer should also improve performance when high volume debugging is turned on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1102) Cleanup obsolete debugging code
[ https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13200813#comment-13200813 ] Leif Hedstrom commented on TS-1102: --- I think the old SVN repo is read-only since the migration happened. The git repo is at http://git-wip-us.apache.org/repos/asf/trafficserver.git (or https:// if you want a read-write repo, the http:// is read-only). I'll look at the rejections in a bit, but if you have time, prepping one that patches against git trunk (master) would be great. Cleanup obsolete debugging code --- Key: TS-1102 URL: https://issues.apache.org/jira/browse/TS-1102 Project: Traffic Server Issue Type: Bug Components: Core, Logging, Performance Affects Versions: 3.0.2 Environment: Any Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.3 Attachments: diags_cleanup.patch, remove_prefix_arg.patch, remove_prefix_arg_v2.patch Original Estimate: 24h Remaining Estimate: 24h The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc = 4.1 for all compilation environments, and it includes variadic argument macro support with ##_VA_ARGS_ that deletes the final comma if no arguments are provided. Removing the added layer should also improve performance when high volume debugging is turned on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13198837#comment-13198837 ] Leif Hedstrom commented on TS-1079: --- Cool, I'll take a look at TS-1102 today (unless someone else beats me to it :). As for the API / remap: One possibility is to look at the APIs we added to support overriding records.config settings per transaction. It's a bit hacky, but works fairly well. The only caveat here is that it only works in places in the code where you have access to the HttpSM's State. So that might be a problem for this? If necessary, we could add another @ option to remap.config, but we tried to avoid that as much as possible with the new per-transaction records.config features (in fact, we removed 3 @ options after adding this feature). Add an API function to turn debugging on for specific transactions/sessions --- Key: TS-1079 URL: https://issues.apache.org/jira/browse/TS-1079 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Uri Shachar Priority: Minor Attachments: debug_specific.patch Original Estimate: 72h Remaining Estimate: 72h When attempting to troubleshoot issues on a production ATS system, it is often impossible/difficult to turn on any of the 'high-volume' debug tags like http due to the performance impact. This enhancement allows a plugin to set a debug flag for a specific txn/ssn, and replaces some of the internal Debug calls with a new function that checks if the flag is turned on, and outputs the debug line regardless of the tag if it is (The diags enable/disable flag is still taken into account). The API will also have TSDebugSpecific in order to allow plugins to use the same functionality. In addition, we might consider adding an internal config file (remap-like) to allow turning this flag on without plugin intervention. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1102) Cleanup obsolete debugging code
[ https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13198881#comment-13198881 ] Leif Hedstrom commented on TS-1102: --- Uri, the remove_prefix_arg.patch fails on current trunk. Any chance you can prepare a patch for trunk? Cleanup obsolete debugging code --- Key: TS-1102 URL: https://issues.apache.org/jira/browse/TS-1102 Project: Traffic Server Issue Type: Bug Components: Core, Logging, Performance Affects Versions: 3.0.2 Environment: Any Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.2 Attachments: diags_cleanup.patch, remove_prefix_arg.patch Original Estimate: 24h Remaining Estimate: 24h The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc = 4.1 for all compilation environments, and it includes variadic argument macro support with ##_VA_ARGS_ that deletes the final comma if no arguments are provided. Removing the added layer should also improve performance when high volume debugging is turned on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-937) EThread::execute still processing cancelled event
[
https://issues.apache.org/jira/browse/TS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13199504#comment-13199504
]
Leif Hedstrom commented on TS-937:
--
Brian, should we keep this for 3.1.2, or move out to 3.1.3 ?
EThread::execute still processing cancelled event
-
Key: TS-937
URL: https://issues.apache.org/jira/browse/TS-937
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.1, 2.1.9
Environment: RHEL6
Reporter: Brian Geffon
Assignee: Brian Geffon
Fix For: 3.1.2
Attachments: UnixEThread.patch
The included GDB log will show that ATS is trying to process an event that
has already been canceled, examining the code of UnixEThread.cc line 232
shows that EThread::process_event gets called without a check for the event
being cancelled.
Brian
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x764fa700 (LWP 28518)]
0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64
keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.1.x86_64
libcom_err-1.41.12-7.el6.x86_64 libgcc-4.4.5-6.el6.x86_64
libselinux-2.0.94-5.el6.x86_64 libstdc++-4.4.5-6.el6.x86_64
openssl-1.0.0-10.el6_1.4.x86_64 pcre-7.8-3.1.el6.x86_64
tcl-8.5.7-6.el6.x86_64 zlib-1.2.3-25.el6.x86_64
(gdb) bt
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
(gdb) bt full
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
lock = {m = {m_ptr = 0x764f9d20}, lock_acquired = 202}
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
done_one = false
e = 0x1db45c0
NegativeQueue = {DLLEvent, Event::Link_link = {head = 0xfc75f0},
tail = 0xfc75f0}
next_time = 1314647904419648000
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
p = 0xfb7e80
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb) f 0
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
(gdb) p *e
$2 = {Action = {_vptr.Action = 0x775170, continuation = 0x1f2fc08, mutex =
{m_ptr = 0x7fffd40fba40}, cancelled = 1}, ethread = 0x768ff010,
in_the_prot_queue = 0, in_the_priority_queue = 0,
immediate = 1, globally_allocated = 1, in_heap = 0, callback_event = 1,
timeout_at = 0, period = 0, cookie = 0x0, link = {SLinkEvent = {next =
0x0}, prev = 0x0}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1094) TS hangs after repeated requests from the same kept-alive connection
[ https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197969#comment-13197969 ] Leif Hedstrom commented on TS-1094: --- Cool, I'll test this in a bit. Question: Do we still need that second change from TS-466, we reorders the call to mime_scanner_append() ? TS hangs after repeated requests from the same kept-alive connection Key: TS-1094 URL: https://issues.apache.org/jira/browse/TS-1094 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.0 Environment: Oracle Enterprise Linux 5.5 64-bit Reporter: Wilson Ho Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 Attachments: ts-1094.diff When a client submits multiple requests while re-using the same keep-alived connection, TS hangs. Usually, the client eventually times out, and at that point TS will be waken up and forwards the request to the original server. But by then it's too late and the client already closed connection. In real life traffic, this bug is very hard to reproduce. But here is an artificial test case. First, make sure client-side keep alive is on. My test case uses HTTP (port 80) GET. Second, make sure the total header size of the requests is exactly 275 bytes, including the carriage returns and line feeds. One byte more or less would fail to reproduce the bug. Third, repeatedly submit the same request through this keep-alived connection. At exactly the 283rd iteration, TS hangs. Note that if the client opens a new connection every time, TS works fine. There is a second test case, where the header size is exactly 283 bytes, and TS hangs at exactly the 275th iteration. (Does 275 x 283 mean something?) These magic numbers seem to suggest a memory buffer size (or allocation) problem. I speculate that headers from repeated requests are placed in a buffer (or a circular buffer?), and when the total hits a particular size, some boundary conditions must have be violated and resulted in memory corruption. In real life traffic, each request typically has slightly different header size, so it is really hard to hit this bug. I suspect there is a +/- 1 calculation error in some buffer. BTW, turning on/off caching does not make any difference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1094) TS hangs after repeated requests from the same kept-alive connection
[ https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197364#comment-13197364 ] Leif Hedstrom commented on TS-1094: --- Yeah, it needs a different fix. But, glad to hear it works for you, means at least I'm on the right track. Unfortunately $work is getting in the way right now, but I'll work more on this soon (and Alan promised to help too, since it's his fault ;). TS hangs after repeated requests from the same kept-alive connection Key: TS-1094 URL: https://issues.apache.org/jira/browse/TS-1094 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.0 Environment: Oracle Enterprise Linux 5.5 64-bit Reporter: Wilson Ho Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 When a client submits multiple requests while re-using the same keep-alived connection, TS hangs. Usually, the client eventually times out, and at that point TS will be waken up and forwards the request to the original server. But by then it's too late and the client already closed connection. In real life traffic, this bug is very hard to reproduce. But here is an artificial test case. First, make sure client-side keep alive is on. My test case uses HTTP (port 80) GET. Second, make sure the total header size of the requests is exactly 275 bytes, including the carriage returns and line feeds. One byte more or less would fail to reproduce the bug. Third, repeatedly submit the same request through this keep-alived connection. At exactly the 283rd iteration, TS hangs. Note that if the client opens a new connection every time, TS works fine. There is a second test case, where the header size is exactly 283 bytes, and TS hangs at exactly the 275th iteration. (Does 275 x 283 mean something?) These magic numbers seem to suggest a memory buffer size (or allocation) problem. I speculate that headers from repeated requests are placed in a buffer (or a circular buffer?), and when the total hits a particular size, some boundary conditions must have be violated and resulted in memory corruption. In real life traffic, each request typically has slightly different header size, so it is really hard to hit this bug. I suspect there is a +/- 1 calculation error in some buffer. BTW, turning on/off caching does not make any difference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1100) Coredump at startup when there's a duplicate remap rule
[ https://issues.apache.org/jira/browse/TS-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197416#comment-13197416 ] Leif Hedstrom commented on TS-1100: --- This is sort of by design, it refuses to start up with a bad remap.config. The reason you get a segfault is because our destructors are running on uninitialized objects :-/. Coredump at startup when there's a duplicate remap rule --- Key: TS-1100 URL: https://issues.apache.org/jira/browse/TS-1100 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.1 Environment: Bog standard linux/x86; own build. Reporter: Nick Kew Priority: Minor A minor accident with cutpaste in vi leads to TS coredumping at startup. I had duplicated a line in remap.config: map http://myhost:8080/ http://target/ () map http://myhost:8080/ http://target/ The second instance is line 125 in remap.config, and the dump shows: FATAL: [ReverseProxy] Unable to add mapping rule to lookup table at line 125 bin/traffic_server - STACK TRACE: /usr/local/trafficserver/lib/libtsutil.so.3(ink_fatal_va+0xc7)[0xe21873] /usr/local/trafficserver/lib/libtsutil.so.3(ink_fatal+0x2b)[0xe218c5] bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x1e48)[0x81e1120] bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x562)[0x810] bin/traffic_server(_Z18init_reverse_proxyv+0x41)[0x815500b] bin/traffic_server(_Z20init_HttpProxyServerv+0xe)[0x818fccc] bin/traffic_server(main+0xf7f)[0x813b65d] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x692bd6] bin/traffic_server[0x80f6001] Aborted -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1094) TS hangs after repeated requests from the same kept-alive connection
[
https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13195910#comment-13195910
]
Leif Hedstrom commented on TS-1094:
---
Yeah, I ended up doing something similar too (except I used ab). I can
reproduce it with (in my case)
{code}
ab -c 1 -k -n 247 -H Foo:
23
http://loki.ogre.com/bench/100.bmp
{code}
Turning on slow log, it clearly indicates that it's hung in reading the request
header (which is no surprise). I also tested it with a single net-thread, and
while ab is hanging, the server still responds to other requests on that
thread. So, it's not blocking the thread.
What's weird is that I tested the above ab from localhost (linux) and also
from another Linux box (over GigE), and they both hang. But from my Mac, I'm
not able to reproduce it (tested various other header lengths etc.).
TS hangs after repeated requests from the same kept-alive connection
Key: TS-1094
URL: https://issues.apache.org/jira/browse/TS-1094
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.0
Environment: Oracle Enterprise Linux 5.5 64-bit
Reporter: Wilson Ho
Priority: Blocker
Fix For: 3.1.3
When a client submits multiple requests while re-using the same keep-alived
connection, TS hangs. Usually, the client eventually times out, and at that
point TS will be waken up and forwards the request to the original server.
But by then it's too late and the client already closed connection.
In real life traffic, this bug is very hard to reproduce. But here is an
artificial test case.
First, make sure client-side keep alive is on. My test case uses HTTP (port
80) GET.
Second, make sure the total header size of the requests is exactly 275 bytes,
including the carriage returns and line feeds. One byte more or less would
fail to reproduce the bug.
Third, repeatedly submit the same request through this keep-alived
connection. At exactly the 283rd iteration, TS hangs. Note that if the
client opens a new connection every time, TS works fine.
There is a second test case, where the header size is exactly 283 bytes, and
TS hangs at exactly the 275th iteration. (Does 275 x 283 mean something?)
These magic numbers seem to suggest a memory buffer size (or allocation)
problem. I speculate that headers from repeated requests are placed in a
buffer (or a circular buffer?), and when the total hits a particular size,
some boundary conditions must have be violated and resulted in memory
corruption.
In real life traffic, each request typically has slightly different header
size, so it is really hard to hit this bug. I suspect there is a +/- 1
calculation error in some buffer.
BTW, turning on/off caching does not make any difference.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1094) TS hangs after repeated requests from the same kept-alive connection
[
https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13195935#comment-13195935
]
Leif Hedstrom commented on TS-1094:
---
I'm not 100% sure (or even 90% sure), but can you try this patch (against
trunk, but probably 3.1.0|1 would work too):
{code}
diff --git a/proxy/hdrs/MIME.cc b/proxy/hdrs/MIME.cc
index d448421..0c4db0e 100644
--- a/proxy/hdrs/MIME.cc
+++ b/proxy/hdrs/MIME.cc
@@ -2461,7 +2461,6 @@ mime_scanner_get(MIMEScanner * S,
} else if (data_size) {
// Inside a field but more data is expected. Save what we've got.
mime_scanner_append(S, *raw_input_s, data_size);
- data_size = 0; // Don't append again.
}
}
{code}
This fix in its own doesn't make any sense, but it'd help to know if this
eliminates (or changes) the problem for you in any way.
TS hangs after repeated requests from the same kept-alive connection
Key: TS-1094
URL: https://issues.apache.org/jira/browse/TS-1094
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.0
Environment: Oracle Enterprise Linux 5.5 64-bit
Reporter: Wilson Ho
Priority: Blocker
Fix For: 3.1.3
When a client submits multiple requests while re-using the same keep-alived
connection, TS hangs. Usually, the client eventually times out, and at that
point TS will be waken up and forwards the request to the original server.
But by then it's too late and the client already closed connection.
In real life traffic, this bug is very hard to reproduce. But here is an
artificial test case.
First, make sure client-side keep alive is on. My test case uses HTTP (port
80) GET.
Second, make sure the total header size of the requests is exactly 275 bytes,
including the carriage returns and line feeds. One byte more or less would
fail to reproduce the bug.
Third, repeatedly submit the same request through this keep-alived
connection. At exactly the 283rd iteration, TS hangs. Note that if the
client opens a new connection every time, TS works fine.
There is a second test case, where the header size is exactly 283 bytes, and
TS hangs at exactly the 275th iteration. (Does 275 x 283 mean something?)
These magic numbers seem to suggest a memory buffer size (or allocation)
problem. I speculate that headers from repeated requests are placed in a
buffer (or a circular buffer?), and when the total hits a particular size,
some boundary conditions must have be violated and resulted in memory
corruption.
In real life traffic, each request typically has slightly different header
size, so it is really hard to hit this bug. I suspect there is a +/- 1
calculation error in some buffer.
BTW, turning on/off caching does not make any difference.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1094) TS hangs after repeated requests from the same kept-alive connection
[ https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13195277#comment-13195277 ] Leif Hedstrom commented on TS-1094: --- You don't happen to have a script that reproduces this, do you ? TS hangs after repeated requests from the same kept-alive connection Key: TS-1094 URL: https://issues.apache.org/jira/browse/TS-1094 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.0 Environment: Oracle Enterprise Linux 5.5 64-bit Reporter: Wilson Ho Priority: Blocker Fix For: 3.1.3 When a client submits multiple requests while re-using the same keep-alived connection, TS hangs. Usually, the client eventually times out, and at that point TS will be waken up and forwards the request to the original server. But by then it's too late and the client already closed connection. In real life traffic, this bug is very hard to reproduce. But here is an artificial test case. First, make sure client-side keep alive is on. My test case uses HTTP (port 80) GET. Second, make sure the total header size of the requests is exactly 275 bytes, including the carriage returns and line feeds. One byte more or less would fail to reproduce the bug. Third, repeatedly submit the same request through this keep-alived connection. At exactly the 283rd iteration, TS hangs. Note that if the client opens a new connection every time, TS works fine. There is a second test case, where the header size is exactly 283 bytes, and TS hangs at exactly the 275th iteration. (Does 275 x 283 mean something?) These magic numbers seem to suggest a memory buffer size (or allocation) problem. I speculate that headers from repeated requests are placed in a buffer (or a circular buffer?), and when the total hits a particular size, some boundary conditions must have be violated and resulted in memory corruption. In real life traffic, each request typically has slightly different header size, so it is really hard to hit this bug. I suspect there is a +/- 1 calculation error in some buffer. BTW, turning on/off caching does not make any difference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1083) initial SSL next protocol negotiation support
[ https://issues.apache.org/jira/browse/TS-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192190#comment-13192190 ] Leif Hedstrom commented on TS-1083: --- Quick question: when I first looked at this, my code simply did #ifdef OPENSSL_NPN_NEGOTIATED Is there a reason we have to have autoconf check for NPN support? Is there ever a reason not to support NPN (even with just HTTPS) if the OpenSSL library has it available? initial SSL next protocol negotiation support - Key: TS-1083 URL: https://issues.apache.org/jira/browse/TS-1083 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Attachments: 0001-Compile-time-detection-of-NextProtocolNegotiation-su.patch, 0002-Initial-NPN-plumbing.patch Initial autoconf support for detecting OpenSSL Next Protocol Negotiation APIs. Advertise that we support HTTP/1.0 and HTTP/1.1. Because we do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1083) initial SSL next protocol negotiation support
[ https://issues.apache.org/jira/browse/TS-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192288#comment-13192288 ] Leif Hedstrom commented on TS-1083: --- Well, that's one #define available in OpenSSL when NPN is available. I have no problems with your patch, so just decide which route you think we should go. I picked OPENSSL_NPN_NEGOTIATED, because I saw other solutions doing the same :). initial SSL next protocol negotiation support - Key: TS-1083 URL: https://issues.apache.org/jira/browse/TS-1083 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Attachments: 0001-Compile-time-detection-of-NextProtocolNegotiation-su.patch, 0002-Initial-NPN-plumbing.patch Initial autoconf support for detecting OpenSSL Next Protocol Negotiation APIs. Advertise that we support HTTP/1.0 and HTTP/1.1. Because we do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192465#comment-13192465 ] Leif Hedstrom commented on TS-1079: --- The patch looks good to me. And yes, I agree, we require gcc (or compatible) 4.1 I think (to simplify atomic support). I'm fine with cleanup (getting rid of old crud is good). I'm assuming the next step is for you to change some (select) Debug() invocations in the core? How do you plan to decide which ones are useful or not? Add an API function to turn debugging on for specific transactions/sessions --- Key: TS-1079 URL: https://issues.apache.org/jira/browse/TS-1079 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Uri Shachar Priority: Minor Attachments: debug_specific.patch Original Estimate: 72h Remaining Estimate: 72h When attempting to troubleshoot issues on a production ATS system, it is often impossible/difficult to turn on any of the 'high-volume' debug tags like http due to the performance impact. This enhancement allows a plugin to set a debug flag for a specific txn/ssn, and replaces some of the internal Debug calls with a new function that checks if the flag is turned on, and outputs the debug line regardless of the tag if it is (The diags enable/disable flag is still taken into account). The API will also have TSDebugSpecific in order to allow plugins to use the same functionality. In addition, we might consider adding an internal config file (remap-like) to allow turning this flag on without plugin intervention. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191256#comment-13191256
]
Leif Hedstrom commented on TS-1091:
---
Would it not be possible to make a regex that captures all the cases? Perhaps
something like (untested)
s/ *-w */ /g
? It means we might have an additional whitespace in the CFLAGs, but that seems
ok :).
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code, but I could not find any #pragma that seemed to do
this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e
's/ -w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.
[
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191276#comment-13191276
]
Leif Hedstrom commented on TS-1073:
---
Sorry to be a pain here, but should we not try to be IPv6 compatible here ?
Perhaps it could be e.g.
{code}
+if (t_state.cop_test_page)
+ ink_inet_copy(t_state.host_db_info.ip(),
t_state.state_machine-ua_session-get_netvc()-get_local_addr());
{code}
Or, are the COP test pages always guaranteed to be IPv4 only (not sure how that
works, but even so, at some point, I imagine IPv4 will go away completely :).
Thoughts?
no_dns_just_forward_to_parent configuration parameter is ignored/not used.
--
Key: TS-1073
URL: https://issues.apache.org/jira/browse/TS-1073
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.0.2
Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
Fix For: 3.1.2
Attachments: TS-1073.patch
I have two instances of trafficserver configured, one instance is configured
to use the second instance as a parent proxy using the following parameters
from the records.config:
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
The parent config looks like this:
dest_domain=. parent=parent:8080 round_robin=false
The no_dns_just_forward_to_parent is not used in the code and as a result dns
lookups are being performed in the child instance.
The following code changes seem to fix this:
proxy/http/HttpSM.cc
@@ -6406,11 +6405,20 @@
t_state.dns_info.lookup_success = true;
call_transact_and_set_next_state(NULL);
break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED
t_state.dns_info.lookup_success) {
// Already set, and we don't have a parent proxy to lookup
ink_assert(t_state.host_db_info.ip());
Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup,
provided by plugin);
call_transact_and_set_next_state(NULL);
break;
+ } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER
+ t_state.http_config_param-no_dns_forward_to_parent){
+
+if(t_state.cop_test_page) {
+t_state.host_db_info.ip()
=t_state.state_machine-ua_session-get_netvc()-get_local_ip();
+}
+
+t_state.dns_info.lookup_success = true;
+call_transact_and_set_next_state(NULL);
+break;
}
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
to avoid reverse ns lookups
/proxy/http/HttpTransact.cc
@@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9'
s-dns_info.lookup_name[0] = '0'
//(s-state_machine-authAdapter.needs_rev_dns() ||
- ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)) {
+ ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)
+ !s-http_config_param-no_dns_forward_to_parent) {
// note, broken logic: ACC fudges the OR stmt to always be true,
// 'AuthHttpAdapter' should do the rev-dns if needed, not here .
TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
I would like to have these changes applied to the repository if they look ok.
I also created an empty resolv.conf and pointed ats to the empty file:
CONFIG proxy.config.dns.resolv_conf STRING
/usr/local/etc/trafficserver/resolv.conf
When these changes are applied the child instance no longer attempts to
perform dns lookups for the
http requests that it receives. If they are not applied and the dns lookup it
slow or unreliable on the
child then the http requests are blocked by the dns lookup within the child
trafficserver instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-998) Broken ClientReq in TSAPI
[ https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187240#comment-13187240 ] Leif Hedstrom commented on TS-998: -- So, I'm not sure I like this approach. What are the advantages here of making a stringified copy of the pristine request headers, instead of making a copy of the request object? If we made a copy of the original request object, and leave it immutable (static), we can keep using the normal APIs for getting headers etc. out of it, no? In a similar fashion, we already have TSHttpTxnPristineUrlGet(). So, we'd add something like TSHttpTxnPristineReqGet() or some such. Broken ClientReq in TSAPI - Key: TS-998 URL: https://issues.apache.org/jira/browse/TS-998 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.1 Environment: any Reporter: Nick Kew Assignee: Nick Kew Fix For: 3.1.2 Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request line. Expected behaviour: In a PRE_REMAP hook it should return the client request line and headers, ideally verbatim. Observed behaviour: http://; is prepended to the request URL: GET /path/ HTTP/1.1 becomes GET http:///path/ HTTP/1.1 (yes, that's three slashes) Pseudo-code to reproduce from a PRE_REMAP hook: TSHttpTxnClientReqGet(txnp, buf, hdr); TSHttpHdrPrint(buf, hdr, iobuf); reader = TSIOBufferReaderAlloc(iobuf); block = TSIOBufferReaderStart(reader); len = TSIOBufferBlockReadAvail(block, reader); data = TSIOBufferBlockReadStart(block, reader, len); Now examine the contents of data. Assigned to AMC as suggested yesterday on-list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-998) Broken ClientReq in TSAPI
[
https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187345#comment-13187345
]
Leif Hedstrom commented on TS-998:
--
I'm assuming that
{code}
if (must_copy s_str) {
s_str = heap-duplicate_str(s_str, s_len);
}
{code}
will have to copy the string version of something (sounds like the entire
request URL + header). Maybe that is cheap. As for the logging, that string is
only used (afaik) if you use the cquuc tag in a custom log (it would not be
used in the default logs, or error logs). We could perhaps change that if/where
it makes sense.
What I'm saying is, what would make most sense to me personally would be to
keep an immutable request object before remap happens, and then we can use
normal APIs on that. This would remove the need for the PristineUrl API, and
this string version of the request URL for logging (which is created solely for
logging, if someone uses the cquuc tag in a custom log).
Broken ClientReq in TSAPI
-
Key: TS-998
URL: https://issues.apache.org/jira/browse/TS-998
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.1
Environment: any
Reporter: Nick Kew
Assignee: Nick Kew
Fix For: 3.1.2
Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request
line.
Expected behaviour: In a PRE_REMAP hook it should return the client request
line and headers, ideally verbatim.
Observed behaviour: http://; is prepended to the request URL:
GET /path/ HTTP/1.1
becomes
GET http:///path/ HTTP/1.1
(yes, that's three slashes)
Pseudo-code to reproduce from a PRE_REMAP hook:
TSHttpTxnClientReqGet(txnp, buf, hdr);
TSHttpHdrPrint(buf, hdr, iobuf);
reader = TSIOBufferReaderAlloc(iobuf);
block = TSIOBufferReaderStart(reader);
len = TSIOBufferBlockReadAvail(block, reader);
data = TSIOBufferBlockReadStart(block, reader, len);
Now examine the contents of data.
Assigned to AMC as suggested yesterday on-list.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-998) Broken ClientReq in TSAPI
[
https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187434#comment-13187434
]
Leif Hedstrom commented on TS-998:
--
Ok, I re-ran all the benchmarks (with and without the latest patch here):
Before:
{code}
tinkerballa (20:22) 256/0 $ ~/benchit.sh 100 300
48759110 fetches on 482907 conns, 300 max parallel, 4.875910E+09 bytes, in 300
seconds
100 mean bytes/fetch
162530.2 fetches/sec, 1.625302E+07 bytes/sec
msecs/connect: 0.266 mean, 9.225 max, 0.042 min
msecs/first-response: 1.329 mean, 294.947 max, 0.083 min
{code}
After:
{code}
http_load -parallel 100 -seconds 300 -keep_alive 100 /tmp/URL
43633453 fetches on 432166 conns, 300 max parallel, 4.363350E+09 bytes, in 300
seconds
100 mean bytes/fetch
145444.9 fetches/sec, 1.454449E+07 bytes/sec
msecs/connect: 0.188 mean, 10.545 max, 0.041 min
msecs/first-response: 1.528 mean, 234.828 max, 0.082 min
{code}
So yeah, pretty sure there's a noticeable cost of doing this copy, no?
Broken ClientReq in TSAPI
-
Key: TS-998
URL: https://issues.apache.org/jira/browse/TS-998
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.1
Environment: any
Reporter: Nick Kew
Assignee: Nick Kew
Fix For: 3.1.2
Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request
line.
Expected behaviour: In a PRE_REMAP hook it should return the client request
line and headers, ideally verbatim.
Observed behaviour: http://; is prepended to the request URL:
GET /path/ HTTP/1.1
becomes
GET http:///path/ HTTP/1.1
(yes, that's three slashes)
Pseudo-code to reproduce from a PRE_REMAP hook:
TSHttpTxnClientReqGet(txnp, buf, hdr);
TSHttpHdrPrint(buf, hdr, iobuf);
reader = TSIOBufferReaderAlloc(iobuf);
block = TSIOBufferReaderStart(reader);
len = TSIOBufferBlockReadAvail(block, reader);
data = TSIOBufferBlockReadStart(block, reader, len);
Now examine the contents of data.
Assigned to AMC as suggested yesterday on-list.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-880) Major performance problem with second request on same keep-alive connection
[ https://issues.apache.org/jira/browse/TS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13183519#comment-13183519 ] Leif Hedstrom commented on TS-880: -- Perhaps try CONFIG proxy.config.http.share_server_sessions INT 2 This is available with 3.1.1 (and soon, 3.1.2). I don't think it was backported to the 3.0.x branch. Major performance problem with second request on same keep-alive connection --- Key: TS-880 URL: https://issues.apache.org/jira/browse/TS-880 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.0, 2.1.4 Environment: 32-bit TS on linux, using epoll. With proxy.config.http.keep_alive_enabled_out = 1 Reporter: William Bardwell Assignee: William Bardwell Fix For: 3.1.0 Attachments: performance.try3.diff, performance_2nd_req.diff, performance_2nd_req_another_version.patch, performance_2nd_req_try2.diff If I load the same URL through TS twice in a row to a server with keep-alives turned on I get really slow performance on the second request. E.g. (loading 212M over loopback with uncachable content, but results are similar with cachable content): % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 212M 100 212M0 0 140M 0 0:00:01 0:00:01 --:--:-- 142M* % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 212M 100 212M0 0 6397k 0 0:00:34 0:00:34 --:--:-- 6400k* If I turn off proxy.config.http.keep_alive_enabled_out the problem goes away, it can also be partially solved by making proxy.config.io.max_buffer_size really big (but it needs to be bigger for larger content, and that supports the comment below, and proves that it isn't the origin server's fault.) When I turn on debug messages it looks like the IO loop for the second request only wakes up every 10ms (when an epoll_wait times out) and then it reads and writes, for the first request it goes much faster without those pauses. My theory is that the issue is related to the the fact that the outgoing connection fd gets added to the epoll fd for the thread handling the first request and the first user agent fd is added to the same epoll fd, and it stays on that epoll fd. But the new user agent request is on a different epoll fd which I assume means is tied to a different thread. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1076) Implement the ESI for ATS
[ https://issues.apache.org/jira/browse/TS-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182814#comment-13182814 ] Leif Hedstrom commented on TS-1076: --- Brian, you are never wrong. It's in the plugins directory, above the main traffic tree. Implement the ESI for ATS -- Key: TS-1076 URL: https://issues.apache.org/jira/browse/TS-1076 Project: Traffic Server Issue Type: New Feature Components: Plugins Affects Versions: 3.0.2 Reporter: Eric Ahn Priority: Minor Labels: cache Support ESI feature. You can review the doc (http://www.akamai.com/html/support/esi.html) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.
[
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182950#comment-13182950
]
Leif Hedstrom commented on TS-1073:
---
Hmmm, so this doesn't work with trunk, due to all the IPv6 changes... Would you
be able to get it working there? If not, I'll take a stab if necessary.
Thanks!
no_dns_just_forward_to_parent configuration parameter is ignored/not used.
--
Key: TS-1073
URL: https://issues.apache.org/jira/browse/TS-1073
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.0.2
Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
Fix For: 3.1.2
Attachments: TS-1073.patch
I have two instances of trafficserver configured, one instance is configured
to use the second instance as a parent proxy using the following parameters
from the records.config:
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
The parent config looks like this:
dest_domain=. parent=parent:8080 round_robin=false
The no_dns_just_forward_to_parent is not used in the code and as a result dns
lookups are being performed in the child instance.
The following code changes seem to fix this:
proxy/http/HttpSM.cc
@@ -6406,11 +6405,20 @@
t_state.dns_info.lookup_success = true;
call_transact_and_set_next_state(NULL);
break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED
t_state.dns_info.lookup_success) {
// Already set, and we don't have a parent proxy to lookup
ink_assert(t_state.host_db_info.ip());
Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup,
provided by plugin);
call_transact_and_set_next_state(NULL);
break;
+ } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER
+ t_state.http_config_param-no_dns_forward_to_parent){
+
+if(t_state.cop_test_page) {
+t_state.host_db_info.ip()
=t_state.state_machine-ua_session-get_netvc()-get_local_ip();
+}
+
+t_state.dns_info.lookup_success = true;
+call_transact_and_set_next_state(NULL);
+break;
}
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
to avoid reverse ns lookups
/proxy/http/HttpTransact.cc
@@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9'
s-dns_info.lookup_name[0] = '0'
//(s-state_machine-authAdapter.needs_rev_dns() ||
- ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)) {
+ ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)
+ !s-http_config_param-no_dns_forward_to_parent) {
// note, broken logic: ACC fudges the OR stmt to always be true,
// 'AuthHttpAdapter' should do the rev-dns if needed, not here .
TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
I would like to have these changes applied to the repository if they look ok.
I also created an empty resolv.conf and pointed ats to the empty file:
CONFIG proxy.config.dns.resolv_conf STRING
/usr/local/etc/trafficserver/resolv.conf
When these changes are applied the child instance no longer attempts to
perform dns lookups for the
http requests that it receives. If they are not applied and the dns lookup it
slow or unreliable on the
child then the http requests are blocked by the dns lookup within the child
trafficserver instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1049) TS hangs (dead lock) on HTTPS POST requests
[ https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182309#comment-13182309 ] Leif Hedstrom commented on TS-1049: --- Reading the code for the normal NetVC, and the SSL NetVC, I'm fairly certain your suggestion is correct. Thanks! TS hangs (dead lock) on HTTPS POST requests --- Key: TS-1049 URL: https://issues.apache.org/jira/browse/TS-1049 Project: Traffic Server Issue Type: Bug Components: Core, HTTP, SSL Affects Versions: 3.1.1, 3.1.0, 3.0.2 Environment: RedHat Enterprise Linux 6.0, Intel 32-bit Reporter: Wilson Ho Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 Attachments: records.config A very reproducible bug where the body of a HTTPS POST request is never forwarded to the origin server. Client submits a HTTPS POST request to TS, which is supposed to forward to the backend/origin server via HTTP. TS process the HTTP headers and establishes connection to the origin server, but the body of the HTTPS POST is never read. This hangs until the client times out and shuts down the connection. To reproduce: 1) Client connects to TS using HTTPS (works OK if it is just HTTP). 2) It must be a POST request. 3) TS must use at least 2 worker threads. 4) Easier to reproduce when the connections to the origin server is HTTP (not HTTPS). 5) POST body must be large enough so that the HTTP request headers and POST body do *NOT* fit within the same TCP packet. (2000 bytes is a good size) 6) I can consistently reproduce this problem using 2 separate clients each simultaneously submitting 2 requests back to back (i.e., 2 requests from each client, a total of 4 requests). This gives you a high probability that at least one of the requests would hang. Observation: 1) Thread A accepted and processed the HTTP headers, and called UnixNetProcessor::connect_re to prepare a new connection to the origin server. 2) Thread A must not have read the body of the POST. Otherwise, it works fine. 3) Thread B was assigned the task to handle the origin server connection. If the same thread A was picked, then everything works fine. 4) Apparently, one of the first things that thread B does is to acquire the mutex for reading from the client. (Why does it do that??) 5) While thread B was holding the mutex, thread A proceeded in SSLNetVConnection::net_read_io, tried and failed to acquire the mutex. Thread A typically re-tried calling SSLNetVConnection::net_read_io soon, but gave up after the second failure. But if thread B released the mutex soon enough, that thread A could proceed happily and everything works. 6) From this point, the body of the POST is never read from the client, and there is nothing to be proxy'd to the origin server, and both the consumer and producer tasks are never scheduled to run again -- or until the client times out. I tried setting the client-side time out to as long as 3-5 minutes and TS really does not recover by itself until the client closed the connection. This is the first time I uses this bug system. Please let me know how I could produce the configuration files and trace logs, etc. Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-996) HTTPHdr::m_host goes stale if HdrHeap::evacuate_from_str_heaps is called
[ https://issues.apache.org/jira/browse/TS-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182313#comment-13182313 ] Leif Hedstrom commented on TS-996: -- I think the V2 patch is missing some changes (the header definitions for sure). Can you please update with a new patch, and I'll review it. Thanks! HTTPHdr::m_host goes stale if HdrHeap::evacuate_from_str_heaps is called Key: TS-996 URL: https://issues.apache.org/jira/browse/TS-996 Project: Traffic Server Issue Type: Bug Components: HTTP, MIME Affects Versions: 3.1.0 Reporter: B Wyatt Fix For: 3.1.2 Attachments: m_host.V2.patch, m_host.patch class HTTPHdr stores a copy of the string pointer from either the URLimpl or the MIMEHdr for the host name in m_host. In both cases, these strings can be moved to a new heap underneath the HTTPHdr. When this happens, the process will, at best read stale memory and be fine and at worst read unmapped memory and segfault. Currently, HdrHeap::evacuate_from_str_heaps is called to coalesce multiple heaps into a single heap. When this happens it will directly access the low level objects via ::move_strings calls. These objects do not posses the necessary information to inform parent objects about the change, nor does the HdrHeap directly inform interested parties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults
[ https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181480#comment-13181480 ] Leif Hedstrom commented on TS-1035: --- Brian: Would you mind incorporating Igor's suggestions into a new patch? EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults --- Key: TS-1035 URL: https://issues.apache.org/jira/browse/TS-1035 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Fix For: 3.1.2 Attachments: LargeNumberOfPorts.patch, UnixEventProcessor.patch The easiest way to see this bug is to use several hundred ports with accept threads turned on. The bug exists because in I_EventProcessor.h there is a hard coded limit of 512 event threads and there is no check in spawn_thread that you haven't exceeded that limit so it will result in a segfault if you're creating too many threads. From what I can tell the best solution is an assertion that you haven't exceeded MAX_EVENT_THREADS. Patch is included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181723#comment-13181723 ] Leif Hedstrom commented on TS-1045: --- James: Do you want me to review and commit the patch in https://issues.apache.org/jira/secure/attachment/12509025/0001-Add-new-public-API-TSFetchHdrGet.patch ? PATCH: add new TSFetchHdrGet API Key: TS-1045 URL: https://issues.apache.org/jira/browse/TS-1045 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.2 Attachments: 0001-Add-new-public-API-TSFetchHdrGet.patch, 0007-Add-new-public-API-TSFetchHdrGet.patch, TS-1045-formatting.diff TSFetchUrl does not provide any way to get the headers from the result. This patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet() and returns the headers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.
[
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181744#comment-13181744
]
Leif Hedstrom commented on TS-1073:
---
Hi Kevin!
Thanks for the bug, and patch. Would you mind attaching the patch as a real
attachement? It makes review (and commiting) it a lot easier.
Cheers,
-- Leif
no_dns_just_forward_to_parent configuration parameter is ignored/not used.
--
Key: TS-1073
URL: https://issues.apache.org/jira/browse/TS-1073
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.0.2
Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Fix For: 3.1.2
I have two instances of trafficserver configured, one instance is configured
to use the second instance as a parent proxy using the following parameters
from the records.config:
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
The parent config looks like this:
dest_domain=. parent=parent:8080 round_robin=false
The no_dns_just_forward_to_parent is not used in the code and as a result dns
lookups are being performed in the child instance.
The following code changes seem to fix this:
proxy/http/HttpSM.cc
@@ -6406,11 +6405,20 @@
t_state.dns_info.lookup_success = true;
call_transact_and_set_next_state(NULL);
break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED
t_state.dns_info.lookup_success) {
// Already set, and we don't have a parent proxy to lookup
ink_assert(t_state.host_db_info.ip());
Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup,
provided by plugin);
call_transact_and_set_next_state(NULL);
break;
+ } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER
+ t_state.http_config_param-no_dns_forward_to_parent){
+
+if(t_state.cop_test_page) {
+t_state.host_db_info.ip()
=t_state.state_machine-ua_session-get_netvc()-get_local_ip();
+}
+
+t_state.dns_info.lookup_success = true;
+call_transact_and_set_next_state(NULL);
+break;
}
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
to avoid reverse ns lookups
/proxy/http/HttpTransact.cc
@@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9'
s-dns_info.lookup_name[0] = '0'
//(s-state_machine-authAdapter.needs_rev_dns() ||
- ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)) {
+ ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)
+ !s-http_config_param-no_dns_forward_to_parent) {
// note, broken logic: ACC fudges the OR stmt to always be true,
// 'AuthHttpAdapter' should do the rev-dns if needed, not here .
TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
I would like to have these changes applied to the repository if they look ok.
I also created an empty resolv.conf and pointed ats to the empty file:
CONFIG proxy.config.dns.resolv_conf STRING
/usr/local/etc/trafficserver/resolv.conf
When these changes are applied the child instance no longer attempts to
perform dns lookups for the
http requests that it receives. If they are not applied and the dns lookup it
slow or unreliable on the
child then the http requests are blocked by the dns lookup within the child
trafficserver instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1008) TCP connection data isn't available from TSHttpSsn Object
[ https://issues.apache.org/jira/browse/TS-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181747#comment-13181747 ] Leif Hedstrom commented on TS-1008: --- Nick: Can we close this? TCP connection data isn't available from TSHttpSsn Object - Key: TS-1008 URL: https://issues.apache.org/jira/browse/TS-1008 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.1 Reporter: Nick Kew Assignee: Nick Kew Fix For: 3.1.2 TCP connection data can be obtained through several API functions, such as TSHttpTxnClientAddrGet. But the connection naturally belongs not to the TXN object but to the SSN object. There should be a TSHttpSsn*AddrGet family of functions that can be used in a SSN_START (or any later) hook to obtain connection information. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1049) TS hangs (dead lock) on HTTPS POST requests
[ https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181861#comment-13181861 ] Leif Hedstrom commented on TS-1049: --- Interesting.Did you try turning off sharing origin connections (or setting it to 2, which creates a connection pool per thread)? Not saying that's a fix, but curious to hear if it helps (and if it does, it's a viable work around). I'll also look at your suggested patch, and see if it makes sense :) Thanks! -- leif TS hangs (dead lock) on HTTPS POST requests --- Key: TS-1049 URL: https://issues.apache.org/jira/browse/TS-1049 Project: Traffic Server Issue Type: Bug Components: Core, HTTP, SSL Affects Versions: 3.1.1, 3.1.0, 3.0.2 Environment: RedHat Enterprise Linux 6.0, Intel 32-bit Reporter: Wilson Ho Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 Attachments: records.config A very reproducible bug where the body of a HTTPS POST request is never forwarded to the origin server. Client submits a HTTPS POST request to TS, which is supposed to forward to the backend/origin server via HTTP. TS process the HTTP headers and establishes connection to the origin server, but the body of the HTTPS POST is never read. This hangs until the client times out and shuts down the connection. To reproduce: 1) Client connects to TS using HTTPS (works OK if it is just HTTP). 2) It must be a POST request. 3) TS must use at least 2 worker threads. 4) Easier to reproduce when the connections to the origin server is HTTP (not HTTPS). 5) POST body must be large enough so that the HTTP request headers and POST body do *NOT* fit within the same TCP packet. (2000 bytes is a good size) 6) I can consistently reproduce this problem using 2 separate clients each simultaneously submitting 2 requests back to back (i.e., 2 requests from each client, a total of 4 requests). This gives you a high probability that at least one of the requests would hang. Observation: 1) Thread A accepted and processed the HTTP headers, and called UnixNetProcessor::connect_re to prepare a new connection to the origin server. 2) Thread A must not have read the body of the POST. Otherwise, it works fine. 3) Thread B was assigned the task to handle the origin server connection. If the same thread A was picked, then everything works fine. 4) Apparently, one of the first things that thread B does is to acquire the mutex for reading from the client. (Why does it do that??) 5) While thread B was holding the mutex, thread A proceeded in SSLNetVConnection::net_read_io, tried and failed to acquire the mutex. Thread A typically re-tried calling SSLNetVConnection::net_read_io soon, but gave up after the second failure. But if thread B released the mutex soon enough, that thread A could proceed happily and everything works. 6) From this point, the body of the POST is never read from the client, and there is nothing to be proxy'd to the origin server, and both the consumer and producer tasks are never scheduled to run again -- or until the client times out. I tried setting the client-side time out to as long as 3-5 minutes and TS really does not recover by itself until the client closed the connection. This is the first time I uses this bug system. Please let me know how I could produce the configuration files and trace logs, etc. Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-981) ATS as transparent proxy crashes under heavy load
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181863#comment-13181863 ] Leif Hedstrom commented on TS-981: -- I'm curious if you have only got this to reproduce in transparent proxy, or if it happens in reverse or forward proxy as well? Also, can you reproduce it with a debug build? It would (hopefully) have more information. ATS as transparent proxy crashes under heavy load - Key: TS-981 URL: https://issues.apache.org/jira/browse/TS-981 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.0 Environment: 4 core desktop. Centos 5.6, kernel 2.6.39.2 compiled with TPROXY support. ATS compiled as: ./configure --enable-tproxy --enable-libev Reporter: Danny Shporer Priority: Critical Fix For: 3.1.2 Attachments: records.config ATS crashes under heavy load testing - around 25,000 HTTP transactions per second. I have tested it on both vesions 3.0.0 and 3.0.1 and the same happens. GDB info: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42174940 (LWP 6663)] 0x0068fd4b in modify (this=0x2b12c628, event=value optimized out, e=value optimized out) at P_UnixNet.h:536 536 fd_change(event_loop-eio, eio.fd, 0); (gdb) bt #0 0x0068fd4b in modify (this=0x2b12c628, event=value optimized out, e=value optimized out) at P_UnixNet.h:536 #1 NetHandler::mainNetEvent (this=0x2b12c628, event=value optimized out, e=value optimized out) at UnixNet.cc:432 #2 0x006bfc4f in EThread::process_event (this=0x2b12b010, e=0xf44570, calling_code=5) at I_Continuation.h:146 #3 0x006c055c in EThread::execute (this=0x2b12b010) at UnixEThread.cc:262 #4 0x006bef8e in spawn_thread_internal (a=0xf35c90) at Thread.cc:88 #5 0x003e9dc0673d in start_thread () from /lib64/libpthread.so.0 #6 0x003e9d0d44bd in clone () from /lib64/libc.so.6 (gdb) info f Stack level 0, frame at 0x42174030: rip = 0x68fd4b in modify (P_UnixNet.h:536); saved rip 0x6bfc4f inlined into frame 1 source language c++. Arglist at unknown address. Locals at unknown address, Previous frame's sp in rsp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-980) change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
[
https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181865#comment-13181865
]
Leif Hedstrom commented on TS-980:
--
Is this ready for review? If so, please assign it to me, and I'll take a look.
Thanks!
-- leif
change client_session schedule from global to thread local, and reduce the
try_locks in UnixNetVConnection::reenable
-
Key: TS-980
URL: https://issues.apache.org/jira/browse/TS-980
Project: Traffic Server
Issue Type: Improvement
Components: Network, Performance
Affects Versions: 3.1.0, 3.0.0
Environment: all
Reporter: weijin
Assignee: weijin
Fix For: 3.1.2
Attachments: ts-980.diff
I did some performance test on ats last days(disable cache, set share_server
session 2, pure proxy mode), I did see significant improvement on low load,
but it dropped rapidly when load is high. meanwhile, some stability problems
happened. Through gdb, I found the client_session`s mutex can be acquired by
two or more threads, I believe some schedules happened during the sm
life_time. May be we need do some work to find these eventProcessor.schedules
and change them to thread schedules.
UnixVConnecton::reenable {
if (nh-mutex-thread_holding == t) {
// put into ready_list
} else {
MUTEX_TRY_LOCK(lock, nh-mutex, t);
if (!lock) {
// put into enable_list;
} else {
// put into ready_list;
}
}
remove UnixNetVConnection::reenable try_lock operations, 3 reasons
1. try_lock operation means obj allocation and deallocation operation.
frequently
2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule
by as soon as possible)
3. try_lock should not acquire the net-handler`s mutex. That may lead more
net io latency if it is an epoll event need to be processed in other threads.
If it is not an epoll event(time event), I don`t think putting vc in
ready_list has any advantage than in enable_list.
may be we can change reenale function like this:
UnixVConnecton::reenable {
if (nh-mutex-thread_holding == t) {
// put into ready_list;
} else {
// put into enable_list;
}
my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1072) No transactions per second available in traffic server 3.0
[ https://issues.apache.org/jira/browse/TS-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181095#comment-13181095 ] Leif Hedstrom commented on TS-1072: --- Hmmm, it works for me: $ sudo /opt/ats/bin/traffic_line -r proxy.node.http.user_agent_xacts_per_second cachedir = '/opt/ats/var/trafficserver' 100.080086 Are you sure you are running both traffic_server and traffic_manager on this box? No transactions per second available in traffic server 3.0 -- Key: TS-1072 URL: https://issues.apache.org/jira/browse/TS-1072 Project: Traffic Server Issue Type: Bug Components: Stats Affects Versions: 3.0.1 Environment: CentOS 5.7 Reporter: Steve Owens The following command yields an error which is not in accordance with the currently available documentation for traffic server: /tmp /opt/trafficserver/bin/traffic_line -r proxy.node.http.user_agent_xacts_per_second /opt/trafficserver/bin/traffic_line: Variable Not Found How can we get the basic statistic related to how many transactions per second the traffic server is handling. This is needed for capacity planning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1024) remap_required 0 not functioning in revproxy mode
[ https://issues.apache.org/jira/browse/TS-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13179820#comment-13179820 ] Leif Hedstrom commented on TS-1024: --- Ideally we'd fix it so that parent proxying doesn't require a remap rule (unless remap.required == 1). remap_required 0 not functioning in revproxy mode - Key: TS-1024 URL: https://issues.apache.org/jira/browse/TS-1024 Project: Traffic Server Issue Type: Bug Components: Remap API Affects Versions: 3.0.2 Reporter: Greg Dallavalle Assignee: Leif Hedstrom Priority: Minor Labels: parent, remap_required Fix For: 3.1.2 with [records.config] proxy.config.url_remap.remap_required INT 0 proxy.config.http.parent_proxy_routing_enable INT 1 proxy.config.http.no_dns_just_forward_to_parent INT 1 ATS still requires a remap URL to be used. The way I worked around this was to have remapped URLs to themselves: [remap.config] map http://example.com http://example.com map http://sub.example.com http://sub.example.com With those settings all requests are passed through to my origin, or parent cache servers. The pass to the parent cache did not work in 3.0.1. I had to build from the 3.0.x branch for this to function. [parent.config] dest_domain=. parent=1.2.3.4:80; 4.5.6.7:80 round_robin=strict I think this is convoluted given my fairly common setup of two reverse proxies caching/load balancing round robin to a few origin servers. I guess the only bug here is that the remap_required parameter is not functioning as well as it could be. I hope for improvement in the way this setup is handled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1048) Add TS API to enable plugins to use traffic server configuration infrastructure
[ https://issues.apache.org/jira/browse/TS-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13177712#comment-13177712 ] Leif Hedstrom commented on TS-1048: --- Bianca: Is the diff.txt patch the final version you want us to review and commit ? Thanks, -- leif Add TS API to enable plugins to use traffic server configuration infrastructure Key: TS-1048 URL: https://issues.apache.org/jira/browse/TS-1048 Project: Traffic Server Issue Type: Improvement Components: Configuration, TS API Environment: Centos 6 Reporter: bianca cooper Assignee: Leif Hedstrom Priority: Minor Labels: api-addition, configuration Fix For: 3.1.2 Attachments: diff.txt Original Estimate: 72h Remaining Estimate: 72h Export RecRegisterConfigInt and RecRegisterConfigString to enable adding a configuration record to the records hashtable. Once plugin new configuration records should be added, the addition will be done by calling the API in the plugin code. No need to add the record to RecordsConfig static array. No need to recompile the ATS each time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-254) Add TSEscapifyString() and TSUnescapifyString()
[ https://issues.apache.org/jira/browse/TS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172903#comment-13172903 ] Leif Hedstrom commented on TS-254: -- yes. Add TSEscapifyString() and TSUnescapifyString() Key: TS-254 URL: https://issues.apache.org/jira/browse/TS-254 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 3.0.0 Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 It would be very convenient for plugin developers to have SDK APIs that allows for escaping and unescaping of strings. E.g. TSEscapifyString(http://www.ogre.com/ogre.png;) - http%3A%2F%2Fwww.ogre.com%2Fogre.png TSUnescapifyString(http%3A%2F%2Fwww.ogre.com%2Fogre.png) - http://www.ogre.com/ogre.png The unescapify string is fairly straight forward, but the escapify version might benefit from taking an (optional) table which describes what characters needs to be escaped (e.g. in in some cases you want a / to be escaped, but in others you do not). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-254) Add TSEscapifyString() and TSUnescapifyString()
[ https://issues.apache.org/jira/browse/TS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172905#comment-13172905 ] Leif Hedstrom commented on TS-254: -- Actually, i was going to leave out the URL part, beacuse this really isnt just for URL. Not sure about Encode vs Escape though, I guess, but I thought it was generally referred to as escaping, no ? Add TSEscapifyString() and TSUnescapifyString() Key: TS-254 URL: https://issues.apache.org/jira/browse/TS-254 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 3.0.0 Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 It would be very convenient for plugin developers to have SDK APIs that allows for escaping and unescaping of strings. E.g. TSEscapifyString(http://www.ogre.com/ogre.png;) - http%3A%2F%2Fwww.ogre.com%2Fogre.png TSUnescapifyString(http%3A%2F%2Fwww.ogre.com%2Fogre.png) - http://www.ogre.com/ogre.png The unescapify string is fairly straight forward, but the escapify version might benefit from taking an (optional) table which describes what characters needs to be escaped (e.g. in in some cases you want a / to be escaped, but in others you do not). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-992) Generic portability fixes.
[ https://issues.apache.org/jira/browse/TS-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171637#comment-13171637 ] Leif Hedstrom commented on TS-992: -- I've committed all these patches to the trunk. Thanks! Generic portability fixes. -- Key: TS-992 URL: https://issues.apache.org/jira/browse/TS-992 Project: Traffic Server Issue Type: Improvement Environment: OpenBSD Reporter: Piotr Sikora Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.2 Attachments: 0001-iocore-s-swap-ts_swap-g.patch, 0001-iocore-s-swap-ts_swap-g.patch, 0002-iocore-don-t-mix-old-and-new-arpa-nameser.h-interfac.patch, 0003-mgmt-drop-getnetparms-it-isn-t-used-anywhere.patch, 0004-iocore-fix-incorrect-HostDBProcessor-getby-call.patch, 0005-tests-add-missing-link-time-flags.patch, 0006-proxy-NULL-is-defined-in-unistd.h.patch, 0007-iocore-guard-against-missing-ENOSR-and-EPROTO-defini.patch, 0008-proxy-fix-usage-of-NEED_ALTZONE_DEFINED.patch, 0009-proxy-fix-off-by-one-error-in-sscanf.patch, 0010-autoconf-improve-detection-of-available-system-heade.patch, 0011-mgmt-cast-localtime-argument-to-const-time_t.patch, 0012-examples-add-missing-sys-types.h-header.patch Bunch of patches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13168519#comment-13168519 ] Leif Hedstrom commented on TS-1045: --- Reading this, and the code, I'm starting to wonder if TSFetchPageRespGet() is a broken API ? I mean, the differences between it, and the new TSFetchHdrGet(), is simply getting the header from the response. Is there ever a case when we need all three of these APIs (TSFetchPageRespGet(), TSFetchRespGet() and TSFetchHdrGet() ) ? PATCH: add new TSFetchHdrGet API Key: TS-1045 URL: https://issues.apache.org/jira/browse/TS-1045 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.2 Attachments: 0007-Add-new-public-API-TSFetchHdrGet.patch TSFetchUrl does not provide any way to get the headers from the result. This patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet() and returns the headers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13168541#comment-13168541 ] Leif Hedstrom commented on TS-1045: --- I'm honestly not sure what the intention was here... There seems to be overlap for sure. I mean, if TSFetchPageRespGet() returns the full response, then why do we need TSFetchRespGet()? That's why I'm wondering that we either a) Keep only TSFetchPageRespGet(), and expose appropriate APIs to get stuff out of it. or b) Eliminate TSFetchPageRespGet(), and only keep TSFetchRespGet() and a new TSFetchHdrGet() Or is there ever a case where we'd need all three ? PATCH: add new TSFetchHdrGet API Key: TS-1045 URL: https://issues.apache.org/jira/browse/TS-1045 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.2 Attachments: 0007-Add-new-public-API-TSFetchHdrGet.patch TSFetchUrl does not provide any way to get the headers from the result. This patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet() and returns the headers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1042) PATCH: correct debug message in FetchSM
[ https://issues.apache.org/jira/browse/TS-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13166222#comment-13166222 ] Leif Hedstrom commented on TS-1042: --- Hmmm, why %*.*s, length, length) ? Everywhere else we just do %.*s, length, string) PATCH: correct debug message in FetchSM --- Key: TS-1042 URL: https://issues.apache.org/jira/browse/TS-1042 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: James Peach Assignee: Igor Galić Priority: Minor Fix For: 3.1.2 Attachments: 0004-Fix-FetchSM-debugging-message.patch In the FetchSM module, there is a debug message that can walk off the end of the buffer. This patch corrects that by limiting the printed string to the known length. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-937) EThread::execute still processing cancelled event
[
https://issues.apache.org/jira/browse/TS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13166718#comment-13166718
]
Leif Hedstrom commented on TS-937:
--
Sold.
I did add a --disable-freelist configure option a while ago, which turns the
freelist into malloc/free calls (I hope at least, unless I fucked it up :). The
thought was that we'd use this option for memory debugging either with
valgrind, or e.g. tcmalloc.
EThread::execute still processing cancelled event
-
Key: TS-937
URL: https://issues.apache.org/jira/browse/TS-937
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.1, 2.1.9
Environment: RHEL6
Reporter: Brian Geffon
Fix For: 3.1.2
Attachments: UnixEThread.patch
The included GDB log will show that ATS is trying to process an event that
has already been canceled, examining the code of UnixEThread.cc line 232
shows that EThread::process_event gets called without a check for the event
being cancelled.
Brian
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x764fa700 (LWP 28518)]
0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64
keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.1.x86_64
libcom_err-1.41.12-7.el6.x86_64 libgcc-4.4.5-6.el6.x86_64
libselinux-2.0.94-5.el6.x86_64 libstdc++-4.4.5-6.el6.x86_64
openssl-1.0.0-10.el6_1.4.x86_64 pcre-7.8-3.1.el6.x86_64
tcl-8.5.7-6.el6.x86_64 zlib-1.2.3-25.el6.x86_64
(gdb) bt
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
(gdb) bt full
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
lock = {m = {m_ptr = 0x764f9d20}, lock_acquired = 202}
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
done_one = false
e = 0x1db45c0
NegativeQueue = {DLLEvent, Event::Link_link = {head = 0xfc75f0},
tail = 0xfc75f0}
next_time = 1314647904419648000
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
p = 0xfb7e80
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb) f 0
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
(gdb) p *e
$2 = {Action = {_vptr.Action = 0x775170, continuation = 0x1f2fc08, mutex =
{m_ptr = 0x7fffd40fba40}, cancelled = 1}, ethread = 0x768ff010,
in_the_prot_queue = 0, in_the_priority_queue = 0,
immediate = 1, globally_allocated = 1, in_heap = 0, callback_event = 1,
timeout_at = 0, period = 0, cookie = 0x0, link = {SLinkEvent = {next =
0x0}, prev = 0x0}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-937) EThread::execute still processing cancelled event
[
https://issues.apache.org/jira/browse/TS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164103#comment-13164103
]
Leif Hedstrom commented on TS-937:
--
I saw a bunch of TS_HAS_PURIFY while doing all the memory allocation changes.
Should we just nuke that sucker, now that we have jemalloc / tcmalloc support ?
I have no idea if the purify stuff actually works?
Although in this case, no idea why we'd make a special case here for purify...
EThread::execute still processing cancelled event
-
Key: TS-937
URL: https://issues.apache.org/jira/browse/TS-937
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.1, 2.1.9
Environment: RHEL6
Reporter: Brian Geffon
Fix For: 3.1.2
Attachments: UnixEThread.patch
The included GDB log will show that ATS is trying to process an event that
has already been canceled, examining the code of UnixEThread.cc line 232
shows that EThread::process_event gets called without a check for the event
being cancelled.
Brian
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x764fa700 (LWP 28518)]
0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64
keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.1.x86_64
libcom_err-1.41.12-7.el6.x86_64 libgcc-4.4.5-6.el6.x86_64
libselinux-2.0.94-5.el6.x86_64 libstdc++-4.4.5-6.el6.x86_64
openssl-1.0.0-10.el6_1.4.x86_64 pcre-7.8-3.1.el6.x86_64
tcl-8.5.7-6.el6.x86_64 zlib-1.2.3-25.el6.x86_64
(gdb) bt
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
(gdb) bt full
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
lock = {m = {m_ptr = 0x764f9d20}, lock_acquired = 202}
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
done_one = false
e = 0x1db45c0
NegativeQueue = {DLLEvent, Event::Link_link = {head = 0xfc75f0},
tail = 0xfc75f0}
next_time = 1314647904419648000
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
p = 0xfb7e80
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb) f 0
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
(gdb) p *e
$2 = {Action = {_vptr.Action = 0x775170, continuation = 0x1f2fc08, mutex =
{m_ptr = 0x7fffd40fba40}, cancelled = 1}, ethread = 0x768ff010,
in_the_prot_queue = 0, in_the_priority_queue = 0,
immediate = 1, globally_allocated = 1, in_heap = 0, callback_event = 1,
timeout_at = 0, period = 0, cookie = 0x0, link = {SLinkEvent = {next =
0x0}, prev = 0x0}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-837) ATS fails to compile with gcc 4.6.1 with --enable-debug
[
https://issues.apache.org/jira/browse/TS-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163067#comment-13163067
]
Leif Hedstrom commented on TS-837:
--
What's the status here ? I'm compiling with gcc 4.6.2 without problems.
ATS fails to compile with gcc 4.6.1 with --enable-debug
---
Key: TS-837
URL: https://issues.apache.org/jira/browse/TS-837
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.0
Environment: Linux, Debian, Amd64 + GCC 4.6.1
Reporter: Igor Galić
Assignee: Igor Galić
Fix For: 3.1.4
Attachments: proxything.diff
{noformat}
In file included from ../../proxy/ControlMatcher.h:104:0,
from ../../proxy/ParentSelection.h:37,
from P_Socks.h:30,
from P_Net.h:106,
from Connection.cc:34:
../../proxy/hdrs/HTTP.h: In member function 'INK_MD5
HTTPInfo::object_key_get()':
../../proxy/hdrs/HTTP.h:1375:24: error: dereferencing type-punned pointer
will break strict-aliasing rules [-Werror=strict-aliasing]
../../proxy/hdrs/HTTP.h: In member function 'int64_t
HTTPInfo::object_size_get()':
../../proxy/hdrs/HTTP.h:1405:24: error: dereferencing type-punned pointer
will break strict-aliasing rules [-Werror=strict-aliasing]
../../proxy/hdrs/HTTP.h: In member function 'void
HTTPInfo::object_size_set(int64_t)':
../../proxy/hdrs/HTTP.h:1422:51: error: dereferencing type-punned pointer
will break strict-aliasing rules [-Werror=strict-aliasing]
cc1plus: all warnings being treated as errors
*** [Connection.o] Error 1
make[2]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore/net'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore'
make: *** [all-recursive] Error 1
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1027) remap.config limited to ~255 entries
[
https://issues.apache.org/jira/browse/TS-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162588#comment-13162588
]
Leif Hedstrom commented on TS-1027:
---
Test it :). Yes, there will be some penalty, but it also depends on your
configs. There's an initial hash on the hostname, so if you have unique
hostnames on each remap rule, it ought to be O(1). However, degenerated cases
with lots of rules for the same host could have some performance implications
(however, it does a trie on the prefix part of the path in that case).
This is in theory though, things might have changed. If you are seeing
performance problems, we should investigate. At a minimum, rules with unique
hostnames should be O(1) always (it's a simple hash table lookup).
remap.config limited to ~255 entries
Key: TS-1027
URL: https://issues.apache.org/jira/browse/TS-1027
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 3.0.2
Reporter: Greg Dallavalle
Remap.config errors out trafficserver when the entries exceed ~249
Due to issue TS-1024 I am using a large number of remaps to workaround the
issue. With this limit I'm unable to proceed with ATS. If there are ways to
overcome these problems, by all means, I'd be happy to listen and test.
The errors from traffic.out:
[Nov 21 15:20:08.572] Server {1080866016} ERROR: Cannot insert duplicate!
[Nov 21 15:20:08.573] Server {1080866016} ERROR: Couldn't insert into trie!
[Nov 21 15:20:08.573] Server {1080866016} ERROR: Could not insert new mapping
[Nov 21 15:20:08.573] Server {1080866016} WARNING: Could not add rule at line
#249; Aborting!
[Nov 21 15:20:08.578] Server {1080866016} WARNING: [ReverseProxy] Unable to
add mapping rule to lookup table at line 249
FATAL: [ReverseProxy] Unable to add mapping rule to lookup table at line 249
/usr/bin/traffic_server - STACK TRACE:
/usr/lib/trafficserver/libtsutil.so.3(ink_fatal_va+0xf7)[0x400301a7]
/usr/lib/trafficserver/libtsutil.so.3(ink_fatal+0x2c)[0x4003020c]
/usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x5a2)[0x819b402]
/usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x337)[0x819da87]
/usr/bin/traffic_server(_Z18init_reverse_proxyv+0x9a)[0x810bb6a]
/usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x814664b]
/usr/bin/traffic_server(main+0x12bb)[0x80b547b]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x40561113]
/usr/bin/traffic_server[0x80baffd]
[Nov 21 15:20:08.638] Manager {3072087760} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: (last system error 2: No
such file or directory)
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: (last system error 2: No
such file or directory)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults
[ https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13159777#comment-13159777 ] Leif Hedstrom commented on TS-1035: --- Perhaps time to either make this limit records.config'urable, or bigger? What do you think ? EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults --- Key: TS-1035 URL: https://issues.apache.org/jira/browse/TS-1035 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Attachments: UnixEventProcessor.patch The easiest way to see this bug is to use several hundred ports with accept threads turned on. The bug exists because in I_EventProcessor.h there is a hard coded limit of 512 event threads and there is no check in spawn_thread that you haven't exceeded that limit so it will result in a segfault if you're creating too many threads. From what I can tell the best solution is an assertion that you haven't exceeded MAX_EVENT_THREADS. Patch is included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1033) Add some missing WKS's to HdrToken.
[ https://issues.apache.org/jira/browse/TS-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13157957#comment-13157957 ] Leif Hedstrom commented on TS-1033: --- Here are a few to add: DNT P3P X-Powered-By Store Post-Check Pre-Check X-Content-Type-Options X-XSS-Protection X-Frame-Options X-AspNet-Version 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] [Commented] (TS-1027) remap.config limited to ~255 entries
[
https://issues.apache.org/jira/browse/TS-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13154838#comment-13154838
]
Leif Hedstrom commented on TS-1027:
---
Are you sure you do not have a duplicated rule? As the error message suggests,
it does not allow you to have duplicated rules (rules that would resolve the
same). This is because of the way the trie works.
remap.config limited to ~255 entries
Key: TS-1027
URL: https://issues.apache.org/jira/browse/TS-1027
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 3.0.2
Reporter: Greg Dallavalle
Remap.config errors out trafficserver when the entries exceed ~249
Due to issue TS-1024 I am using a large number of remaps to workaround the
issue. With this limit I'm unable to proceed with ATS. If there are ways to
overcome these problems, by all means, I'd be happy to listen and test.
The errors from traffic.out:
[Nov 21 15:20:08.572] Server {1080866016} ERROR: Cannot insert duplicate!
[Nov 21 15:20:08.573] Server {1080866016} ERROR: Couldn't insert into trie!
[Nov 21 15:20:08.573] Server {1080866016} ERROR: Could not insert new mapping
[Nov 21 15:20:08.573] Server {1080866016} WARNING: Could not add rule at line
#249; Aborting!
[Nov 21 15:20:08.578] Server {1080866016} WARNING: [ReverseProxy] Unable to
add mapping rule to lookup table at line 249
FATAL: [ReverseProxy] Unable to add mapping rule to lookup table at line 249
/usr/bin/traffic_server - STACK TRACE:
/usr/lib/trafficserver/libtsutil.so.3(ink_fatal_va+0xf7)[0x400301a7]
/usr/lib/trafficserver/libtsutil.so.3(ink_fatal+0x2c)[0x4003020c]
/usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x5a2)[0x819b402]
/usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x337)[0x819da87]
/usr/bin/traffic_server(_Z18init_reverse_proxyv+0x9a)[0x810bb6a]
/usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x814664b]
/usr/bin/traffic_server(main+0x12bb)[0x80b547b]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x40561113]
/usr/bin/traffic_server[0x80baffd]
[Nov 21 15:20:08.638] Manager {3072087760} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: (last system error 2: No
such file or directory)
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: (last system error 2: No
such file or directory)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1027) remap.config limited to ~255 entries
[
https://issues.apache.org/jira/browse/TS-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13154864#comment-13154864
]
Leif Hedstrom commented on TS-1027:
---
No worries. Does that mean we can close this ticket?
remap.config limited to ~255 entries
Key: TS-1027
URL: https://issues.apache.org/jira/browse/TS-1027
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 3.0.2
Reporter: Greg Dallavalle
Remap.config errors out trafficserver when the entries exceed ~249
Due to issue TS-1024 I am using a large number of remaps to workaround the
issue. With this limit I'm unable to proceed with ATS. If there are ways to
overcome these problems, by all means, I'd be happy to listen and test.
The errors from traffic.out:
[Nov 21 15:20:08.572] Server {1080866016} ERROR: Cannot insert duplicate!
[Nov 21 15:20:08.573] Server {1080866016} ERROR: Couldn't insert into trie!
[Nov 21 15:20:08.573] Server {1080866016} ERROR: Could not insert new mapping
[Nov 21 15:20:08.573] Server {1080866016} WARNING: Could not add rule at line
#249; Aborting!
[Nov 21 15:20:08.578] Server {1080866016} WARNING: [ReverseProxy] Unable to
add mapping rule to lookup table at line 249
FATAL: [ReverseProxy] Unable to add mapping rule to lookup table at line 249
/usr/bin/traffic_server - STACK TRACE:
/usr/lib/trafficserver/libtsutil.so.3(ink_fatal_va+0xf7)[0x400301a7]
/usr/lib/trafficserver/libtsutil.so.3(ink_fatal+0x2c)[0x4003020c]
/usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x5a2)[0x819b402]
/usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x337)[0x819da87]
/usr/bin/traffic_server(_Z18init_reverse_proxyv+0x9a)[0x810bb6a]
/usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x814664b]
/usr/bin/traffic_server(main+0x12bb)[0x80b547b]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x40561113]
/usr/bin/traffic_server[0x80baffd]
[Nov 21 15:20:08.638] Manager {3072087760} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: (last system error 2: No
such file or directory)
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: (last system error 2: No
such file or directory)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-988) Upgrade ICP support for IPv6
[
https://issues.apache.org/jira/browse/TS-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133510#comment-13133510
]
Leif Hedstrom commented on TS-988:
--
Also, trying to start traffic_manager gives
[Oct 22 17:01:46.214] Manager {0x7fb82c87d800} FATAL: [LocalManager::initCCom]
Unable to find IPv4 network interface lo. Exiting...
[Oct 22 17:01:46.214] Manager {0x7fb82c87d800} FATAL: (last system error 2: No
such file or directory)
Upgrade ICP support for IPv6
Key: TS-988
URL: https://issues.apache.org/jira/browse/TS-988
Project: Traffic Server
Issue Type: Improvement
Components: Clustering
Affects Versions: 3.1.0
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Priority: Minor
Labels: icp, ipv6
Fix For: 3.1.2
Make ICP compatible with IPv6.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-988) Upgrade ICP support for IPv6
[
https://issues.apache.org/jira/browse/TS-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133509#comment-13133509
]
Leif Hedstrom commented on TS-988:
--
Alan: Even with ICP disabled, when I start up, I get
[Oct 22 17:00:52.259] Server {0x7f02d58be800} WARNING: ICP interface [(null)]
has no IP address
[Oct 22 17:00:52.259] Server {0x7f02d58be800} WARNING: ICP interface has no IP
address
[Oct 22 17:00:52.259] Server {0x7f02d58be800} WARNING: ICP setup, no defined
send Peer(s)
[Oct 22 17:00:52.259] Server {0x7f02d58be800} WARNING: ICP setup, no defined
send Peer(s)
Upgrade ICP support for IPv6
Key: TS-988
URL: https://issues.apache.org/jira/browse/TS-988
Project: Traffic Server
Issue Type: Improvement
Components: Clustering
Affects Versions: 3.1.0
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Priority: Minor
Labels: icp, ipv6
Fix For: 3.1.2
Make ICP compatible with IPv6.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-992) Generic portability fixes.
[ https://issues.apache.org/jira/browse/TS-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132296#comment-13132296 ] Leif Hedstrom commented on TS-992: -- Just took a quick glance, but lets make sure we use the ats_ prefix for core code, and not use the ts_ prefix. The TS prefix is reserved for public APIs. Generic portability fixes. -- Key: TS-992 URL: https://issues.apache.org/jira/browse/TS-992 Project: Traffic Server Issue Type: Improvement Environment: OpenBSD Reporter: Piotr Sikora Priority: Minor Attachments: 0001-iocore-s-swap-ts_swap-g.patch, 0002-iocore-don-t-mix-old-and-new-arpa-nameser.h-interfac.patch, 0003-mgmt-drop-getnetparms-it-isn-t-used-anywhere.patch, 0004-iocore-fix-incorrect-HostDBProcessor-getby-call.patch, 0005-tests-add-missing-link-time-flags.patch, 0006-proxy-NULL-is-defined-in-unistd.h.patch, 0007-iocore-guard-against-missing-ENOSR-and-EPROTO-defini.patch, 0008-proxy-fix-usage-of-NEED_ALTZONE_DEFINED.patch, 0009-proxy-fix-off-by-one-error-in-sscanf.patch, 0010-autoconf-improve-detection-of-available-system-heade.patch, 0011-mgmt-cast-localtime-argument-to-const-time_t.patch, 0012-examples-add-missing-sys-types.h-header.patch Bunch of patches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-954) when use raw disks, some blocks is lost when caculate disk usable blocks
[
https://issues.apache.org/jira/browse/TS-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13129862#comment-13129862
]
Leif Hedstrom commented on TS-954:
--
I'm fairly certain this will invalidate the cache. Should we bump either (or
both) of
{code}
#define CACHE_DB_MAJOR_VERSION 21
#define CACHE_DIR_MAJOR_VERSION 18
{code}
to be safe?
when use raw disks, some blocks is lost when caculate disk usable blocks
Key: TS-954
URL: https://issues.apache.org/jira/browse/TS-954
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.1.0
Environment: all when use raw disks
Reporter: weijin
Assignee: John Plevyak
Fix For: 3.1.1
Attachments: calcu_blocks.dff
when use raw disks, some blocks may be lost because the skip variable is in
bytes not in blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-928) Compile problem in TsErrataUtil on FreeBSD 8
[ https://issues.apache.org/jira/browse/TS-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13129207#comment-13129207 ] Leif Hedstrom commented on TS-928: -- Crap, ignore that first line that changes the #include from the .hpp to .h. It should work now with the .hpp. Compile problem in TsErrataUtil on FreeBSD 8 Key: TS-928 URL: https://issues.apache.org/jira/browse/TS-928 Project: Traffic Server Issue Type: Bug Components: Build Affects Versions: 3.0.1 Environment: FreeBSD 8.2, 32-bit, gcc (GCC) 4.2.1 20070719 Reporter: Radim Kolar Labels: build-failure, freebsd, wccp Fix For: 3.1.1 Attachments: TS-928.diff TF with --enable-wccp do not compile on FreeBSD. I have gnu sed, flex and bison updated to their latest versions. /bin/sh ../../libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../lib -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dfreebsd -I/usr/local/include -I/usr/local/include/tcl8.5 -O2 -pipe -march=prescott -fno-strict-aliasing -march=i586 -g -Wall -Werror -O3 -feliminate-unused-debug-symbols -Wno-invalid-offsetof -MT TsErrataUtil.lo -MD -MP -MF .deps/TsErrataUtil.Tpo -c -o TsErrataUtil.lo TsErrataUtil.cc libtool: compile: c++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../lib -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dfreebsd -I/usr/local/include -I/usr/local/include/tcl8.5 -O2 -pipe -march=prescott -fno-strict-aliasing -march=i586 -g -Wall -Werror -O3 -feliminate-unused-debug-symbols -Wno-invalid-offsetof -MT TsErrataUtil.lo -MD -MP -MF .deps/TsErrataUtil.Tpo -c TsErrataUtil.cc -fPIC -DPIC -o .libs/TsErrataUtil.o cc1plus: warnings being treated as errors TsErrataUtil.cc: In function 'ts::Errata ts::msg::vlogf_errno(ts::Errata, ts::NumericTypeunsigned int, ts::MsgIdTag, ts::NumericTypeunsigned int, ts::CodeTag, const char*, char*)': TsErrataUtil.cc:143: warning: format '%s' expects type 'char*', but argument 5 has type 'int' TsErrataUtil.cc:143: warning: format '%s' expects type 'char*', but argument 5 has type 'int' gmake[3]: *** [TsErrataUtil.lo] Error 1 gmake[3]: Leaving directory `/home/hsn/ports/trafficserver/work/trafficserver-3.0.1/lib/tsconfig' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/hsn/ports/trafficserver/work/trafficserver-3.0.1/lib/tsconfig' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/hsn/ports/trafficserver/work/trafficserver-3.0.1/lib' gmake: *** [all-recursive] Error 1 *** Error code 1 Stop in /home/hsn/ports/trafficserver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-948) do not reload bad remap.config
[ https://issues.apache.org/jira/browse/TS-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128222#comment-13128222 ] Leif Hedstrom commented on TS-948: -- Argh, I missed one place ... Fixing it now, thanks for cathing it. And just to be sure, note that we'll fail to startup the first time if the remap file is broken. This is intentional, and I would be hard to convince otherwise. What the changes do is to prevent a running server to exit when you reload the config. do not reload bad remap.config -- Key: TS-948 URL: https://issues.apache.org/jira/browse/TS-948 Project: Traffic Server Issue Type: Improvement Components: Configuration, Management Affects Versions: 3.1.0, 3.0.1 Reporter: Conan Wang Assignee: Leif Hedstrom Priority: Critical Fix For: 3.1.1 traffic_server will exit if exists bad rules in remap.config, whenever startup or reload ( traffic_line -x ). If remap.config is not edited correctly, the server/cluster will crash when reloading. It's better to pre-check the remap table and not switch to the new table if remap.config is not enough correct. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-948) do not reload bad remap.config
[ https://issues.apache.org/jira/browse/TS-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126780#comment-13126780 ] Leif Hedstrom commented on TS-948: -- Let me know if this last commit fixes it. do not reload bad remap.config -- Key: TS-948 URL: https://issues.apache.org/jira/browse/TS-948 Project: Traffic Server Issue Type: Improvement Components: Configuration, Management Affects Versions: 3.1.0, 3.0.1 Reporter: Conan Wang Assignee: Leif Hedstrom Priority: Critical Fix For: 3.1.1 traffic_server will exit if exists bad rules in remap.config, whenever startup or reload ( traffic_line -x ). If remap.config is not edited correctly, the server/cluster will crash when reloading. It's better to pre-check the remap table and not switch to the new table if remap.config is not enough correct. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-948) do not reload bad remap.config
[ https://issues.apache.org/jira/browse/TS-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125265#comment-13125265 ] Leif Hedstrom commented on TS-948: -- Please try the changes on trunk, I'm closing this for now. do not reload bad remap.config -- Key: TS-948 URL: https://issues.apache.org/jira/browse/TS-948 Project: Traffic Server Issue Type: Improvement Components: Configuration, Management Affects Versions: 3.1.0, 3.0.1 Reporter: Conan Wang Assignee: Leif Hedstrom Priority: Critical Fix For: 3.1.1 traffic_server will exit if exists bad rules in remap.config, whenever startup or reload ( traffic_line -x ). If remap.config is not edited correctly, the server/cluster will crash when reloading. It's better to pre-check the remap table and not switch to the new table if remap.config is not enough correct. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-917) url_mapping objects don't seem to be deleted
[
https://issues.apache.org/jira/browse/TS-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125315#comment-13125315
]
Leif Hedstrom commented on TS-917:
--
Manjesh: I took a look at this, and I don't quite see it. First, I tried it by
reloading the remap.config lots of times, and I see no indications of memory
being leaked. ps and valgrind both says there's no leak.
Secondly, looking at the code, it looks like it should free it, e.g.
{code}
forl_LL(T, iter, m_value_list)
delete iter;
m_value_list.clear();
{code}
If I'm not mistaken, this invokes the destructor for the url_mapping. Or are
there other places where this is missing? Perhaps something with URL regexes
(which I didn't test)?
url_mapping objects don't seem to be deleted
Key: TS-917
URL: https://issues.apache.org/jira/browse/TS-917
Project: Traffic Server
Issue Type: Bug
Components: Remap API
Affects Versions: 3.0.0
Reporter: Manjesh Nilange
Assignee: Leif Hedstrom
Fix For: 3.1.1
In the recent changes to data structures in
UrlRewrite/UrlMappingPathIndex/UrlMappingContainer classes, the url_mapping
itself is not deleted, I think. The PathIndex, Trie objects are cleaned up,
but not the url_mapping.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-917) url_mapping objects don't seem to be deleted
[
https://issues.apache.org/jira/browse/TS-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125319#comment-13125319
]
Leif Hedstrom commented on TS-917:
--
Hmmm, no, it looks like the regex maps should also free the url_mapping:
{code}
forl_LL(RegexMapping, list_iter, mappings) {
delete list_iter-url_map;
{code}
Any thoughts? I'd like to clarify this, so we can either close it, or get some
ideas of where exactly we're leaking.
Thanks!
url_mapping objects don't seem to be deleted
Key: TS-917
URL: https://issues.apache.org/jira/browse/TS-917
Project: Traffic Server
Issue Type: Bug
Components: Remap API
Affects Versions: 3.0.0
Reporter: Manjesh Nilange
Assignee: Leif Hedstrom
Fix For: 3.1.1
In the recent changes to data structures in
UrlRewrite/UrlMappingPathIndex/UrlMappingContainer classes, the url_mapping
itself is not deleted, I think. The PathIndex, Trie objects are cleaned up,
but not the url_mapping.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-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=13125453#comment-13125453
]
Leif Hedstrom commented on TS-725:
--
Can someone please try to either reproduce this, or confirm that it is (or
isn't) a problem still? Moving out to 3.1.4 for now.
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.1.1
reported by user:
{code:none}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/ts/bin/traffic_server - STACK TRACE:
[0x4001c420]
/lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
[0xf]
/usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char
const*, int, bool)+0x51)[0x8229631]
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/ts/bin/traffic_server - STACK TRACE:
[0x4001c420]
/lib/tls/i686/cmov/libc.so.6(memcpy+0x15)[0x404a19b5]
[0xf]
/usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*, URLImpl*, char
const*, int, bool)+0x51)[0x8229631]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0xab)[0x816a8eb]
/usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x321)[0x817acc1]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x1a4)[0x8184894]
/usr/local/ts/bin/traffic_server[0x82f880c]
/usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x4ce)[0x82edffe]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x1ff)[0x83226bf]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x449)[0x8322e69]
/usr/local/ts/bin/traffic_server[0x8321abc]
/lib/tls/i686/cmov/libpthread.so.0[0x400284fb]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0x40504e5e]
[Mar 8 11:02:52.960] Manager {3080226496} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmenta
tion fault
[Mar 8 11:02:52.960] Manager {3080226496} ERROR: (last system error 2: No
such file or directory)
[Mar 8 11:02:52.961] Manager {3080226496} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Mar 8 11:02:52.961] Manager {3080226496} ERROR: (last system error 2: No
such file or directory)
[Mar 8 11:02:53.964] Manager {3080226496} NOTE: [LocalManager::startProxy]
Launching ts process
[TrafficServer] using root directory '/usr/local/ts'
[Mar 8 11:02:53.973] Manager {3080226496} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '12'
[Mar 8 11:02:53.973] Manager {3080226496} NOTE: [Alarms::signalAlarm] Server
Process born
[Mar 8 11:02:55.015] {1079500240} STATUS: opened
/usr/local/ts/var/log/trafficserver/diags.log
[Mar 8 11:02:55.015] {1079500240} NOTE: updated diags config
[Mar 8 11:02:55.024] Server {1079500240} NOTE: cache clustering disabled
[Mar 8 11:02:55.069] Server {1079500240} NOTE: cache clustering disabled
[Mar 8 11:02:55.274] Server {1079500240} STATUS: Rolling disabled for
/usr/local/ts/var/log/trafficserver/access.log.pipe
[Mar 8 11:02:55.325] Server {1079500240} NOTE: logging initialized[7],
logging_mode = 3
[Mar 8 11:02:55.368] Server {1079500240} NOTE: traffic server running
[Mar 8 11:02:58.584] Server {1096645520} NOTE: cache enabled
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-968) During/after daily logfile roll, trafficserver seg faults (Sig 11)
[
https://issues.apache.org/jira/browse/TS-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125451#comment-13125451
]
Leif Hedstrom commented on TS-968:
--
Hmmm, I use log rotation all the time, and never see this. Can you give us a
stack trace from this crash?
During/after daily logfile roll, trafficserver seg faults (Sig 11)
--
Key: TS-968
URL: https://issues.apache.org/jira/browse/TS-968
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.0.1
Environment: Ubuntu 10.10, 2.6.35-24-virtual
Reporter: Drew Rothstein
Fix For: 3.1.1
Every day at 00:00:00 after/during the log file roll, I see a segfault. Here
are the past couple days:
[Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
/usr/local/var/log/trafficserver/error.log was rolled to
/usr/local/var/log/trafficserver/error.log_trafficserver02.20110921.00h00m06s-20110922.00h00m00s.old.
[Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
/usr/local/var/log/trafficserver/squid.log was rolled to
/usr/local/var/log/trafficserver/squid.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
[Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
/usr/local/var/log/trafficserver/extended2.log was rolled to
/usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
[Sep 22 00:00:17.729] Manager {140722071643936} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Sep 22 00:00:17.729] Manager {140722071643936} FATAL: (last system error
104: Connection reset by peer)
[Sep 22 00:00:17.730] Manager {140722071643936} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Sep 22 00:00:17.730] Manager {140722071643936} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
[Sep 22 00:00:17.730] Manager {140722071643936} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Sep 22 00:00:17.730] Manager {140722071643936} ERROR: (last system error
32: Broken pipe)
[E. Mgmt] log == [TrafficManager] using root directory '/usr/local'
[Sep 22 00:00:17.786] {140131209512736} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
[Sep 22 00:00:17.786] {140131209512736} NOTE: updated diags config
[Sep 22 00:00:17.805] Manager {140131209512736} NOTE:
[ClusterCom::ClusterCom] Node running on OS: 'Linux' Release:
'2.6.35-24-virtual'
[Sep 22 00:00:17.805] Manager {140131209512736} NOTE:
[LocalManager::listenForProxy] Listening on port: 80
[Sep 22 00:00:17.805] Manager {140131209512736} NOTE: [TrafficManager] Setup
complete
[Sep 22 00:00:18.827] Manager {140131209512736} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr/local'
[Sep 22 00:00:18.849] Manager {140131209512736} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '13'
[Sep 22 00:00:18.849] Manager {140131209512736} NOTE: [Alarms::signalAlarm]
Server Process born
[Sep 22 00:00:19.874] {47510015031936} STATUS: opened
/usr/local/var/log/trafficserver/diags.log
[Sep 22 00:00:19.874] {47510015031936} NOTE: updated diags config
[Sep 22 00:00:19.879] Server {47510015031936} NOTE: cache clustering disabled
[Sep 22 00:00:19.908] Server {47510015031936} NOTE: cache clustering disabled
[Sep 22 00:00:20.019] Server {47510015031936} NOTE: logging initialized[7],
logging_mode = 3
[Sep 22 00:00:20.032] Server {47510015031936} NOTE: traffic server running
[Sep 22 00:00:20.045] Server {47510028859136} NOTE: cache enabled
[Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
/usr/local/var/log/trafficserver/error.log was rolled to
/usr/local/var/log/trafficserver/error.log_trafficserver02.20110922.00h00m11s-20110923.00h00m00s.old.
[Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
/usr/local/var/log/trafficserver/squid.log was rolled to
/usr/local/var/log/trafficserver/squid.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
[Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
/usr/local/var/log/trafficserver/extended2.log was rolled to
/usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
[Sep 23 00:00:14.668] Manager {140131209512736} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Sep 23 00:00:14.668] Manager {140131209512736} FATAL: (last system error
104: Connection reset by peer)
