[jira] [Resolved] (TS-1121) --disable-diags configuration option does not do anything
[ https://issues.apache.org/jira/browse/TS-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1121. --- Resolution: Fixed Fixed in 0db892e25817c67c5994c527862e1eaa341be307 --disable-diags configuration option does not do anything - Key: TS-1121 URL: https://issues.apache.org/jira/browse/TS-1121 Project: Traffic Server Issue Type: Bug Components: Build, Core Affects Versions: 3.0.3 Environment: any Reporter: Uri Shachar Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.4 Original Estimate: 2h Remaining Estimate: 2h The --disable-diags flag sets TS_USE_DIAGS to 0 but Diags.h tests if it is defined or not -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1189) Build problem on CentOS5
[
https://issues.apache.org/jira/browse/TS-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1189.
---
Resolution: Fixed
Fixed as per jpeach's wishes.
Build problem on CentOS5
Key: TS-1189
URL: https://issues.apache.org/jira/browse/TS-1189
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Priority: Critical
Fix For: 3.1.4
{code}
diff --git a/iocore/net/SSLNetVConnection.cc b/iocore/net/SSLNetVConnection.cc
index 33ebe64..0a41a08 100644
--- a/iocore/net/SSLNetVConnection.cc
+++ b/iocore/net/SSLNetVConnection.cc
@@ -673,9 +673,9 @@ SSLNetVConnection::registerNextProtocolSet(const
SSLNextProtocolSet * s)
}
int
-SSLNetVConnection::advertise_next_protocol(
-SSL *ssl, const unsigned char **out, unsigned int *outlen, void *arg)
+SSLNetVConnection::advertise_next_protocol(SSL *ssl, const unsigned char
**out, unsigned int *outlen, void *arg)
{
+#if TS_USE_TLS_NPN
SSLNetVConnection * netvc = (SSLNetVConnection *)SSL_get_app_data(ssl);
ink_release_assert(netvc != NULL);
@@ -686,4 +686,7 @@ SSLNetVConnection::advertise_next_protocol(
}
return SSL_TLSEXT_ERR_NOACK;
+#else
+ return 0;
+#endif
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1190) Change default for proxy.config.http.share_server_sessions
[ https://issues.apache.org/jira/browse/TS-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1190. --- Resolution: Fixed Fixed in 3500ba8d0957a2cde866090786a81e258e134688. Change default for proxy.config.http.share_server_sessions -- Key: TS-1190 URL: https://issues.apache.org/jira/browse/TS-1190 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.4 We should enable session sharing with dedicated session pools per net-thread as the default. It has the best performance for a majority of our use cases. CONFIG proxy.config.http.share_server_sessions INT 2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (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 resolved TS-1156.
---
Resolution: Fixed
Resolved in cc6da81a3250bb9d7b5a276c8e69b9cc00e48e19.
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] [Resolved] (TS-1173) remap.config comments are wrong
[ https://issues.apache.org/jira/browse/TS-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1173. --- Resolution: Fixed Fix Version/s: (was: 3.3.0) 3.1.4 remap.config comments are wrong --- Key: TS-1173 URL: https://issues.apache.org/jira/browse/TS-1173 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 3.1.3 Reporter: Alan M. Carroll Assignee: Leif Hedstrom Priority: Minor Labels: remap Fix For: 3.1.4 The comments in remap.config describe the configuration lines incorrectly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1092) Remove server mode SSL termination.
[ https://issues.apache.org/jira/browse/TS-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1092. --- Resolution: Fixed Remove server mode SSL termination. --- Key: TS-1092 URL: https://issues.apache.org/jira/browse/TS-1092 Project: Traffic Server Issue Type: Improvement Components: SSL Affects Versions: 3.1.1 Reporter: Alan M. Carroll Assignee: Leif Hedstrom Priority: Minor Labels: cleanup, ssl Fix For: 3.1.4 Checks are done in the SSL configuration to check for server mode termination. As far as I can tell it is never actually used anywhere, nor is it documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1176) Eliminate the delayed delete of LogBuffer
[ https://issues.apache.org/jira/browse/TS-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1176. --- Resolution: Fixed Eliminate the delayed delete of LogBuffer - Key: TS-1176 URL: https://issues.apache.org/jira/browse/TS-1176 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.4 There's a race condition in another place in the code, and it's obvious to me that this deferred delete was done to avoid this race condition. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (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 resolved TS-1080.
---
Resolution: Fixed
Fixed in commit 3691e5dca658cc59885f803cc70c5616591d8b23
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] [Resolved] (TS-1172) Remove remap/StringHash.{cc,h}
[
https://issues.apache.org/jira/browse/TS-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1172.
---
Resolution: Fixed
Remove remap/StringHash.{cc,h}
--
Key: TS-1172
URL: https://issues.apache.org/jira/browse/TS-1172
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.1.4
These files are not used, nuke.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1078) trafficserver-3.1.1-unstable.tar.bz2 core dumps during load test
[
https://issues.apache.org/jira/browse/TS-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1078.
---
Resolution: Duplicate
Fix Version/s: (was: 3.1.4)
Marking as duplicate for now, please reopen if it still happens on trunk.
trafficserver-3.1.1-unstable.tar.bz2 core dumps during load test
Key: TS-1078
URL: https://issues.apache.org/jira/browse/TS-1078
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.1.1
Environment: Redhat linux with no plugins (although stack trace shows
our plugin being called). The tests were run with no plugin and exactly the
same stack trace occurred.
Reporter: Alistair Stevenson
Assignee: weijin
Priority: Blocker
{code}
(gdb) bt
#0 ink_restore_signal_handler_frame (stack=0x7f2a67650490, len=value
optimized out, signalhandler_frame=2) at ink_stack_trace.cc:68
#1 ink_stack_trace_get (stack=0x7f2a67650490, len=value optimized out,
signalhandler_frame=2) at ink_stack_trace.cc:89
#2 0x7f2a682dcf7d in ink_stack_trace_dump (sighandler_frame=2) at
ink_stack_trace.cc:114
#3 0x004d2512 in signal_handler (sig=11) at signals.cc:222
#4 signal handler called
#5 ink_atomiclist_push (l=0x100bb0, item=0x72a9100) at ink_queue.cc:457
#6 0x0065800b in ProtectedQueue::enqueue (this=0x100bb0, e=value
optimized out, fast_signal=false) at ProtectedQueue.cc:53
#7 0x0062c3ca in NetVConnection::Handle::do_locked_io_close
(this=0x6e01830, lerrno=-1) at NetVConnection.cc:93
#8 0x00507608 in HttpServerSession::do_io_close (this=0x6e01770,
alerrno=value optimized out) at HttpServerSession.cc:122
#9 0x0050a78b in HttpSessionManager::acquire_session (this=0x941940,
cont=value optimized out, ip=0xa5443c0, hostname=0x5732c19
10.20.48.15, ua_session=value optimized out, sm=0xa543d20)
at HttpSessionManager.cc:257
#10 0x0051d544 in HttpSM::do_http_server_open (this=0xa543d20,
raw=false) at HttpSM.cc:4139
#11 0x0051e0e8 in HttpSM::set_next_state (this=0xa543d20) at
HttpSM.cc:6464
#12 0x0050b8ff in HttpSM::call_transact_and_set_next_state
(this=0xa543d20, f=value optimized out) at HttpSM.cc:6319
#13 0x005162d8 in HttpSM::state_api_callout (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1446
#14 0x00518499 in HttpSM::state_api_callback (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1265
#15 0x004a9af8 in TSHttpTxnReenable (txnp=value optimized out,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5407
#16 0x7f2a63a3d45b in opwvPluginHandler (contp=0x7631780,
event=TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE, edata=0xa543d20) at
/bfs-build/build-area.93/builds/LinuxNBngp_andes/2012-01-09-0057/http/src/traffi
c_server/plugin.cpp:82
#17 0x00516585 in HttpSM::state_api_callout (this=0xa543d20,
event=value optimized out, data=value optimized out) at
HttpSM.cc:1372
#18 0x0051de1a in HttpSM::set_next_state (this=0xa543d20) at
HttpSM.cc:6353
#19 0x0050b8ff in HttpSM::call_transact_and_set_next_state
(this=0xa543d20, f=value optimized out) at HttpSM.cc:6319
#20 0x005162d8 in HttpSM::state_api_callout (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1446
#21 0x00518499 in HttpSM::state_api_callback (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1265
#22 0x004a9af8 in TSHttpTxnReenable (txnp=value optimized out,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5407
#23 0x7f2a63a3d6cc in opwvPluginHandler (contp=0x7631780,
event=TS_EVENT_HTTP_OS_DNS, edata=0xa543d20) at
/bfs-build/build-area.93/builds/LinuxNBngp_andes/2012-01-09-0057/http/src/traffi
c_server/plugin.cpp:117
#24 0x00516585 in HttpSM::state_api_callout (this=0xa543d20,
event=value optimized out, data=value optimized out) at
HttpSM.cc:1372
#25 0x0051de1a in HttpSM::set_next_state (this=0xa543d20) at
HttpSM.cc:6353
#26 0x0050b8ff in HttpSM::call_transact_and_set_next_state
(this=0xa543d20, f=value optimized out) at HttpSM.cc:6319
#27 0x0050d58a in HttpSM::do_hostdb_lookup (this=0xa543d20) at
HttpSM.cc:3749
#28 0x0051e72b in HttpSM::set_next_state (this=0xa543d20) at
HttpSM.cc:6414
#29 0x0050b8ff in HttpSM::call_transact_and_set_next_state
(this=0xa543d20, f=value optimized out) at HttpSM.cc:6319
#30 0x005162d8 in HttpSM::state_api_callout (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1446
#31 0x00518499 in HttpSM::state_api_callback (this=0xa543d20,
event=6, data=0x0) at HttpSM.cc:1265
#32 0x004a9af8 in TSHttpTxnReenable (txnp=value optimized out,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5407
#33 0x7f2a63a3d4eb in opwvPluginHandler
[jira] [Resolved] (TS-981) Remove libev support (it's not well support, and might crash)
[ https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-981. -- Resolution: Fixed Remove libev support (it's not well support, and might crash) - 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] [Resolved] (TS-768) [GSoc2011] content compression plugin (gzip plugin)
[ https://issues.apache.org/jira/browse/TS-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-768. -- Resolution: Duplicate Fix Version/s: (was: 3.1.5) Closing this as a duplicate, please reopen if not true. [GSoc2011] content compression plugin (gzip plugin) --- Key: TS-768 URL: https://issues.apache.org/jira/browse/TS-768 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Igor Galić Labels: compression, gsoc2011, plugin Traffic Server needs a plugin which will allow administrators (of reverse proxies, chiefly) to configure a single point at which content compression happens, thereby reducing the pressure on the back-ends even more Gzipped content SHOULD be cachable. Furthermore it MUST conform to RFC 2616, as well as the upcoming httpbis: see e.g.: http://tools.ietf.org/id/draft-ietf-httpbis-p3-payload-14.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-796) Crash Report: mime_str_u16_set, possible
[
https://issues.apache.org/jira/browse/TS-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-796.
--
Resolution: Duplicate
Fix Version/s: (was: 3.1.5)
I'm fairly certain this is the same strack trace as from CVE 2012-0256, so
closing this. Please reopen if not the case.
Crash Report: mime_str_u16_set, possible
Key: TS-796
URL: https://issues.apache.org/jira/browse/TS-796
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 2.1.8
Reporter: Zhao Yongming
Labels: crash
report from user, may need more detail
{code}
/usr/local/ts/bin/traffic_server(mime_str_u16_set(HdrHeap*, char const*,
unsigned short, char const**, unsigned short*,
bool)+0x5d)[0x821b16d]/usr/local/ts/bin/traffic_server(url_host_set(HdrHeap*,
URLImpl*, char const*, int, bool)+0x51)[0x82251c1]
/usr/local/ts/bin/traffic_server(HTTPHdr::set_url_target_from_host_field(URL*)+0x84)[0x8215a74]
/usr/local/ts/bin/traffic_server(RemapProcessor::setup_for_remap(HttpTransact::State*)+0x272)[0x81c6132]
/usr/local/ts/bin/traffic_server(HttpSM::do_remap_request(bool)+0x3a)[0x816bf8a]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0xad3)[0x81855b3]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0xab)[0x816903b]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x19f)[0x818278f]
/usr/local/ts/bin/traffic_server(HttpSM::state_api_callout(int,
void*)+0x340)[0x8178f60]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x160)[0x8184c40]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0xab)[0x816903b]
/usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x19f)[0x818278f]
/usr/local/ts/bin/traffic_server(HttpSM::state_api_callout(int,
void*)+0x340)[0x8178f60]
/usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x160)[0x8184c40]
/usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0xab)[0x816903b]
/usr/local/ts/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x31d)[0x817cf9d]
/usr/local/ts/bin/traffic_server(HttpSM::main_handler(int,
void*)+0x1a4)[0x8181154]
/usr/local/ts/bin/traffic_server[0x82f6d4c]
/usr/local/ts/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x515)[0x82eb295]
/usr/local/ts/bin/traffic_server(EThread::process_event(Event*,
int)+0x1ff)[0x831fa9f]
/usr/local/ts/bin/traffic_server(EThread::execute()+0x449)[0x8320249]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1133) Make remap max-host length configure.ac configurable
[ https://issues.apache.org/jira/browse/TS-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1133. --- Resolution: Fixed Make remap max-host length configure.ac configurable Key: TS-1133 URL: https://issues.apache.org/jira/browse/TS-1133 Project: Traffic Server Issue Type: Improvement Components: Remap API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.3 Right now, we have a hardcoded limit of 256 bytes on the Host matching. We should make this configurable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1126) traffic_server is unable to bind 127.0.0.1:8084 (the default mgmt port) on OSX
[
https://issues.apache.org/jira/browse/TS-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1126.
---
Resolution: Fixed
Fixed with commit:
457f85b71de4776da461eae9ce8226a5b157321d
traffic_server is unable to bind 127.0.0.1:8084 (the default mgmt port) on OSX
--
Key: TS-1126
URL: https://issues.apache.org/jira/browse/TS-1126
Project: Traffic Server
Issue Type: Bug
Components: Management API
Affects Versions: 3.1.2
Reporter: Leif Hedstrom
Priority: Critical
Fix For: 3.1.3
When we start up, it errors out binding 8084:
[Mar 1 16:40:33.937] Server {0x7fff74cdb960} ERROR: Could not bind or listen
to port 8084 (error: -1)
[Mar 1 16:40:33.937] Server {0x7fff74cdb960} WARNING: unable to listen on
port 8084: -1 49, Can't assign requested address
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1124) Move a few plugins into main repo.
[ https://issues.apache.org/jira/browse/TS-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1124. --- Resolution: Fixed Move a few plugins into main repo. -- Key: TS-1124 URL: https://issues.apache.org/jira/browse/TS-1124 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.3 Moving regex_remap, header_filter and stats_over_http into main git repo (in plugins). I've tried to preserve history, but it gets a little wonky due to the change in directory structure. But the history is there :). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1104) Build problem on solaris
[
https://issues.apache.org/jira/browse/TS-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1104.
---
Resolution: Fixed
Build problem on solaris
Key: TS-1104
URL: https://issues.apache.org/jira/browse/TS-1104
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.1.3
Reported and fixed by Igor Brezac
{code}
--- Store.cc.orig 2012-02-06 10:11:26.365180262 -0500
+++ Store.cc2012-02-06 10:11:56.035330329 -0500
@@ -629,7 +629,7 @@
blocks = size / STORE_BLOCK_SIZE;
file_pathname = !((s.st_mode S_IFMT) == S_IFDIR);
- Debug(cache_init, Span::init - %s hw_sector_size = %d size = %
PRId64 , blocks = % PRId64 , disk_id = %d, file_pathname = %d,
filename, hw_sector_size, size, blocks, disk_id, file_pathname);
+ Debug(cache_init, Span::init - %s hw_sector_size = % PRId64 ,
size = % PRId64 , blocks = % PRId64 , disk_id = %d, file_pathname
= %d, filename, hw_sector_size, size, blocks, disk_id,
file_pathname);
Lfail:
socketManager.close(fd);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1101) traffic_line -x doesn't seem to work
[ https://issues.apache.org/jira/browse/TS-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1101. --- Resolution: Fixed traffic_line -x doesn't seem to work Key: TS-1101 URL: https://issues.apache.org/jira/browse/TS-1101 Project: Traffic Server Issue Type: Bug Components: Management Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Blocker Fix For: 3.1.2 traffic_line -x doesn't seem to work any more. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1098) Make RC script support Amazon EC2 Linux AMI
[ https://issues.apache.org/jira/browse/TS-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1098. --- Resolution: Fixed Make RC script support Amazon EC2 Linux AMI --- Key: TS-1098 URL: https://issues.apache.org/jira/browse/TS-1098 Project: Traffic Server Issue Type: Improvement Components: Packaging Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.2 Add support to detect the Amazon Linux flavor of RHEL/CentOS that runs in the default AMIs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-17) Expose atomic abstractions via InkAPI
[ https://issues.apache.org/jira/browse/TS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-17. - Resolution: Won't Fix Fix Version/s: (was: 3.3.0) I think this is a moot point now, people should just use the standard gcc atomics. Expose atomic abstractions via InkAPI - Key: TS-17 URL: https://issues.apache.org/jira/browse/TS-17 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor With the changes being made to the atomic abstractions, we should take this opportunity to expose atomic APIs via InkAPI (InkAPI.h). Breaking API or binarby ABIs is not a problem. Doing this, will make it easier to use atomic instructions in plugins, and keep the plugins cross platform. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-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 ] Leif Hedstrom resolved TS-1061. --- Resolution: Fixed Committed on trunk, sorry for tardiness, please keep 'em bug reports coming! 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: Leif Hedstrom 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] [Resolved] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1091.
---
Resolution: Fixed
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Assignee: Leif Hedstrom
Priority: Minor
Labels: autoconf, build, configure
Fix For: 3.1.2
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7'
to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int,
int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code
(http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising
but I could not find one that worked), but I could not find any #pragma that
seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e
's/ -w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-524) Have a single directive for HTTP ports
[ https://issues.apache.org/jira/browse/TS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-524. -- Resolution: Fixed Duplicate of TS-1077. Have a single directive for HTTP ports -- Key: TS-524 URL: https://issues.apache.org/jira/browse/TS-524 Project: Traffic Server Issue Type: Improvement Components: Configuration Affects Versions: 3.0.0 Environment: Any Reporter: Marcus Clyne Priority: Trivial Why have both proxy.config.http.server_port and proxy.config.http.server_other_ports as config options? Unless there is a good reason to have to options, it would probably be better to have a single config option. See also https://issues.apache.org/jira/browse/TS-523 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-523) [GSoC2011] Allow the use of multiple SSL ports
[ https://issues.apache.org/jira/browse/TS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-523. -- Resolution: Duplicate Duplicated of TS-1077 [GSoC2011] Allow the use of multiple SSL ports -- Key: TS-523 URL: https://issues.apache.org/jira/browse/TS-523 Project: Traffic Server Issue Type: New Feature Components: Configuration, SSL Affects Versions: 2.1.3 Reporter: Marcus Clyne Priority: Minor Labels: gsoc2011, ssl Currently proxy.config.ssl.server_port allows only one SSL port to be specified, and it appears that it is not possible to specify multiple ports for SSL like proxy.config.http.server_other_ports. It would make sense to have a single directive as a string for all SSL ports, rather than have two config options like HTTP ports (a separate ticket has been posted for that - see https://issues.apache.org/jira/browse/TS-524). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-448) Provide the ability to bind to more than one interface
[ https://issues.apache.org/jira/browse/TS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-448. -- Resolution: Duplicate Marking as duplicate of TS-1077. Provide the ability to bind to more than one interface -- Key: TS-448 URL: https://issues.apache.org/jira/browse/TS-448 Project: Traffic Server Issue Type: Improvement Components: Network Affects Versions: 2.1.0 Reporter: Shaun McGinnity Priority: Minor If I am running Traffic Server on a machine with multiple interfaces I would like to able to bind to a subset of those interfaces. I can bind to all or one using proxy.local.incoming_ip_to_bind but can't bind to more than one, but not all. It would also be useful to be able to specify different listening ports per interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-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 resolved TS-996. -- Resolution: Fixed 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, m_host.v3.patch, m_host.v4.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] [Resolved] (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 resolved TS-1049. --- Resolution: Fixed Great job Wilson! 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] [Resolved] (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 resolved TS-1074. --- Resolution: Fixed Resolving this. Brian, would you mind going through the bug list, and close as duplicate(s) whatever bugs you think this actually fixes as well? 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] [Resolved] (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 resolved TS-254. -- Resolution: Fixed Resolving for now, please reopen if there is a problem with this proposal. 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.2 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] [Resolved] (TS-999) Deprecate TSUrlDestroy ?
[ https://issues.apache.org/jira/browse/TS-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-999. -- Resolution: Fixed Deprecate TSUrlDestroy ? Key: TS-999 URL: https://issues.apache.org/jira/browse/TS-999 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.2 This API is a complete no-op as of quite a while ago. Should we just deprecate it? Or, does anyone foresee a future where we actually need to call TSUrlDestroy? Alan? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (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 resolved TS-1055.
---
Resolution: Fixed
Closing for now, reopen if/when we decide to backport to 3.0.x.
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] [Resolved] (TS-1028) Assert when enabling shared origin connections with a setting of 2
[ https://issues.apache.org/jira/browse/TS-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1028. --- Resolution: Fixed Assert when enabling shared origin connections with a setting of 2 -- Key: TS-1028 URL: https://issues.apache.org/jira/browse/TS-1028 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.2 When you enable the 2 setting for sharing origin connections (which creates a connection pool per net-thread), we trigger an assert in Debug builds. I think it only triggers too with logging enabled, but not certain. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1027) remap.config limited to ~255 entries
[
https://issues.apache.org/jira/browse/TS-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1027.
---
Resolution: Invalid
remap.config limited to ~255 entries
Key: TS-1027
URL: https://issues.apache.org/jira/browse/TS-1027
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 3.0.2
Reporter: Greg Dallavalle
Remap.config errors out trafficserver when the entries exceed ~249
Due to issue TS-1024 I am using a large number of remaps to workaround the
issue. With this limit I'm unable to proceed with ATS. If there are ways to
overcome these problems, by all means, I'd be happy to listen and test.
The errors from traffic.out:
[Nov 21 15:20:08.572] Server {1080866016} ERROR: Cannot insert duplicate!
[Nov 21 15:20:08.573] Server {1080866016} ERROR: Couldn't insert into trie!
[Nov 21 15:20:08.573] Server {1080866016} ERROR: Could not insert new mapping
[Nov 21 15:20:08.573] Server {1080866016} WARNING: Could not add rule at line
#249; Aborting!
[Nov 21 15:20:08.578] Server {1080866016} WARNING: [ReverseProxy] Unable to
add mapping rule to lookup table at line 249
FATAL: [ReverseProxy] Unable to add mapping rule to lookup table at line 249
/usr/bin/traffic_server - STACK TRACE:
/usr/lib/trafficserver/libtsutil.so.3(ink_fatal_va+0xf7)[0x400301a7]
/usr/lib/trafficserver/libtsutil.so.3(ink_fatal+0x2c)[0x4003020c]
/usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x5a2)[0x819b402]
/usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x337)[0x819da87]
/usr/bin/traffic_server(_Z18init_reverse_proxyv+0x9a)[0x810bb6a]
/usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x814664b]
/usr/bin/traffic_server(main+0x12bb)[0x80b547b]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x40561113]
/usr/bin/traffic_server[0x80baffd]
[Nov 21 15:20:08.638] Manager {3072087760} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: (last system error 2: No
such file or directory)
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Nov 21 15:20:08.639] Manager {3072087760} ERROR: (last system error 2: No
such file or directory)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-985) ts/ts.h uses C++ comments, which are technically not C
[ https://issues.apache.org/jira/browse/TS-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-985. -- Resolution: Fixed ts/ts.h uses C++ comments, which are technically not C -- Key: TS-985 URL: https://issues.apache.org/jira/browse/TS-985 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.1.1 So, replace // with /* */ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-948) do not reload bad remap.config
[ https://issues.apache.org/jira/browse/TS-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-948. -- Resolution: Fixed Resolving again, please reopen with more issues ;). do not reload bad remap.config -- Key: TS-948 URL: https://issues.apache.org/jira/browse/TS-948 Project: Traffic Server Issue Type: Improvement Components: Configuration, Management Affects Versions: 3.1.0, 3.0.1 Reporter: Conan Wang Assignee: Leif Hedstrom Priority: Critical Fix For: 3.1.1 traffic_server will exit if exists bad rules in remap.config, whenever startup or reload ( traffic_line -x ). If remap.config is not edited correctly, the server/cluster will crash when reloading. It's better to pre-check the remap table and not switch to the new table if remap.config is not enough correct. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-948) do not reload bad remap.config
[ https://issues.apache.org/jira/browse/TS-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-948. -- Resolution: Fixed do not reload bad remap.config -- Key: TS-948 URL: https://issues.apache.org/jira/browse/TS-948 Project: Traffic Server Issue Type: Improvement Components: Configuration, Management Affects Versions: 3.1.0, 3.0.1 Reporter: Conan Wang Assignee: Leif Hedstrom Priority: Critical Fix For: 3.1.1 traffic_server will exit if exists bad rules in remap.config, whenever startup or reload ( traffic_line -x ). If remap.config is not edited correctly, the server/cluster will crash when reloading. It's better to pre-check the remap table and not switch to the new table if remap.config is not enough correct. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-922) TSVIONTodoGet() has bug!
[
https://issues.apache.org/jira/browse/TS-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-922.
--
Resolution: Invalid
I'm closing this as invalid, I think William's comment is accurate, it's as
expected. Please reopen if you disagree.
TSVIONTodoGet() has bug!
Key: TS-922
URL: https://issues.apache.org/jira/browse/TS-922
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.0.1
Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0, Web
Browser：firefox 4.0.1，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk:
500G
Reporter: taoyunxing
Labels: TS_API_bug
Fix For: 3.1.1
Original Estimate: 672h
Remaining Estimate: 672h
when I use null-transform plugin and print some debug info, I find the
TSVIONTodoGet() return a huge member, I consider it maybe has a bug !
The details shows below:
code in null-transform.c:
TSVIO input_vio;
int64_t towrite = 0;
int64_t avail = 0;
towrite = TSVIONTodoGet(input_vio);
TSDebug(null-transform, \ttoWrite is % PRId64 , towrite);
if (towrite 0) {
/* The amount of data left to read needs to be truncated by
* the amount of data actually in the read buffer.
*/
avail = TSIOBufferReaderAvail(TSVIOReaderGet(input_vio));
TSDebug(null-transform, \tavail is % PRId64 , avail);
#if MDSN_LOG
if (log) {
TSTextLogObjectWrite(log, handle_transform() with data to
write length: % PRId64 , IOBufferReader available data length: % PRId64
, towrite, avail);}
#endif
log info:
20110818.13h51m11s handle_transform() with data to write length:
9223372036854775807, IOBufferReader available data length: 1388
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-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
]
Leif Hedstrom resolved TS-830.
--
Resolution: Fixed
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: Leif Hedstrom
Priority: Minor
Fix For: 3.1.1
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] [Resolved] (TS-962) typo of key name in logstats.cc
[
https://issues.apache.org/jira/browse/TS-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-962.
--
Resolution: Fixed
typo of key name in logstats.cc
---
Key: TS-962
URL: https://issues.apache.org/jira/browse/TS-962
Project: Traffic Server
Issue Type: Bug
Components: Stats
Affects Versions: 3.0.1
Reporter: Nick Berry
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 3.1.1
Attachments: logstats.cc-key_name_typo-patch
appears in trunk as well.
{code}
$ traffic_logstats -j
{ total: {
*snip*
error.conenct_failed : { req: 0, req_pct: 0.00, bytes: 0,
bytes_pct: 0.00 },
*snip*
},
}
{code}
error.connect_failed is misspelled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-940) Support altering the initial congestion window for inbound UA connections.
[ https://issues.apache.org/jira/browse/TS-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-940. -- Resolution: Fixed I'm closing this, since I think / assume this is completed? If not, please reopen (or open a followup bug). Support altering the initial congestion window for inbound UA connections. -- Key: TS-940 URL: https://issues.apache.org/jira/browse/TS-940 Project: Traffic Server Issue Type: Improvement Components: Network Affects Versions: 3.1.0 Reporter: Theo Schlossnagle Assignee: Theo Schlossnagle Priority: Minor Fix For: 3.1.1 Original Estimate: 24h Remaining Estimate: 24h http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-01 This is particularly useful for CDNs. We should allow traffic server to bump this on operating systems that support it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-964) No 64bit integer plugin APIs for HTTP headers
[ https://issues.apache.org/jira/browse/TS-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-964. -- Resolution: Fixed No 64bit integer plugin APIs for HTTP headers - Key: TS-964 URL: https://issues.apache.org/jira/browse/TS-964 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: William Bardwell Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.1 There are APIs for unsigned int, but stuff like content-length should be done as 64-bit values, so we should add TSMimeHdrFieldValueUint64Get(), TSMimeHdrFieldValueUint64Set(), TSMimeHdrFieldValueUint64Insert() or Int64 versions of those APIs (since the mime_* stuff seems to have unsigned int, int and int64, but no uint64). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
