[jira] [Updated] (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
]
Leif Hedstrom updated TS-947:
-
Fix Version/s: (was: 3.1.2)
sometime
Moving this out for later, we might want John Plevyak to look at this, and see
if this needs a more thorough redesign.
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: sometime
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] [Updated] (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
]
Leif Hedstrom updated TS-857:
-
Fix Version/s: (was: 3.1.1)
3.1.3
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.3
Attachments: ts-857.diff, ts-857.diff
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] [Commented] (TS-837) ATS fails to compile with gcc 4.6.1 with --enable-debug
[
https://issues.apache.org/jira/browse/TS-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163067#comment-13163067
]
Leif Hedstrom commented on TS-837:
--
What's the status here ? I'm compiling with gcc 4.6.2 without problems.
ATS fails to compile with gcc 4.6.1 with --enable-debug
---
Key: TS-837
URL: https://issues.apache.org/jira/browse/TS-837
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.0
Environment: Linux, Debian, Amd64 + GCC 4.6.1
Reporter: Igor Galić
Assignee: Igor Galić
Fix For: 3.1.4
Attachments: proxything.diff
{noformat}
In file included from ../../proxy/ControlMatcher.h:104:0,
from ../../proxy/ParentSelection.h:37,
from P_Socks.h:30,
from P_Net.h:106,
from Connection.cc:34:
../../proxy/hdrs/HTTP.h: In member function 'INK_MD5
HTTPInfo::object_key_get()':
../../proxy/hdrs/HTTP.h:1375:24: error: dereferencing type-punned pointer
will break strict-aliasing rules [-Werror=strict-aliasing]
../../proxy/hdrs/HTTP.h: In member function 'int64_t
HTTPInfo::object_size_get()':
../../proxy/hdrs/HTTP.h:1405:24: error: dereferencing type-punned pointer
will break strict-aliasing rules [-Werror=strict-aliasing]
../../proxy/hdrs/HTTP.h: In member function 'void
HTTPInfo::object_size_set(int64_t)':
../../proxy/hdrs/HTTP.h:1422:51: error: dereferencing type-punned pointer
will break strict-aliasing rules [-Werror=strict-aliasing]
cc1plus: all warnings being treated as errors
*** [Connection.o] Error 1
make[2]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore/net'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore'
make: *** [all-recursive] Error 1
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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 ] Leif Hedstrom updated TS-669: - Fix Version/s: (was: 3.1.4) 3.3.0 [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 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] [Updated] (TS-32) Fix ICP
[ https://issues.apache.org/jira/browse/TS-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-32: Fix Version/s: (was: 3.1.4) 3.3.0 Fix ICP --- Key: TS-32 URL: https://issues.apache.org/jira/browse/TS-32 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.0 Reporter: Miles Libbey Fix For: 3.3.0 http://icp.ircache.net/ The ICP implementation in Traffic Server broke when epoll() was introduced. Its still an interesting and used feature in caches: - when a caching layer of several boxes are used ICP helps to reduce disparities when a client is not routed to the same cache on subsequent requests - after a restart, it can help reduce the time spent in a cold cache situation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-939) enhance DNS round robin functionality in ATS
[ https://issues.apache.org/jira/browse/TS-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-939: - Fix Version/s: (was: 3.1.4) 3.3.0 enhance DNS round robin functionality in ATS Key: TS-939 URL: https://issues.apache.org/jira/browse/TS-939 Project: Traffic Server Issue Type: New Feature Components: DNS Affects Versions: 3.0.0 Reporter: vijaya bhaskar mamidi Priority: Minor Fix For: 3.3.0 right now proxy.config.dns.round_robin_nameservers can only have two values # Enables (1) or disables (0) DNS server round-robin. CONFIG proxy.config.dns.round_robin_nameservers INT 1 enhance the above feature to have a third value (2). If the value is set to 2, it should do round robin and if ATS fails to connect to one of the IP tries to connect to other one if all the IPs are tried return a error to Client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-954) when use raw disks, some blocks is lost when caculate disk usable blocks
[ https://issues.apache.org/jira/browse/TS-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-954: - Fix Version/s: (was: 3.1.4) 3.3.0 when use raw disks, some blocks is lost when caculate disk usable blocks Key: TS-954 URL: https://issues.apache.org/jira/browse/TS-954 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0 Environment: all when use raw disks Reporter: weijin Assignee: John Plevyak Fix For: 3.3.0 Attachments: calcu_blocks.dff when use raw disks, some blocks may be lost because the skip variable is in bytes not in blocks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-612) ATS does not allow password protected certificates
[
https://issues.apache.org/jira/browse/TS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-612:
-
Fix Version/s: (was: 3.1.4)
3.3.0
ATS does not allow password protected certificates
--
Key: TS-612
URL: https://issues.apache.org/jira/browse/TS-612
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Affects Versions: 3.0.0
Environment: Any
Reporter: Igor Galić
Fix For: 3.3.0
Create a (self-signed) certificate with a password that is non-empty. {cat
server.key server.crt server.pem} and configure it as
{CONFIG proxy.config.ssl.server.cert.filename STRING server.pem}
The result will be:
{noformat}
Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: --- Server Starting
---
Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: Server Version:
Apache Traffic Server - traffic_server - 2.0.1 - (build # 113112 on Dec 31
2010 at 12:58:34)
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} STATUS: opened
var/log/trafficserver/diags.log
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: updated
diags config
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
clustering disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING: no
cache disks specified in etc/trafficserver/storage.config: cache disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
clustering disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING:
unable to open cache disk(s): Cache Disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
ERROR: Cannot use server private key file.
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
SSL::0:error:0906406D:PEM routines:PEM_def_callback:problems getting
password:pem_lib.c:105:
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
SSL::0:error:0906A068:PEM routines:PEM_do_header:bad password
read:pem_lib.c:406:
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
SSL::0:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM
lib:ssl_rsa.c:669:
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
ERROR: Can't initialize the SSL library, disabling SSL termination!.
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: logging
initialized[7], logging_mode = 3
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: traffic
server running
{noformat}
A first -- ugly -- shot would be to at least have a password field in the
configuration.
In the end something taking the input of an external program or from a file
would be more desirable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-799) Have AdminClient.pm created from .in file
[ https://issues.apache.org/jira/browse/TS-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-799: - Fix Version/s: (was: 3.1.4) 3.3.0 Have AdminClient.pm created from .in file - Key: TS-799 URL: https://issues.apache.org/jira/browse/TS-799 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.0 Reporter: Igor Galić Priority: Trivial Fix For: 3.3.0 AdminClient.pm should be created from an .in file. @sockets_def = should be extended with @localstatedir@ on top. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-340) EC2 Updates/Testing/Building
[ https://issues.apache.org/jira/browse/TS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-340: - Fix Version/s: (was: 3.1.4) 3.3.0 EC2 Updates/Testing/Building Key: TS-340 URL: https://issues.apache.org/jira/browse/TS-340 Project: Traffic Server Issue Type: Bug Components: Build, Portability Affects Versions: 3.0.0, 2.0.0a Environment: EC2 Reporter: Jason Giedymin Assignee: Jason Giedymin Priority: Minor Labels: AMI, EC2, Fedora, Ubuntu Fix For: 3.3.0 1.) More Lucid Testing 2.) Rebuild with latest ATS Release 3.) Seed to West, EU, Asia datacenters (20 Images in total, Fedora/Ubuntu9/Ubuntu10/32/64) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-946) Scheduling a continuation on all threads of a specific type
[ https://issues.apache.org/jira/browse/TS-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-946: - Fix Version/s: (was: 3.1.4) 3.3.0 Scheduling a continuation on all threads of a specific type --- Key: TS-946 URL: https://issues.apache.org/jira/browse/TS-946 Project: Traffic Server Issue Type: New Feature Components: Core Affects Versions: 3.0.0 Reporter: Leif Hedstrom Fix For: 3.3.0 It would be incredibly useful, both in the core and in plugin APIs, to be able to schedule a continuation to run on all threads of a specific type. E.g. in a plugin, something like TSAction TSContScheduleOnThreads(TSCont cont, TSThreadPool tp); This would be useful for e.g. setting up per-thread specifics from a plugin, but quite possibly also from the core. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-858) traffic_server segmentation_fault when cache storage value is below 65M
[
https://issues.apache.org/jira/browse/TS-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-858:
-
Fix Version/s: (was: 3.1.4)
3.3.0
traffic_server segmentation_fault when cache storage value is below 65M
---
Key: TS-858
URL: https://issues.apache.org/jira/browse/TS-858
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.0.0
Environment: Fedora 14
Reporter: Kevin Giles
Priority: Minor
Fix For: 3.3.0
specify the storage as var/trafficserver 64M in the storage.conf,
traffic_server will core dump upon launch, the following is the stack trace:
{noformat}
FATAL: Cache.cc:2293: failed assert `dpb dpb-len == (uint64_t)b`
traffic_server - STACK TRACE:
traffic_server(ink_fatal_va+0x8e)[0x82ef221]
traffic_server(ink_fatal+0x1e)[0x82ef252]
traffic_server(_ink_assert+0x90)[0x82eeb6c]
traffic_server(cplist_reconfigure()+0x2fd)[0x8283054]
traffic_server(CacheProcessor::diskInitialized()+0x19b)[0x827b7d1]
traffic_server(CacheDisk::openDone(int, void*)+0x40)[0x8291142]
traffic_server(CacheDisk::clearDone(int, void*)+0xcc)[0x8290eb2]
traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
traffic_server(AIOCallbackInternal::io_complete(int, void*)+0x2c)[0x82862c8]
traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
traffic_server(EThread::process_event(Event*, int)+0x10e)[0x82e83f2]
traffic_server(EThread::execute()+0xa6)[0x82e862a]
traffic_server[0x82e74b1]
/lib/libpthread.so.0[0x658e99]
/lib/libc.so.6(clone+0x5e)[0x59ed2e]
{noformat}
It will core dump everytime, if the cache size is set to 65M, traffic_server
will launch fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-362) Create packaging scripts for TrafficServer
[ https://issues.apache.org/jira/browse/TS-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-362: - Fix Version/s: (was: 3.1.4) 3.3.0 Create packaging scripts for TrafficServer -- Key: TS-362 URL: https://issues.apache.org/jira/browse/TS-362 Project: Traffic Server Issue Type: New Feature Components: Packaging Affects Versions: 3.0.0 Environment: Linux, Solaris Reporter: Mladen Turk Assignee: Mladen Turk Priority: Minor Fix For: 3.3.0 Original Estimate: 504h Remaining Estimate: 504h Create pkg directory build/pkg with sub-directories for rpm and pkg This will allow to create .rpm and Solaris .package.gz platform native installation packages -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-242) Connect timeout doesn't reset until first byte is received from server
[ https://issues.apache.org/jira/browse/TS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-242: - Fix Version/s: (was: 3.1.3) 3.3.0 Connect timeout doesn't reset until first byte is received from server -- Key: TS-242 URL: https://issues.apache.org/jira/browse/TS-242 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Steve Jiang Assignee: Alan M. Carroll Priority: Minor Fix For: 3.3.0 proxy.config.http.connect_attempts_timeout proxy.config.http.parent_proxy.connect_attempts_timeout proxy.config.http.post_connect_attempts_timeout These timeouts are implemented with inactivity timeout on the netvc and don't behave as expected. If the connect succeeds (the remote server successfully accepted) but the remote server does not respond with any bytes within the timeout period, TS still treats it as a connect timeout. If retries are enabled and the origin server is slow to start sending responses (but not down), it will keep sending requests and closing the connection after getting no response within the connect timeout. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-999) Deprecate TSUrlDestroy ?
[ https://issues.apache.org/jira/browse/TS-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-999: - Fix Version/s: (was: 3.1.2) 3.1.3 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.3 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] [Updated] (TS-965) cache.config can't deal with both revalidate= and ttl-in-cache= specified
[ https://issues.apache.org/jira/browse/TS-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-965: - Fix Version/s: (was: 3.1.2) 3.1.3 cache.config can't deal with both revalidate= and ttl-in-cache= specified - Key: TS-965 URL: https://issues.apache.org/jira/browse/TS-965 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0, 3.0.1 Reporter: Igor Galić Fix For: 3.1.3 If both of these options are specified (with the same time?), nothing is cached 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] [Updated] (TS-877) Segfault caused by HTTPInfo::object_key_get
[
https://issues.apache.org/jira/browse/TS-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-877:
-
Fix Version/s: (was: 3.1.2)
3.1.3
Segfault caused by HTTPInfo::object_key_get
Key: TS-877
URL: https://issues.apache.org/jira/browse/TS-877
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.0.0
Environment: Ubuntu 10.04tls 64bit
Reporter: Kingsley Foreman
Labels: crash
Fix For: 3.1.3
Segfault caused by HTTPInfo::object_key_get
Reading symbols from /usr/lib/libtsutil.so.3...done.
Loaded symbols for /usr/lib/libtsutil.so.3
Reading symbols from /lib/libpthread.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libresolv.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libpcre.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libpcre.so.3
Reading symbols from /lib/libssl.so.0.9.8...(no debugging symbols
found)...done.
Loaded symbols for /lib/libssl.so.0.9.8
Reading symbols from /lib/libcrypto.so.0.9.8...(no debugging symbols
found)...done.
Loaded symbols for /lib/libcrypto.so.0.9.8
Reading symbols from /usr/lib/libtcl8.4.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libtcl8.4.so.0
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libexpat.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libexpat.so.1
Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnss_dns.so.2
Reading symbols from /usr/libexec/trafficserver/header_filter.so...done.
Loaded symbols for /usr/libexec/trafficserver/header_filter.so
Core was generated by `/usr/bin/traffic_server -M -A,9:X'.
Program terminated with signal 11, Segmentation fault.
#0 0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at
../../proxy/hdrs/HTTP.h:1375
1375 ((int32_t *) val)[0] = m_alt-m_object_key[0];
(gdb) bt
#0 0x005975ef in HTTPInfo::object_key_get (this=0x2ae710002c58) at
../../proxy/hdrs/HTTP.h:1375
#1 0x00592c72 in HttpTransactCache::SelectFromAlternates
(cache_vector=0x1c96568, client_request=0x1c96528,
http_config_params=0x2ae66c4b5228)
at HttpTransactCache.cc:213
#2 0x006cb4f1 in CacheVC::openReadChooseWriter (this=0x1c96460,
event=2, e=0x1e6d6d0) at CacheRead.cc:262
#3 0x006cbc82 in CacheVC::openReadFromWriter (this=0x1c96460,
event=2, e=0x1e6d6d0) at CacheRead.cc:332
#4 0x004e63e8 in Continuation::handleEvent (this=0x1c96460, event=2,
data=0x1e6d6d0) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x0072055d in EThread::process_event (this=0x2ae646b46010,
e=0x1e6d6d0, calling_code=2) at UnixEThread.cc:140
#6 0x0072090d in EThread::execute (this=0x2ae646b46010) at
UnixEThread.cc:217
#7 0x0071ec32 in spawn_thread_internal (a=0x1a14380) at Thread.cc:88
#8 0x2ae643f639ca in start_thread () from /lib/libpthread.so.0
#9 0x2ae64616970d in clone () from /lib/libc.so.6
#10 0x in ?? ()
(gdb) print *this
$1 = {m_alt = 0x0}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-986) ts/experimental has a dependency on netinet/net.h (for struct in_addr)
[ https://issues.apache.org/jira/browse/TS-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-986: - Fix Version/s: (was: 3.1.2) 3.1.3 ts/experimental has a dependency on netinet/net.h (for struct in_addr) -- Key: TS-986 URL: https://issues.apache.org/jira/browse/TS-986 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Fix For: 3.1.3 Alan seems to indicate this is wrong anyways, but just adding this bug so we remember it's probably a bad idea. The offending API is tsapi int TSNodeHandleToIPAddr(TSNodeHandle_t *h, struct in_addr *in); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-966) cache.config dest_domain= dest_hostname= dest_ip= do not match anything
[ https://issues.apache.org/jira/browse/TS-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-966: - Fix Version/s: (was: 3.1.2) 3.1.3 cache.config dest_domain= dest_hostname= dest_ip= do not match anything --- Key: TS-966 URL: https://issues.apache.org/jira/browse/TS-966 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.1.0, 3.0.1 Reporter: Igor Galić Fix For: 3.1.3 Caching policies are not applied when using these options to match targets. It is also not very clear *what* dest_domain= vs dest_hostname= can 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] [Commented] (TS-937) EThread::execute still processing cancelled event
[
https://issues.apache.org/jira/browse/TS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163156#comment-13163156
]
John Plevyak commented on TS-937:
-
This patch shouldn't have any effect in correct code. Checking -canceled
outside of the mutex is at best an optimization. In any case, before the
continuation is used the canceled field has to be checked under the lock. Most
likely the core problem is that someone is canceling the event without holding
the lock (a situation which subsumes the case of being in a callback as weijin
suggested). If this happens, there is a potential race where process_event is
in progress, someone cancels the event (without the lock) and deletes the
Continuation resulting in a crash.
However, this patch does reduce the change of a race condition in the debug
build. The core problem is that the macro MUTEX_LOCK_FOR is accessing
HANDLER_NAME
which dereferences the continuation. This is bad. The macro needs to be fixed
to delay deferencing the Continuation until the lock is taken.
EThread::execute still processing cancelled event
-
Key: TS-937
URL: https://issues.apache.org/jira/browse/TS-937
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.1, 2.1.9
Environment: RHEL6
Reporter: Brian Geffon
Fix For: 3.1.2
Attachments: UnixEThread.patch
The included GDB log will show that ATS is trying to process an event that
has already been canceled, examining the code of UnixEThread.cc line 232
shows that EThread::process_event gets called without a check for the event
being cancelled.
Brian
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x764fa700 (LWP 28518)]
0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64
keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.1.x86_64
libcom_err-1.41.12-7.el6.x86_64 libgcc-4.4.5-6.el6.x86_64
libselinux-2.0.94-5.el6.x86_64 libstdc++-4.4.5-6.el6.x86_64
openssl-1.0.0-10.el6_1.4.x86_64 pcre-7.8-3.1.el6.x86_64
tcl-8.5.7-6.el6.x86_64 zlib-1.2.3-25.el6.x86_64
(gdb) bt
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
(gdb) bt full
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
lock = {m = {m_ptr = 0x764f9d20}, lock_acquired = 202}
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
done_one = false
e = 0x1db45c0
NegativeQueue = {DLLEvent, Event::Link_link = {head = 0xfc75f0},
tail = 0xfc75f0}
next_time = 1314647904419648000
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
p = 0xfb7e80
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb) f 0
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
(gdb) p *e
$2 = {Action = {_vptr.Action = 0x775170, continuation = 0x1f2fc08, mutex =
{m_ptr = 0x7fffd40fba40}, cancelled = 1}, ethread = 0x768ff010,
in_the_prot_queue = 0, in_the_priority_queue = 0,
immediate = 1, globally_allocated = 1, in_heap = 0, callback_event = 1,
timeout_at = 0, period = 0, cookie = 0x0, link = {SLinkEvent = {next =
0x0}, prev = 0x0}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-937) EThread::execute still processing cancelled event
[
https://issues.apache.org/jira/browse/TS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163157#comment-13163157
]
John Plevyak commented on TS-937:
-
On a side note, this macro should not do the deref on non-debug builds but
for some reason it looks like the case is TS_HAS_PURIFY what the heck is
that all about?
EThread::execute still processing cancelled event
-
Key: TS-937
URL: https://issues.apache.org/jira/browse/TS-937
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.1, 2.1.9
Environment: RHEL6
Reporter: Brian Geffon
Fix For: 3.1.2
Attachments: UnixEThread.patch
The included GDB log will show that ATS is trying to process an event that
has already been canceled, examining the code of UnixEThread.cc line 232
shows that EThread::process_event gets called without a check for the event
being cancelled.
Brian
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x764fa700 (LWP 28518)]
0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64
keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.1.x86_64
libcom_err-1.41.12-7.el6.x86_64 libgcc-4.4.5-6.el6.x86_64
libselinux-2.0.94-5.el6.x86_64 libstdc++-4.4.5-6.el6.x86_64
openssl-1.0.0-10.el6_1.4.x86_64 pcre-7.8-3.1.el6.x86_64
tcl-8.5.7-6.el6.x86_64 zlib-1.2.3-25.el6.x86_64
(gdb) bt
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
(gdb) bt full
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
lock = {m = {m_ptr = 0x764f9d20}, lock_acquired = 202}
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
done_one = false
e = 0x1db45c0
NegativeQueue = {DLLEvent, Event::Link_link = {head = 0xfc75f0},
tail = 0xfc75f0}
next_time = 1314647904419648000
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
p = 0xfb7e80
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb) f 0
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
(gdb) p *e
$2 = {Action = {_vptr.Action = 0x775170, continuation = 0x1f2fc08, mutex =
{m_ptr = 0x7fffd40fba40}, cancelled = 1}, ethread = 0x768ff010,
in_the_prot_queue = 0, in_the_priority_queue = 0,
immediate = 1, globally_allocated = 1, in_heap = 0, callback_event = 1,
timeout_at = 0, period = 0, cookie = 0x0, link = {SLinkEvent = {next =
0x0}, prev = 0x0}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
