[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x

[Vladyslav Bachynskyi (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831241#comment-13831241
 ] 

Vladyslav Bachynskyi commented on TS-2384:
--

Sure!

> Regression in key-lookup code between 4.0.x and 4.1.x
> -
>
> Key: TS-2384
> URL: https://issues.apache.org/jira/browse/TS-2384
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Igor Galić
> Fix For: 4.2.0
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume  #1 - store='/dev/sda'
> first key   409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial388912
> header length   2480
> fragment type   1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume  #1 - store='/dev/sda'
> first key   409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length   2480 
> fragment type   1
> No of Alternates1
> {noformat}
> When run 4.1.1 all previously cached objects under 4.0.1 are MISS, these 
> objects  downloading from parent, and then they HIT again.
> *Note* This does not cause the cache to be reinitialized.
> It's just that the generated cache-lookup *key* is wrong in 4.1.x. This means 
> that the existing objects on the disks will stay in place, but we won't be 
> able to find them, because we are looking in the wrong place. As such we 
> simply store the object again.
> That's *almost* the same for people running with a 60 TiB cache, because 
> everything requested is also stored again,
> and after a while the old objects that have been lying around for a while 
> will be rotated out so that's bad. People with
> tiny caches or very high turn overs might even notice the downward spike in 
> 304s.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2329) Document header_rewrite's ability to set overridable configurations

[JIRA]

[ 
https://issues.apache.org/jira/browse/TS-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831235#comment-13831235
 ] 

Igor Galić commented on TS-2329:


What we can do now is,
{code}
% git mv plugins/header_rewrite/README 
doc/reference/plugins/header_rewrite.en.rst
{code}

> Document header_rewrite's ability to set overridable configurations 
> 
>
> Key: TS-2329
> URL: https://issues.apache.org/jira/browse/TS-2329
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation, Plugins
>Affects Versions: 4.2.0
>Reporter: Igor Galić
>Assignee: Leif Hedstrom
> Fix For: Docs
>
>
> This plugin contains a README, but we should probably drop that in favour of 
> the reference documentation for the plugin.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x

[JIRA]

[ 
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831231#comment-13831231
 ] 

Igor Galić commented on TS-2384:


[~vlad.bach], do you think you could test the 4.1.x branch for us before we 
attempt another release?

> Regression in key-lookup code between 4.0.x and 4.1.x
> -
>
> Key: TS-2384
> URL: https://issues.apache.org/jira/browse/TS-2384
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Igor Galić
> Fix For: 4.2.0
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume  #1 - store='/dev/sda'
> first key   409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial388912
> header length   2480
> fragment type   1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume  #1 - store='/dev/sda'
> first key   409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length   2480 
> fragment type   1
> No of Alternates1
> {noformat}
> When run 4.1.1 all previously cached objects under 4.0.1 are MISS, these 
> objects  downloading from parent, and then they HIT again.
> *Note* This does not cause the cache to be reinitialized.
> It's just that the generated cache-lookup *key* is wrong in 4.1.x. This means 
> that the existing objects on the disks will stay in place, but we won't be 
> able to find them, because we are looking in the wrong place. As such we 
> simply store the object again.
> That's *almost* the same for people running with a 60 TiB cache, because 
> everything requested is also stored again,
> and after a while the old objects that have been lying around for a while 
> will be rotated out so that's bad. People with
> tiny caches or very high turn overs might even notice the downward spike in 
> 304s.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2372) Add forward security support (SSL related)

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831159#comment-13831159
 ] 

James Peach commented on TS-2372:
-

OK, looks like there's 2 things we need to do here:

1. Set support for setting Diffie-Hellman parameters on the SSL context
2. Set up the ECDH support.

> Add forward security support (SSL related)
> --
>
> Key: TS-2372
> URL: https://issues.apache.org/jira/browse/TS-2372
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Bryan Call
>  Labels: ssl
> Fix For: 4.2.0
>
>
> mod_ssl bug and changes:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49559
> Discussion on httpd-dev list:
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2372) Add forward security support (SSL related)

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831158#comment-13831158
 ] 

James Peach commented on TS-2372:
-

http://en.wikibooks.org/wiki/OpenSSL/Diffie-Hellman_parameters

> Add forward security support (SSL related)
> --
>
> Key: TS-2372
> URL: https://issues.apache.org/jira/browse/TS-2372
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Bryan Call
>  Labels: ssl
> Fix For: 4.2.0
>
>
> mod_ssl bug and changes:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49559
> Discussion on httpd-dev list:
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (TS-980) change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable

[Zhao Yongming (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhao Yongming reassigned TS-980:


Assignee: weijin  (was: weijin)

> change client_session schedule from global  to thread local, and reduce the 
> try_locks in UnixNetVConnection::reenable
> -
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Network, Performance
>Affects Versions: 3.1.0, 3.0.0
> Environment: all
>Reporter: weijin
>Assignee: weijin
> Fix For: 5.0.0
>
> Attachments: ts-980.diff
>
>
> I did some performance test on ats last days(disable cache, set share_server 
> session 2, pure proxy mode), I did see significant improvement on low load, 
> but it dropped rapidly when load is high. meanwhile, some stability problems 
> happened. Through gdb, I found the client_session`s mutex can be acquired by 
> two or more threads, I believe some schedules happened during the sm 
> life_time. May be we need do some work to find these eventProcessor.schedules 
> and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
>   // put into ready_list
> } else {
>MUTEX_TRY_LOCK(lock, nh->mutex, t);
>if (!lock) {
>  // put into enable_list;
>} else {
>  // put into ready_list;
>}
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation. 
> frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule 
> by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more 
> net io latency if it is an epoll event need to be processed in other threads. 
> If it is not an epoll event(time event), I don`t think putting vc in 
> ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
>   // put into ready_list;
> } else {
>   // put into enable_list;
> }
> my buddies, any advice?



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (TS-899) ts crash

[Zhao Yongming (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhao Yongming reassigned TS-899:


Assignee: weijin  (was: weijin)

> ts crash
> 
>
> Key: TS-899
> URL: https://issues.apache.org/jira/browse/TS-899
> Project: Traffic Server
>  Issue Type: Sub-task
>  Components: HTTP, MIME
>Affects Versions: 3.0.1
> Environment: readhat5.5, ts-3.0.1, X86-64
>Reporter: weijin
>Assignee: weijin
> Fix For: 5.0.0
>
>
> If a request url is forbidden then redirected to another url, TS crash.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (TS-2034) make test fails with Linux AIO enabled

[Zhao Yongming (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhao Yongming reassigned TS-2034:
-

Assignee: weijin

> make test fails with Linux AIO enabled
> --
>
> Key: TS-2034
> URL: https://issues.apache.org/jira/browse/TS-2034
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: weijin
> Fix For: 5.0.0
>
>
> With
> {code}
> test_AIO-test_AIO.o: In function `main':
> /home/leif/apache/trafficserver.git/BUILDS/debug/iocore/aio/../../../../iocore/aio/test_AIO.cc:494:
>  undefined reference to `cache_config_threads_per_disk'
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2249) make check failed on test_AIO.cc:494: undefined reference to `cache_config_threads_per_disk'

[Zhao Yongming (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831153#comment-13831153
 ] 

Zhao Yongming commented on TS-2249:
---

it fail even you comment out that variable

> make check failed on test_AIO.cc:494: undefined reference to 
> `cache_config_threads_per_disk'
> 
>
> Key: TS-2249
> URL: https://issues.apache.org/jira/browse/TS-2249
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Yunkai Zhang
> Fix For: 4.2.0
>
>
> Compiles ATS master branch with:
> {code}
> [qiushu.zyk@dev163005 trafficserver]$ pwd
> /home/qiushu.zyk/trafficserver
> [qiushu.zyk@dev163005 trafficserver]$ ./configure --enable-layout=Gentoo 
> --with-user=ats --with-group=ats --enable-experimental-plugins --enable-wccp 
> --disable-debug --enable-linux-native-aio --enable-reclaimable-freelist 
> --enable-interim-cache
> {code}
> *make check* failed on test_AIO.cc:494: undefined reference to 
> `cache_config_threads_per_disk':
> {code}
> [qiushu.zyk@dev163005 aio]$ pwd
> /home/qiushu.zyk/trafficserver/iocore/aio
> [qiushu.zyk@dev163005 aio]$ make check
> make  test_AIO
> make[1]: Entering directory `/home/qiushu.zyk/trafficserver/iocore/aio'
>   CXXtest_AIO-test_AIO.o
>   CXXLD  test_AIO
> test_AIO-test_AIO.o: In function `main':
> /home/qiushu.zyk/trafficserver/iocore/aio/test_AIO.cc:494: undefined 
> reference to `cache_config_threads_per_disk'
> collect2: ld returned 1 exit status
> make[1]: *** [test_AIO] Error 1
> make[1]: Leaving directory `/home/qiushu.zyk/trafficserver/iocore/aio'
> make: *** [check-am] Error 2
> {code}
> Use following patch can solve *undefined error*:
> {code}
> [qiushu.zyk@dev163005 aio]$ git diff
> diff --git a/iocore/aio/test_AIO.cc b/iocore/aio/test_AIO.cc
> index 817d8a2..22d06a4 100644
> --- a/iocore/aio/test_AIO.cc
> +++ b/iocore/aio/test_AIO.cc
> @@ -135,7 +135,7 @@ volatile int n_accessors = 0;
>  int orig_n_accessors;
>  AIO_Device *dev[MAX_DISK_THREADS];
>  
> -extern RecInt cache_config_threads_per_disk;
> +RecInt cache_config_threads_per_disk;
>  
>  int write_after = 0;
>  int write_skip = 0;
> {code}
> After applied above patch, *make check* will also fail:
> {code}
> [qiushu.zyk@dev163005 aio]$ make check
> make  test_AIO
> make[1]: Entering directory `/home/qiushu.zyk/trafficserver/iocore/aio'
>   CXXtest_AIO-test_AIO.o
>   CXXLD  test_AIO
> make[1]: Leaving directory `/home/qiushu.zyk/trafficserver/iocore/aio'
> make  check-TESTS
> make[1]: Entering directory `/home/qiushu.zyk/trafficserver/iocore/aio'
> reading disk_size = 1
> reading hotset_size = 1
> reading hotset_frequency = 0.5
> reading run_time = 30
> reading threads_per_disk = 1
> reading touch_data = 1
> reading seq_read_percent = 0.5
> reading seq_write_percent = 0.3
> reading rand_read_percent = 0.2
> reading seq_read_size = 131072
> reading seq_write_size = 4093
> reading rand_read_size = 4096
> reading write_skip = 5
> reading chains = 1
> reading delete_disks = 1
> reading disk_path = ./aio.tst
> Starting hotset document writing 
> /bin/sh: line 5: 20105 Segmentation fault  (core dumped) ${dir}$tst
> FAIL: test_AIO.sample
> =
> 1 of 1 test failed
> Please report to d...@trafficserver.apache.org
> =
> make[1]: *** [check-TESTS] Error 1
> make[1]: Leaving directory `/home/qiushu.zyk/trafficserver/iocore/aio'
> make: *** [check-am] Error 2
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2034) make test fails with Linux AIO enabled

[Zhao Yongming (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831152#comment-13831152
 ] 

Zhao Yongming commented on TS-2034:
---

{code}
zym@ubuntu:~/trafficserver/iocore/aio$ gdb  --args .libs/test_AIO sample.cfg
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/zym/trafficserver/iocore/aio/.libs/test_AIO...done.
(gdb) r
Starting program: /home/zym/trafficserver/iocore/aio/.libs/test_AIO sample.cfg
warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x77ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7573e700 (LWP 24878)]
[New Thread 0x7553c700 (LWP 24879)]
[New Thread 0x7533a700 (LWP 24880)]
reading disk_size = 1
reading hotset_size = 1
reading hotset_frequency = 0.5
reading run_time = 30
reading threads_per_disk = 1
reading touch_data = 1
reading seq_read_percent = 0.5
reading seq_write_percent = 0.3
reading rand_read_percent = 0.2
reading seq_read_size = 131072
reading seq_write_size = 4093
reading rand_read_size = 4096
reading write_skip = 5
reading chains = 1
reading delete_disks = 1
reading disk_path = ./aio.tst
Starting hotset document writing

Program received signal SIGSEGV, Segmentation fault.
ink_aio_write (op=0x6682d0) at AIO.cc:616
616   this_ethread()->diskHandler->ready_list.enqueue(op);
(gdb) bt
#0  ink_aio_write (op=0x6682d0) at AIO.cc:616
#1  0x00405a8d in AIO_Device::do_hotset (this=0x670240) at 
test_AIO.cc:319
#2  0x004189a1 in handleEvent (data=0x77e6eea0, event=1, 
this=) at I_Continuation.h:146
#3  EThread::process_event (this=0x77e74010, e=0x77e6eea0, 
calling_code=1) at UnixEThread.cc:145
#4  0x00419403 in EThread::execute (this=0x77e74010) at 
UnixEThread.cc:196
#5  0x00404e65 in main (argv=) at test_AIO.cc:520
(gdb)
{code}

> make test fails with Linux AIO enabled
> --
>
> Key: TS-2034
> URL: https://issues.apache.org/jira/browse/TS-2034
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
> Fix For: 5.0.0
>
>
> With
> {code}
> test_AIO-test_AIO.o: In function `main':
> /home/leif/apache/trafficserver.git/BUILDS/debug/iocore/aio/../../../../iocore/aio/test_AIO.cc:494:
>  undefined reference to `cache_config_threads_per_disk'
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2376) some makefiles don't get LDFLAGS right

[Daniel Vitor Morilha (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831132#comment-13831132
 ] 

Daniel Vitor Morilha commented on TS-2376:
--

by using -Wl,-rpath it works, I guess I didn't try it... sorry about that

> some makefiles don't get LDFLAGS right
> --
>
> Key: TS-2376
> URL: https://issues.apache.org/jira/browse/TS-2376
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Daniel Vitor Morilha
> Fix For: sometime
>
>
> I am trying to set a global LDFLAGS -rpath=...
> some of the libraries get it right, most of the binaries spit:
> c++: unrecognized option '-rpath=...'
> I believe it is lacking the -Wl in front, so the compiler can properly pass 
> the argument to the linker.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-302) -fstrict-aliasing optimizer generates bad code

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831116#comment-13831116
 ] 

ASF subversion and git services commented on TS-302:


Commit a90c877e8eb76d92f9ddfdf510a90c32a4ab6478 in branch refs/heads/4.1.x from 
[~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a90c877 ]

TS-2384: Regression in key-lookup code between 4.0.x and 4.1.x

Revert "TS-302: Fix HTTPCacheAlt to use INK_MD5 directly instead of arrays of 
uin32_t. Simplify methods because of this."

This reverts commit c40c601c9167c4937f972daf7825821e527a5f67.

This breaks cache keys on certain builds. It's not clear why, but we
should remove this from 4.1.x so that we can have a stable release.


> -fstrict-aliasing optimizer generates bad code
> --
>
> Key: TS-302
> URL: https://issues.apache.org/jira/browse/TS-302
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup
>Reporter: Miles Libbey
>Assignee: Phil Sorber
>Priority: Minor
> Fix For: 6.0.0
>
> Attachments: no-no-fstrict-alias.patch, ts-302.patch
>
>
> (moving from yahoo bug 525119)
> Original description
> by Leif Hedstrom 4 years ago at 2005-12-16 08:41
> Not sure if this is a compiler bug or a code issue on our side, but enabling 
> the
> -fstrict-aliasing optimization option generates faulty code. This optimization
> technique is enabled implicitly with -Os, -O2 and -O3, so for now I'm 
> explicitly
> turning it off with
>-O3 -fno-strict-aliasing
> This solves the problem where the traffic server would return data of 0 or 1
> length out of the cache. This initially looked like the cache corruption
> problem, but is completely different and unrelated. The cache corruption 
> problem
> has been fixed and closed.
> I'm opening this bug as a reminder, at some point we should isolate which code
> triggers the strict-aliasing problem, and confirm if it's a compiler bug or a
> problem in our code.
>   
>  
> Comment 1
>  by Michael Bigby 4 years ago at 2005-12-16 09:07:40
> I'm recommending that we get Ed's input on this.  He may some insight compiler
> issues...
>   
>  
> Comment 2
>  by Leif Hedstrom  4 years ago at 2005-12-16 10:02:07
> That'd be great!
> We haven't had a chance yet to review the code that might be affecting this,
> it's obviously something with unions and how the compiler handles
> storage/alignment on the members.
>   
>  
> Comment 3
>  by Ed Hall  4 years ago at 2006-03-03 11:46:52
> This is with gcc 2.95.3, correct?  There have been a number of complaints 
> around
> the 'net about problems with -fstrict-aliasing.  I've not really looked very
> deeply into it, though I should mention that certain C code was known at the
> time to malfunction when by-the-standard aliasing rules were enforced 
> (starting
> with the Linux kernel).
> In essense, the -fstrict-aliasing optimizations assume that any particular 
> part
> of memory accessed via a specific type of pointer won't be accessed as another
> type. There are a set of optimizations that are safe only when it can be
> guaranteed that a given bit of memory hasn't been manipulated via pointer; if
> the compiler assumes that the rather arcane C aliasing rules have been 
> followed
> ("aliasing" in this case meaning accessing a given bit of memory with more 
> than
> one type of pointer), there are more situations where such optimizations can 
> be
> applied.  Code which uses type casts where unions might be more appropriate is
> the most likely to break aliasing rules.
> In any case, gcc 3/4 is less aggressive (and perhaps less buggy) in applying 
> the
> C aliasing rules, and has added warnings for obvious violations.  It's never
> been clear to me if gcc 2.95.3 was actually broken or not, or if there simply
> was a lot of code out there that ran afoul of the standard.
>   
>  
> Comment 4
>  by Leif Hedstrom  4 years ago at 2006-03-03 12:50:22
> Actually, the problem only occured after we converted the code from gcc-2.9x 
> to
> gcc-3.4.4. We have since cleared out a *lot* of compiler warnings (thousands 
> and
> thousands), so maybe we should try again to compile without the
> -fno-strict-aliasing, and see if gcc will point us to some places where we do
> dangerous things. The code does some very scary things manipulating objects
> directly, by byte-offsets for instance.
> I think it's pretty easy to reproduce the problem, it basically renders the
> cache completely useless, returning objects of size 0 or 1.
>   
>  
> Comment 5
>  by Ed Hall 4 years ago at 2006-03-03 16:44:04
> Ah, that makes sense.  I just checked, and the -fstrict-aliasing option wasn't
> part of the -O2 optimizations on gcc 2.95, but go

[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831115#comment-13831115
 ] 

ASF subversion and git services commented on TS-2384:
-

Commit a90c877e8eb76d92f9ddfdf510a90c32a4ab6478 in branch refs/heads/4.1.x from 
[~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a90c877 ]

TS-2384: Regression in key-lookup code between 4.0.x and 4.1.x

Revert "TS-302: Fix HTTPCacheAlt to use INK_MD5 directly instead of arrays of 
uin32_t. Simplify methods because of this."

This reverts commit c40c601c9167c4937f972daf7825821e527a5f67.

This breaks cache keys on certain builds. It's not clear why, but we
should remove this from 4.1.x so that we can have a stable release.


> Regression in key-lookup code between 4.0.x and 4.1.x
> -
>
> Key: TS-2384
> URL: https://issues.apache.org/jira/browse/TS-2384
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Igor Galić
> Fix For: 4.2.0
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume  #1 - store='/dev/sda'
> first key   409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial388912
> header length   2480
> fragment type   1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume  #1 - store='/dev/sda'
> first key   409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length   2480 
> fragment type   1
> No of Alternates1
> {noformat}
> When run 4.1.1 all previously cached objects under 4.0.1 are MISS, these 
> objects  downloading from parent, and then they HIT again.
> *Note* This does not cause the cache to be reinitialized.
> It's just that the generated cache-lookup *key* is wrong in 4.1.x. This means 
> that the existing objects on the disks will stay in place, but we won't be 
> able to find them, because we are looking in the wrong place. As such we 
> simply store the object again.
> That's *almost* the same for people running with a 60 TiB cache, because 
> everything requested is also stored again,
> and after a while the old objects that have been lying around for a while 
> will be rotated out so that's bad. People with
> tiny caches or very high turn overs might even notice the downward spike in 
> 304s.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2358) DNS does not fail-over promptly for DNS server returning SERVFAIL

[William Bardwell (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831107#comment-13831107
 ] 

William Bardwell commented on TS-2358:
--

I am not working on this one for now.

> DNS does not fail-over promptly for DNS server returning SERVFAIL
> -
>
> Key: TS-2358
> URL: https://issues.apache.org/jira/browse/TS-2358
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 3.2.5
>Reporter: William Bardwell
> Attachments: ats.dns.txt
>
>
> If I have 2 dns servers listed in my resolv.conf and the first one is 
> returning SERVFAIL for something that I try to lookup, ATS takes a long time 
> to fail over, and won't do it for the first request to look something up.  
> Using normal system commands (host, ping etc.) with the same resolv.conf work 
> fine.
> I tried various config values with out much improvement.  I could make it 
> fail in 40sec instead of 60sec for the initial failure...
> debug logs will be attached, doing one DNS and then waiting a while and doing 
> another.  (Doing more before enough time has passed don't seem to help much.)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2325) remap.config .include should support directories

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2325:
--

Fix Version/s: 4.2.0

> remap.config .include should support directories
> 
>
> Key: TS-2325
> URL: https://issues.apache.org/jira/browse/TS-2325
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core
>Reporter: James Peach
> Fix For: 4.2.0
>
>
> The remap.config .include directive should support including a directory. The 
> implementation for this would be to simply read all the files in the 
> directory and include each one.
> I don't think the files in the directory should be sorted, since that 
> requires us to read all the names into memory, and there might be a very 
> large number of them. Typical ordering constraints can be expressed using 
> multiple directories.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (TS-2318) header_rewrite/header_filter plugin is not likey to parse properly.

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom resolved TS-2318.
---

Resolution: Duplicate

> header_rewrite/header_filter plugin is not likey to parse properly.
> ---
>
> Key: TS-2318
> URL: https://issues.apache.org/jira/browse/TS-2318
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: seri,Kim
>
> header_rewrite/header_filter plugin is not parsing properly.
> My header_rewrite config is
> cond %\{READ_RESPONSE_HDR_HOOK\}
> cond %\{HEADER:Vary\} =Accept-Encoding,User-Agent \[NC\]
> set-header Vary "Accept-Encoding"
> header_rewrite plugin is likely to parse
> not
> Vary: Accept-Encoding,User-Agent
> to
> Vary: Accept-Encoding
> My config is missing something?
> Please, help me.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2325) remap.config .include should support directories

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831102#comment-13831102
 ] 

Leif Hedstrom commented on TS-2325:
---

James, you taking this one ?

> remap.config .include should support directories
> 
>
> Key: TS-2325
> URL: https://issues.apache.org/jira/browse/TS-2325
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core
>Reporter: James Peach
> Fix For: 4.2.0
>
>
> The remap.config .include directive should support including a directory. The 
> implementation for this would be to simply read all the files in the 
> directory and include each one.
> I don't think the files in the directory should be sorted, since that 
> requires us to read all the names into memory, and there might be a very 
> large number of them. Typical ordering constraints can be expressed using 
> multiple directories.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2272) cache init is too slow

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831099#comment-13831099
 ] 

Leif Hedstrom commented on TS-2272:
---

Is this still relevant after TS-2138 ?

> cache init is too slow
> --
>
> Key: TS-2272
> URL: https://issues.apache.org/jira/browse/TS-2272
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Core
>Affects Versions: 4.1.0
>Reporter: Zhao Yongming
>Assignee: weijin
>Priority: Minor
>
> from the log, that each disk is wasting about 1-3s to get initialized, looks 
> that is working in serial way, may need more work to get all disk done in 1-3s
> {code}
> [Oct 15 18:16:52.352] Server {0x2b77c9a19700} WARNING: disk header different 
> for disk /dev/sdd: clearing the disk
> [Oct 15 18:16:52.359] Server {0x2b77c9413700} WARNING: disk header different 
> for disk /dev/sde: clearing the disk
> [Oct 15 18:16:52.364] Server {0x2b77c9a19700} WARNING: disk header different 
> for disk /dev/sdf: clearing the disk
> [Oct 15 18:16:52.369] Server {0x2b77c9413700} WARNING: disk header different 
> for disk /dev/sdg: clearing the disk
> [Oct 15 18:16:52.375] Server {0x2b77c9c1b700} WARNING: disk header different 
> for disk /dev/sdh: clearing the disk
> [Oct 15 18:16:52.382] Server {0x2b77c28c1e40} NOTE: traffic server running
> [Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdb
> [Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdc
> [Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdd
> [Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sde
> [Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdf
> [Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdg
> [Oct 15 18:16:52.469] Server {0x2b77c9918700} NOTE: Clearing Disk: /dev/sdh
> [Oct 15 18:16:52.474] Server {0x2b77c9918700} NOTE: clearing cache directory 
> '/dev/sdb 122880:73257708'
> [Oct 15 18:16:53.637] Server {0x2b77c9918700} NOTE: clearing cache directory 
> '/dev/sdc 122880:73257708'
> [Oct 15 18:16:54.797] Server {0x2b77c9918700} NOTE: clearing cache directory 
> '/dev/sdd 122880:73257708'
> [Oct 15 18:16:55.961] Server {0x2b77c9918700} NOTE: clearing cache directory 
> '/dev/sde 122880:73257708'
> [Oct 15 18:16:57.089] Server {0x2b77c9918700} NOTE: clearing cache directory 
> '/dev/sdf 122880:73257708'
> [Oct 15 18:16:58.216] Server {0x2b77c9918700} NOTE: clearing cache directory 
> '/dev/sdg 122880:73257708'
> [Oct 15 18:16:59.326] Server {0x2b77c9918700} NOTE: clearing cache directory 
> '/dev/sdh 122880:73257708'
> [Oct 15 18:17:05.417] Server {0x2b77c9f1e700} NOTE: cache enabled
> [Oct 15 18:17:16.811] {0x7f40b73847e0} STATUS: opened 
> /var/log/trafficserver/diags.log
> [Oct 15 18:17:16.811] {0x7f40b73847e0} NOTE: updated diags config
> [Oct 15 18:17:16.814] Server {0x7f40b73847e0} NOTE: cache clustering disabled
> [Oct 15 18:17:16.840] Server {0x7f40b73847e0} NOTE: CLEAR
> [Oct 15 18:17:16.840] Server {0x7f40b73847e0} NOTE: Clearing Configuration
> [Oct 15 18:17:16.840] Server {0x7f40b73847e0} NOTE: Clearing Host Database
> [Oct 15 18:17:16.858] Server {0x7f40b73847e0} NOTE: Clearing Cache
> [Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdb
> [Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdc
> [Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdd
> [Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sde
> [Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdf
> [Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdg
> [Oct 15 18:17:16.898] Server {0x7f40b40da700} NOTE: Clearing Disk: /dev/sdh
> [Oct 15 18:17:16.903] Server {0x7f40b40da700} NOTE: clearing cache directory 
> '/dev/sdb 122880:73257708'
> [Oct 15 18:17:18.162] Server {0x7f40b40da700} NOTE: clearing cache directory 
> '/dev/sdc 122880:73257708'
> [Oct 15 18:17:19.391] Server {0x7f40b40da700} NOTE: clearing cache directory 
> '/dev/sdd 122880:73257708'
> [Oct 15 18:17:20.608] Server {0x7f40b40da700} NOTE: clearing cache directory 
> '/dev/sde 122880:73257708'
> [Oct 15 18:17:21.837] Server {0x7f40b40da700} NOTE: clearing cache directory 
> '/dev/sdf 122880:73257708'
> [Oct 15 18:17:23.083] Server {0x7f40b40da700} NOTE: clearing cache directory 
> '/dev/sdg 122880:73257708'
> [Oct 15 18:17:24.387] Server {0x7f40b40da700} NOTE: clearing cache directory 
> '/dev/sdh 122880:73257708'
> [Oct 15 18:17:30.790] Server {0x7f40b3ad4700} NOTE: cache enabled
> [Oct 15 18:17:30.956] Server {0x7f40b41db700} NOTE: CLEAR, succeeded
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2318) header_rewrite/header_filter plugin is not likey to parse properly.

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831100#comment-13831100
 ] 

Leif Hedstrom commented on TS-2318:
---

I believe I fixed this in another bug, TS-2360. I'm closing this as a dupe of 
TS-2360, please reopen if this is still an issue.

> header_rewrite/header_filter plugin is not likey to parse properly.
> ---
>
> Key: TS-2318
> URL: https://issues.apache.org/jira/browse/TS-2318
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: seri,Kim
>
> header_rewrite/header_filter plugin is not parsing properly.
> My header_rewrite config is
> cond %\{READ_RESPONSE_HDR_HOOK\}
> cond %\{HEADER:Vary\} =Accept-Encoding,User-Agent \[NC\]
> set-header Vary "Accept-Encoding"
> header_rewrite plugin is likely to parse
> not
> Vary: Accept-Encoding,User-Agent
> to
> Vary: Accept-Encoding
> My config is missing something?
> Please, help me.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2334) --with-tcmalloc does not test whether the "found" library actually exists

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2334:
--

Fix Version/s: 5.0.0

> --with-tcmalloc does not test whether the "found" library actually exists
> -
>
> Key: TS-2334
> URL: https://issues.apache.org/jira/browse/TS-2334
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 4.1.0, 4.2.0
>Reporter: Igor Galić
> Fix For: 5.0.0
>
>
> Our {{TS_CHECK_TCMALLOC}} does not work.
> I found this when compiling --with-tcmalloc on Ubuntu, where the {{tcmalloc}} 
> library is called {{tcmalloc_minimal}}. (And its corresponding -dev package, 
> will, intuitively be named {{libgoogle-perftools-dev}}. )
> But none of this actually matters. I don't need to have any tcmalloc 
> libraries installed for this to fail horribly: {{-ltcmalloc}} will be added 
> to the build simply because I specified {{--with-tcmalloc}} this causes 
> pretty much everything in the configure run to break, or at least run with 
> defaults. (e.g.: glibc2 is not recognized to have a reentrant 
> {{gethostbyname()}}, see TS-2331)
> proposal: ACTUALLY check if {{tcmalloc}} can be found, abort {{configure}} if 
> it can't.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2138:
--

Fix Version/s: (was: sometime)
   4.1.1

> Using linux native-AIO, restarting ATS causes complete cache data loss
> --
>
> Key: TS-2138
> URL: https://issues.apache.org/jira/browse/TS-2138
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: bettydramit
>Assignee: weijin
> Fix For: 4.1.1
>
> Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
>
>
> ENV: centos 6 x86_64 gitmaster and 
> http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
> ./configure --enable-layout=Gentoo  --libdir=%{_libdir}/trafficserver 
> --enable-linux-native-aio --enable-reclaimable-freelist
>  
> when restart ats ,my all hit data will be lost.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2347) buffer_upload uses unsafe function tempnam()

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831097#comment-13831097
 ] 

Leif Hedstrom commented on TS-2347:
---

Kit: Great. Lets get this in for v4.2.0.

> buffer_upload uses unsafe function tempnam()
> 
>
> Key: TS-2347
> URL: https://issues.apache.org/jira/browse/TS-2347
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Igor Galić
>Assignee: Kit Chan
> Fix For: 4.2.0
>
>
> {code}
> make[3]: Entering directory 
> `/home/igalic/src/asf/trafficserver/bldir/plugins/experimental/buffer_upload'
>   CXX  buffer_upload.lo
>   CXXLDbuffer_upload.la
> .libs/buffer_upload.o: In function `attach_pvc_plugin(tsapi_cont*, TSEvent, 
> void*)':
> /home/igalic/src/asf/trafficserver/bldir/plugins/experimental/buffer_upload/../../../../plugins/experimental/buffer_upload/buffer_upload.cc:915:
>  warning: the use of `tempnam' is dangerous, better use `mkstemp'
> make[3]: Leaving directory 
> `/home/igalic/src/asf/trafficserver/bldir/plugins/experimental/buffer_upload'
> Making all in esi
> make[3]: Entering directory 
> `/home/igalic/src/asf/trafficserver/bldir/plugins/experimental/esi'
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831098#comment-13831098
 ] 

Leif Hedstrom commented on TS-2138:
---

Why is this bug still open ? It sounds like this would have gone into v4.1.1 ?

> Using linux native-AIO, restarting ATS causes complete cache data loss
> --
>
> Key: TS-2138
> URL: https://issues.apache.org/jira/browse/TS-2138
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: bettydramit
>Assignee: weijin
> Fix For: sometime
>
> Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
>
>
> ENV: centos 6 x86_64 gitmaster and 
> http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
> ./configure --enable-layout=Gentoo  --libdir=%{_libdir}/trafficserver 
> --enable-linux-native-aio --enable-reclaimable-freelist
>  
> when restart ats ,my all hit data will be lost.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2330) Update proxy.config.body_factory.enable_customizations comments in records.config

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2330:
--

Fix Version/s: 4.2.0

> Update proxy.config.body_factory.enable_customizations comments in 
> records.config
> -
>
> Key: TS-2330
> URL: https://issues.apache.org/jira/browse/TS-2330
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 4.1.0
>Reporter: David Carlin
>Assignee: Leif Hedstrom
> Fix For: 4.2.0
>
>
> The comments in records.config for 
> proxy.config.body_factory.enable_customizations don't reflect TS-2217 changes 
> - remove any mention of option 0.
> {noformat}
> ##
> #
> # Customizable User Response Pages
> #
> ##
># 0 - turn off customizable user response pages
># 1 - enable customizable user response pages in only the "default" 
> directory
># 2 - enable language-targeted user response pages
> CONFIG proxy.config.body_factory.enable_customizations INT 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2329) Document header_rewrite's ability to set overridable configurations

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831096#comment-13831096
 ] 

Leif Hedstrom commented on TS-2329:
---

Is anyone from LinkedIn working on these docs btw?

> Document header_rewrite's ability to set overridable configurations 
> 
>
> Key: TS-2329
> URL: https://issues.apache.org/jira/browse/TS-2329
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation, Plugins
>Affects Versions: 4.2.0
>Reporter: Igor Galić
>Assignee: Leif Hedstrom
> Fix For: Docs
>
>
> This plugin contains a README, but we should probably drop that in favour of 
> the reference documentation for the plugin.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (TS-2330) Update proxy.config.body_factory.enable_customizations comments in records.config

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom reassigned TS-2330:
-

Assignee: Leif Hedstrom

> Update proxy.config.body_factory.enable_customizations comments in 
> records.config
> -
>
> Key: TS-2330
> URL: https://issues.apache.org/jira/browse/TS-2330
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 4.1.0
>Reporter: David Carlin
>Assignee: Leif Hedstrom
> Fix For: 4.2.0
>
>
> The comments in records.config for 
> proxy.config.body_factory.enable_customizations don't reflect TS-2217 changes 
> - remove any mention of option 0.
> {noformat}
> ##
> #
> # Customizable User Response Pages
> #
> ##
># 0 - turn off customizable user response pages
># 1 - enable customizable user response pages in only the "default" 
> directory
># 2 - enable language-targeted user response pages
> CONFIG proxy.config.body_factory.enable_customizations INT 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2347) buffer_upload uses unsafe function tempnam()

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2347:
--

Fix Version/s: 4.2.0

> buffer_upload uses unsafe function tempnam()
> 
>
> Key: TS-2347
> URL: https://issues.apache.org/jira/browse/TS-2347
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Igor Galić
>Assignee: Kit Chan
> Fix For: 4.2.0
>
>
> {code}
> make[3]: Entering directory 
> `/home/igalic/src/asf/trafficserver/bldir/plugins/experimental/buffer_upload'
>   CXX  buffer_upload.lo
>   CXXLDbuffer_upload.la
> .libs/buffer_upload.o: In function `attach_pvc_plugin(tsapi_cont*, TSEvent, 
> void*)':
> /home/igalic/src/asf/trafficserver/bldir/plugins/experimental/buffer_upload/../../../../plugins/experimental/buffer_upload/buffer_upload.cc:915:
>  warning: the use of `tempnam' is dangerous, better use `mkstemp'
> make[3]: Leaving directory 
> `/home/igalic/src/asf/trafficserver/bldir/plugins/experimental/buffer_upload'
> Making all in esi
> make[3]: Entering directory 
> `/home/igalic/src/asf/trafficserver/bldir/plugins/experimental/esi'
> {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2329) Document header_rewrite's ability to set overridable configurations

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831095#comment-13831095
 ] 

Leif Hedstrom commented on TS-2329:
---

We need to document the entire plugin though, there's nothing in the docs right 
now :/.

> Document header_rewrite's ability to set overridable configurations 
> 
>
> Key: TS-2329
> URL: https://issues.apache.org/jira/browse/TS-2329
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation, Plugins
>Affects Versions: 4.2.0
>Reporter: Igor Galić
>Assignee: Leif Hedstrom
> Fix For: Docs
>
>
> This plugin contains a README, but we should probably drop that in favour of 
> the reference documentation for the plugin.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2329) Document header_rewrite's ability to set overridable configurations

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2329:
--

Fix Version/s: Docs

> Document header_rewrite's ability to set overridable configurations 
> 
>
> Key: TS-2329
> URL: https://issues.apache.org/jira/browse/TS-2329
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation, Plugins
>Affects Versions: 4.2.0
>Reporter: Igor Galić
>Assignee: Leif Hedstrom
> Fix For: Docs
>
>
> This plugin contains a README, but we should probably drop that in favour of 
> the reference documentation for the plugin.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (TS-2357) Add option to cache POST requests

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom reassigned TS-2357:
-

Assignee: Bryan Call

Giving to Bryan, since this is hopefully a quick merge of YTS to ATS :).

> Add option to cache POST requests
> -
>
> Key: TS-2357
> URL: https://issues.apache.org/jira/browse/TS-2357
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 4.2.0
>
>
> This feature was added to YTS after it was open sourced.  Yahoo bug number: 
> 2831983
> This is the configuration option and it might be nice to keep it the same 
> name for those that are migrating from YTS to ATS:
> CONFIG proxy.config.http.cache.cache_method_post INT 1



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831091#comment-13831091
 ] 

Leif Hedstrom commented on TS-2362:
---

Alan, is this going into v4.2 ? In either case, please target an appropriate 
Fix Version.

> Backwards cache compatibility for 4.X (read 3.2)
> 
>
> Key: TS-2362
> URL: https://issues.apache.org/jira/browse/TS-2362
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>
> Enable the 4.X series to be able to read 3.2 caches.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2358) DNS does not fail-over promptly for DNS server returning SERVFAIL

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831092#comment-13831092
 ] 

Leif Hedstrom commented on TS-2358:
---

William: Are you working / taking this bug? What version should we target it 
for?

> DNS does not fail-over promptly for DNS server returning SERVFAIL
> -
>
> Key: TS-2358
> URL: https://issues.apache.org/jira/browse/TS-2358
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 3.2.5
>Reporter: William Bardwell
> Attachments: ats.dns.txt
>
>
> If I have 2 dns servers listed in my resolv.conf and the first one is 
> returning SERVFAIL for something that I try to lookup, ATS takes a long time 
> to fail over, and won't do it for the first request to look something up.  
> Using normal system commands (host, ping etc.) with the same resolv.conf work 
> fine.
> I tried various config values with out much improvement.  I could make it 
> fail in 40sec instead of 60sec for the initial failure...
> debug logs will be attached, doing one DNS and then waiting a while and doing 
> another.  (Doing more before enough time has passed don't seem to help much.)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2357) Add option to cache POST requests

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2357:
--

Fix Version/s: 4.2.0

> Add option to cache POST requests
> -
>
> Key: TS-2357
> URL: https://issues.apache.org/jira/browse/TS-2357
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Bryan Call
> Fix For: 4.2.0
>
>
> This feature was added to YTS after it was open sourced.  Yahoo bug number: 
> 2831983
> This is the configuration option and it might be nice to keep it the same 
> name for those that are migrating from YTS to ATS:
> CONFIG proxy.config.http.cache.cache_method_post INT 1



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2392) Enable elliptic curve ciphers to support forward secrecy

[Jan-Frode Myklebust (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831089#comment-13831089
 ] 

Jan-Frode Myklebust commented on TS-2392:
-

Ooops, sorry, I tried searching for relevant tickets before filing this one, 
but missed TS-2372. So, yes, agree.. dupe.

> Enable elliptic curve ciphers to support forward secrecy
> 
>
> Key: TS-2392
> URL: https://issues.apache.org/jira/browse/TS-2392
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Jan-Frode Myklebust
>
> ATS does not seem to support the elliptic curve diffie hellman ephemeral key 
> exchanges (ECDH)  that are available in openssl. It seems these needs to be 
> enabled explicitly to take advantage of them. Ref: the following commit for 
> how this support was added to apache httpd v2.3.3:
> http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E
> and for stud:
> https://github.com/bumptech/stud/pull/61/files
> Maybe both a DH key exchange needs to be set up, and then the various 
> elliptic curves needs to be initialized..?
> Checking the openssl docs, I see SSL_CTX_set_tmp_dh_callback() needs to be 
> called to set up the ephemeral keys:
>   http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
> https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/
> http://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
> And these are the named curves available with openssl-1.0.1e-16.el6_5.x86_64 
> on RHEL-6.5:
> {noformat}
> $ openssl ecparam -list_curves
>   secp384r1 : NIST/SECG curve over a 384 bit prime field
>   prime256v1: X9.62/SECG curve over a 256 bit prime field
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2376) some makefiles don't get LDFLAGS right

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2376:
--

Fix Version/s: sometime

> some makefiles don't get LDFLAGS right
> --
>
> Key: TS-2376
> URL: https://issues.apache.org/jira/browse/TS-2376
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Daniel Vitor Morilha
> Fix For: sometime
>
>
> I am trying to set a global LDFLAGS -rpath=...
> some of the libraries get it right, most of the binaries spit:
> c++: unrecognized option '-rpath=...'
> I believe it is lacking the -Wl in front, so the compiler can properly pass 
> the argument to the linker.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2376) some makefiles don't get LDFLAGS right

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831090#comment-13831090
 ] 

Leif Hedstrom commented on TS-2376:
---

Guess I'm not sure I understand, why not give it -Wl,-rpath= ... ?

> some makefiles don't get LDFLAGS right
> --
>
> Key: TS-2376
> URL: https://issues.apache.org/jira/browse/TS-2376
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Daniel Vitor Morilha
> Fix For: sometime
>
>
> I am trying to set a global LDFLAGS -rpath=...
> some of the libraries get it right, most of the binaries spit:
> c++: unrecognized option '-rpath=...'
> I believe it is lacking the -Wl in front, so the compiler can properly pass 
> the argument to the linker.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2390) CLONE - only enable -Werror for debug builds

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2390:
--

Fix Version/s: 4.2.0

> CLONE - only enable -Werror for debug builds
> 
>
> Key: TS-2390
> URL: https://issues.apache.org/jira/browse/TS-2390
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.2.0
>
>
> It's very difficult to always build with -Werror on every platform we 
> support. -Werror is only valuable to developers, not so much for users. We 
> should consider only enabling -Werror if the build was configured with 
> --enable-debug. This probably involves adding autoconf macros to test whether 
> the compiler actually supports -Werror.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2386) clean up unused files and codes -- round 4.2

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2386:
--

Fix Version/s: 4.2.0

> clean up unused files and codes -- round 4.2
> 
>
> Key: TS-2386
> URL: https://issues.apache.org/jira/browse/TS-2386
> Project: Traffic Server
>  Issue Type: Task
>  Components: Cleanup
>Reporter: Zhao Yongming
> Fix For: 4.2.0
>
>
> nuke unused files and codes, as we want to



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (TS-2386) clean up unused files and codes -- round 4.2

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom reassigned TS-2386:
-

Assignee: Zhao Yongming

> clean up unused files and codes -- round 4.2
> 
>
> Key: TS-2386
> URL: https://issues.apache.org/jira/browse/TS-2386
> Project: Traffic Server
>  Issue Type: Task
>  Components: Cleanup
>Reporter: Zhao Yongming
>Assignee: Zhao Yongming
> Fix For: 4.2.0
>
>
> nuke unused files and codes, as we want to



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2386) clean up unused files and codes -- round 4.2

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831087#comment-13831087
 ] 

Leif Hedstrom commented on TS-2386:
---

zym: Can this be closed ?

> clean up unused files and codes -- round 4.2
> 
>
> Key: TS-2386
> URL: https://issues.apache.org/jira/browse/TS-2386
> Project: Traffic Server
>  Issue Type: Task
>  Components: Cleanup
>Reporter: Zhao Yongming
>Assignee: Zhao Yongming
> Fix For: 4.2.0
>
>
> nuke unused files and codes, as we want to



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2387) traffic_top should resize to the terminal window size

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2387:
--

Fix Version/s: 4.2.0

> traffic_top should resize to the terminal window size
> -
>
> Key: TS-2387
> URL: https://issues.apache.org/jira/browse/TS-2387
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Console, Management
>Reporter: James Peach
>Assignee: Bryan Call
> Fix For: 4.2.0
>
>
> traffic_top is hard-coded to draw a 80x24 window. It would be much better if 
> it queried the window size and drew itself with the actual window dimensions. 
> Bonus points for resizing when the terminal window size changes.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2392) Enable elliptic curve ciphers to support forward secrecy

[Jan-Frode Myklebust (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan-Frode Myklebust updated TS-2392:


Description: 
ATS does not seem to support the elliptic curve diffie hellman ephemeral key 
exchanges (ECDH)  that are available in openssl. It seems these needs to be 
enabled explicitly to take advantage of them. Ref: the following commit for how 
this support was added to apache httpd v2.3.3:

http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E

and for stud:

https://github.com/bumptech/stud/pull/61/files

Maybe both a DH key exchange needs to be set up, and then the various elliptic 
curves needs to be initialized..?

Checking the openssl docs, I see SSL_CTX_set_tmp_dh_callback() needs to be 
called to set up the ephemeral keys:

  http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html


https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/

http://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman

And these are the named curves available with openssl-1.0.1e-16.el6_5.x86_64 on 
RHEL-6.5:

{noformat}
$ openssl ecparam -list_curves
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

{noformat}


  was:
ATS does not seem to support the elliptic curve diffie hellman ephemeral key 
exchanges (ECDH)  that are available in openssl. It seems these needs to be 
enabled explicitly to take advantage of them. Ref: the following commit for how 
this support was added to apache httpd v2.3.3:

http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E

and for stud:

https://github.com/bumptech/stud/pull/61/files

Maybe both a DH key exchange needs to be set up, and then the various elliptic 
curves needs to be initialized..?

Checking the openssl docs, I see SSL_CTX_set_tmp_dh_callback() needs to be 
called to set up the ephemeral keys:

  http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html


https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/




> Enable elliptic curve ciphers to support forward secrecy
> 
>
> Key: TS-2392
> URL: https://issues.apache.org/jira/browse/TS-2392
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Jan-Frode Myklebust
>
> ATS does not seem to support the elliptic curve diffie hellman ephemeral key 
> exchanges (ECDH)  that are available in openssl. It seems these needs to be 
> enabled explicitly to take advantage of them. Ref: the following commit for 
> how this support was added to apache httpd v2.3.3:
> http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E
> and for stud:
> https://github.com/bumptech/stud/pull/61/files
> Maybe both a DH key exchange needs to be set up, and then the various 
> elliptic curves needs to be initialized..?
> Checking the openssl docs, I see SSL_CTX_set_tmp_dh_callback() needs to be 
> called to set up the ephemeral keys:
>   http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
> https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/
> http://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
> And these are the named curves available with openssl-1.0.1e-16.el6_5.x86_64 
> on RHEL-6.5:
> {noformat}
> $ openssl ecparam -list_curves
>   secp384r1 : NIST/SECG curve over a 384 bit prime field
>   prime256v1: X9.62/SECG curve over a 256 bit prime field
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2389) proxy.config.http.uncacheable_requests_bypass_parent is undocumented

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2389:
--

Fix Version/s: Docs

>  proxy.config.http.uncacheable_requests_bypass_parent is undocumented
> -
>
> Key: TS-2389
> URL: https://issues.apache.org/jira/browse/TS-2389
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Igor Galić
> Fix For: Docs
>
>
> reported to dev@: 
> https://mail-archives.apache.org/mod_mbox/trafficserver-dev/201311.mbox/%3C350802F99B0A6D4F9CC1F05A2279621B21D8A68D%40HQMAIL.ictv.com%3E
> Not sure how this got lost, but according to our old documentation, this 
> boolean
> {quote}
> When enabled (1), Traffic Server bypasses the parent proxy for a request that 
> is not cacheable.
> {quote}
> more important might be the question of how this relates to OP's issue re:
> {quote}
> This single setting was what our issue was where our trafficserver instance 
> was not properly referring https requests to the outbound proxy server.
> {quote}
> Digging in the source may be required.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2392) Enable elliptic curve ciphers to support forward secrecy

[Jan-Frode Myklebust (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan-Frode Myklebust updated TS-2392:


Description: 
ATS does not seem to support the elliptic curve diffie hellman ephemeral key 
exchanges (ECDH)  that are available in openssl. It seems these needs to be 
enabled explicitly to take advantage of them. Ref: the following commit for how 
this support was added to apache httpd v2.3.3:

http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E

and for stud:

https://github.com/bumptech/stud/pull/61/files

Maybe both a DH key exchange needs to be set up, and then the various elliptic 
curves needs to be initialized..?

Checking the openssl docs, I see SSL_CTX_set_tmp_dh_callback() needs to be 
called to set up the ephemeral keys:

  http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html


https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/



  was:
ATS does not seem to support the elliptic curve diffie hellman ephemeral key 
exchanges (ECDH)  that are available in openssl. It seems these needs to be 
enabled explicitly to take advantage of them. Ref: the following commit for how 
this support was added to apache httpd v2.3.3:

http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E

and for stud:

https://github.com/bumptech/stud/pull/61/files

Maybe both a DH key exchange needs to be set up, and then the various elliptic 
curves needs to be initialized..?



> Enable elliptic curve ciphers to support forward secrecy
> 
>
> Key: TS-2392
> URL: https://issues.apache.org/jira/browse/TS-2392
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Jan-Frode Myklebust
>
> ATS does not seem to support the elliptic curve diffie hellman ephemeral key 
> exchanges (ECDH)  that are available in openssl. It seems these needs to be 
> enabled explicitly to take advantage of them. Ref: the following commit for 
> how this support was added to apache httpd v2.3.3:
> http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E
> and for stud:
> https://github.com/bumptech/stud/pull/61/files
> Maybe both a DH key exchange needs to be set up, and then the various 
> elliptic curves needs to be initialized..?
> Checking the openssl docs, I see SSL_CTX_set_tmp_dh_callback() needs to be 
> called to set up the ephemeral keys:
>   http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
> https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (TS-2392) Enable elliptic curve ciphers to support forward secrecy

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom resolved TS-2392.
---

Resolution: Duplicate

I think this is a dupe of TS-2372, if it's not, please reopen this bug.

> Enable elliptic curve ciphers to support forward secrecy
> 
>
> Key: TS-2392
> URL: https://issues.apache.org/jira/browse/TS-2392
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Jan-Frode Myklebust
>
> ATS does not seem to support the elliptic curve diffie hellman ephemeral key 
> exchanges (ECDH)  that are available in openssl. It seems these needs to be 
> enabled explicitly to take advantage of them. Ref: the following commit for 
> how this support was added to apache httpd v2.3.3:
> http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E
> and for stud:
> https://github.com/bumptech/stud/pull/61/files
> Maybe both a DH key exchange needs to be set up, and then the various 
> elliptic curves needs to be initialized..?
> Checking the openssl docs, I see SSL_CTX_set_tmp_dh_callback() needs to be 
> called to set up the ephemeral keys:
>   http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
> https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2392) Enable elliptic curve ciphers to support forward secrecy

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2392:
--

Component/s: (was: Core)
 SSL

> Enable elliptic curve ciphers to support forward secrecy
> 
>
> Key: TS-2392
> URL: https://issues.apache.org/jira/browse/TS-2392
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Jan-Frode Myklebust
>
> ATS does not seem to support the elliptic curve diffie hellman ephemeral key 
> exchanges (ECDH)  that are available in openssl. It seems these needs to be 
> enabled explicitly to take advantage of them. Ref: the following commit for 
> how this support was added to apache httpd v2.3.3:
> http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E
> and for stud:
> https://github.com/bumptech/stud/pull/61/files
> Maybe both a DH key exchange needs to be set up, and then the various 
> elliptic curves needs to be initialized..?
> Checking the openssl docs, I see SSL_CTX_set_tmp_dh_callback() needs to be 
> called to set up the ephemeral keys:
>   http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
> https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (TS-2391) Traffic Server tries to reverse resolve 127.0.0.1

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-2391:
--

Fix Version/s: 4.2.0

> Traffic Server tries to reverse resolve 127.0.0.1
> -
>
> Key: TS-2391
> URL: https://issues.apache.org/jira/browse/TS-2391
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: David Carlin
> Fix For: 4.2.0
>
>
> We have a number of remaps using 127.0.0.1 for serving healthchecks.  Bryan 
> Call noticed ATS seems to try and resolve 1.0.0.127.in-addr.arpa for every 
> one of the requests (there are a lot, sometimes hundreds per second).
> Occasionally this process hangs; If I grep squid.blog for 127.0.0.1 I'll see 
> the healthcheck log entries flowing and then all of a sudden it'll stop 
> anywhere from 15-80 seconds.  Then the backlog of healthchecks is cleared out 
> at once.  5-20 minutes later this process will recur. 
> From traffic.out with debug dns.*|hostdb.*  - this occurs continuously.   
> Lookup for 1.0.0.127.in-addr.arpa fails (NXDOMAIN) and it doesn't get added 
> to HostDB.
> Unsure if related, but TS-852 seemed similar.
> {noformat}
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received query  
> type = 12, timeout = 0
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) enqueing query 
> 1.0.0.127.in-addr.arpa
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) adding first to 
> collapsing queue
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query 
> (qtype=12) for 1.0.0.127.in-addr.arpa to fd 236
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = 
> 1.0.0.127.in-addr.arpa, id = 56887, nameserver = 0
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent_one: 
> failover_number for resolver 0 is 1
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received packet 
> size = 109
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS 
> response code = 0
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 3
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 3 for 
> [1.0.0.127.in-addr.arpa]
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query 
> (qtype=12) for  to fd 236
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = , id 
> = 4497, nameserver = 0
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) sent_one: 
> failover_number for resolver 0 is 1
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received packet 
> size = 92
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS 
> response code = 0
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 0
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 0 for []
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) FAIL result for  = 
>  retry 0
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) called back 
> continuation for
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
> aa30de0f80a82135 1 [ignore_timeout = 1]
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) failed for 
> 127.0.0.1
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) inserting for: 
> : (md5: aa30de0f80a82135) bucket: 1017 now: 1385325494 timeout: 0 ttl: 0
> [Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe 127.0.0.1 
> 9993e35a45b4be6a 1 [ignore_timeout = 0]
> [Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) immediate 
> answer for 127.0.0.1
> [Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe  
> aa30de0f80a82135 1 [ignore_timeout = 0]
> [Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) '' failed
> [Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) fail timeout 0
> [Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) delaying force 
> 0 answer for 127.0.0.1
> [Nov 24 20:40:46.707] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
> aa30de0f80a82135 1 [ignore_timeout = 0]
> [Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
> [Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
> [Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) DNS IP 127.0.0.1
> {noformat}
> YTS doesn't have this issue:
> {noformat}
> bash-3.2# traffic_server -k
> [Nov 24 20:18:11.941] {4146358528} STATUS: opened /home/y/logs/yts/diags.log
> [Nov 24 20:18:11.959] Server {4146358528} DEBUG: (dns) ink_dns_init: called 
> with init_called = 0
> [Nov 24 20:18:11.992] Server {4146358528} DEBUG: (dns) initial 
> 

[jira] [Commented] (TS-2391) Traffic Server tries to reverse resolve 127.0.0.1

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831085#comment-13831085
 ] 

Leif Hedstrom commented on TS-2391:
---

So, it seems this is some sort of regression, since YTS does not experience 
this problem. I'd be curious as to why it wants to resolve "127.0.0.1" at all, 
certainly not with a PTR lookup? Is it by chance related to some ACLs or some 
such? 

I remember a while back (at Yahoo) we added the option 
proxy.config.http.doc_in_cache_skip_dns, enabled by default, which prevents a 
potentially expensive DNS lookup when the lookup is a cache hit. This reason 
for the option is/was that there could be reason why you wanted to do a lookup 
to guarantee access control mechanism to succeed before serving out of cache as 
well.

So, I'm wondering if maybe we've made changes to various ACL mechanism such 
that it tries to do a reverse lookup? Or some other reason for the PTR lookup? 
It feels if this is intentional, we need to add another option like 
proxy.config.http.doc_in_cache_skip_dns, to allow turning off these PTR lookups.

Alan? You want to own this one?


> Traffic Server tries to reverse resolve 127.0.0.1
> -
>
> Key: TS-2391
> URL: https://issues.apache.org/jira/browse/TS-2391
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: David Carlin
> Fix For: 4.2.0
>
>
> We have a number of remaps using 127.0.0.1 for serving healthchecks.  Bryan 
> Call noticed ATS seems to try and resolve 1.0.0.127.in-addr.arpa for every 
> one of the requests (there are a lot, sometimes hundreds per second).
> Occasionally this process hangs; If I grep squid.blog for 127.0.0.1 I'll see 
> the healthcheck log entries flowing and then all of a sudden it'll stop 
> anywhere from 15-80 seconds.  Then the backlog of healthchecks is cleared out 
> at once.  5-20 minutes later this process will recur. 
> From traffic.out with debug dns.*|hostdb.*  - this occurs continuously.   
> Lookup for 1.0.0.127.in-addr.arpa fails (NXDOMAIN) and it doesn't get added 
> to HostDB.
> Unsure if related, but TS-852 seemed similar.
> {noformat}
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received query  
> type = 12, timeout = 0
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) enqueing query 
> 1.0.0.127.in-addr.arpa
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) adding first to 
> collapsing queue
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query 
> (qtype=12) for 1.0.0.127.in-addr.arpa to fd 236
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = 
> 1.0.0.127.in-addr.arpa, id = 56887, nameserver = 0
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent_one: 
> failover_number for resolver 0 is 1
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received packet 
> size = 109
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS 
> response code = 0
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 3
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 3 for 
> [1.0.0.127.in-addr.arpa]
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query 
> (qtype=12) for  to fd 236
> [Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = , id 
> = 4497, nameserver = 0
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) sent_one: 
> failover_number for resolver 0 is 1
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received packet 
> size = 92
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS 
> response code = 0
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 0
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 0 for []
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) FAIL result for  = 
>  retry 0
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) called back 
> continuation for
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
> aa30de0f80a82135 1 [ignore_timeout = 1]
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) failed for 
> 127.0.0.1
> [Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) inserting for: 
> : (md5: aa30de0f80a82135) bucket: 1017 now: 1385325494 timeout: 0 ttl: 0
> [Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe 127.0.0.1 
> 9993e35a45b4be6a 1 [ignore_timeout = 0]
> [Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) immediate 
> answer for 127.0.0.1
> [Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (ho

[jira] [Created] (TS-2392) Enable elliptic curve ciphers to support forward secrecy

[Jan-Frode Myklebust (JIRA)]

Jan-Frode Myklebust created TS-2392:
---

 Summary: Enable elliptic curve ciphers to support forward secrecy
 Key: TS-2392
 URL: https://issues.apache.org/jira/browse/TS-2392
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Reporter: Jan-Frode Myklebust


ATS does not seem to support the elliptic curve diffie hellman ephemeral key 
exchanges (ECDH)  that are available in openssl. It seems these needs to be 
enabled explicitly to take advantage of them. Ref: the following commit for how 
this support was added to apache httpd v2.3.3:

http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E

and for stud:

https://github.com/bumptech/stud/pull/61/files

Maybe both a DH key exchange needs to be set up, and then the various elliptic 
curves needs to be initialized..?




--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (TS-2391) Traffic Server tries to reverse resolve 127.0.0.1

[David Carlin (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831051#comment-13831051
 ] 

David Carlin commented on TS-2391:
--

This is what I see during a 'hang'

{noformat}
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) enqueuing 
additional request
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) enqueuing 
additional request
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) enqueuing 
additional request
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) enqueuing 
additional request
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) enqueuing 
additional request
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (hostdb) enqueuing 
additional request
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (dns) received packet size 
= 109
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS response 
code = 0
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 3
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 3 for 
[1.0.0.127.in-addr.arpa]
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (dns) send query 
(qtype=12) for  to fd 236
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = , id = 
61114, nameserver = 0
[Nov 24 20:57:58.036] Server {0x2b759c8953a0} DEBUG: (dns) sent_one: 
failover_number for resolver 0 is 1
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (dns) received packet size 
= 92
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS response 
code = 0
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 0
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 0 for []
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (dns) FAIL result for  = 
 retry 0
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (dns) called back 
continuation for
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 1]
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) failed for 
127.0.0.1
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) inserting for: : 
(md5: aa30de0f80a82135) bucket: 1017 now: 1385326523 timeout: 0 ttl: 0
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) dequeuing 
additional request
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) dequeuing 
additional request
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) dequeuing 
additional request
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) dequeuing 
additional request
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) dequeuing 
additional request
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) dequeuing 
additional request
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) dequeuing 
additional request
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) dequeuing 
additional request
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) dequeuing 
additional request
[Nov 24 20:57:58.037] Server {0x2b759c8953a0} DEBUG: (hostdb) dequeuing 
additional request
[Nov 24 20:57:58.03

[jira] [Updated] (TS-2391) Traffic Server tries to reverse resolve 127.0.0.1

[David Carlin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Carlin updated TS-2391:
-

Description: 
We have a number of remaps using 127.0.0.1 for serving healthchecks.  Bryan 
Call noticed ATS seems to try and resolve 1.0.0.127.in-addr.arpa for every one 
of the requests (there are a lot, sometimes hundreds per second).

Occasionally this process hangs; If I grep squid.blog for 127.0.0.1 I'll see 
the healthcheck log entries flowing and then all of a sudden it'll stop 
anywhere from 15-80 seconds.  Then the backlog of healthchecks is cleared out 
at once.  5-20 minutes later this process will recur. 

>From traffic.out with debug dns.*|hostdb.*  - this occurs continuously.   
>Lookup for 1.0.0.127.in-addr.arpa fails (NXDOMAIN) and it doesn't get added to 
>HostDB.

Unsure if related, but TS-852 seemed similar.

{noformat}
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received query  type 
= 12, timeout = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) enqueing query 
1.0.0.127.in-addr.arpa
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) adding first to 
collapsing queue
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query 
(qtype=12) for 1.0.0.127.in-addr.arpa to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = 
1.0.0.127.in-addr.arpa, id = 56887, nameserver = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent_one: 
failover_number for resolver 0 is 1
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received packet size 
= 109
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS response 
code = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 3
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 3 for 
[1.0.0.127.in-addr.arpa]
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query 
(qtype=12) for  to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = , id = 
4497, nameserver = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) sent_one: 
failover_number for resolver 0 is 1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received packet size 
= 92
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS response 
code = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 0 for []
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) FAIL result for  = 
 retry 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) called back 
continuation for
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 1]
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) failed for 
127.0.0.1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) inserting for: : 
(md5: aa30de0f80a82135) bucket: 1017 now: 1385325494 timeout: 0 ttl: 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe 127.0.0.1 
9993e35a45b4be6a 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) immediate answer 
for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) delaying force 0 
answer for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) DNS IP 127.0.0.1
{noformat}

YTS doesn't have this issue:

{noformat}
bash-3.2# traffic_server -k

[Nov 24 20:18:11.941] {4146358528} STATUS: opened /home/y/logs/yts/diags.log
[Nov 24 20:18:11.959] Server {4146358528} DEBUG: (dns) ink_dns_init: called 
with init_called = 0
[Nov 24 20:18:11.992] Server {4146358528} DEBUG: (dns) initial 
dns_sequence_number = 10131
[Nov 24 20:18:11.993] Server {4146358528} DEBUG: (dns) localhost=
[Nov 24 20:18:11.993] Server {4146358528} DEBUG: (dns) Round-robin nameservers 
= 0
[Nov 24 20:18:12.554] Server {4146358528} DEBUG: (dns) DNSHandler::startEvent: 
on thread0
[Nov 24 20:18:12.554] Server {4146358528} DEBUG: (dns) open_con: opening 
connection :53
[Nov 24 20:18:12.554] Server {4146358528} DEBUG: (dns) random port = 28292
[Nov 24 20:18:12.554] Server {4146358528} DEBUG: (dns) opening connection :53 SUCCEEDED for 0

[jira] [Updated] (TS-2391) Traffic Server tries to reverse resolve 127.0.0.1

[David Carlin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Carlin updated TS-2391:
-

Description: 
We have a number of remaps using 127.0.0.1 for serving healthchecks.  Bryan 
Call noticed ATS seems to try and resolve 1.0.0.127.in-addr.arpa for every one 
of the requests (there are a lot, sometimes hundreds per second).

Occasionally this process hangs; If I grep squid.blog for 127.0.0.1 I'll see 
the healthcheck log entries flowing and then all of a sudden it'll stop 
anywhere from 15-80 seconds.  Then the backlog of healthchecks is cleared out 
at once.  5-10 minutes later this process will recur. 

>From traffic.out with debug dns.*|hostdb.*  - this occurs continuously.   
>Lookup for 1.0.0.127.in-addr.arpa fails (NXDOMAIN) and it doesn't get added to 
>HostDB.

Unsure if related, but TS-852 seemed similar.

{noformat}
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received query  type 
= 12, timeout = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) enqueing query 
1.0.0.127.in-addr.arpa
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) adding first to 
collapsing queue
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query 
(qtype=12) for 1.0.0.127.in-addr.arpa to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = 
1.0.0.127.in-addr.arpa, id = 56887, nameserver = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent_one: 
failover_number for resolver 0 is 1
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received packet size 
= 109
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS response 
code = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 3
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 3 for 
[1.0.0.127.in-addr.arpa]
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query 
(qtype=12) for  to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = , id = 
4497, nameserver = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) sent_one: 
failover_number for resolver 0 is 1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received packet size 
= 92
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS response 
code = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 0 for []
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) FAIL result for  = 
 retry 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) called back 
continuation for
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 1]
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) failed for 
127.0.0.1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) inserting for: : 
(md5: aa30de0f80a82135) bucket: 1017 now: 1385325494 timeout: 0 ttl: 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe 127.0.0.1 
9993e35a45b4be6a 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) immediate answer 
for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) delaying force 0 
answer for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) DNS IP 127.0.0.1
{noformat}

YTS doesn't have this issue:

{noformat}
bash-3.2# traffic_server -k

[Nov 24 20:18:11.941] {4146358528} STATUS: opened /home/y/logs/yts/diags.log
[Nov 24 20:18:11.959] Server {4146358528} DEBUG: (dns) ink_dns_init: called 
with init_called = 0
[Nov 24 20:18:11.992] Server {4146358528} DEBUG: (dns) initial 
dns_sequence_number = 10131
[Nov 24 20:18:11.993] Server {4146358528} DEBUG: (dns) localhost=
[Nov 24 20:18:11.993] Server {4146358528} DEBUG: (dns) Round-robin nameservers 
= 0
[Nov 24 20:18:12.554] Server {4146358528} DEBUG: (dns) DNSHandler::startEvent: 
on thread0
[Nov 24 20:18:12.554] Server {4146358528} DEBUG: (dns) open_con: opening 
connection :53
[Nov 24 20:18:12.554] Server {4146358528} DEBUG: (dns) random port = 28292
[Nov 24 20:18:12.554] Server {4146358528} DEBUG: (dns) opening connection :53 SUCCEEDED for 0

[jira] [Created] (TS-2391) Traffic Server tries to reverse resolve 127.0.0.1

[David Carlin (JIRA)]

David Carlin created TS-2391:


 Summary: Traffic Server tries to reverse resolve 127.0.0.1
 Key: TS-2391
 URL: https://issues.apache.org/jira/browse/TS-2391
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: David Carlin


We have a number of remaps using 127.0.0.1 for serving healthchecks.  Bryan 
Call noticed ATS seems to try and resolve 1.0.0.127.in-addr.arpa for every one 
of the requests (there are a lot, sometimes hundreds per second).

Occasionally this process hangs; If I grep squid.blog for 127.0.0.1 I'll see 
the healthcheck log entries flowing and then all of a sudden it'll stop 
anywhere from 15-80 seconds.  Then the backlog of healthchecks is cleared out 
at once.  5-10 minutes later this process will recur. 

>From traffic.out with debug dns.*|hostdb.*  - this occurs continuously.   
>Lookup for 1.0.0.127.in-addr.arpa fails (NXDOMAIN) and it doesn't get added to 
>HostDB.

Unsure if related, but TS-852 seemed similar.

{noformat}
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received query  type 
= 12, timeout = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) enqueing query 
1.0.0.127.in-addr.arpa
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) adding first to 
collapsing queue
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query 
(qtype=12) for 1.0.0.127.in-addr.arpa to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = 
1.0.0.127.in-addr.arpa, id = 56887, nameserver = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent_one: 
failover_number for resolver 0 is 1
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received packet size 
= 109
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS response 
code = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 3
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 3 for 
[1.0.0.127.in-addr.arpa]
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query 
(qtype=12) for  to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = , id = 
4497, nameserver = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) sent_one: 
failover_number for resolver 0 is 1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received packet size 
= 92
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS response 
code = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 0 for []
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) FAIL result for  = 
 retry 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) called back 
continuation for
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 1]
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) failed for 
127.0.0.1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) inserting for: : 
(md5: aa30de0f80a82135) bucket: 1017 now: 1385325494 timeout: 0 ttl: 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe 127.0.0.1 
9993e35a45b4be6a 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) immediate answer 
for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) delaying force 0 
answer for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759c8953a0} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) DNS IP 127.0.0.1
{noformat}

YTS doesn't have this issue:

{noformat}
[Nov 24 20:18:11.941] {4146358528} STATUS: opened /home/y/logs/yts/diags.log
[Nov 24 20:18:11.959] Server {4146358528} DEBUG: (dns) ink_dns_init: called 
with init_called = 0
[Nov 24 20:18:11.992] Server {4146358528} DEBUG: (dns) initial 
dns_sequence_number = 10131
[Nov 24 20:18:11.993] Server {4146358528} DEBUG: (dns) localhost=
[Nov 24 20:18:11.993] Server {4146358528} DEBUG: (dns) Round-robin nameservers 
= 0
[Nov 24 20:18:12.554] Server {4146358528} DEBUG: (dns) DNSHandler::startEvent: 
on thread0
[Nov 24 20:18:12.554] Server {4146358528} DEBUG: (dns) open_con: opening 
connection :53
[Nov 24 20:18:12.554] Server {4146358528

[jira] [Commented] (TS-2390) CLONE - only enable -Werror for debug builds

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831027#comment-13831027
 ] 

Leif Hedstrom commented on TS-2390:
---

I cloned this one, such that we can agree on a way to enable -Werror without a 
-dev in the package name. We no longer produce -dev packages, and 'master' is 
always stable. The concept of -dev is simply gone, and we should encourage 
everyone to not consider "master" as a -dev state.

Couple of ideas would be

1) Only do -Werror on --enable-debug builds (as suggested initially). This 
doesn't give perfect coverage.

2) Only do -Werror when building out of a "git" repository.

3) Make it an explicit configure option (such that we can enable it on all 
build-bots for example).


Thoughts?

> CLONE - only enable -Werror for debug builds
> 
>
> Key: TS-2390
> URL: https://issues.apache.org/jira/browse/TS-2390
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: James Peach
>
> It's very difficult to always build with -Werror on every platform we 
> support. -Werror is only valuable to developers, not so much for users. We 
> should consider only enabling -Werror if the build was configured with 
> --enable-debug. This probably involves adding autoconf macros to test whether 
> the compiler actually supports -Werror.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (TS-2390) CLONE - only enable -Werror for debug builds

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-2390:
-

 Summary: CLONE - only enable -Werror for debug builds
 Key: TS-2390
 URL: https://issues.apache.org/jira/browse/TS-2390
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: James Peach
Assignee: James Peach


It's very difficult to always build with -Werror on every platform we support. 
-Werror is only valuable to developers, not so much for users. We should 
consider only enabling -Werror if the build was configured with --enable-debug. 
This probably involves adding autoconf macros to test whether the compiler 
actually supports -Werror.



--
This message was sent by Atlassian JIRA
(v6.1#6144)