[jira] [Assigned] (TS-1210) remove 3.0.x deprecated APIs
[ https://issues.apache.org/jira/browse/TS-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1210: --- Assignee: James Peach remove 3.0.x deprecated APIs Key: TS-1210 URL: https://issues.apache.org/jira/browse/TS-1210 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: James Peach Assignee: James Peach Fix For: 3.1.4 We should remove the following APIs that were deprecated in 3.0: tsapi TSReturnCode TSUrlDestroy(TSMBuffer bufp, TSMLoc offset); tsapi TS_DEPRECATED unsigned int TSHttpTxnClientIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED TSReturnCode TSHttpTxnClientRemotePortGet(TSHttpTxn txnp, int* portp); tsapi TS_DEPRECATED int TSHttpTxnClientIncomingPortGet(TSHttpTxn txnp); tsapi TS_DEPRECATED unsigned int TSHttpTxnServerIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED unsigned int TSHttpTxnNextHopIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED int TSHttpTxnNextHopPortGet(TSHttpTxn txnp); tsapi TS_DEPRECATED int TSHttpTxnMaxArgCntGet(void); tsapi TS_DEPRECATED unsigned int TSNetVConnRemoteIPGet(TSVConn vc); tsapi TS_DEPRECATED int TSNetVConnRemotePortGet(TSVConn vc); tsapi TS_DEPRECATED unsigned int TSHostLookupResultIPGet(TSHostLookupResult lookup_result); tsapi TS_DEPRECATED void TSOSIpSet(TSHttpTxn txnp, unsigned int ip); tsapi TS_DEPRECATED void TSIOBufferAppend(TSIOBuffer bufp, TSIOBufferBlock blockp); tsapi TS_DEPRECATED TSIOBufferData TSIOBufferDataCreate(void* data, int size, TSIOBufferDataFlags flags); tsapi TS_DEPRECATED TSIOBufferBlock TSIOBufferBlockCreate(TSIOBufferData datap, int size, int offset); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1203) Crash report: HdrHeap::duplicate_str, in host_set
[
https://issues.apache.org/jira/browse/TS-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming reassigned TS-1203:
-
Assignee: weijin
this issue is new rising in our evn, after the patch for hdrheap protecting,
maybe a blocker for us.
Crash report: HdrHeap::duplicate_str, in host_set
-
Key: TS-1203
URL: https://issues.apache.org/jira/browse/TS-1203
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.3
Environment: 3.0.x, new crashes
Reporter: Zhao Yongming
Assignee: weijin
we get some new crashes in the production:
{code}
warning: no loadable sections found in added symbol-file system-supplied DSO
at 0x727fd000
Core was generated by `/usr/bin/traffic_server -M -A,12:X,13:X'.
Program terminated with signal 11, Segmentation fault.
#0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
(gdb) bt
#0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
#1 0x005aab68 in HdrHeap::duplicate_str (this=value optimized out,
str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds,
nbytes=21) at HdrHeap.cc:344
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds, s_len=21,
d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
MIME.cc:3034
#3 0x005aef28 in host_set (this=0x2aae268f8c18, url=value optimized
out) at URL.h:541
#4 HTTPHdr::set_url_target_from_host_field (this=0x2aae268f8c18, url=value
optimized out) at HTTP.cc:1484
#5 0x0055dc69 in RemapProcessor::setup_for_remap (this=value
optimized out, s=0x2aae268f83c8) at RemapProcessor.cc:130
#6 0x005165d9 in HttpSM::do_remap_request (this=0x2aae268f8360,
run_inline=true) at HttpSM.cc:3666
#7 0x00526cbb in HttpSM::set_next_state (this=0x2aaabd62be12) at
HttpSM.cc:6392
#8 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=value optimized out) at HttpSM.cc:6345
#9 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
HttpSM.cc:6553
#10 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=value optimized out) at HttpSM.cc:6345
#11 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
HttpSM.cc:6553
#12 0x005136f0 in HttpSM::call_transact_and_set_next_state
(this=0x2aae268f8360, f=value optimized out) at HttpSM.cc:6345
#13 0x00520f21 in HttpSM::state_read_client_request_header
(this=0x2aae268f8360, event=100, data=value optimized out)
at HttpSM.cc:783
#14 0x005259b9 in HttpSM::main_handler (this=0x2aae268f8360,
event=100, data=0x2aae68aee6e0) at HttpSM.cc:2456
#15 0x0066d1fb in handleEvent (nh=0x2b105668, vc=0x2aae68aee520,
thread=0x2b104010)
at ../../iocore/eventsystem/I_Continuation.h:146
#16 read_signal_and_update (nh=0x2b105668, vc=0x2aae68aee520,
thread=0x2b104010) at UnixNetVConnection.cc:138
#17 read_from_net (nh=0x2b105668, vc=0x2aae68aee520,
thread=0x2b104010) at UnixNetVConnection.cc:320
#18 0x00666579 in NetHandler::mainNetEvent (this=0x2b105668,
event=value optimized out, e=0x2b8ed028) at UnixNet.cc:389
#19 0x00691c8f in EThread::process_event (this=0x2b104010,
e=0x35681c0, calling_code=5) at I_Continuation.h:146
#20 0x0069259c in EThread::execute (this=0x2b104010) at
UnixEThread.cc:263
#21 0x0069115e in spawn_thread_internal (a=0x35621b0) at Thread.cc:88
#22 0x003e5b80673d in start_thread () from /lib64/libpthread.so.0
#23 0x003e5b0d44bd in clone () from /lib64/libc.so.6
(gdb) f 1
#1 0x005aab68 in HdrHeap::duplicate_str (this=value optimized out,
str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds,
nbytes=21) at HdrHeap.cc:344
344 memcpy(new_str, str, nbytes);
(gdb) p str
$1 = 0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds
(gdb) p nbytes
$2 = 21
(gdb) f 2
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds, s_len=21,
d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
MIME.cc:3034
3034 s_str = heap-duplicate_str(s_str, s_len);
(gdb) p s_str
$3 = 0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds
(gdb) f 3
#3 0x005aef28 in host_set (this=0x2aae268f8c18, url=value optimized
out) at URL.h:541
541 url_host_set(m_heap, m_url_impl, value, length, true);
(gdb) p value
$4 = value optimized out
(gdb) p length
$5 = value optimized out
(gdb) f 2
#2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
s_str=0x2aae474a6ec0 Address 0x2aae474a6ec0 out of bounds, s_len=21,
[jira] [Assigned] (TS-1205) Crash report: double free when RecDataSet in cluster mode
[
https://issues.apache.org/jira/browse/TS-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming reassigned TS-1205:
-
Assignee: kuotai
may or may not be the problem of clustering, need more investing into the
RecCore cluster mode config syncing
Crash report: double free when RecDataSet in cluster mode
-
Key: TS-1205
URL: https://issues.apache.org/jira/browse/TS-1205
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Configuration
Affects Versions: 3.1.3
Environment: v3.0.x, with cluster mode 2
Reporter: Zhao Yongming
Assignee: kuotai
Fix For: 3.3.0
we have seen some config system syncing config files in cluster mode.
{code}
*** glibc detected *** /usr/bin/traffic_server: double free or corruption
(fasttop): 0x2b639c0009a0 ***
=== Backtrace: =
/lib64/libc.so.6[0x3f8f0750c6]
/usr/bin/traffic_server(RecDataSet(RecDataT, RecData*,
RecData*)+0xb8)[0x65dd58]
/usr/bin/traffic_server(RecForceInsert(RecRecord*)+0x74)[0x6584b4]
/usr/bin/traffic_server[0x65cd62]
/usr/bin/traffic_server(RecMessageRecvThis(void*, char*, int)+0x16)[0x65ed46]
/usr/bin/traffic_server(BaseManager::executeMgmtCallback(int, char*,
int)+0x3d)[0x5b562d]
/usr/bin/traffic_server(ProcessManager::processEventQueue()+0x29)[0x5b5d49]
/usr/bin/traffic_server(startProcessManager(void*)+0x8d)[0x5b633d]
/lib64/libpthread.so.0[0x3f8f4077f1]
/lib64/libc.so.6(clone+0x6d)[0x3f8f0e570d]
=== Memory map:
{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] [Assigned] (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:all-tabpanel ] Igor Galić reassigned TS-1202: -- Assignee: Igor Galić 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] [Assigned] (TS-1200) DOAP file reference incorrect
[ https://issues.apache.org/jira/browse/TS-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1200: - Assignee: Leif Hedstrom 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] [Assigned] (TS-1197) Build fails when building outside the source tree
[ https://issues.apache.org/jira/browse/TS-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1197: -- Assignee: Igor Galić Build fails when building outside the source tree - Key: TS-1197 URL: https://issues.apache.org/jira/browse/TS-1197 Project: Traffic Server Issue Type: Bug Components: Build Affects Versions: 3.1.3 Reporter: Yossi Gottlieb Assignee: Igor Galić Priority: Minor Fix For: 3.1.4 Attachments: ats_build_fix.diff Currently some Makefiles assume $(builddir) == $(srcdir), which is an incorrect assumption. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-621: Assignee: weijin (was: John Plevyak) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached - Key: TS-621 URL: https://issues.apache.org/jira/browse/TS-621 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 2.1.5 Reporter: John Plevyak Assignee: weijin Fix For: 3.1.4 Attachments: TS-621_cluster_zero_size_objects.patch, force_empty.diff, ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.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] [Assigned] (TS-975) server-transform.c broken
[ https://issues.apache.org/jira/browse/TS-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-975: Assignee: Leif Hedstrom (was: Igor Galić) server-transform.c broken - Key: TS-975 URL: https://issues.apache.org/jira/browse/TS-975 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.0.0 Reporter: Otto van der Schaaf Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Attachments: server-transform.c.diff While playing around with the server-transform plugin example, i noticed it was broken. After some meddling around, i got it working again. The changes are mainly that in some cases content-length was passed in network-byte order where it shouldn't be. Another fix was handling the TS_EVENT_IMMEDIATE event in transform_write_event(). i currently perform a TSVIOReenable(data-server_vio); on that event, and it seems to work. However, I'm not sure at all if that is the correct thing to do, so if anybody could help me out on that? :-). I have tested the changed code with a custom echo server, and confirmed that the plugin is actually sending and receiving to the echo server. I added the working 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] [Assigned] (TS-1192) Remove gethostbyname usage in test code
[ https://issues.apache.org/jira/browse/TS-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-1192: Assignee: Brian Geffon Remove gethostbyname usage in test code --- Key: TS-1192 URL: https://issues.apache.org/jira/browse/TS-1192 Project: Traffic Server Issue Type: Improvement Affects Versions: 3.1.3 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.1.4 NetTest-simple-proxy.cc and test_I_simple_proxy.cc directly use gethostbyname(). These will be changed to use getaddrinfo(). We're removing gethostbyname() and gethostbyaddr() in an effort to get traffic server building on more platforms. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1180) gzip plugin needs to be configurable for certain file/mime types
[ https://issues.apache.org/jira/browse/TS-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1180: -- Assignee: Otto van der Schaaf Hi Otto, being familiar with the codebase, would you very much mind looking into this? gzip plugin needs to be configurable for certain file/mime types Key: TS-1180 URL: https://issues.apache.org/jira/browse/TS-1180 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Igor Galić Assignee: Otto van der Schaaf Most browsers don't take it very well when JavaScript is compressed - or rather, when AJAX requests are. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (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:all-tabpanel
]
Leif Hedstrom reassigned TS-1156:
-
Assignee: Leif Hedstrom
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
Assignee: 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] [Assigned] (TS-1103) Traffic Server ESI plugin issues
[ https://issues.apache.org/jira/browse/TS-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming reassigned TS-1103: - Assignee: Zhao Yongming Traffic Server ESI plugin issues Key: TS-1103 URL: https://issues.apache.org/jira/browse/TS-1103 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: sometime Environment: Newest trunk. Reporter: Kevin Fox Assignee: Zhao Yongming Fix For: 3.1.4 Attachments: esi.patch, gzip.patch Patch to fix: * Makefile fix to add missing files. * Change return code checking to match whats trunk trafficserver. * Include missing header files. * Fix c++ namespace issues. * Work around strange name mangling/linking issue. * Force the assumption that the cached data is RAW_ESI, not PACKED_ESI. Things wouldn't work without it. * Comment out a block of code that looked to be incorrectly handling EOF. After this, simply loading the plugin and setting response header X-ESI in apache httpd seems to work. A few further bugs I have bumped into that aren't addressed in this patch: * It doesn't seem to parse gzip like it looks like it should. To work around, I had to disable it in apache httpd with RewriteRule . - [E=no-gzip:1] * If the client requests gzip, the ESI processor will gzip the result. It works in firefox but is invalid in chrome. Pulling a dump with curl and running it through gzip --list shows it has the correct uncompressed size and compressed size. using zcat shows the correct data but has the warning: invalid compressed data--length error. As far as I read the gzip spec though, the raw binary file looks valid to me. Not sure what this is. This can probably be simply disabled for now though. * esi:include is slightly broken. You get all the data back properly but sometimes the headers are sent prematurely with a Content-Length of 2**31-1. This causes clients to timeout and fail. I'm currently unsure how to fix this. I've tried a few of the more advanced esi features, including ensuring cookies make it back to the origin server and things seem to work good. So, once the above bugs are figured out (particularly the include one), I think it will be in pretty good shape. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-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:all-tabpanel ] Leif Hedstrom reassigned TS-1079: - Assignee: Leif Hedstrom 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] [Assigned] (TS-1167) proxy/ParentSelection.cc is not IPv6 compliant.
[ https://issues.apache.org/jira/browse/TS-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-1167: --- Assignee: Alan M. Carroll proxy/ParentSelection.cc is not IPv6 compliant. --- Key: TS-1167 URL: https://issues.apache.org/jira/browse/TS-1167 Project: Traffic Server Issue Type: Bug Components: Clustering Affects Versions: 3.1.3 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Labels: ipv6, parent, socks Fix For: 3.1.4 setup_socks_servers is IPv4 only. It should be changed to use getaddrinfo() and handle IPv6 addresses. This may require changing ParentRecord. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1168) Remap blind tunnel handling is not IPv6 compliant
[ https://issues.apache.org/jira/browse/TS-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-1168: --- Assignee: Alan M. Carroll Remap blind tunnel handling is not IPv6 compliant - Key: TS-1168 URL: https://issues.apache.org/jira/browse/TS-1168 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.3 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Labels: blind, ipv6, remap, tunnel Fix For: 3.1.4 When a blind tunnel request is received, the hostname is set as the IP address. This is hardwired for IPv4. ink_gethostbyname should be replaced by getaddrinfo and the logic made IPv6 compliant. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1080) Assert under heavy load with logging enabled
[
https://issues.apache.org/jira/browse/TS-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1080:
-
Assignee: Leif Hedstrom
Assert under heavy load with logging enabled
Key: TS-1080
URL: https://issues.apache.org/jira/browse/TS-1080
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Critical
Fix For: 3.1.4
Given enough load (in the 100,000 QPS or more), we run out of some sort of
buffer space, with an assert of
{code}
#0 0x2ba719d50285 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x2ba719d51b9b in __GI_abort () at abort.c:91
#2 0x006b561a in ink_die_die_die (retval=optimized out) at
ink_error.cc:43
#3 ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *)
(return_code=optimized out, message_format=optimized out,
ap=0x7fff7275a7d8) at ink_error.cc:65
#4 0x006b56a7 in ink_fatal (return_code=optimized out,
message_format=optimized out) at ink_error.cc:73
#5 0x006b4970 in _ink_assert (a=0x6fd380
_num_flush_buffers[_open_flush_array] FLUSH_ARRAY_SIZE, f=optimized
out, l=96) at ink_assert.cc:44
#6 0x005a8b34 in add_to_flush_queue (buffer=0x2ba7443ca970,
this=0x22fb918) at LogObject.h:96
#7 LogObject::_checkout_write (this=0x22fb880, write_offset=0x7fff7275add8,
bytes_needed=152) at LogObject.cc:455
#8 0x005a8fd3 in LogObject::log (this=0x22fb880, lad=0x7fff7275b030,
text_entry=0x0) at LogObject.cc:580
#9 0x0058e956 in log (lad=0x7fff7275b030, this=optimized out) at
LogObject.h:475
#10 Log::access (lad=0x7fff7275b030) at Log.cc:1086
{code}
Increasing FLUSH_ARRAY_SIZE alleviates the problem, but really, we shouldn't
end up in this situation at all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1036) Improve squid log compatibility
[ https://issues.apache.org/jira/browse/TS-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1036: - Assignee: Leif Hedstrom Improve squid log compatibility Key: TS-1036 URL: https://issues.apache.org/jira/browse/TS-1036 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.4 See https://github.com/mnot/squidpeek/commit/3874cb902f257974d16c8eae5fc5a77c6fafbf69 for some differences, from mnot as well: all of the ERR_* ones squid does TCP_REFRESH_FAIL_HIT, you do TCP_REF_FAIL_HIT squid does TCP_CLIENT_REFRESH_MISS, you do TCP_CLIENT_REFRESH squid does TCP_SWAPFAIL_MISS, you do TCP_SWAPFAIL -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-981) ATS as transparent proxy crashes under heavy load
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-981: Assignee: Leif Hedstrom ATS as transparent proxy crashes under heavy load - Key: TS-981 URL: https://issues.apache.org/jira/browse/TS-981 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.0 Environment: 4 core desktop. Centos 5.6, kernel 2.6.39.2 compiled with TPROXY support. ATS compiled as: ./configure --enable-tproxy --enable-libev Reporter: Danny Shporer Assignee: Leif Hedstrom Priority: Critical Fix For: 3.1.4 Attachments: records.config ATS crashes under heavy load testing - around 25,000 HTTP transactions per second. I have tested it on both vesions 3.0.0 and 3.0.1 and the same happens. GDB info: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42174940 (LWP 6663)] 0x0068fd4b in modify (this=0x2b12c628, event=value optimized out, e=value optimized out) at P_UnixNet.h:536 536 fd_change(event_loop-eio, eio.fd, 0); (gdb) bt #0 0x0068fd4b in modify (this=0x2b12c628, event=value optimized out, e=value optimized out) at P_UnixNet.h:536 #1 NetHandler::mainNetEvent (this=0x2b12c628, event=value optimized out, e=value optimized out) at UnixNet.cc:432 #2 0x006bfc4f in EThread::process_event (this=0x2b12b010, e=0xf44570, calling_code=5) at I_Continuation.h:146 #3 0x006c055c in EThread::execute (this=0x2b12b010) at UnixEThread.cc:262 #4 0x006bef8e in spawn_thread_internal (a=0xf35c90) at Thread.cc:88 #5 0x003e9dc0673d in start_thread () from /lib64/libpthread.so.0 #6 0x003e9d0d44bd in clone () from /lib64/libc.so.6 (gdb) info f Stack level 0, frame at 0x42174030: rip = 0x68fd4b in modify (P_UnixNet.h:536); saved rip 0x6bfc4f inlined into frame 1 source language c++. Arglist at unknown address. Locals at unknown address, Previous frame's sp in rsp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1162) UnixNetVConnection.cc assertion when accepting a TLS connection
[
https://issues.apache.org/jira/browse/TS-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-1162:
---
Assignee: James Peach
UnixNetVConnection.cc assertion when accepting a TLS connection
---
Key: TS-1162
URL: https://issues.apache.org/jira/browse/TS-1162
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.4
Reporter: James Peach
Assignee: James Peach
Fix For: 3.1.4
Trunk always crashes when accepting a TLS connection:
FATAL: UnixNetVConnection.cc:801: failed assert `vio-mutex-thread_holding
== this_ethread()`
/opt/ats/bin/traffic_server - STACK TRACE:
0 libtsutil.3.dylib 0x00010c3e7ee7 ink_fatal + 359
1 libtsutil.3.dylib 0x00010c3e6e22 _ink_assert + 66
2 traffic_server 0x00010b9e6d9a
_ZN18UnixNetVConnection11set_enabledEP3VIO + 90
3 traffic_server 0x00010b9e681d
_ZN18UnixNetVConnection8reenableEP3VIO + 93
4 traffic_server 0x00010b7bfcd6 _ZN3VIO8reenableEv
+ 54
5 traffic_server 0x00010b9e5cd9
_ZN18UnixNetVConnection10do_io_readEP12ContinuationxP9MIOBuffer + 297
6 traffic_server 0x00010b792611
_ZN11VConnection5do_ioEiP12ContinuationxP9MIOBufferi + 129
7 traffic_server 0x00010b9d6da9
_ZN21SSLNextProtocolAccept9mainEventEiPv + 329
8 traffic_server 0x00010b792229
_ZN12Continuation11handleEventEiPv + 121
9 traffic_server 0x00010b9e89bd
_ZN18UnixNetVConnection11acceptEventEiP5Event + 829
10 traffic_server 0x00010b792229
_ZN12Continuation11handleEventEiPv + 121
11 traffic_server 0x00010ba0905d
_ZN7EThread13process_eventEP5Eventi + 349
12 traffic_server 0x00010ba09367
_ZN7EThread7executeEv + 215
13 traffic_server 0x00010ba080ed
_ZL21spawn_thread_internalPv + 109
14 libsystem_c.dylib 0x7fff8fcb78bf _pthread_start +
335
15 libsystem_c.dylib 0x7fff8fcbab75 thread_start + 13
[Mar 22 21:58:45.009] Manager {0x7fff79b01960} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Abort trap: 6
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1165) Health checks not working
[ https://issues.apache.org/jira/browse/TS-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-1165: --- Assignee: Alan M. Carroll Health checks not working - Key: TS-1165 URL: https://issues.apache.org/jira/browse/TS-1165 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.3 Reporter: Igor Brezac Assignee: Alan M. Carroll Fix For: 3.1.4 Health checks not working -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1148) support systemd init system
[ https://issues.apache.org/jira/browse/TS-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1148: -- Assignee: Igor Galić support systemd init system --- Key: TS-1148 URL: https://issues.apache.org/jira/browse/TS-1148 Project: Traffic Server Issue Type: Improvement Components: Packaging Reporter: Jan-Frode Myklebust Assignee: Igor Galić Fix For: 3.0.3 Attachments: 0001-TS-1148-Support-systemd-activation-of-ATS.patch, 0002-TS-1148-Support-systemd-activation-of-ATS.patch ATS should support systemd init system for managing the trafficserver service. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1135) support wildcard certificates for ServerNameIndication (SNI)
[ https://issues.apache.org/jira/browse/TS-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1135: --- Assignee: James Peach support wildcard certificates for ServerNameIndication (SNI) Key: TS-1135 URL: https://issues.apache.org/jira/browse/TS-1135 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: James Peach The ServerNameIndication support added in TS-472 doesn't handle wildcard certificates. We need to add certificate parsing support to detect wildcard certificates and then (if there is not an exact match) choose the certificate with the longest wildcard match. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1127) Wrong returned value of incoming port address
[ https://issues.apache.org/jira/browse/TS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1127: - Assignee: Alan M. Carroll Wrong returned value of incoming port address - Key: TS-1127 URL: https://issues.apache.org/jira/browse/TS-1127 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.1.2 Reporter: Yakov Kopel Assignee: Alan M. Carroll Fix For: 3.1.3 Attachments: fix.patch Original Estimate: 1m Remaining Estimate: 1m The API TSHttpTxnClientIncomingPortGet has been changed in Wed Oct 5 19:14:07 2011 (TS-926) and it returns another value. in the old version it returned the incoming port of the TS(the port which the client connected to the TS). in the new version the returned value is the sending port of the user. The different is in the line: - return sm-t_state.client_info.port; + return ink_inet_get_port(sm-t_state.client_info.addr); The assignment of those two members (port, addr) are in the HttpSM.cc file ink_inet_copy(t_state.client_info.addr, netvc-get_remote_addr()); t_state.client_info.port = netvc-get_local_port(); The old code gave the right answer from the port member, and the new one gives us wrong answer from the remote address. I attached a patch to fix this returned value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-462) Support TLS Server Name Indication (SNI) negotiation
[ https://issues.apache.org/jira/browse/TS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-462: -- Assignee: James Peach (was: Igor Galić) 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: James Peach 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] [Assigned] (TS-669) [GSoC2011] ATS does not support SSL in IPv6
[ https://issues.apache.org/jira/browse/TS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-669: -- Assignee: Alan M. Carroll Alan, with your recent IPV6 and port configuration work, is SSL now supported for IPV6? [GSoC2011] ATS does not support SSL in IPv6 --- Key: TS-669 URL: https://issues.apache.org/jira/browse/TS-669 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.0.0 Reporter: vijaya bhaskar mamidi Assignee: Alan M. Carroll Labels: gsoc2011, ipv6, ssl Fix For: 3.3.0 proxy.config.http.server_other_ports is used to support IPv6 but this only work for http ports and not secure ports. We should support IPv6 for secure ports as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1051) Updating logs_xml.config requires full restart
[
https://issues.apache.org/jira/browse/TS-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming reassigned TS-1051:
-
Assignee: Zhao Yongming (was: Leif Hedstrom)
Updating logs_xml.config requires full restart
--
Key: TS-1051
URL: https://issues.apache.org/jira/browse/TS-1051
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.1.2
Reporter: Billy Vierra
Assignee: Zhao Yongming
Fix For: 3.1.4
Using SVN Rev: 1214051
URL: http://svn.apache.org/repos/asf/trafficserver/traffic/trunk
upon adding a new LogObject and doing traffic_line -x you get the following
in traffic.out
[Dec 14 12:31:48.533] Manager {0x7f2f2abef700} NOTE: User has changed config
file logs_xml.config
However it does not go into effect (new log is not created). Upon full
restart: trafficserver stop, trafficserver start it will add the new log file
as expected.
Not sure if it is a bug with docs or in code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1002) log unmapped HOST when pristine_host_hdr disabled
[
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming reassigned TS-1002:
-
Assignee: Zhao Yongming
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: Wish
Components: Logging
Reporter: Conan Wang
Assignee: Zhao Yongming
Priority: Minor
Fix For: 3.1.5
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] [Assigned] (TS-1114) Crash report: HttpTransactCache::SelectFromAlternates
[
https://issues.apache.org/jira/browse/TS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
weijin reassigned TS-1114:
--
Assignee: weijin
Crash report: HttpTransactCache::SelectFromAlternates
-
Key: TS-1114
URL: https://issues.apache.org/jira/browse/TS-1114
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Assignee: weijin
Fix For: 3.1.4
it may or may not be the upstream issue, let us open it for tracking.
{code}
#0 0x0053075e in HttpTransactCache::SelectFromAlternates
(cache_vector=0x2aaab80ff500, client_request=0x2aaab80ff4c0,
http_config_params=0x2aaab547b800) at ../../proxy/hdrs/HTTP.h:1375
1375((int32_t *) val)[0] = m_alt-m_object_key[0];
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1110) logstats incorrectly bucketizes all status codes greater than 599 as 5xx
[ https://issues.apache.org/jira/browse/TS-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-1110: Assignee: Brian Geffon logstats incorrectly bucketizes all status codes greater than 599 as 5xx Key: TS-1110 URL: https://issues.apache.org/jira/browse/TS-1110 Project: Traffic Server Issue Type: Bug Components: Stats Affects Versions: 3.0.3 Reporter: Manjesh Nilange Assignee: Brian Geffon Attachments: logstats.cc.patch logstats incorrectly bucketizes all status codes greater than 599 as 5xx. If people use custom status codes (999 for example), this will get counted as a 5xx status. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-841) Refactor SSL code to make it possible to perform NPN negotiation without entering the HTTP SM
[ https://issues.apache.org/jira/browse/TS-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-841: -- Assignee: James Peach Refactor SSL code to make it possible to perform NPN negotiation without entering the HTTP SM - Key: TS-841 URL: https://issues.apache.org/jira/browse/TS-841 Project: Traffic Server Issue Type: New Feature Components: HTTP, SSL Reporter: Leif Hedstrom Assignee: James Peach Fix For: 3.1.3 In order to make it possible to write protocol handlers like SPDY, we need to negotiate NPN protocol before entering the HTTP SM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-874) asf-dist should be git nice
[ https://issues.apache.org/jira/browse/TS-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-874: - Assignee: Igor Galić (was: Zhao Yongming) asf-dist should be git nice --- Key: TS-874 URL: https://issues.apache.org/jira/browse/TS-874 Project: Traffic Server Issue Type: Improvement Components: Build Affects Versions: 3.1.0 Reporter: Zhao Yongming Assignee: Igor Galić Priority: Trivial Fix For: 3.1.0 Attachments: TS-874.txt the asf-dist make target should be git nice, I think many of us on git. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1102) Cleanup obsolete debugging code
[ https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1102: - Assignee: Leif Hedstrom 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] [Assigned] (TS-1038) TSHttpTxnErrorBodySet() can leak memory (pt 2)
[ https://issues.apache.org/jira/browse/TS-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1038: -- Assignee: Igor Galić (was: Leif Hedstrom) TSHttpTxnErrorBodySet() can leak memory (pt 2) -- Key: TS-1038 URL: https://issues.apache.org/jira/browse/TS-1038 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Igor Galić Fix For: 3.1.2 Attachments: TSHttpTxnErrorBodySet.patch TS-826 resolved a memory leak with TSHttpTxnErrorBodySet but it appears that mimetype is still being leaked. See HttpSM::setup_internal_transfer line 5416 which frees internal_msg_buffer_type...it's expected that mimetype was malloced since clearly it's being freed. So that means there is still a memory leak in TSHttpTxnErrorBodySet(). Patch 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] [Assigned] (TS-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed a
[ https://issues.apache.org/jira/browse/TS-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1061: -- Assignee: Igor Galić (was: Leif Hedstrom) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed as it is not used. - Key: TS-1061 URL: https://issues.apache.org/jira/browse/TS-1061 Project: Traffic Server Issue Type: Bug Components: Plugins Affects Versions: 3.1.1, 3.0.1 Environment: Redhat Linux but it is not environment specific Reporter: Alistair Stevenson Assignee: Igor Galić Priority: Minor Labels: api-change Fix For: 3.1.2 Original Estimate: 1h Remaining Estimate: 1h The definitions are: ./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes) ./proxy/api/ts/ts.h.in: tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp); The int * bytes parameter is not used and means that the function does not resolve and so cannot be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1055) Wrong implementation of TSHttpSsnArgGet
[
https://issues.apache.org/jira/browse/TS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić reassigned TS-1055:
--
Assignee: Igor Galić (was: Leif Hedstrom)
Wrong implementation of TSHttpSsnArgGet
---
Key: TS-1055
URL: https://issues.apache.org/jira/browse/TS-1055
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.1.1
Reporter: Yakov Kopel
Assignee: Igor Galić
Labels: api-change
Fix For: 3.1.2
Original Estimate: 24h
Remaining Estimate: 24h
There is a different between the interface of TSHttpSsnArgGet and it
implemenation.
In the interface (proxy/api/ts/ts.h.in):
tsapi void* TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx);
In the implementation(proxy/InkAPI.cc):
void * TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
So, I wrote a simple patch to fix this problem:
Index: InkAPI.cc
===
--- InkAPI.cc (revision 1220421)
+++ InkAPI.cc (working copy)
@@ -5500,7 +5500,7 @@
}
void *
-TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
+TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx)
{
sdk_assert(sdk_sanity_check_http_ssn(ssnp) == TS_SUCCESS);
sdk_assert(arg_idx = 0 arg_idx HTTP_SSN_TXN_MAX_USER_ARG);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1065) traffic_cop segment fault when enable TRACE_LOG_COP
[
https://issues.apache.org/jira/browse/TS-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić reassigned TS-1065:
--
Assignee: Igor Galić (was: Leif Hedstrom)
traffic_cop segment fault when enable TRACE_LOG_COP
---
Key: TS-1065
URL: https://issues.apache.org/jira/browse/TS-1065
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.1, 3.0.2
Environment: mac os 10.7.2, centos 5.4 64bit
Reporter: Conan Wang
Assignee: Igor Galić
Priority: Minor
Fix For: 3.1.2
Attachments: traffic_cop.diff
When enable traffic_cop's debug log: #define TRACE_LOG_COP 1
Some cop_log invocation will cause segment fault, because va_list object in
cop_log is used twice between 'va_start' and 'va_end'.
{code}
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x7fff846b64f0 in strlen ()
(gdb) bt
#0 0x7fff846b64f0 in strlen ()
#1 0x7fff846578c3 in __vfprintf ()
#2 0x7fff846a109b in vsprintf_l ()
#3 0x00011883 in cop_log (priority=5, format=0x172a8 --- Cop
Starting [Version: %s] ---\n) at TrafficCop.cc:172
#4 0x00012244 in check_lockfile () at TrafficCop.cc:1733
#5 0x000122c0 in init () at TrafficCop.cc:1894
#6 0x00016689 in main (argc=1, argv=0x7fff5fbffbb0) at
TrafficCop.cc:1958
{code}
Reference:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.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] [Assigned] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.
[ https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1074: -- Assignee: Igor Galić (was: Brian Geffon) PluginVC should schedule to the local queue instead of the external queue. -- Key: TS-1074 URL: https://issues.apache.org/jira/browse/TS-1074 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Igor Galić Fix For: 3.1.2 Attachments: PluginVC.patch In TS-867 a patch was introduced to resolve a crash that was appearing w/ TSFetchURL, the patch would schedule events on the same thread if it is a net thread, if not it will only then schedule with the event processor. If you're scheduling on the same thread, wouldn't it be more efficient to place the event directly on the local queue? It turns out that going to the ExternalQueue under low load it would cause the event to become delayed. Patch Attached. To best see the symptoms see complaints in (TS-912 and TS-1043). I have verified that this patch fixes the 10ms symptom seen in TS-912 and TS-1043. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1004) transformation plugins cause connection close when content length is not known ahead
[ https://issues.apache.org/jira/browse/TS-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1004: -- Assignee: Igor Galić (was: Brian Geffon) transformation plugins cause connection close when content length is not known ahead Key: TS-1004 URL: https://issues.apache.org/jira/browse/TS-1004 Project: Traffic Server Issue Type: Bug Components: HTTP, Plugins Affects Versions: 3.0.1 Reporter: Otto van der Schaaf Assignee: Igor Galić Fix For: 3.1.1 Attachments: chunk_transform_response.diff whenever the null transform plugin (or gzip) is executed, ATS will force the ua connection closed. when the user agent supports it, sending a chunked response w/ keepalive enabled would be preferred i guess i'll add a patch for review. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-876) forward map based on request receive port
[ https://issues.apache.org/jira/browse/TS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-876: - Assignee: Igor Galić (was: Brian Geffon) forward map based on request receive port - Key: TS-876 URL: https://issues.apache.org/jira/browse/TS-876 Project: Traffic Server Issue Type: New Feature Components: Remap API Reporter: Manjesh Nilange Assignee: Igor Galić Fix For: 3.1.0 Attachments: TS876.fixed.patch, map_with_recv_port.patch Currently the port in the from fields of all remap rules are compared against the port in the request (explicitly in the request or implicitly deduced from the protocol). TS supports listening on multiple ports, so there is a use case for a remap rule that uses the TS port at which the request is received instead of the request port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1095) 3.0.x ts.h.in has incorrect declaration for TSFetchURL
[ https://issues.apache.org/jira/browse/TS-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1095: -- Assignee: Igor Galić (was: Brian Geffon) 3.0.x ts.h.in has incorrect declaration for TSFetchURL -- Key: TS-1095 URL: https://issues.apache.org/jira/browse/TS-1095 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.2 Reporter: Brian Geffon Assignee: Igor Galić Fix For: 3.0.3 Attachments: ts.h.in.patch If you look at the declaration in ts.h.in for TSFetchURL it doesn't match the definition in InkAPI.cc. Patch attached, and updating STATUS file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1014) slow log can not print logs well on 32-bit system, I changed the %d to RPI64
[ https://issues.apache.org/jira/browse/TS-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1014: -- Assignee: Igor Galić (was: Leif Hedstrom) slow log can not print logs well on 32-bit system, I changed the %d to RPI64 Key: TS-1014 URL: https://issues.apache.org/jira/browse/TS-1014 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.0 Environment: 32-bit system Reporter: weijin Assignee: Igor Galić Priority: Minor Fix For: 3.1.2, 3.0.3 Attachments: slow_log.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-830) traffic_line -r returns Variable Not Found, even if it's a permission issue
[
https://issues.apache.org/jira/browse/TS-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić reassigned TS-830:
-
Assignee: Igor Galić (was: Leif Hedstrom)
traffic_line -r returns Variable Not Found, even if it's a permission issue
-
Key: TS-830
URL: https://issues.apache.org/jira/browse/TS-830
Project: Traffic Server
Issue Type: Bug
Components: Management
Affects Versions: 3.1.0, 2.1.9
Reporter: Igor Galić
Assignee: Igor Galić
Priority: Minor
Fix For: 3.1.1, 3.0.3
Attachments: ts830.patch
Example:
{noformat}
i.galic@pheme ~ % /opt/bw/bin/traffic_line -r proxy.config.dns.nameservers
/opt/bw/bin/traffic_line: Variable Not Found
1 i.galic@pheme ~ % sudo /opt/bw/bin/traffic_line -r
proxy.config.dns.nameservers
NULL
i.galic@pheme ~ % sudo /opt/bw/bin/traffic_line -r
proxy.config.dns.nameservers
/opt/bw/bin/traffic_line: Variable Not Found
{noformat}
I propose we tell the user, when it's actually a permission problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-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:all-tabpanel ] Leif Hedstrom reassigned TS-1094: - Assignee: Leif Hedstrom 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] [Assigned] (TS-1096) readline support for traffic_shell
[ https://issues.apache.org/jira/browse/TS-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1096: --- Assignee: James Peach readline support for traffic_shell -- Key: TS-1096 URL: https://issues.apache.org/jira/browse/TS-1096 Project: Traffic Server Issue Type: Improvement Components: Management Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.2 traffic_shell should use readline to support line editing and command history. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1097) online help for traffic_shell
[ https://issues.apache.org/jira/browse/TS-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1097: --- Assignee: James Peach online help for traffic_shell - Key: TS-1097 URL: https://issues.apache.org/jira/browse/TS-1097 Project: Traffic Server Issue Type: Improvement Components: Management Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.2 traffic_shell should have online help for its commands -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.
[ https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1074: - Assignee: Brian Geffon (was: Leif Hedstrom) PluginVC should schedule to the local queue instead of the external queue. -- Key: TS-1074 URL: https://issues.apache.org/jira/browse/TS-1074 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.1.2 Attachments: PluginVC.patch In TS-867 a patch was introduced to resolve a crash that was appearing w/ TSFetchURL, the patch would schedule events on the same thread if it is a net thread, if not it will only then schedule with the event processor. If you're scheduling on the same thread, wouldn't it be more efficient to place the event directly on the local queue? It turns out that going to the ExternalQueue under low load it would cause the event to become delayed. Patch Attached. To best see the symptoms see complaints in (TS-912 and TS-1043). I have verified that this patch fixes the 10ms symptom seen in TS-912 and TS-1043. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-876) forward map based on request receive port
[ https://issues.apache.org/jira/browse/TS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-876: Assignee: Brian Geffon (was: Leif Hedstrom) forward map based on request receive port - Key: TS-876 URL: https://issues.apache.org/jira/browse/TS-876 Project: Traffic Server Issue Type: New Feature Components: Remap API Reporter: Manjesh Nilange Assignee: Brian Geffon Fix For: 3.1.0 Attachments: map_with_recv_port.patch Currently the port in the from fields of all remap rules are compared against the port in the request (explicitly in the request or implicitly deduced from the protocol). TS supports listening on multiple ports, so there is a use case for a remap rule that uses the TS port at which the request is received instead of the request port. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1004) transformation plugins cause connection close when content length is not known ahead
[ https://issues.apache.org/jira/browse/TS-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1004: - Assignee: Brian Geffon (was: Leif Hedstrom) transformation plugins cause connection close when content length is not known ahead Key: TS-1004 URL: https://issues.apache.org/jira/browse/TS-1004 Project: Traffic Server Issue Type: Bug Components: HTTP, Plugins Affects Versions: 3.0.1 Reporter: Otto van der Schaaf Assignee: Brian Geffon Fix For: 3.1.1 Attachments: chunk_transform_response.diff whenever the null transform plugin (or gzip) is executed, ATS will force the ua connection closed. when the user agent supports it, sending a chunked response w/ keepalive enabled would be preferred i guess i'll add a patch for review. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1024) remap_required 0 not functioning in revproxy mode
[ https://issues.apache.org/jira/browse/TS-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1024: - Assignee: (was: Leif Hedstrom) 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 Priority: Minor Labels: parent, remap_required Fix For: sometime 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] [Assigned] (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:all-tabpanel ] Brian Geffon reassigned TS-1035: Assignee: Brian Geffon (was: Leif Hedstrom) 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 Assignee: Brian Geffon Fix For: 3.1.3 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] [Assigned] (TS-1082) configure always clobbers optimiser flags
[ https://issues.apache.org/jira/browse/TS-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1082: -- Assignee: James Peach (was: Igor Galić) Sorry for being so brief, need sleep configure always clobbers optimiser flags - Key: TS-1082 URL: https://issues.apache.org/jira/browse/TS-1082 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Assignee: James Peach Priority: Minor Attachments: 0001-TS-1082-Fix-optimizer-flags-detection.patch If the builder specifies optimizer flags, don't flip the default to -O3. Current behaviour is to always use -O3, since the check to disable this doesn't work. I believe the intention if for the builder to be able to do CXXFLAGS=-O1 ./configure and have the build use -O1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1082) configure always clobbers optimiser flags
[ https://issues.apache.org/jira/browse/TS-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1082: --- Assignee: Igor Galić (was: James Peach) configure always clobbers optimiser flags - Key: TS-1082 URL: https://issues.apache.org/jira/browse/TS-1082 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Assignee: Igor Galić Priority: Minor Attachments: 0001-TS-1082-Fix-optimizer-flags-detection.patch If the builder specifies optimizer flags, don't flip the default to -O3. Current behaviour is to always use -O3, since the check to disable this doesn't work. I believe the intention if for the builder to be able to do CXXFLAGS=-O1 ./configure and have the build use -O1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1082) configure always clobbers optimiser flags
[ https://issues.apache.org/jira/browse/TS-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1082: --- Assignee: Igor Galić (was: James Peach) Igor, can you please review and commit if appropriate. Thanks. configure always clobbers optimiser flags - Key: TS-1082 URL: https://issues.apache.org/jira/browse/TS-1082 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Assignee: Igor Galić Priority: Minor Attachments: 0001-TS-1082-Fix-optimizer-flags-detection.patch If the builder specifies optimizer flags, don't flip the default to -O3. Current behaviour is to always use -O3, since the check to disable this doesn't work. I believe the intention if for the builder to be able to do CXXFLAGS=-O1 ./configure and have the build use -O1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1084) enable compile-time format string checking
[ https://issues.apache.org/jira/browse/TS-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1084: --- Assignee: Leif Hedstrom Leif, can you review and apply if appropriate. Thanks. enable compile-time format string checking -- Key: TS-1084 URL: https://issues.apache.org/jira/browse/TS-1084 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Attachments: 0001-Add-format-string-checking.patch Add format string checking. Add format string checking to internal and external APIs that take a printf(3) format string. No functional changes. Fix all the resulting warnings - time_t is formatted as long long for portability - size_t became %zu - pointers all became %p -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-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:all-tabpanel ] Leif Hedstrom reassigned TS-996: Assignee: Leif Hedstrom 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 Assignee: Leif Hedstrom 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] [Assigned] (TS-1038) TSHttpTxnErrorBodySet() can leak memory (pt 2)
[ https://issues.apache.org/jira/browse/TS-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1038: - Assignee: Leif Hedstrom (was: William Bardwell) TSHttpTxnErrorBodySet() can leak memory (pt 2) -- Key: TS-1038 URL: https://issues.apache.org/jira/browse/TS-1038 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Leif Hedstrom Fix For: 3.1.2 Attachments: TSHttpTxnErrorBodySet.patch TS-826 resolved a memory leak with TSHttpTxnErrorBodySet but it appears that mimetype is still being leaked. See HttpSM::setup_internal_transfer line 5416 which frees internal_msg_buffer_type...it's expected that mimetype was malloced since clearly it's being freed. So that means there is still a memory leak in TSHttpTxnErrorBodySet(). Patch 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] [Assigned] (TS-1062) TSFetchUrl doesn't handle chunked encoding
[ https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1062: - Assignee: James Peach TSFetchUrl doesn't handle chunked encoding -- Key: TS-1062 URL: https://issues.apache.org/jira/browse/TS-1062 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: James Peach Assignee: James Peach Fix For: 3.1.2 If you use TSFetchUrl() to fetch a resource and the response comes back with chunked encoding, you are basically hosed. The caller never gets the SUCCESS event because FetchSM does not know how to decode the body. There's no content-length header and the origin server doesn't drop the TCP connection, so we just sit there waiting for the response to finish forever (well until the origin server drops the connection 10s later). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-937) EThread::execute still processing cancelled event
[
https://issues.apache.org/jira/browse/TS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-937:
Assignee: Brian Geffon
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] [Assigned] (TS-1054) TSFetchUrl takes an address but does the DNS lookup anyway
[
https://issues.apache.org/jira/browse/TS-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1054:
-
Assignee: James Peach
TSFetchUrl takes an address but does the DNS lookup anyway
--
Key: TS-1054
URL: https://issues.apache.org/jira/browse/TS-1054
Project: Traffic Server
Issue Type: Bug
Components: Performance
Affects Versions: 3.0.2
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 3.1.2
TSFetchUrl() takes an IP address as one of its arguments, so the API client
has to resolve the hostname portion of any URL it wants to fetch. However
once you get into the HTTP state machine, the host gets resolved again. One
of these DNS queries is redundant for performance reasons. Additionally, the
plugin might have some special knowledge about which IP address to use that
the DNS resolver doesn't, in which case the result would be wrong.
[Dec 14 20:36:29.414] Server {0x7fff7b5f9960} DIAG: (plugin) [1] http request
(90 of 90 bytes):
GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
accept: */*
[Dec 14 20:36:29.415] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [init] FetchSM
initialized for request with headers
--
GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
accept: */*
--
[Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [httpConnect]
calling httpconnect write
[Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Created
PluginVCCore at 0x102872c00, active 0x102872c38, passive 0x102872e10
[Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (http_seq)
HttpAccept:mainEvent] accepted connection
[Dec 14 20:36:29.425] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] session
born, netvc 0x102872e10
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] using
accept inactivity timeout [120 seconds]
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] Starting
transaction 1 using sm [0]
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
do_io_read for 0 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
do_io_read for -1 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
do_io_read for -1 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
do_io_write for 90 bytes
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Passive:
Received event 1
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side; act_on 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
closed? 0 shutdown? 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Active:
Received event 1
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_read_side
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_read_side; act_on 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
closed? 0 shutdown? 0
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_write_side
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_write_side; act_on 90
[Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
process_write_side; added 90
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
[fetch_handler] calling fetch_plugin
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
[process_fetch_write] calling process write
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side; act_on 90
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
process_read_side; added 90
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0]
[HttpSM::main_handler, VC_EVENT_READ_READY]
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0]
[HttpSM::state_read_client_request_header, VC_EVENT_READ_READY]
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] done parsing
client request header
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
reenable Read
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) START
HttpTransact::ModifyRequest
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans)
[ink_cluster_time] local: 1323923789, highest_delta: 0, cluster: 1323923789
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) END
[jira] [Assigned] (TS-1070) replace and deprecate TSFetchURL()
[
https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-1070:
---
Assignee: James Peach
replace and deprecate TSFetchURL()
--
Key: TS-1070
URL: https://issues.apache.org/jira/browse/TS-1070
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: James Peach
Assignee: James Peach
Priority: Minor
Fix For: 3.1.2
TSFetchURL() has a number of shortcomings:
1. it's not cancellable
2. the event delivery is bizarre
3. it doesn't play nicely with the TSHttpHdr*() API.
I propose the following API changes:
typedef enum
{
...
TS_EVENT_FETCH_SUCCESS,
TS_EVENT_FETCH_FAILURE
} TSEvent;
TSAction TSFetchResource(TSCont, TSMBuffer, TSLoc, const sockaddr *,
TSFetchWakeUpOptions);
TSFetchResource() takes a TSMBuffer/TSLoc pair that must contain the HTTP and
MIME headers. If the HTTP method in the HTTP header is not GET, and a error
will be reported.
The continuation callback will be invoked with either TS_EVENT_FETCH_SUCCESS
or TS_EVENT_FETCH_SUCCESS. For TS_EVENT_FETCH_SUCCESS, the edata pointer will
be a HttpTxn pointer suitable for call TSFetchRespGet() or TSFetchHdrGet().
For TS_EVENT_FETCH_FAILURE, I'd like to arrange a way to get the HTTP error
code. Hopefully there is some existing precedent to follow.
TSFetchResource() should be cancellable via the TSAction return value.
I'm not sure whether TSFetchWakeUpOptions is really necessary, but if we
eliminate this, I'd argue for a uint64_t flags parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-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:all-tabpanel ] Leif Hedstrom reassigned TS-1035: - Assignee: Leif Hedstrom 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 Assignee: Leif Hedstrom 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] [Assigned] (TS-1041) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet
[ https://issues.apache.org/jira/browse/TS-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1041: --- Assignee: James Peach (was: Leif Hedstrom) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet -- Key: TS-1041 URL: https://issues.apache.org/jira/browse/TS-1041 Project: Traffic Server Issue Type: Improvement Components: DNS Environment: Mac OS X 10.7 Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.2 Attachments: 0003-Ensure-sockaddr-length-is-always-populated.patch The sockaddr returned by TSHostLookupResultAddrGet() does not always get it's sa_len field populated correctly. This patch guarantees to populate it to the correct value so that plugin authors can rely on that field when copying the TSHostLookupResultAddrGet() result. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.
[ https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1074: - Assignee: Leif Hedstrom PluginVC should schedule to the local queue instead of the external queue. -- Key: TS-1074 URL: https://issues.apache.org/jira/browse/TS-1074 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Leif Hedstrom Fix For: 3.1.2 Attachments: PluginVC.patch In TS-867 a patch was introduced to resolve a crash that was appearing w/ TSFetchURL, the patch would schedule events on the same thread if it is a net thread, if not it will only then schedule with the event processor. If you're scheduling on the same thread, wouldn't it be more efficient to place the event directly on the local queue? It turns out that going to the ExternalQueue under low load it would cause the event to become delayed. Patch Attached. To best see the symptoms see complaints in (TS-912 and TS-1043). I have verified that this patch fixes the 10ms symptom seen in TS-912 and TS-1043. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1049) TS hangs (dead lock) on HTTPS POST requests
[ https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1049: - Assignee: Leif Hedstrom 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] [Assigned] (TS-1071) Debug statement in FetchSM broken
[
https://issues.apache.org/jira/browse/TS-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1071:
-
Assignee: Leif Hedstrom
Debug statement in FetchSM broken
-
Key: TS-1071
URL: https://issues.apache.org/jira/browse/TS-1071
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.2, 3.0.1
Reporter: Brian Geffon
Assignee: Leif Hedstrom
Priority: Trivial
Fix For: 3.1.2
Attachments: fetchsm.patch
While debugging FetchSM I noticed that a debug statement was broken:
[Jan 4 15:02:49.889] Server {140737294432000} DEBUG: (FetchSM)
[get_info_from_buffer] total avail ld
It's a missing % in the DEBUG, patch included, and tested:
[Jan 4 15:14:11.349] Server {139899653895936} DEBUG: (FetchSM)
[get_info_from_buffer] total avail 24615
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1044) PATCH: Fix TSVConn{Read,Write}VIOGet in UnixNetVConnection.
[
https://issues.apache.org/jira/browse/TS-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-1044:
---
Assignee: Leif Hedstrom
Leif, can you please review and commit if it looks OK?
PATCH: Fix TSVConn{Read,Write}VIOGet in UnixNetVConnection.
---
Key: TS-1044
URL: https://issues.apache.org/jira/browse/TS-1044
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
Assignee: Leif Hedstrom
Fix For: 3.1.2
Attachments:
0006-Fix-TSVConn-Read-Write-VIOGet-in-UnixNetVConnection.patch
UnixNetVConnection does not actually implement the virtual interface
necessary to support the TSVConn{Read,Write}VIOGet() APIs. Even worse, the
API layer assumes that this can't fail and proceeds to return a pointer to
stack junk.
This patch implements TSVConn{Read,Write}VIOGet() for UnixNetVConnection and
allows the API to return NULL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1041) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet
[ https://issues.apache.org/jira/browse/TS-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1041: --- Assignee: Leif Hedstrom Leif, can you please review and apply if it looks ok? PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet -- Key: TS-1041 URL: https://issues.apache.org/jira/browse/TS-1041 Project: Traffic Server Issue Type: Improvement Components: DNS Environment: Mac OS X 10.7 Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.2 Attachments: 0003-Ensure-sockaddr-length-is-always-populated.patch The sockaddr returned by TSHostLookupResultAddrGet() does not always get it's sa_len field populated correctly. This patch guarantees to populate it to the correct value so that plugin authors can rely on that field when copying the TSHostLookupResultAddrGet() result. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-312) add option to always share keep-alive connections to the origin server
[ https://issues.apache.org/jira/browse/TS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-312: Assignee: (was: Leif Hedstrom) add option to always share keep-alive connections to the origin server --- Key: TS-312 URL: https://issues.apache.org/jira/browse/TS-312 Project: Traffic Server Issue Type: Improvement Components: Network Reporter: Miles Libbey Priority: Minor Fix For: 3.3.0 (was yahoo bug 1411758) Original description by Bryan Call (bcall) 2 years ago at 2007-08-08 13:35 Leif and I were talking about extending the meaning of proxy.config.http.share_server_session for reusing keep-alive connections from the TS server and the origin server, for separate clients attached to TS. You can read more about this in [BUG 1162233]. The configuration options should be: so lets add more options to share_server_session? E.g. 0 - Never share/reuse connections 1 - Share/reuse connections if max_connections is set (default) 2 - Always try to share-reuse connections option 1 will give the behavior we currently have and 2 will always try to share the keep-alive connections to the origin servers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-777) Increasing logbuffer size makes us drop log entries
[ https://issues.apache.org/jira/browse/TS-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-777: Assignee: (was: Leif Hedstrom) Increasing logbuffer size makes us drop log entries - Key: TS-777 URL: https://issues.apache.org/jira/browse/TS-777 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 2.1.8 Reporter: Leif Hedstrom Fix For: 3.3.0 Setting proxy.config.log.log_buffer_size higher than somewhere around 24KB makes us start losing log entries. This is bad, since increasing this setting could be a way to increase performance for busy systems. I've for now set the defaults to 16KB, which seems to be stable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1014) slow log can not print logs well on 32-bit system, I changed the %d to RPI64
[ https://issues.apache.org/jira/browse/TS-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1014: - Assignee: Leif Hedstrom slow log can not print logs well on 32-bit system, I changed the %d to RPI64 Key: TS-1014 URL: https://issues.apache.org/jira/browse/TS-1014 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.0 Environment: 32-bit system Reporter: weijin Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.2 Attachments: slow_log.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1052) trafficserver restart does not work (needs to let old process die)
[ https://issues.apache.org/jira/browse/TS-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1052: - Assignee: Leif Hedstrom trafficserver restart does not work (needs to let old process die) -- Key: TS-1052 URL: https://issues.apache.org/jira/browse/TS-1052 Project: Traffic Server Issue Type: Bug Components: Management Affects Versions: 3.1.2 Environment: Ubuntu 11.10 64bit Reporter: Billy Vierra Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.2 Attachments: trafficserver.diff 'bin/trafficserver restart' does not wait for the old process to stop thus causing the restart to fail. In my testing this takes from 5-8sec to happen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1065) traffic_cop segment fault when enable TRACE_LOG_COP
[
https://issues.apache.org/jira/browse/TS-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1065:
-
Assignee: Leif Hedstrom
traffic_cop segment fault when enable TRACE_LOG_COP
---
Key: TS-1065
URL: https://issues.apache.org/jira/browse/TS-1065
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.1, 3.0.2
Environment: mac os 10.7.2, centos 5.4 64bit
Reporter: Conan Wang
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 3.1.2
Attachments: traffic_cop.diff
When enable traffic_cop's debug log: #define TRACE_LOG_COP 1
Some cop_log invocation will cause segment fault, because va_list object in
cop_log is used twice between 'va_start' and 'va_end'.
{code}
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x7fff846b64f0 in strlen ()
(gdb) bt
#0 0x7fff846b64f0 in strlen ()
#1 0x7fff846578c3 in __vfprintf ()
#2 0x7fff846a109b in vsprintf_l ()
#3 0x00011883 in cop_log (priority=5, format=0x172a8 --- Cop
Starting [Version: %s] ---\n) at TrafficCop.cc:172
#4 0x00012244 in check_lockfile () at TrafficCop.cc:1733
#5 0x000122c0 in init () at TrafficCop.cc:1894
#6 0x00016689 in main (argc=1, argv=0x7fff5fbffbb0) at
TrafficCop.cc:1958
{code}
Reference:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.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] [Assigned] (TS-998) Broken ClientReq in TSAPI
[ https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Kew reassigned TS-998: --- Assignee: Nick Kew (was: Alan M. Carroll) 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] [Assigned] (TS-254) Add TSEscapifyString() and TSUnescapifyString()
[ https://issues.apache.org/jira/browse/TS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-254: Assignee: Leif Hedstrom (was: Igor Galić) 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] [Assigned] (TS-1056) Lost UA connections can show up as 400 ERR_INVALID_REQ in logs
[
https://issues.apache.org/jira/browse/TS-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1056:
-
Assignee: Leif Hedstrom
Lost UA connections can show up as 400 ERR_INVALID_REQ in logs
Key: TS-1056
URL: https://issues.apache.org/jira/browse/TS-1056
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.1.2
Attachments: HttpSM.diff
So, it seems that with Firefox (it's the only one I've been able to reproduce
this with), we can end up getting a bunch of errors like
{code}
1324075013.826 0 216.239.45.4 ERR_INVALID_REQ/400 217 - / - NONE/- text/html -
{code}
Tracking this down, it seems the HTTP SM is getting a VC_EVENT_EOS (stream
closed) in state_read_client_request_header(). However, there is nothing in
the request_header (zero bytes), so when it tries to parse the (empty)
request header, it looks like a request error.
I'm not certain, yet at least, under what conditions we get this event (I'm
fairly certain that Firefox is somehow closing down the connection in some
weird state to us?). So, I'm suggesting we at least deal with this situation
earlier (before trying to parse the headers), which will instead cause an
UNKNOWN_ERROR (since we have no request nor response code. Suggested
changes attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1055) Wrong implementation of TSHttpSsnArgGet
[
https://issues.apache.org/jira/browse/TS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1055:
-
Assignee: Leif Hedstrom
Wrong implementation of TSHttpSsnArgGet
---
Key: TS-1055
URL: https://issues.apache.org/jira/browse/TS-1055
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.1.1
Reporter: Yakov Kopel
Assignee: Leif Hedstrom
Labels: api-change
Fix For: 3.1.2
Original Estimate: 24h
Remaining Estimate: 24h
There is a different between the interface of TSHttpSsnArgGet and it
implemenation.
In the interface (proxy/api/ts/ts.h.in):
tsapi void* TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx);
In the implementation(proxy/InkAPI.cc):
void * TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
So, I wrote a simple patch to fix this problem:
Index: InkAPI.cc
===
--- InkAPI.cc (revision 1220421)
+++ InkAPI.cc (working copy)
@@ -5500,7 +5500,7 @@
}
void *
-TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
+TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx)
{
sdk_assert(sdk_sanity_check_http_ssn(ssnp) == TS_SUCCESS);
sdk_assert(arg_idx = 0 arg_idx HTTP_SSN_TXN_MAX_USER_ARG);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1047) Several spelling fixes in strings
[ https://issues.apache.org/jira/browse/TS-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1047: - Assignee: Leif Hedstrom Several spelling fixes in strings - Key: TS-1047 URL: https://issues.apache.org/jira/browse/TS-1047 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.1 Reporter: Arno Toell Assignee: Leif Hedstrom Priority: Trivial Fix For: 3.1.2 Attachments: spelling-fixes.diff The current trunk contains several spelling fixes in strings printed out to users in some cases. I'm attaching a patch fixing some of the most obvious spelling errors I noticed (or rather, Lintian the Debian static analysis tool blamed me for :)) you may want to merge. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-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:all-tabpanel ] Leif Hedstrom reassigned TS-1048: - Assignee: Leif Hedstrom 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 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] [Assigned] (TS-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1045: - Assignee: Leif Hedstrom 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] [Assigned] (TS-1047) Several spelling fixes in strings
[ https://issues.apache.org/jira/browse/TS-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1047: -- Assignee: Igor Galić (was: Leif Hedstrom) Several spelling fixes in strings - Key: TS-1047 URL: https://issues.apache.org/jira/browse/TS-1047 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.1 Reporter: Arno Toell Assignee: Igor Galić Priority: Trivial Fix For: 3.1.2, 3.0.3 Attachments: spelling-fixes.diff The current trunk contains several spelling fixes in strings printed out to users in some cases. I'm attaching a patch fixing some of the most obvious spelling errors I noticed (or rather, Lintian the Debian static analysis tool blamed me for :)) you may want to merge. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-254) Add TSEscapifyString() and TSUnescapifyString()
[ https://issues.apache.org/jira/browse/TS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-254: - Assignee: Igor Galić (was: Leif Hedstrom) 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: Igor Galić 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] [Assigned] (TS-1039) PATCH: use pcre-config to find libpcre
[ https://issues.apache.org/jira/browse/TS-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1039: -- Assignee: Igor Galić PATCH: use pcre-config to find libpcre -- Key: TS-1039 URL: https://issues.apache.org/jira/browse/TS-1039 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: James Peach Assignee: Igor Galić Priority: Minor Attachments: 0001-Use-pcre-config-to-find-libpcre.patch This patch uses pcre-config to determine the compilation options needed to use libpcre. This is an improvement over the exiting configure arguments since it will work without user intervention in more circumstances. The existing configuration option still works as expected for compatibility reasons. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1042) PATCH: correct debug message in FetchSM
[ https://issues.apache.org/jira/browse/TS-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1042: -- Assignee: Igor Galić 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 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] [Assigned] (TS-1032) Assertion when upstream connection is established (with event handled by thread A) and immediately disconnected (handled by thread B)
[ https://issues.apache.org/jira/browse/TS-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1032: - Assignee: Leif Hedstrom Assertion when upstream connection is established (with event handled by thread A) and immediately disconnected (handled by thread B) - Key: TS-1032 URL: https://issues.apache.org/jira/browse/TS-1032 Project: Traffic Server Issue Type: Bug Components: Core, HTTP Affects Versions: 3.1.1 Environment: Linux 32bit CentOS 5.4. Pre-open source version of ATS. Reporter: Uri Shachar Assignee: Leif Hedstrom Fix For: 3.1.2 Attachments: wait_patch.diff Original Estimate: 1h Remaining Estimate: 1h This happened twice on a very old version of ATS (pre opensource code), but it looks like it can happen in current ATS as well (it's a very rare race condition, haven't been able to reproduce). Scenario: 1) Client request arrives, handled by TS thread 1 and is reenabled by a plugin (Inside a continuation called by ContSched) 2) TS thread 2 starts to connect upstream 3) A client disconnection event is placed in thread 1 queue. 4) A successful connection event is placed in thread 2 queue. 5) Thread 1 starts to handle pending events (setting cur_time to X) 6) Thread 2 starts to handle pending events (setting cur_time to Z=X+Y) 7) Thread 2 handles the connection established event (setting server_first_connect to Z) 8) Thread 1 handles the client disconnection event - Getting a negative wait and asserting... Sample stack trace: Program received signal SIGABRT, Aborted. [Switching to Thread 0xe3131b90 (LWP 14584)] 0xe410 in __kernel_vsyscall () #0 0xe410 in __kernel_vsyscall () #1 0x007e2df0 in raise () from /lib/libc.so.6 #2 0x007e484e in abort () from /lib/libc.so.6 #3 0x08427612 in ink_die_die_die (retval=1) at /usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_error.cc:45 #4 0x08427778 in ink_fatal_va (return_code=1, message_format=0xe312ee1f /tmp/ushachar-rpmbuild/BUILD/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:5572: failed assert `wait = 0`, ap=0xe312ee08 \002) at /usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_error.cc:100 #5 0x084277d3 in ink_fatal (return_code=1, message_format=0xe312ee1f /tmp/ushachar-rpmbuild/BUILD/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:5572: failed assert `wait = 0`) at /usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_error.cc:111 #6 0x08424508 in _ink_assert (a=0x853db72 wait = 0, f=0x853ab3c /tmp/ushachar-rpmbuild/BUILD/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc, l=5572) at /usr/src/debug/wts/proxy/ts/traffic/libwebsense++/ink_assert.cc:27 #7 0x082f2505 in HttpSM::mark_server_down_on_client_abort (this=0xb622ece0) at /usr/src/debug/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:5572 #8 0x082f6080 in HttpSM::state_watch_for_client_abort (this=0xb622ece0, event=3, data=0x7e0e2a88) at /usr/src/debug/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:1148 #9 0x082fad0f in HttpSM::main_handler (this=0xb622ece0, event=3, data=0x7e0e2a88) at /usr/src/debug/wts/proxy/ts/traffic/proxy/http2/HttpSM.cc:3213 #10 0x0810a07b in Continuation::handleEvent (this=0xb622ece0, event=3, data=0x7e0e2a88) at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/Continuation.h:85 #11 0x083ab348 in read_signal_and_update (event=3, vc=0x7e0e2a30) at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:262 #12 0x083ab3fe in read_signal_done (event=3, nh=0xa339b28, vc=0x7e0e2a30) at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:300 #13 0x083ab44f in read_signal_error (nh=0xa339b28, vc=0x7e0e2a30, lerrno=104) at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:324 #14 0x083ae1c5 in read_from_net (nh=0xa339b28, vc=0x7e0e2a30, thread=0xa32e490) at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:783 #15 0x083ae5a7 in UnixNetVConnection::net_read_io (this=0x7e0e2a30, nh=0xa339b28, lthread=0xa32e490) at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:1059 #16 0x083adced in NetHandler::mainNetEvent (this=0xa339b28, event=5, e=0xa1ab810) at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixNet.cc:1272 #17 0x0810a07b in Continuation::handleEvent (this=0xa339b28, event=5, data=0xa1ab810) at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/Continuation.h:85 #18 0x083a19ac in EThread::process_event (this=0xa32e490, e=0xa1ab810, calling_code=5) at /usr/src/debug/wts/proxy/ts/traffic/proxy/iocore/UnixEThread.cc:132 #19 0x0839f800 in EThread::execute (this=0xa32e490) at
[jira] [Assigned] (TS-1026) Changes to improve docs formatting
[ https://issues.apache.org/jira/browse/TS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-1026: -- Assignee: Igor Galić Changes to improve docs formatting -- Key: TS-1026 URL: https://issues.apache.org/jira/browse/TS-1026 Project: Traffic Server Issue Type: Improvement Components: Web site Reporter: zoe slattery Assignee: Igor Galić Priority: Minor Attachments: docspage.diff, docspagethml.diff, indexhtml.diff, stylescss.diff, stylescss.diff Remove the 'banner' class in styles.css and make all heading formats the same. Modify the docs template to use class blurbbox, this will leave margins around text. Still to do - fix the header of docs pages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1024) remap_required 0 not functioning in revproxy mode
[ https://issues.apache.org/jira/browse/TS-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1024: - Assignee: Leif Hedstrom 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] [Assigned] (TS-1019) clean up access to librecords and remove wrappers
[
https://issues.apache.org/jira/browse/TS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić reassigned TS-1019:
--
Assignee: Igor Galić
clean up access to librecords and remove wrappers
-
Key: TS-1019
URL: https://issues.apache.org/jira/browse/TS-1019
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Bryan Call
Assignee: Igor Galić
Priority: Minor
There are unneeded define wrappers around the librecord function calls:
{noformat}
[bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger
* | grep define
iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger
REC_ConfigReadInteger
proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger
REC_ConfigReadInteger
proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger
REC_ConfigReadInteger
proxy/logging/LogConfig.h:#define LOG_LocalReadInteger
REC_ConfigReadInteger
proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-346) ATS does not verify server certificate
[ https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-346: - Assignee: Igor Galić ATS does not verify server certificate -- Key: TS-346 URL: https://issues.apache.org/jira/browse/TS-346 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: vijaya bhaskar mamidi Assignee: Igor Galić Priority: Critical Fix For: 3.1.3 ATS does not verify the certificates correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (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:all-tabpanel ] Nick Kew reassigned TS-1008: Assignee: Nick Kew 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 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] [Assigned] (TS-944) ssl.server.cert.path ssl.server.private_key.path do not work as expected
[
https://issues.apache.org/jira/browse/TS-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić reassigned TS-944:
-
Assignee: Igor Galić
ssl.server.cert.path ssl.server.private_key.path do not work as expected
--
Key: TS-944
URL: https://issues.apache.org/jira/browse/TS-944
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 3.0.1
Environment: CentOS 5.6
TrafficServer 3.0.1
Reporter: Ethan Lai
Assignee: Igor Galić
Fix For: 3.1.2
Weird behavior of ssl.server.cert.path ssl.server.private_key.path
Test config1:
records.config:
CONFIG proxy.config.ssl.server.cert.filename STRING cert1.pem
CONFIG proxy.config.ssl.server.cert.path STRING /usr/local/etc/ats-cert
CONFIG proxy.config.ssl.server.private_key.filename STRING cert1.key
CONFIG proxy.config.ssl.server.private_key.path STRING
/usr/local/etc/ats-cert
ssl_multicert.config:
dest_ip=172.16.192.168 ssl_cert_name=cert2.pem ssl_key_name=cert2.key
traffic.out:
ERROR: SSL::0:error:02001002:system library:fopen:No such file or
directory:bss_file.c:352:fopen('/usr/local/etc/ats-certcert2.pem','r')
My observation:
*Trailing slash of ssl.server.cert.path not automatic added?*
Test config2:
records.config:
CONFIG proxy.config.ssl.server.cert.filename STRING cert1.pem
CONFIG proxy.config.ssl.server.cert.path STRING /usr/local/etc/ats-cert/
CONFIG proxy.config.ssl.server.private_key.filename STRING cert1.key
CONFIG proxy.config.ssl.server.private_key.path STRING
/usr/local/etc/ats-cert/
ssl_multicert.config:
dest_ip=172.16.192.168 ssl_cert_name=cert2.pem ssl_key_name=cert2.key
traffic.out:
ERROR: SSL::0:error:02001002:system library:fopen:No such file or
directory:bss_file.c:352:fopen('/usr/local/etc/ats-certcert2.pem','r')
My observation:
*Trailing slash of ssl.server.cert.path trimmed.*
Test config3:
records.config:
CONFIG proxy.config.ssl.server.cert.filename STRING cert1.pem
CONFIG proxy.config.ssl.server.cert.path STRING /usr/local/etc/ats-cert
CONFIG proxy.config.ssl.server.private_key.filename STRING cert1.key
CONFIG proxy.config.ssl.server.private_key.path STRING
/usr/local/etc/ats-cert
ssl_multicert.config:
dest_ip=210.71.204.149 ssl_cert_name=/cert2.pem ssl_key_name=cert2.key
traffic.out:
ERROR: SSL::0:error:02001002:system library:fopen:No such file or
directory:bss_file.c:352:fopen('cert2.key','r')
My observation:
*ssl.server.private_key.path config value not effective?*
Test config4:
records.config:
CONFIG proxy.config.ssl.server.cert.filename STRING
/usr/local/etc/ats-cert/cert1.pem
CONFIG proxy.config.ssl.server.cert.path STRING NULL
CONFIG proxy.config.ssl.server.private_key.filename STRING
/usr/local/etc/ats-cert/cert1.key
CONFIG proxy.config.ssl.server.private_key.path STRING NULL
ssl_multicert.config:
dest_ip=210.71.204.149 ssl_cert_name=/usr/local/etc/ats-cert/cert2.pem
ssl_key_name=/usr/local/etc/ats-cert/cert2.key
traffic.out:
ERROR: SSL::0:error:02001002:system library:fopen:No such file or
directory:bss_file.c:352:fopen('/usr/local/usr/local/etc/ats-cert/cert2.pem','r')
My observation:
*prefix added before ssl_cert_name while ssl.server.cert.path not set*
Test config5:
records.config:
CONFIG proxy.config.ssl.server.cert.filename STRING
/usr/local/etc/ats-cert/cert1.pem
CONFIG proxy.config.ssl.server.cert.path STRING NULL
CONFIG proxy.config.ssl.server.private_key.filename STRING
/usr/local/etc/ats-cert/cert1.key
CONFIG proxy.config.ssl.server.private_key.path STRING NULL
ssl_multicert.config:
dest_ip=210.71.204.149 ssl_cert_name=/etc/ats-cert/cert2.pem
ssl_key_name=/etc/ats-cert/cert2.key
traffic.out:
ERROR: SSL::0:error:02001002:system library:fopen:No such file or
directory:bss_file.c:352:fopen('/etc/ats-cert/cert2.key','r')
My observation:
*prefix NOT added before ssl_key_name while ssl.server.private_key.path not
set*
Worked config:
records.config:
CONFIG proxy.config.ssl.server.cert.filename STRING cert1.pem
CONFIG proxy.config.ssl.server.cert.path STRING /usr/local/etc/ats-cert
CONFIG proxy.config.ssl.server.private_key.filename STRING cert1.key
CONFIG proxy.config.ssl.server.private_key.path STRING
/usr/local/etc/ats-cert
ssl_multicert.config:
dest_ip=210.71.204.149 ssl_cert_name=/cert2.pem
ssl_key_name=/usr/local/etc/ats-cert
It seems ssl.server.cert.path has different (and weird) behavior with
ssl.server.private_key.path.
--
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:
[jira] [Assigned] (TS-857) Crash Report: HttpTunnel::chain_abort_all - HttpServerSession::do_io_close - UnixNetVConnection::do_io_close
[
https://issues.apache.org/jira/browse/TS-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming reassigned TS-857:
Assignee: weijin
weijin is working on threading net crashing issue. he have got some
directions for this issue.
Crash Report: HttpTunnel::chain_abort_all - HttpServerSession::do_io_close
- UnixNetVConnection::do_io_close
--
Key: TS-857
URL: https://issues.apache.org/jira/browse/TS-857
Project: Traffic Server
Issue Type: Bug
Components: HTTP, Network
Affects Versions: 3.1.0
Environment: in my branch that is something same as 3.0.x
Reporter: Zhao Yongming
Assignee: weijin
Fix For: 3.1.2
here is the bt from the crash, some of the information is missing due to we
have not enable the --enable-debug configure options.
{code}
[New process 7532]
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out)
at ink_stack_trace.cc:68
68fp = (void **) (*fp);
(gdb) bt
#0 ink_stack_trace_get (stack=value optimized out, len=value optimized
out, signalhandler_frame=value optimized out)
at ink_stack_trace.cc:68
#1 0x2ba641dccef1 in ink_stack_trace_dump (sighandler_frame=value
optimized out) at ink_stack_trace.cc:114
#2 0x004df020 in signal_handler (sig=value optimized out) at
signals.cc:225
#3 signal handler called
#4 0x006a1ea9 in UnixNetVConnection::do_io_close (this=0x1cc9bd20,
alerrno=value optimized out)
at ../../iocore/eventsystem/I_Lock.h:297
#5 0x0051f1d0 in HttpServerSession::do_io_close
(this=0x2aaab0042c80, alerrno=20600) at HttpServerSession.cc:127
#6 0x0056d1e9 in HttpTunnel::chain_abort_all (this=0x2aabeeffdd70,
p=0x2aabeeffdf68) at HttpTunnel.cc:1300
#7 0x005269ca in HttpSM::tunnel_handler_ua (this=0x2aabeeffc070,
event=104, c=0x2aabeeffdda8) at HttpSM.cc:2987
#8 0x00571dfc in HttpTunnel::consumer_handler (this=0x2aabeeffdd70,
event=104, c=0x2aabeeffdda8) at HttpTunnel.cc:1232
#9 0x00572032 in HttpTunnel::main_handler (this=0x2aabeeffdd70,
event=1088608784, data=value optimized out)
at HttpTunnel.cc:1456
#10 0x006a6307 in write_to_net_io (nh=0x2b12d688, vc=0x1cc876e0,
thread=value optimized out)
at ../../iocore/eventsystem/I_Continuation.h:146
#11 0x0069ce97 in NetHandler::mainNetEvent (this=0x2b12d688,
event=value optimized out, e=0x171c1ed0) at UnixNet.cc:405
#12 0x006cddaf in EThread::process_event (this=0x2b12c010,
e=0x171c1ed0, calling_code=5) at I_Continuation.h:146
#13 0x006ce6bc in EThread::execute (this=0x2b12c010) at
UnixEThread.cc:262
#14 0x006cd0ee in spawn_thread_internal (a=0x171b58f0) at Thread.cc:88
#15 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
#16 0x003c330d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x40e2b790:
rip = 0x2ba641dccdf3 in ink_stack_trace_get(void**, int, int)
(ink_stack_trace.cc:68); saved rip 0x2ba641dccef1
called by frame at 0x40e2bbe0
source language c++.
Arglist at 0x40e2b770, args: stack=value optimized out, len=value
optimized out, signalhandler_frame=value optimized out
Locals at 0x40e2b770, Previous frame's sp is 0x40e2b790
Saved registers:
rbx at 0x40e2b778, rbp at 0x40e2b780, rip at 0x40e2b788
(gdb)
{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] [Assigned] (TS-1005) initscript should implement a reload function
[ https://issues.apache.org/jira/browse/TS-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1005: - Assignee: Leif Hedstrom initscript should implement a reload function - Key: TS-1005 URL: https://issues.apache.org/jira/browse/TS-1005 Project: Traffic Server Issue Type: Improvement Components: Packaging Reporter: Jan-Frode Myklebust Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.1 Attachments: 0001-Implement-reload-function-using-traffic_line-x-in-th.patch, 0002-Remove-force-reload-label-on-restart-function-since-.patch The initscript should provide a reload function, so that it can be told to reload it's configuration trough common interfaces (/sbin/service trafficserver reload on fedora/rhel). It looks like traffic_line -x is the tool to achieve this, so I've implemented this in rc/trafficserver.in. It's only tested on RHEL6, so I'm a bit uncertain if the other DISTRIB_ID's sections are 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] [Assigned] (TS-992) Generic portability fixes.
[ https://issues.apache.org/jira/browse/TS-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-992: Assignee: Leif Hedstrom 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] [Assigned] (TS-997) ATS crashes on remap plugin initialization failure
[ https://issues.apache.org/jira/browse/TS-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-997: Assignee: Leif Hedstrom ATS crashes on remap plugin initialization failure --- Key: TS-997 URL: https://issues.apache.org/jira/browse/TS-997 Project: Traffic Server Issue Type: Bug Reporter: Manjesh Nilange Assignee: Leif Hedstrom Fix For: 3.1.1 Attachments: bad-destruction.patch A bad destructor causes the planned exit() to fail. This prevents remap plugins from logging why initialization failed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-947:
--
Assignee: John Plevyak (was: Alan M. Carroll)
AIO Race condition on non NT systems
Key: TS-947
URL: https://issues.apache.org/jira/browse/TS-947
Project: Traffic Server
Issue Type: Bug
Components: Core
Environment: stock build with static libts, running on a 4 core server
Reporter: B Wyatt
Assignee: John Plevyak
Fix For: 3.1.2
Attachments: lock-safe-AIO.patch
Refer to code below. The timeslice starting when a consumer thread
determines that the temp_list is empty (A) and ending when it releases the
aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
and as a result request producers enqueue items on the temporary atomic list
(D). As a consumer in this state will wait for a signal on aio_cond to
proceed before processing the temp_list again, any requests on the temp_list
are effectively stalled until a future request produces this signal or
manually processes the temp_list.
In the case of cache volume initialization, there is no future request and
the initialization sequence soft locks.
{code:title=iocore/aio/AIO.cc(annotated)}
void *
aio_thread_main(void *arg)
{
...
ink_mutex_acquire(my_aio_req-aio_mutex);
for (;;) {
do {
current_req = my_aio_req;
/* check if any pending requests on the atomic list */
A if (!INK_ATOMICLIST_EMPTY(my_aio_req-aio_temp_list))
aio_move(my_aio_req);
if (!(op = my_aio_req-aio_todo.pop()) !(op =
my_aio_req-http_aio_todo.pop()))
Bbreak;
...
service request
...
} while (1);
Cink_cond_wait(my_aio_req-aio_cond, my_aio_req-aio_mutex);
}
...
}
static void
aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
{
...
if (!ink_mutex_try_acquire(req-aio_mutex)) {
Dink_atomiclist_push(req-aio_temp_list, op);
} else {
/* check if any pending requests on the atomic list */
if (!INK_ATOMICLIST_EMPTY(req-aio_temp_list))
aio_move(req);
/* now put the new request */
aio_insert(op, req);
ink_cond_signal(req-aio_cond);
ink_mutex_release(req-aio_mutex);
}
...
}
{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] [Assigned] (TS-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-947:
--
Assignee: Alan M. Carroll
AIO Race condition on non NT systems
Key: TS-947
URL: https://issues.apache.org/jira/browse/TS-947
Project: Traffic Server
Issue Type: Bug
Components: Core
Environment: stock build with static libts, running on a 4 core server
Reporter: B Wyatt
Assignee: Alan M. Carroll
Fix For: 3.1.2
Attachments: lock-safe-AIO.patch
Refer to code below. The timeslice starting when a consumer thread
determines that the temp_list is empty (A) and ending when it releases the
aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
and as a result request producers enqueue items on the temporary atomic list
(D). As a consumer in this state will wait for a signal on aio_cond to
proceed before processing the temp_list again, any requests on the temp_list
are effectively stalled until a future request produces this signal or
manually processes the temp_list.
In the case of cache volume initialization, there is no future request and
the initialization sequence soft locks.
{code:title=iocore/aio/AIO.cc(annotated)}
void *
aio_thread_main(void *arg)
{
...
ink_mutex_acquire(my_aio_req-aio_mutex);
for (;;) {
do {
current_req = my_aio_req;
/* check if any pending requests on the atomic list */
A if (!INK_ATOMICLIST_EMPTY(my_aio_req-aio_temp_list))
aio_move(my_aio_req);
if (!(op = my_aio_req-aio_todo.pop()) !(op =
my_aio_req-http_aio_todo.pop()))
Bbreak;
...
service request
...
} while (1);
Cink_cond_wait(my_aio_req-aio_cond, my_aio_req-aio_mutex);
}
...
}
static void
aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
{
...
if (!ink_mutex_try_acquire(req-aio_mutex)) {
Dink_atomiclist_push(req-aio_temp_list, op);
} else {
/* check if any pending requests on the atomic list */
if (!INK_ATOMICLIST_EMPTY(req-aio_temp_list))
aio_move(req);
/* now put the new request */
aio_insert(op, req);
ink_cond_signal(req-aio_cond);
ink_mutex_release(req-aio_mutex);
}
...
}
{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] [Assigned] (TS-928) Compile problem in TsErrataUtil on FreeBSD 8
[ https://issues.apache.org/jira/browse/TS-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-928: Assignee: (was: Leif Hedstrom) 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] [Assigned] (TS-698) LogFilter should support an actual IP type and matching rules
[
https://issues.apache.org/jira/browse/TS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-698:
--
Assignee: Alan M. Carroll
LogFilter should support an actual IP type and matching rules
-
Key: TS-698
URL: https://issues.apache.org/jira/browse/TS-698
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Affects Versions: 2.1.6
Environment: N/A
Reporter: Eric Connell
Assignee: Alan M. Carroll
Priority: Minor
Fix For: 3.3.0
The LogFilter configuration in logs_xml.config should support a native IPv4
and IPv6 filtering. For example, it would be handy to be able to filter out
log lines from a specific server or netblock. For example, the following
config would reject log lines for all hosts in the 10/8 network:
{code}
LogFilter
Name = local_net/
Condition = chi MATCH 10.0.0.0/8/
Action = REJECT/
/LogFilter
LogFormat
Name = access_log/
Format = %shi/
/LogFormat
LogObject
Format = access_log/
Filename = access_log/
Filters = local_net/
/LogObject
{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] [Assigned] (TS-747) [GSoC2011] Add config option to disable SSL compression
[ https://issues.apache.org/jira/browse/TS-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-747: Assignee: Leif Hedstrom [GSoC2011] Add config option to disable SSL compression --- Key: TS-747 URL: https://issues.apache.org/jira/browse/TS-747 Project: Traffic Server Issue Type: Improvement Components: Configuration, SSL Reporter: Igor Galić Assignee: Leif Hedstrom Priority: Minor Labels: gsoc2011, ssl Fix For: 3.1.1 A configuration Option should be added to allow the administrator to disable SSL compression CONFIG proxy.config.ssl.compression INT 1 To maintain compatibility it should default to '1' (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] [Assigned] (TS-942) Assert in HttpTransact::HandleCacheOpenReadMiss
[
https://issues.apache.org/jira/browse/TS-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-942:
Assignee: (was: Leif Hedstrom)
Assert in HttpTransact::HandleCacheOpenReadMiss
---
Key: TS-942
URL: https://issues.apache.org/jira/browse/TS-942
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.1
Reporter: Leif Hedstrom
Priority: Critical
Fix For: 3.1.2
I'm seeing a crasher (see below), and it happens in code like this:
{code}
if (s-current.server-ip == 0) {
ink_release_assert(s-current.request_to == PARENT_PROXY ||
s-http_config_param-no_dns_forward_to_parent != 0);
if (s-current.request_to == PARENT_PROXY) {
{code}
What happens is that .server-ip is indeed 0, but current.request_to is !=
PARENT_PROXY (it is instead ORIGIN_SERVER). I've not seen this before, and it
reproduces rarely, so wondering if it could be IPv6 related.
Crasher:
{code}
(gdb) bt
#0 0x003f2de327f5 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x003f2de33fd5 in abort () at abort.c:92
#2 0x006407a1 in ink_die_die_die (return_code=value optimized out,
message_format=value optimized out, ap=0x2b0756137600) at ink_error.cc:43
#3 ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *)
(return_code=value optimized out, message_format=value optimized out,
ap=0x2b0756137600) at ink_error.cc:65
#4 0x006408d6 in ink_fatal (return_code=value optimized out,
message_format=value optimized out) at ink_error.cc:73
#5 0x0063f761 in _ink_assert (a=0x668400 s-current.request_to ==
PARENT_PROXY || s-http_config_param-no_dns_forward_to_parent != 0,
f=value optimized out, l=2952) at ink_assert.cc:44
#6 0x00516d5c in HttpTransact::HandleCacheOpenReadMiss
(s=0x2b0763638018) at HttpTransact.cc:2952
#7 0x004f08e2 in HttpSM::call_transact_and_set_next_state
(this=0x2b0763637fb0, f=value optimized out) at HttpSM.cc:6339
#8 0x004fffda in HttpSM::handle_api_return (this=0x2b0763637fb0) at
HttpSM.cc:1520
#9 0x004f2d42 in HttpSM::state_hostdb_lookup (this=value optimized
out, event=value optimized out, data=value optimized out) at
HttpSM.cc:2064
#10 0x00503de0 in HttpSM::main_handler (this=0x2b0763637fb0,
event=500, data=0x2b0760231860) at HttpSM.cc:2454
#11 0x0058d07b in handleEvent (cont=0x2b0763637fb0,
ar=0x2b0760231860) at ../../iocore/eventsystem/I_Continuation.h:146
#12 reply_to_cont (cont=0x2b0763637fb0, ar=0x2b0760231860) at HostDB.cc:552
#13 0x0058e939 in HostDBContinuation::dnsEvent (this=value optimized
out, event=value optimized out, e=value optimized out) at HostDB.cc:1504
#14 0x0059d281 in handleEvent (this=0x2a1c340, event=value optimized
out, e=value optimized out) at
../../iocore/eventsystem/I_Continuation.h:146
#15 DNSEntry::postEvent (this=0x2a1c340, event=value optimized out,
e=value optimized out) at DNS.cc:1265
#16 0x00638204 in handleEvent (this=0x2b0755e36010, e=0x2a61090,
calling_code=1) at I_Continuation.h:146
#17 EThread::process_event (this=0x2b0755e36010, e=0x2a61090, calling_code=1)
at UnixEThread.cc:140
#18 0x00638c7b in EThread::execute (this=0x2b0755e36010) at
UnixEThread.cc:189
#19 0x00637052 in spawn_thread_internal (a=0x1b206b0) at Thread.cc:88
#20 0x003f2e6068e0 in start_thread (arg=0x2b0756138710) at
pthread_create.c:297
#21 0x003f2dee0c9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#22 0x in ?? ()
(gdb) frame 6
#6 0x00516d5c in HttpTransact::HandleCacheOpenReadMiss
(s=0x2b0763638018) at HttpTransact.cc:2952
2952s-http_config_param-no_dns_forward_to_parent != 0);
(gdb) print s-current.request_to
$1 = ORIGIN_SERVER
(gdb) print s-current.server-ip
$2 = 0
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
