Re: [jira] [Commented] (TS-4645) traffic_top doesn't start

[James Peach]

Do we need to keep compatibility with the old metrics? At minimum we need to 
add this to the release notes.

> On Jul 19, 2016, at 2:20 AM, Thomas Jackson (JIRA)  wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/TS-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15382530#comment-15382530
>  ] 
> 
> Thomas Jackson commented on TS-4645:
> 
> 
> These metrics where replaced, the new ones are namespaced now:
> {quote}
> [jacksontj@localhost trafficserver]$ ./bin/traffic_line -m '.*' | grep 
> hostdb\.cache
> proxy.process.hostdb.cache.current_items 2
> proxy.process.hostdb.cache.current_size 176
> proxy.process.hostdb.cache.total_inserts 2
> proxy.process.hostdb.cache.total_failed_inserts 0
> proxy.process.hostdb.cache.total_lookups 0
> proxy.process.hostdb.cache.total_hits 0
> proxy.process.hostdb.cache.last_sync.time 1468858782
> proxy.process.hostdb.cache.last_sync.total_items 0
> proxy.process.hostdb.cache.last_sync.total_size 0
> {quote}
> 
>> traffic_top doesn't start
>> -
>> 
>>Key: TS-4645
>>URL: https://issues.apache.org/jira/browse/TS-4645
>>Project: Traffic Server
>> Issue Type: Bug
>> Components: Tools
>>   Affects Versions: 7.0.0
>>   Reporter: Masaori Koshiba
>>Fix For: 7.0.0
>> 
>> 
>> {noformat}
>> Error getting stat: proxy.process.hostdb.total_entries when calling 
>> TSRecordGetInt() failed: file "stats.h", line 268
>> {noformat}
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

[jira] [Resolved] (TS-3640) Drupal auth fails with dda6814f07ee59c over SPDY

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-3640.
---
   Resolution: Invalid
Fix Version/s: (was: 7.0.0)

> Drupal auth fails with dda6814f07ee59c over SPDY
> 
>
> Key: TS-3640
> URL: https://issues.apache.org/jira/browse/TS-3640
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Attachments: ts-3640.diff
>
>
> With the patch from dda6814f07ee59c, when Drupal authenticates a user, it 
> sends back a 302 redirect to that user's "page". This seems to stall the SPDY 
> session entirely (it stops dead in its track at this point). Backing out 
> dda6814f07ee59c makes it work again.
> I've emailed some potentially sensitive traces directly to [~shinrich]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4645) traffic_top doesn't start

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4645:
--
Assignee: Bryan Call

> traffic_top doesn't start
> -
>
> Key: TS-4645
> URL: https://issues.apache.org/jira/browse/TS-4645
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 7.0.0
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
> Fix For: 7.0.0
>
>
> {noformat}
> Error getting stat: proxy.process.hostdb.total_entries when calling 
> TSRecordGetInt() failed: file "stats.h", line 268
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build is back to normal : docs-master #111

[jenkins]

See 

Jenkins build is back to normal : in_tree-master #2100

[jenkins]

See 

Jenkins build is back to normal : out_of_tree-master #1873

[jenkins]

See 

Build failed in Jenkins: out_of_tree-master #1872

[jenkins]

See 

Changes:

[ft] TS-4650: cachekey: not thread safe

[ft] cachekey/pattern.h: clang format

[Leif Hedstrom] TS-4683 Adds better error handling on config problems

[Leif Hedstrom] TS-4311 Removes support for SPDY completely

--
Started by remote host 2001:4800:7821:102:be76:4eff:fe05:ad8b
Building on master in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > http://192.168.3.1/mirror/trafficserver.git # timeout=10
Cleaning workspace
 > /usr/bin/git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > /usr/bin/git reset --hard # timeout=10
 > /usr/bin/git clean -fdx # timeout=10
Fetching upstream changes from http://192.168.3.1/mirror/trafficserver.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git -c core.askpass=true fetch --tags --progress 
 > http://192.168.3.1/mirror/trafficserver.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} # 
 > timeout=10
Checking out Revision 17dbf54ac032a5ba7cbaad17212d45105b34394b 
(refs/remotes/origin/master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f 17dbf54ac032a5ba7cbaad17212d45105b34394b
 > /usr/bin/git rev-list 0aedb75f15f139a75a76728b2b125cd26c05f9d4 # timeout=10
[out_of_tree-master] $ /bin/bash -xe /tmp/hudson3264944669027049633.sh
+ source /home/jenkins/bin/environment.sh
++ export ATS_SRC_HOME=/home/jenkins/src
++ ATS_SRC_HOME=/home/jenkins/src
++ test out_of_tree-master '!=' out_of_tree-master
++ ATS_MAKE=make
++ test out_of_tree-master '!=' out_of_tree-master
++ export ATS_MAKE
+++ /bin/date +%m%d%Y
++ export TODAY=07212016
++ TODAY=07212016
++ ATS_BRANCH=master
++ ATS_IS_7=yes
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ test out_of_tree-master '!=' out_of_tree-master
++ export ATS_BRANCH
++ test out_of_tree-master '!=' out_of_tree-master
/home/jenkins/bin/environment.sh: line 75: unexpected EOF while looking for 
matching `"'
Build step 'Execute shell' marked build as failure

Build failed in Jenkins: docs-master #110

[jenkins]

See 

Changes:

[tstroh] TS-4639: Add git to Vagrant builds

[ft] TS-4650: cachekey: not thread safe

[Pavlo Yatsukhnenko] TS-4680: thread safe initialization in TS*DirGet() 
functions

[Leif Hedstrom] TS-4667 Uses the WKS in the gzip plugin

[ft] cachekey/pattern.h: clang format

[noreply] TS-4688 handle DNS compression labels in SRV responses (#812)

[noreply] TS-4622 Use port from SRV response when connecting to origin (#773)

[Thomas Jackson] Revert "TS-4622 Use port from SRV response when connecting to 
origin

[Thomas Jackson] TS-4622 use port from SRV response for origin connections

[Thomas Jackson] Add some initial SRV tsqa tests

[Thomas Jackson] TS-4615 set SRV scheme based on next_hop_scheme

[Thomas Jackson] Add TSQA tests for https SRV records

[Leif Hedstrom] TS-4683 Adds better error handling on config problems

[Leif Hedstrom] TS-4311 Removes support for SPDY completely

--
Started by remote host 2001:4800:7821:102:be76:4eff:fe05:ad8b
Building on master in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > http://192.168.3.1/mirror/trafficserver.git # timeout=10
Fetching upstream changes from http://192.168.3.1/mirror/trafficserver.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git -c core.askpass=true fetch --tags --progress 
 > http://192.168.3.1/mirror/trafficserver.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} # 
 > timeout=10
Checking out Revision 17dbf54ac032a5ba7cbaad17212d45105b34394b 
(refs/remotes/origin/master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f 17dbf54ac032a5ba7cbaad17212d45105b34394b
 > /usr/bin/git rev-list 880127b91802cd74cd66b8303802a44091e98d87 # timeout=10
[docs-master] $ /bin/bash -xe /tmp/hudson2147656041994009213.sh
+ source /home/jenkins/bin/environment.sh
++ export ATS_SRC_HOME=/home/jenkins/src
++ ATS_SRC_HOME=/home/jenkins/src
++ test docs-master '!=' docs-master
++ ATS_MAKE=make
++ test docs-master '!=' docs-master
++ export ATS_MAKE
+++ /bin/date +%m%d%Y
++ export TODAY=07212016
++ TODAY=07212016
++ ATS_BRANCH=master
++ ATS_IS_7=yes
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ test docs-master '!=' docs-master
++ export ATS_BRANCH
++ test docs-master '!=' docs-master
/home/jenkins/bin/environment.sh: line 75: unexpected EOF while looking for 
matching `"'
Build step 'Execute shell' marked build as failure

Build failed in Jenkins: in_tree-master #2099

[jenkins]

See 

Changes:

[ft] TS-4650: cachekey: not thread safe

[ft] cachekey/pattern.h: clang format

[Leif Hedstrom] TS-4683 Adds better error handling on config problems

[Leif Hedstrom] TS-4311 Removes support for SPDY completely

--
Started by remote host 2001:4800:7821:102:be76:4eff:fe05:ad8b
Building on master in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > http://192.168.3.1/mirror/trafficserver.git # timeout=10
Cleaning workspace
 > /usr/bin/git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > /usr/bin/git reset --hard # timeout=10
 > /usr/bin/git clean -fdx # timeout=10
Fetching upstream changes from http://192.168.3.1/mirror/trafficserver.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git -c core.askpass=true fetch --tags --progress 
 > http://192.168.3.1/mirror/trafficserver.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} # 
 > timeout=10
Checking out Revision 17dbf54ac032a5ba7cbaad17212d45105b34394b 
(refs/remotes/origin/master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f 17dbf54ac032a5ba7cbaad17212d45105b34394b
 > /usr/bin/git rev-list 0aedb75f15f139a75a76728b2b125cd26c05f9d4 # timeout=10
[in_tree-master] $ /bin/bash -xe /tmp/hudson890375306440897623.sh
+ source /home/jenkins/bin/environment.sh
++ export ATS_SRC_HOME=/home/jenkins/src
++ ATS_SRC_HOME=/home/jenkins/src
++ test in_tree-master '!=' in_tree-master
++ ATS_MAKE=make
++ test in_tree-master '!=' in_tree-master
++ export ATS_MAKE
+++ /bin/date +%m%d%Y
++ export TODAY=07212016
++ TODAY=07212016
++ ATS_BRANCH=master
++ ATS_IS_7=yes
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ test in_tree-master '!=' in_tree-master
++ export ATS_BRANCH
++ test in_tree-master '!=' in_tree-master
/home/jenkins/bin/environment.sh: line 75: unexpected EOF while looking for 
matching `"'
Build step 'Execute shell' marked build as failure

[jira] [Work logged] (TS-4311) Remove SPDY protocol support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4311?focusedWorklogId=25842=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25842
 ]

ASF GitHub Bot logged work on TS-4311:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 22:18
Start Date: 21/Jul/16 22:18
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/819


Issue Time Tracking
---

Worklog Id: (was: 25842)
Time Spent: 1h 20m  (was: 1h 10m)

> Remove SPDY protocol support
> 
>
> Key: TS-4311
> URL: https://issues.apache.org/jira/browse/TS-4311
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> With the high adoption rate of HTTP/2 and support for HTTP/2 in ATS since 
> 5.3.0 (experimental) and 6.0.0 (stable) it would be a good time to remove 
> SPDY in ATS 7.0.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #819: TS-4311 Removes support for SPDY completely

[zwoop]

Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/819


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4311) Remove SPDY protocol support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4311?focusedWorklogId=25836=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25836
 ]

ASF GitHub Bot logged work on TS-4311:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 21:08
Start Date: 21/Jul/16 21:08
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/819
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/368/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 25836)
Time Spent: 1h 10m  (was: 1h)

> Remove SPDY protocol support
> 
>
> Key: TS-4311
> URL: https://issues.apache.org/jira/browse/TS-4311
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> With the high adoption rate of HTTP/2 and support for HTTP/2 in ATS since 
> 5.3.0 (experimental) and 6.0.0 (stable) it would be a good time to remove 
> SPDY in ATS 7.0.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #819: TS-4311 Removes support for SPDY completely

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/819
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/368/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4184) Move to use the C++11 standard

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4184:
---

So, you all convinced me, and we'll migrate towards C++11 with v7.0.0. Changed 
this to be for C++11 :).

> Move to use the C++11 standard
> --
>
> Key: TS-4184
> URL: https://issues.apache.org/jira/browse/TS-4184
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Require C++0x and get rid of ats_scoped_resource based classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4184) Move to use the C++0x standard

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reassigned TS-4184:
-

Assignee: Leif Hedstrom

> Move to use the C++0x standard
> --
>
> Key: TS-4184
> URL: https://issues.apache.org/jira/browse/TS-4184
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Require C++0x and get rid of ats_scoped_resource based classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4184) Move to use the C++11 standard

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4184:
--
Summary: Move to use the C++11 standard  (was: Move to use the C++0x 
standard)

> Move to use the C++11 standard
> --
>
> Key: TS-4184
> URL: https://issues.apache.org/jira/browse/TS-4184
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Require C++0x and get rid of ats_scoped_resource based classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4311) Remove SPDY protocol support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4311?focusedWorklogId=25834=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25834
 ]

ASF GitHub Bot logged work on TS-4311:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 21:04
Start Date: 21/Jul/16 21:04
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/819
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/471/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 25834)
Time Spent: 1h  (was: 50m)

> Remove SPDY protocol support
> 
>
> Key: TS-4311
> URL: https://issues.apache.org/jira/browse/TS-4311
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> With the high adoption rate of HTTP/2 and support for HTTP/2 in ATS since 
> 5.3.0 (experimental) and 6.0.0 (stable) it would be a good time to remove 
> SPDY in ATS 7.0.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #819: TS-4311 Removes support for SPDY completely

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/819
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/471/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-3791) Diagnostics can crash in PCRE JIT when there's a bad config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3791:
---

I think I have tracked this down some more. This happens reliably for me when I 
set this setting:

{code}
CONFIG proxy.config.mlock_enabled INT 2
{code}

After enabling this, I trigger a crasher reliably by simply doing e.g.

{code}
sudo traffic_server -T http_hdrs
{code}


> Diagnostics can crash in PCRE JIT when there's a bad config 
> 
>
> Key: TS-3791
> URL: https://issues.apache.org/jira/browse/TS-3791
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
>  Labels: crash
> Fix For: 7.0.0
>
>
> Somewhat strange setup, but basically with a bad parent.config entry, e.g.
> {code}
> dest_domain=. parent="foo.example.com"
> {code}
> (notice the missing :port), and I run traffic_server with a -T option, e.g.
> {code}
> ./bin/traffic_server -T parent
> {code}
> I get a crash with a core of
> {code}
> (gdb) bt
> #0  0x752019c8 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:55
> #1  0x7520365a in __GI_abort () at abort.c:89
> #2  0x77bc3fb8 in ink_die_die_die () at 
> ../../../../lib/ts/ink_error.cc:43
> #3  ink_fatal_va (fmt=0x77bd0820 "ats_malloc: couldn't allocate %zu 
> bytes", ap=ap@entry=0x73994808) at ../../../../lib/ts/ink_error.cc:65
> #4  0x77bc404c in ink_fatal 
> (message_format=message_format@entry=0x77bd0820 "ats_malloc: couldn't 
> allocate %zu bytes") at ../../../../lib/ts/ink_error.cc:73
> #5  0x77bc6f16 in ats_malloc (size=32) at 
> ../../../../lib/ts/ink_memory.cc:56
> #6  0x76911694 in sljit_allocate_stack (allocator_data=0x0, 
> max_limit=1048576, limit=8192) at sljit/sljitUtils.c:236
> #7  pcre_jit_stack_alloc (startsize=8192, maxsize=, 
> maxsize@entry=1048576) at pcre_jit_compile.c:10571
> #8  0x77bbc656 in get_jit_stack (data=) at 
> ../../../../lib/ts/Regex.cc:44
> #9  0x76911358 in _pcre_jit_exec 
> (extra_data=extra_data@entry=0x10aa2d0, subject=subject@entry=0x80ac67 
> "pmgmt", length=length@entry=5, start_offset=start_offset@entry=0, 
> options=options@entry=0, offsets=offsets@entry=0x73994be0, 
> offset_count=2) at pcre_jit_compile.c:10420
> #10 0x768e9e7e in pcre_exec (argument_re=0x10aa270, 
> extra_data=, subject=subject@entry=0x80ac67 "pmgmt", 
> length=length@entry=5, start_offset=start_offset@entry=0, 
> options=options@entry=0, offsets=0x73994be0, offsetcount=30) at 
> pcre_exec.c:6483
> #11 0x77bbc79e in Regex::exec (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=length@entry=5, 
> ovector=ovector@entry=0x73994be0, ovecsize=ovecsize@entry=30) at 
> ../../../../lib/ts/Regex.cc:120
> #12 0x77bbc7c5 in Regex::exec (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=length@entry=5) at 
> ../../../../lib/ts/Regex.cc:112
> #13 0x77bbca1f in DFA::match (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=5) at ../../../../lib/ts/Regex.cc:235
> #14 0x77bbca67 in DFA::match (this=, 
> str=str@entry=0x80ac67 "pmgmt") at ../../../../lib/ts/Regex.cc:225
> #15 0x77bb0a32 in Diags::tag_activated (this=this@entry=0x10aa140, 
> tag=tag@entry=0x80ac67 "pmgmt", mode=mode@entry=DiagsTagType_Debug) at 
> ../../../../lib/ts/Diags.cc:394
> #16 0x77bb1429 in on (mode=DiagsTagType_Debug, tag=0x80ac67 "pmgmt", 
> this=0x10aa140) at ../../../../lib/ts/Diags.h:171
> #17 Diags::log (this=0x10aa140, tag=tag@entry=0x80ac67 "pmgmt", 
> level=level@entry=DL_Debug, file=file@entry=0x80a850 
> "../../../mgmt/ProcessManager.cc", func=func@entry=0x80acf0 
>  "processSignalQueue", 
> line=line@entry=148, format_string=0x80a8f8 "[ProcessManager] ==> Signalling 
> local manager '%d'\n") at ../../../../lib/ts/Diags.cc:513
> #18 0x006979f5 in ProcessManager::processSignalQueue (this=0x10eab30) 
> at ../../../mgmt/ProcessManager.cc:148
> #19 0x00697ffd in startProcessManager (arg=) at 
> ../../../mgmt/ProcessManager.cc:63
> #20 0x76039555 in start_thread (arg=0x73995700) at 
> pthread_create.c:333
> #21 0x752cfb9d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3132) Can't recover the disk, after disk replacement

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3132:
--
Labels: A  (was: )

> Can't recover the disk, after disk replacement
> --
>
> Key: TS-3132
> URL: https://issues.apache.org/jira/browse/TS-3132
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 4.2.0, 5.1.0, 6.1.1
> Environment: CentOS 6.5 x86_64
>Reporter: seri,Kim
>Assignee: Alan M. Carroll
>Priority: Critical
>  Labels: A
> Fix For: 7.0.0
>
>
> {quote}
> \[Oct  9 13:55:18.257\] Server \{0x2add2d1d0700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.259\] Server \{0x2add03736700\} WARNING: Error accessing 
> Disk /dev/sdk \[1/5\]
> \[Oct  9 13:55:18.265\] Server \{0x2add2cdcc700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.271\] Server \{0x2add02120700\} WARNING: Error accessing 
> Disk /dev/sdk \[2/5\]
> \[Oct  9 13:55:18.273\] Server \{0x2add2dbda700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.280\] Server \{0x2add02827700\} WARNING: Error accessing 
> Disk /dev/sdk \[3/5\]
> \[Oct  9 13:55:18.325\] Server \{0x2add2c7c6700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.331\] Server \{0x2add01d1c700\} WARNING: Error accessing 
> Disk /dev/sdk \[4/5\]
> \[Oct  9 22:36:49.223\] Server \{0x2add2cbca700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 22:36:49.226\] Server \{0x2add01b1a700\} WARNING: too many errors 
> accessing disk /dev/sdk \[5/5\]: declaring disk bad
> \[Oct  9 22:36:49.405\] Server \{0x2add2c3c2700\} WARNING: cache disk 
> operation failed READ -1 5
> {quote}
> Because of disk failure,
> 1. I stopped Traffic Server, replaced the disk and started Traffic Server.
> {quote}
> \[Oct 14 16:53:04.131\] Server \{0x2ada6e423700\} WARNING: disk header 
> different for disk /dev/sdk: clearing the disk
> \[Oct 14 16:53:04.225\] Server \{0x2ada67757140\} NOTE: traffic server running
> \[Oct 14 16:53:11.890\] Server \{0x2ada6f231700\} NOTE: cache enabled
> {quote}
> 2. But failed to recover the disk.
> How can I recover the failed disk?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3132) Can't recover the disk, after disk replacement

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3132:
--
Affects Version/s: 6.1.1

> Can't recover the disk, after disk replacement
> --
>
> Key: TS-3132
> URL: https://issues.apache.org/jira/browse/TS-3132
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 4.2.0, 5.1.0, 6.1.1
> Environment: CentOS 6.5 x86_64
>Reporter: seri,Kim
>Assignee: Alan M. Carroll
>  Labels: A
> Fix For: 7.0.0
>
>
> {quote}
> \[Oct  9 13:55:18.257\] Server \{0x2add2d1d0700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.259\] Server \{0x2add03736700\} WARNING: Error accessing 
> Disk /dev/sdk \[1/5\]
> \[Oct  9 13:55:18.265\] Server \{0x2add2cdcc700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.271\] Server \{0x2add02120700\} WARNING: Error accessing 
> Disk /dev/sdk \[2/5\]
> \[Oct  9 13:55:18.273\] Server \{0x2add2dbda700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.280\] Server \{0x2add02827700\} WARNING: Error accessing 
> Disk /dev/sdk \[3/5\]
> \[Oct  9 13:55:18.325\] Server \{0x2add2c7c6700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.331\] Server \{0x2add01d1c700\} WARNING: Error accessing 
> Disk /dev/sdk \[4/5\]
> \[Oct  9 22:36:49.223\] Server \{0x2add2cbca700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 22:36:49.226\] Server \{0x2add01b1a700\} WARNING: too many errors 
> accessing disk /dev/sdk \[5/5\]: declaring disk bad
> \[Oct  9 22:36:49.405\] Server \{0x2add2c3c2700\} WARNING: cache disk 
> operation failed READ -1 5
> {quote}
> Because of disk failure,
> 1. I stopped Traffic Server, replaced the disk and started Traffic Server.
> {quote}
> \[Oct 14 16:53:04.131\] Server \{0x2ada6e423700\} WARNING: disk header 
> different for disk /dev/sdk: clearing the disk
> \[Oct 14 16:53:04.225\] Server \{0x2ada67757140\} NOTE: traffic server running
> \[Oct 14 16:53:11.890\] Server \{0x2ada6f231700\} NOTE: cache enabled
> {quote}
> 2. But failed to recover the disk.
> How can I recover the failed disk?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3132) Can't recover the disk, after disk replacement

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3132:
--
Fix Version/s: (was: sometime)
   7.0.0

> Can't recover the disk, after disk replacement
> --
>
> Key: TS-3132
> URL: https://issues.apache.org/jira/browse/TS-3132
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 4.2.0, 5.1.0, 6.1.1
> Environment: CentOS 6.5 x86_64
>Reporter: seri,Kim
>Assignee: Alan M. Carroll
>  Labels: A
> Fix For: 7.0.0
>
>
> {quote}
> \[Oct  9 13:55:18.257\] Server \{0x2add2d1d0700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.259\] Server \{0x2add03736700\} WARNING: Error accessing 
> Disk /dev/sdk \[1/5\]
> \[Oct  9 13:55:18.265\] Server \{0x2add2cdcc700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.271\] Server \{0x2add02120700\} WARNING: Error accessing 
> Disk /dev/sdk \[2/5\]
> \[Oct  9 13:55:18.273\] Server \{0x2add2dbda700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.280\] Server \{0x2add02827700\} WARNING: Error accessing 
> Disk /dev/sdk \[3/5\]
> \[Oct  9 13:55:18.325\] Server \{0x2add2c7c6700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.331\] Server \{0x2add01d1c700\} WARNING: Error accessing 
> Disk /dev/sdk \[4/5\]
> \[Oct  9 22:36:49.223\] Server \{0x2add2cbca700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 22:36:49.226\] Server \{0x2add01b1a700\} WARNING: too many errors 
> accessing disk /dev/sdk \[5/5\]: declaring disk bad
> \[Oct  9 22:36:49.405\] Server \{0x2add2c3c2700\} WARNING: cache disk 
> operation failed READ -1 5
> {quote}
> Because of disk failure,
> 1. I stopped Traffic Server, replaced the disk and started Traffic Server.
> {quote}
> \[Oct 14 16:53:04.131\] Server \{0x2ada6e423700\} WARNING: disk header 
> different for disk /dev/sdk: clearing the disk
> \[Oct 14 16:53:04.225\] Server \{0x2ada67757140\} NOTE: traffic server running
> \[Oct 14 16:53:11.890\] Server \{0x2ada6f231700\} NOTE: cache enabled
> {quote}
> 2. But failed to recover the disk.
> How can I recover the failed disk?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TS-3132) Can't recover the disk, after disk replacement

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-3132 at 7/21/16 7:48 PM:


I ran into this as well today, basically exactly the same scenario, disk 
replaces, box came up, initialized the new disk properly, but is not using it 
at all. This was with v6.1.1, so the problem still persists.


was (Author: zwoop):
I ran into this as well today, basically exactly the same scenario, disk 
replaces, box came up, initialized the new disk properly, but is not using it 
at all.

> Can't recover the disk, after disk replacement
> --
>
> Key: TS-3132
> URL: https://issues.apache.org/jira/browse/TS-3132
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 4.2.0, 5.1.0, 6.1.1
> Environment: CentOS 6.5 x86_64
>Reporter: seri,Kim
>Assignee: Alan M. Carroll
>  Labels: A
> Fix For: 7.0.0
>
>
> {quote}
> \[Oct  9 13:55:18.257\] Server \{0x2add2d1d0700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.259\] Server \{0x2add03736700\} WARNING: Error accessing 
> Disk /dev/sdk \[1/5\]
> \[Oct  9 13:55:18.265\] Server \{0x2add2cdcc700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.271\] Server \{0x2add02120700\} WARNING: Error accessing 
> Disk /dev/sdk \[2/5\]
> \[Oct  9 13:55:18.273\] Server \{0x2add2dbda700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.280\] Server \{0x2add02827700\} WARNING: Error accessing 
> Disk /dev/sdk \[3/5\]
> \[Oct  9 13:55:18.325\] Server \{0x2add2c7c6700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.331\] Server \{0x2add01d1c700\} WARNING: Error accessing 
> Disk /dev/sdk \[4/5\]
> \[Oct  9 22:36:49.223\] Server \{0x2add2cbca700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 22:36:49.226\] Server \{0x2add01b1a700\} WARNING: too many errors 
> accessing disk /dev/sdk \[5/5\]: declaring disk bad
> \[Oct  9 22:36:49.405\] Server \{0x2add2c3c2700\} WARNING: cache disk 
> operation failed READ -1 5
> {quote}
> Because of disk failure,
> 1. I stopped Traffic Server, replaced the disk and started Traffic Server.
> {quote}
> \[Oct 14 16:53:04.131\] Server \{0x2ada6e423700\} WARNING: disk header 
> different for disk /dev/sdk: clearing the disk
> \[Oct 14 16:53:04.225\] Server \{0x2ada67757140\} NOTE: traffic server running
> \[Oct 14 16:53:11.890\] Server \{0x2ada6f231700\} NOTE: cache enabled
> {quote}
> 2. But failed to recover the disk.
> How can I recover the failed disk?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3132) Can't recover the disk, after disk replacement

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3132:
--
Priority: Critical  (was: Major)

> Can't recover the disk, after disk replacement
> --
>
> Key: TS-3132
> URL: https://issues.apache.org/jira/browse/TS-3132
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 4.2.0, 5.1.0, 6.1.1
> Environment: CentOS 6.5 x86_64
>Reporter: seri,Kim
>Assignee: Alan M. Carroll
>Priority: Critical
>  Labels: A
> Fix For: 7.0.0
>
>
> {quote}
> \[Oct  9 13:55:18.257\] Server \{0x2add2d1d0700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.259\] Server \{0x2add03736700\} WARNING: Error accessing 
> Disk /dev/sdk \[1/5\]
> \[Oct  9 13:55:18.265\] Server \{0x2add2cdcc700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.271\] Server \{0x2add02120700\} WARNING: Error accessing 
> Disk /dev/sdk \[2/5\]
> \[Oct  9 13:55:18.273\] Server \{0x2add2dbda700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.280\] Server \{0x2add02827700\} WARNING: Error accessing 
> Disk /dev/sdk \[3/5\]
> \[Oct  9 13:55:18.325\] Server \{0x2add2c7c6700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.331\] Server \{0x2add01d1c700\} WARNING: Error accessing 
> Disk /dev/sdk \[4/5\]
> \[Oct  9 22:36:49.223\] Server \{0x2add2cbca700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 22:36:49.226\] Server \{0x2add01b1a700\} WARNING: too many errors 
> accessing disk /dev/sdk \[5/5\]: declaring disk bad
> \[Oct  9 22:36:49.405\] Server \{0x2add2c3c2700\} WARNING: cache disk 
> operation failed READ -1 5
> {quote}
> Because of disk failure,
> 1. I stopped Traffic Server, replaced the disk and started Traffic Server.
> {quote}
> \[Oct 14 16:53:04.131\] Server \{0x2ada6e423700\} WARNING: disk header 
> different for disk /dev/sdk: clearing the disk
> \[Oct 14 16:53:04.225\] Server \{0x2ada67757140\} NOTE: traffic server running
> \[Oct 14 16:53:11.890\] Server \{0x2ada6f231700\} NOTE: cache enabled
> {quote}
> 2. But failed to recover the disk.
> How can I recover the failed disk?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TS-3132) Can't recover the disk, after disk replacement

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-3132 at 7/21/16 7:46 PM:


Hi Phil,
 
I just tracked down the source of our problem with replacement drives not being 
picked up by ATS. My grasp on the ATS code is still rather limited, but with 
enough printf’s in the right spots, I have a general idea of what’s going on.
 
First, I need to tell you guys that I’ve verified several times over that the 
issue we’re seeing exists with both ATS 3.2 and 5.2. It has nothing to do with 
the differences between IPCDN’s drive replacement procedure and ours (i.e. 
neither your reboot nor our /dev/ats/cachediskXX symlinks are causing the delta 
in behavior).
 
In our storage.config, we are not listing an explicit volume number for each 
drive, and as such, the list of volumes for that drive ends up being empty 
until the content of the drive is scanned. Because this is a new drive without 
volume info, the drive never ends up with a volume list, and as such ends up in 
a limbo state.
 
The quick and dirty workaround that I just tested with ATS 3.2 is to add a 
‘volume=1’ to every entry in storage.conf, but I believe that the correct 
solution is probably a change to the ‘fillExclusiveDisks()’ function in ATS’s 
iocore/Cache.cc source.
 
Tomorrow, I’ll see how easy it is to put a patch together for this, but I’m 
guessing its trickier than my understanding of the code would allow in any 
short amount of time.
 
-John



was (Author: psudaemon):
{noformat}
Hi Phil,
 
I just tracked down the source of our problem with replacement drives not being 
picked up by ATS. My grasp on the ATS code is still rather limited, but with 
enough printf’s in the right spots, I have a general idea of what’s going on.
 
First, I need to tell you guys that I’ve verified several times over that the 
issue we’re seeing exists with both ATS 3.2 and 5.2. It has nothing to do with 
the differences between IPCDN’s drive replacement procedure and ours (i.e. 
neither your reboot nor our /dev/ats/cachediskXX symlinks are causing the delta 
in behavior).
 
In our storage.config, we are not listing an explicit volume number for each 
drive, and as such, the list of volumes for that drive ends up being empty 
until the content of the drive is scanned. Because this is a new drive without 
volume info, the drive never ends up with a volume list, and as such ends up in 
a limbo state.
 
The quick and dirty workaround that I just tested with ATS 3.2 is to add a 
‘volume=1’ to every entry in storage.conf, but I believe that the correct 
solution is probably a change to the ‘fillExclusiveDisks()’ function in ATS’s 
iocore/Cache.cc source.
 
Tomorrow, I’ll see how easy it is to put a patch together for this, but I’m 
guessing its trickier than my understanding of the code would allow in any 
short amount of time.
 
-John
{noformat}

> Can't recover the disk, after disk replacement
> --
>
> Key: TS-3132
> URL: https://issues.apache.org/jira/browse/TS-3132
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 4.2.0, 5.1.0
> Environment: CentOS 6.5 x86_64
>Reporter: seri,Kim
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> {quote}
> \[Oct  9 13:55:18.257\] Server \{0x2add2d1d0700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.259\] Server \{0x2add03736700\} WARNING: Error accessing 
> Disk /dev/sdk \[1/5\]
> \[Oct  9 13:55:18.265\] Server \{0x2add2cdcc700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.271\] Server \{0x2add02120700\} WARNING: Error accessing 
> Disk /dev/sdk \[2/5\]
> \[Oct  9 13:55:18.273\] Server \{0x2add2dbda700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.280\] Server \{0x2add02827700\} WARNING: Error accessing 
> Disk /dev/sdk \[3/5\]
> \[Oct  9 13:55:18.325\] Server \{0x2add2c7c6700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.331\] Server \{0x2add01d1c700\} WARNING: Error accessing 
> Disk /dev/sdk \[4/5\]
> \[Oct  9 22:36:49.223\] Server \{0x2add2cbca700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 22:36:49.226\] Server \{0x2add01b1a700\} WARNING: too many errors 
> accessing disk /dev/sdk \[5/5\]: declaring disk bad
> \[Oct  9 22:36:49.405\] Server \{0x2add2c3c2700\} WARNING: cache disk 
> operation failed READ -1 5
> {quote}
> Because of disk failure,
> 1. I stopped Traffic Server, replaced the disk and started Traffic Server.
> {quote}
> \[Oct 14 16:53:04.131\] Server \{0x2ada6e423700\} WARNING: disk header 
> different for disk /dev/sdk: clearing the disk
> \[Oct 14 16:53:04.225\] Server \{0x2ada67757140\} NOTE: traffic server 

[jira] [Commented] (TS-3132) Can't recover the disk, after disk replacement

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3132:
---

I ran into this as well today, basically exactly the same scenario, disk 
replaces, box came up, initialized the new disk properly, but is not using it 
at all.

> Can't recover the disk, after disk replacement
> --
>
> Key: TS-3132
> URL: https://issues.apache.org/jira/browse/TS-3132
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Affects Versions: 4.2.0, 5.1.0
> Environment: CentOS 6.5 x86_64
>Reporter: seri,Kim
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> {quote}
> \[Oct  9 13:55:18.257\] Server \{0x2add2d1d0700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.259\] Server \{0x2add03736700\} WARNING: Error accessing 
> Disk /dev/sdk \[1/5\]
> \[Oct  9 13:55:18.265\] Server \{0x2add2cdcc700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.271\] Server \{0x2add02120700\} WARNING: Error accessing 
> Disk /dev/sdk \[2/5\]
> \[Oct  9 13:55:18.273\] Server \{0x2add2dbda700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.280\] Server \{0x2add02827700\} WARNING: Error accessing 
> Disk /dev/sdk \[3/5\]
> \[Oct  9 13:55:18.325\] Server \{0x2add2c7c6700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 13:55:18.331\] Server \{0x2add01d1c700\} WARNING: Error accessing 
> Disk /dev/sdk \[4/5\]
> \[Oct  9 22:36:49.223\] Server \{0x2add2cbca700\} WARNING: cache disk 
> operation failed READ -1 5
> \[Oct  9 22:36:49.226\] Server \{0x2add01b1a700\} WARNING: too many errors 
> accessing disk /dev/sdk \[5/5\]: declaring disk bad
> \[Oct  9 22:36:49.405\] Server \{0x2add2c3c2700\} WARNING: cache disk 
> operation failed READ -1 5
> {quote}
> Because of disk failure,
> 1. I stopped Traffic Server, replaced the disk and started Traffic Server.
> {quote}
> \[Oct 14 16:53:04.131\] Server \{0x2ada6e423700\} WARNING: disk header 
> different for disk /dev/sdk: clearing the disk
> \[Oct 14 16:53:04.225\] Server \{0x2ada67757140\} NOTE: traffic server running
> \[Oct 14 16:53:11.890\] Server \{0x2ada6f231700\} NOTE: cache enabled
> {quote}
> 2. But failed to recover the disk.
> How can I recover the failed disk?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4695) Remove the --enable-cppapi option

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4695:
--
Fix Version/s: 7.0.0

> Remove the --enable-cppapi option
> -
>
> Key: TS-4695
> URL: https://issues.apache.org/jira/browse/TS-4695
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> With 7.0.0 and forward, we require C++11 support, so we should just remove 
> this option and always compile it.
> Unless anyone objects?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4695) Remove the --enable-cppapi option

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4695:
-

 Summary: Remove the --enable-cppapi option
 Key: TS-4695
 URL: https://issues.apache.org/jira/browse/TS-4695
 Project: Traffic Server
  Issue Type: Improvement
  Components: Build
Reporter: Leif Hedstrom


With 7.0.0 and forward, we require C++11 support, so we should just remove this 
option and always compile it.

Unless anyone objects?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4695) Remove the --enable-cppapi option

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom reassigned TS-4695:
-

Assignee: Leif Hedstrom

> Remove the --enable-cppapi option
> -
>
> Key: TS-4695
> URL: https://issues.apache.org/jira/browse/TS-4695
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> With 7.0.0 and forward, we require C++11 support, so we should just remove 
> this option and always compile it.
> Unless anyone objects?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4612) Proposal: InactivityCop Optimize

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4612?focusedWorklogId=25827=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25827
 ]

ASF GitHub Bot logged work on TS-4612:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 18:40
Start Date: 21/Jul/16 18:40
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/771
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/470/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 25827)
Time Spent: 1h 40m  (was: 1.5h)

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #771: TS-4612: Proposal: InactivityCop Optimize

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/771
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/470/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4459) Force domain names in cert to lower on insert into lookup tree

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4459?focusedWorklogId=25826=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25826
 ]

ASF GitHub Bot logged work on TS-4459:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 18:35
Start Date: 21/Jul/16 18:35
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/647
  
@reveller Any update? :)


Issue Time Tracking
---

Worklog Id: (was: 25826)
Time Spent: 10m
Remaining Estimate: 0h

> Force domain names in cert to lower on insert into lookup tree
> --
>
> Key: TS-4459
> URL: https://issues.apache.org/jira/browse/TS-4459
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Steven Feltner
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We have certs from a legacy system that were issued with mixed case domain 
> names.  We are migrating this older product over to ATS and found that domain 
> names need to be lower cased before being inserted in the lookup table.
> I will be submitting  a pull request to resolve this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #647: TS-4459 - Force domain names in cert to lower on i...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/647
  
@reveller Any update? :)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #771: TS-4612: Proposal: InactivityCop Optimize

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/771
  
@oknet This fails on the clang-format, can you please fix and push an 
update?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4612) Proposal: InactivityCop Optimize

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4612?focusedWorklogId=25824=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25824
 ]

ASF GitHub Bot logged work on TS-4612:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 18:33
Start Date: 21/Jul/16 18:33
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/771
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/367/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 25824)
Time Spent: 1h 20m  (was: 1h 10m)

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4612) Proposal: InactivityCop Optimize

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4612?focusedWorklogId=25825=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25825
 ]

ASF GitHub Bot logged work on TS-4612:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 18:34
Start Date: 21/Jul/16 18:34
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/771
  
@oknet This fails on the clang-format, can you please fix and push an 
update?


Issue Time Tracking
---

Worklog Id: (was: 25825)
Time Spent: 1.5h  (was: 1h 20m)

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #771: TS-4612: Proposal: InactivityCop Optimize

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/771
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/367/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (TS-4694) Some refactoring after SPDY is removed

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4694:
-

 Summary: Some refactoring after SPDY is removed
 Key: TS-4694
 URL: https://issues.apache.org/jira/browse/TS-4694
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core, HTTP
Reporter: Leif Hedstrom


There's a place in the code with a comment about refactoring this once we 
remove SPDY (see below). I'm filing this separates from TS-4311, because I'm 
not sure what this refactoring entails. [~shinrich] had some ideas around this 
code :).

{code}
void
ProxyClientTransaction::new_transaction()
{
  ink_assert(current_reader == NULL);

  // Defensive programming, make sure nothing persists across
  // connection re-use

  ink_release_assert(parent != NULL);
  current_reader = HttpSM::allocate();
  current_reader->init();
  DebugHttpTxn("[%" PRId64 "] Starting transaction %d using sm [%" PRId64 "]", 
parent->connection_id(),
   parent->get_transact_count(), current_reader->sm_id);

  // This is a temporary hack until we get rid of SPDY and can use virutal 
methods entirely
  // to track protocol.
  PluginIdentity *pi = dynamic_cast(this->get_netvc());
  if (pi) {
current_reader->plugin_tag = pi->getPluginTag();
current_reader->plugin_id  = pi->getPluginId();
  } else {
const char *protocol_str = this->get_protocol_string();
// We don't set the plugin_tag for http, though in future we should 
probably log http as protocol
if (strlen(protocol_str) != 4 || strncmp("http", protocol_str, 4)) {
  current_reader->plugin_tag = protocol_str;
  // Since there is no more plugin, there is no plugin id for http/2
  // We are copying along the plugin_tag as a standin for protocol name for 
logging
  // and to detect a case in HttpTransaction (TS-3954)
}
  }
  current_reader->attach_client_session(this, sm_reader);
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4694) Some refactoring after SPDY is removed

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4694:
--
Fix Version/s: 7.0.0

> Some refactoring after SPDY is removed
> --
>
> Key: TS-4694
> URL: https://issues.apache.org/jira/browse/TS-4694
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> There's a place in the code with a comment about refactoring this once we 
> remove SPDY (see below). I'm filing this separates from TS-4311, because I'm 
> not sure what this refactoring entails. [~shinrich] had some ideas around 
> this code :).
> {code}
> void
> ProxyClientTransaction::new_transaction()
> {
>   ink_assert(current_reader == NULL);
>   // Defensive programming, make sure nothing persists across
>   // connection re-use
>   ink_release_assert(parent != NULL);
>   current_reader = HttpSM::allocate();
>   current_reader->init();
>   DebugHttpTxn("[%" PRId64 "] Starting transaction %d using sm [%" PRId64 
> "]", parent->connection_id(),
>parent->get_transact_count(), current_reader->sm_id);
>   // This is a temporary hack until we get rid of SPDY and can use virutal 
> methods entirely
>   // to track protocol.
>   PluginIdentity *pi = dynamic_cast(this->get_netvc());
>   if (pi) {
> current_reader->plugin_tag = pi->getPluginTag();
> current_reader->plugin_id  = pi->getPluginId();
>   } else {
> const char *protocol_str = this->get_protocol_string();
> // We don't set the plugin_tag for http, though in future we should 
> probably log http as protocol
> if (strlen(protocol_str) != 4 || strncmp("http", protocol_str, 4)) {
>   current_reader->plugin_tag = protocol_str;
>   // Since there is no more plugin, there is no plugin id for http/2
>   // We are copying along the plugin_tag as a standin for protocol name 
> for logging
>   // and to detect a case in HttpTransaction (TS-3954)
> }
>   }
>   current_reader->attach_client_session(this, sm_reader);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4694) Some refactoring after SPDY is removed

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4694:
--
Assignee: Susan Hinrichs

> Some refactoring after SPDY is removed
> --
>
> Key: TS-4694
> URL: https://issues.apache.org/jira/browse/TS-4694
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> There's a place in the code with a comment about refactoring this once we 
> remove SPDY (see below). I'm filing this separates from TS-4311, because I'm 
> not sure what this refactoring entails. [~shinrich] had some ideas around 
> this code :).
> {code}
> void
> ProxyClientTransaction::new_transaction()
> {
>   ink_assert(current_reader == NULL);
>   // Defensive programming, make sure nothing persists across
>   // connection re-use
>   ink_release_assert(parent != NULL);
>   current_reader = HttpSM::allocate();
>   current_reader->init();
>   DebugHttpTxn("[%" PRId64 "] Starting transaction %d using sm [%" PRId64 
> "]", parent->connection_id(),
>parent->get_transact_count(), current_reader->sm_id);
>   // This is a temporary hack until we get rid of SPDY and can use virutal 
> methods entirely
>   // to track protocol.
>   PluginIdentity *pi = dynamic_cast(this->get_netvc());
>   if (pi) {
> current_reader->plugin_tag = pi->getPluginTag();
> current_reader->plugin_id  = pi->getPluginId();
>   } else {
> const char *protocol_str = this->get_protocol_string();
> // We don't set the plugin_tag for http, though in future we should 
> probably log http as protocol
> if (strlen(protocol_str) != 4 || strncmp("http", protocol_str, 4)) {
>   current_reader->plugin_tag = protocol_str;
>   // Since there is no more plugin, there is no plugin id for http/2
>   // We are copying along the plugin_tag as a standin for protocol name 
> for logging
>   // and to detect a case in HttpTransaction (TS-3954)
> }
>   }
>   current_reader->attach_client_session(this, sm_reader);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4612) Proposal: InactivityCop Optimize

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4612?focusedWorklogId=25823=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25823
 ]

ASF GitHub Bot logged work on TS-4612:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 18:29
Start Date: 21/Jul/16 18:29
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/771
  
@bryancall Should we merge this? [approve ci].


Issue Time Tracking
---

Worklog Id: (was: 25823)
Time Spent: 1h 10m  (was: 1h)

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #771: TS-4612: Proposal: InactivityCop Optimize

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/771
  
@bryancall Should we merge this? [approve ci].


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4553) Add Brotli compression support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4553?focusedWorklogId=25822=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25822
 ]

ASF GitHub Bot logged work on TS-4553:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 18:29
Start Date: 21/Jul/16 18:29
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/776
  
@bgaff  We should decide what to do here, land this, land your version, or 
merge ?


Issue Time Tracking
---

Worklog Id: (was: 25822)
Time Spent: 1h  (was: 50m)

> Add Brotli compression support
> --
>
> Key: TS-4553
> URL: https://issues.apache.org/jira/browse/TS-4553
> Project: Traffic Server
>  Issue Type: Wish
>  Components: Plugins
>Reporter: David Calavera
> Fix For: sometime
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> I think it would be very interesting to add support for the Brotli 
> compression format: https://github.com/google/brotli
> Since I didn't see any issue opened and went ahead so people can discuss 
> about it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #776: TS-4553: Brotli plugin

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/776
  
@bgaff  We should decide what to do here, land this, land your version, or 
merge ?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #792: TS-4650: cachekey: not thread safe

[zwoop]

Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/792


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4650) cachekey: not thread safe

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4650?focusedWorklogId=25821=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25821
 ]

ASF GitHub Bot logged work on TS-4650:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 18:25
Start Date: 21/Jul/16 18:25
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/792


Issue Time Tracking
---

Worklog Id: (was: 25821)
Time Spent: 1h 50m  (was: 1h 40m)

> cachekey: not thread safe
> -
>
> Key: TS-4650
> URL: https://issues.apache.org/jira/browse/TS-4650
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0
>Reporter: Felicity Tarnell
>Assignee: Felicity Tarnell
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> cachekey's Pattern class is not thread safe; it uses member data to store the 
> result of pcre_exec(), but only one instance is shared between all threads.  
> This causes crashes when two threads access the pcre result at the same time.
> Fix: use automatic storage for the pcre result data.
> PR incoming.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4650) cachekey: not thread safe

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4650:
--
Assignee: Felicity Tarnell

> cachekey: not thread safe
> -
>
> Key: TS-4650
> URL: https://issues.apache.org/jira/browse/TS-4650
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0
>Reporter: Felicity Tarnell
>Assignee: Felicity Tarnell
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> cachekey's Pattern class is not thread safe; it uses member data to store the 
> result of pcre_exec(), but only one instance is shared between all threads.  
> This causes crashes when two threads access the pcre result at the same time.
> Fix: use automatic storage for the pcre result data.
> PR incoming.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4650) cachekey: not thread safe

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4650?focusedWorklogId=25820=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25820
 ]

ASF GitHub Bot logged work on TS-4650:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 18:08
Start Date: 21/Jul/16 18:08
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/792
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/366/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 25820)
Time Spent: 1h 40m  (was: 1.5h)

> cachekey: not thread safe
> -
>
> Key: TS-4650
> URL: https://issues.apache.org/jira/browse/TS-4650
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0
>Reporter: Felicity Tarnell
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> cachekey's Pattern class is not thread safe; it uses member data to store the 
> result of pcre_exec(), but only one instance is shared between all threads.  
> This causes crashes when two threads access the pcre result at the same time.
> Fix: use automatic storage for the pcre result data.
> PR incoming.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #792: TS-4650: cachekey: not thread safe

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/792
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/366/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4650) cachekey: not thread safe

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4650?focusedWorklogId=25819=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25819
 ]

ASF GitHub Bot logged work on TS-4650:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 18:03
Start Date: 21/Jul/16 18:03
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/792
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/469/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 25819)
Time Spent: 1.5h  (was: 1h 20m)

> cachekey: not thread safe
> -
>
> Key: TS-4650
> URL: https://issues.apache.org/jira/browse/TS-4650
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0
>Reporter: Felicity Tarnell
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> cachekey's Pattern class is not thread safe; it uses member data to store the 
> result of pcre_exec(), but only one instance is shared between all threads.  
> This causes crashes when two threads access the pcre result at the same time.
> Fix: use automatic storage for the pcre result data.
> PR incoming.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #792: TS-4650: cachekey: not thread safe

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/792
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/469/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4650) cachekey: not thread safe

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4650?focusedWorklogId=25818=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25818
 ]

ASF GitHub Bot logged work on TS-4650:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 17:52
Start Date: 21/Jul/16 17:52
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/792
  
[approve ci]


Issue Time Tracking
---

Worklog Id: (was: 25818)
Time Spent: 1h 20m  (was: 1h 10m)

> cachekey: not thread safe
> -
>
> Key: TS-4650
> URL: https://issues.apache.org/jira/browse/TS-4650
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0
>Reporter: Felicity Tarnell
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> cachekey's Pattern class is not thread safe; it uses member data to store the 
> result of pcre_exec(), but only one instance is shared between all threads.  
> This causes crashes when two threads access the pcre result at the same time.
> Fix: use automatic storage for the pcre result data.
> PR incoming.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #792: TS-4650: cachekey: not thread safe

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/792
  
[approve ci]


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4683) header_rewrite: warning if you use a hook that predates "remap" in a remap mode

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4683?focusedWorklogId=25817=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25817
 ]

ASF GitHub Bot logged work on TS-4683:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 17:51
Start Date: 21/Jul/16 17:51
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/818


Issue Time Tracking
---

Worklog Id: (was: 25817)
Time Spent: 2h 10m  (was: 2h)

> header_rewrite: warning if you use a hook that predates "remap" in a remap 
> mode
> ---
>
> Key: TS-4683
> URL: https://issues.apache.org/jira/browse/TS-4683
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> It's rather confusing, but since remap happens after several of the hooks 
> that header_rewrite supports (in global mode), we should warn the user that 
> this is a no-op (or maybe even error out).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #818: TS-4683 Adds better error handling on confi...

[zwoop]

Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/818


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4683) header_rewrite: warning if you use a hook that predates "remap" in a remap mode

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4683?focusedWorklogId=25816=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25816
 ]

ASF GitHub Bot logged work on TS-4683:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 17:48
Start Date: 21/Jul/16 17:48
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/818
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/365/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 25816)
Time Spent: 2h  (was: 1h 50m)

> header_rewrite: warning if you use a hook that predates "remap" in a remap 
> mode
> ---
>
> Key: TS-4683
> URL: https://issues.apache.org/jira/browse/TS-4683
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> It's rather confusing, but since remap happens after several of the hooks 
> that header_rewrite supports (in global mode), we should warn the user that 
> this is a no-op (or maybe even error out).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #818: TS-4683 Adds better error handling on config probl...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/818
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/365/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4683) header_rewrite: warning if you use a hook that predates "remap" in a remap mode

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4683?focusedWorklogId=25815=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25815
 ]

ASF GitHub Bot logged work on TS-4683:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 17:43
Start Date: 21/Jul/16 17:43
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/818
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/468/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 25815)
Time Spent: 1h 50m  (was: 1h 40m)

> header_rewrite: warning if you use a hook that predates "remap" in a remap 
> mode
> ---
>
> Key: TS-4683
> URL: https://issues.apache.org/jira/browse/TS-4683
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> It's rather confusing, but since remap happens after several of the hooks 
> that header_rewrite supports (in global mode), we should warn the user that 
> this is a no-op (or maybe even error out).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4692) SRV weights don't work

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4692:
--
Fix Version/s: sometime

> SRV weights don't work
> --
>
> Key: TS-4692
> URL: https://issues.apache.org/jira/browse/TS-4692
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: sometime
>
>
> Although weights are stored in hostdb-- from some black-box testing it seems 
> that the weighting isn't taken into consideration for LB.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4693) SRV priorities don't work

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4693:
--
Issue Type: Improvement  (was: Bug)

> SRV priorities don't work
> -
>
> Key: TS-4693
> URL: https://issues.apache.org/jira/browse/TS-4693
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: sometime
>
>
> Although priorities are stored in hostdb-- from some black-box testing it 
> seems that the priorities aren't taken into consideration for LB.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #818: TS-4683 Adds better error handling on config probl...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/818
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/468/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4693) SRV priorities don't work

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4693:
--
Fix Version/s: sometime

> SRV priorities don't work
> -
>
> Key: TS-4693
> URL: https://issues.apache.org/jira/browse/TS-4693
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: sometime
>
>
> Although priorities are stored in hostdb-- from some black-box testing it 
> seems that the priorities aren't taken into consideration for LB.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4671) Revisit Machine::ip

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4671:
--
Fix Version/s: sometime

> Revisit Machine::ip
> ---
>
> Key: TS-4671
> URL: https://issues.apache.org/jira/browse/TS-4671
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup, Core
>Reporter: James Peach
> Fix For: sometime
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {{Machine::ip}} is used in ICP, logging and loop detection. The latter two 
> use cases can be largely handled by the machine UUID now. Since 
> {{Machine::ip}} doesn't play nicely with multi-homed servers, consider 
> whether we should remove it and deal with the remaining use cases differently?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4692) SRV weights don't work

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4692:
--
Issue Type: Improvement  (was: Bug)

> SRV weights don't work
> --
>
> Key: TS-4692
> URL: https://issues.apache.org/jira/browse/TS-4692
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: sometime
>
>
> Although weights are stored in hostdb-- from some black-box testing it seems 
> that the weighting isn't taken into consideration for LB.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4687) ATS fails to start in a useful way with no config files ( or miniumn set so it starts)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4687:
--
Fix Version/s: sometime

> ATS fails to start in a useful way with no config files ( or miniumn set so 
> it starts)
> --
>
> Key: TS-4687
> URL: https://issues.apache.org/jira/browse/TS-4687
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jason Kenny
> Fix For: sometime
>
>
> While making the new testing system for ATS it was found that even with a 
> empty remap.conf and a storage.conf file, ATS does not start in a useful way. 
> This issue is to help track the goal of getting ATS to a useful running 
> state. Current testing shows this in diags.log(below). The result is that ATS 
> starts and is a brick not accepting anything form what I can tell. This setup 
> is done via using TS_ROOT to redirect ATS to a "clean" space to run in as we 
> would want when running in a test environment
> [Jul 18 16:40:41.946] {0x7fd969a10780} STATUS: opened 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/log/diags.log
> [Jul 18 16:40:41.946] {0x7fd969a10780} NOTE:  (reconfigure_diags)> updated diags config
> [Jul 18 16:40:41.947] Server {0x7fd969a10780} WARNING:  (Machine)> Unable to determine local host 'DESKTOP-9TV9KQF' address 
> information - Invalid argument
> [Jul 18 16:40:41.950] Server {0x7fd969a10780} NOTE:  
> cache clustering disabled
> [Jul 18 16:40:41.973] Server {0x7fd969a10780} ERROR:  (readIntoBuffer)> [CacheControl] Can not open 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/cache.config
>  file : No such file or directory
> [Jul 18 16:40:41.973] Server {0x7fd969a10780} NOTE:  (reconfigure)> ip_allow.config updated, reloading
> [Jul 18 16:40:41.973] Server {0x7fd969a10780} ERROR:  (readIntoBuffer)> IpAllow Can not open 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ip_allow.config
>  file : No such file or directory
> [Jul 18 16:40:41.973] Server {0x7fd969a10780} WARNING:  (BuildTable)> IpAllow Failed to read 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ip_allow.config.
>  All IP Addresses will be blocked
> [Jul 18 16:40:41.974] Server {0x7fd969a10780} ERROR:  (readIntoBuffer)> [ParentSelection] Can not open 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/parent.config
>  file : No such file or directory
> [Jul 18 16:40:41.979] Server {0x7fd969a10780} WARNING:  (RecSignalWarning)> configuration changed: [hostdb.config] : reinitializing 
> database
> [Jul 18 16:40:41.979] Server {0x7fd969a10780} NOTE:  
> reconfiguring host database
> [Jul 18 16:40:42.025] Server {0x7fd969a10780} WARNING:  (ClusterMachine)> unable to DNS DESKTOP-9TV9KQF: 1
> [Jul 18 16:40:42.027] Server {0x7fd969a10780} NOTE:  (init)> cache clustering disabled
> [Jul 18 16:40:42.029] Server {0x7fd969a10780} NOTE:  (init_when_enabled)> logging initialized[3], logging_mode = 3
> [Jul 18 16:40:42.049] Server {0x7fd969a10780} NOTE:  (read_xml_log_config)> Error parsing log config file 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/logs_xml.config;
>  ensure that it is XML-based
> [Jul 18 16:40:42.049] Server {0x7fd969a10780} WARNING:  (plugin_init)> unable to open plugin config file 
> '/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/plugin.config':
>  2, No such file or directory
> [Jul 18 16:40:42.051] Server {0x7fd969a10780} NOTE:  (SSLParseCertificateConfiguration)> loading SSL certificate configuration 
> from 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ssl_multicert.config
> [Jul 18 16:40:42.051] Server {0x7fd969a10780} ERROR:  (readIntoBuffer)> SSLParseCertificateConfiguration Can not open 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ssl_multicert.config
>  file : No such file or directory
> [Jul 18 16:40:42.051] Server {0x7fd969a10780} ERROR:  (SSLParseCertificateConfiguration)> failed to read SSL certificate 
> configuration from 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ssl_multicert.config
> [Jul 18 16:40:42.052] Server {0x7fd969a10780} ERROR:  (readIntoBuffer)> [CacheVolition] Can not open 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/volume.config
>  file : No such file or directory
> [Jul 18 16:40:42.053] Server {0x7fd969a10780} WARNING:  (read_config_file)> Cannot read the config file: 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/volume.config
> [Jul 18 16:40:42.060] Server {0x7fd965900700} WARNING:  (openStart)> disk header different for disk 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/var/trafficserver/cache.db:
>  clearing the disk
> [Jul 18 16:40:42.060] 

[jira] [Updated] (TS-4687) ATS fails to start in a useful way with no config files ( or miniumn set so it starts)

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4687:
--
Assignee: Jason Kenny

> ATS fails to start in a useful way with no config files ( or miniumn set so 
> it starts)
> --
>
> Key: TS-4687
> URL: https://issues.apache.org/jira/browse/TS-4687
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jason Kenny
>Assignee: Jason Kenny
> Fix For: sometime
>
>
> While making the new testing system for ATS it was found that even with a 
> empty remap.conf and a storage.conf file, ATS does not start in a useful way. 
> This issue is to help track the goal of getting ATS to a useful running 
> state. Current testing shows this in diags.log(below). The result is that ATS 
> starts and is a brick not accepting anything form what I can tell. This setup 
> is done via using TS_ROOT to redirect ATS to a "clean" space to run in as we 
> would want when running in a test environment
> [Jul 18 16:40:41.946] {0x7fd969a10780} STATUS: opened 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/log/diags.log
> [Jul 18 16:40:41.946] {0x7fd969a10780} NOTE:  (reconfigure_diags)> updated diags config
> [Jul 18 16:40:41.947] Server {0x7fd969a10780} WARNING:  (Machine)> Unable to determine local host 'DESKTOP-9TV9KQF' address 
> information - Invalid argument
> [Jul 18 16:40:41.950] Server {0x7fd969a10780} NOTE:  
> cache clustering disabled
> [Jul 18 16:40:41.973] Server {0x7fd969a10780} ERROR:  (readIntoBuffer)> [CacheControl] Can not open 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/cache.config
>  file : No such file or directory
> [Jul 18 16:40:41.973] Server {0x7fd969a10780} NOTE:  (reconfigure)> ip_allow.config updated, reloading
> [Jul 18 16:40:41.973] Server {0x7fd969a10780} ERROR:  (readIntoBuffer)> IpAllow Can not open 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ip_allow.config
>  file : No such file or directory
> [Jul 18 16:40:41.973] Server {0x7fd969a10780} WARNING:  (BuildTable)> IpAllow Failed to read 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ip_allow.config.
>  All IP Addresses will be blocked
> [Jul 18 16:40:41.974] Server {0x7fd969a10780} ERROR:  (readIntoBuffer)> [ParentSelection] Can not open 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/parent.config
>  file : No such file or directory
> [Jul 18 16:40:41.979] Server {0x7fd969a10780} WARNING:  (RecSignalWarning)> configuration changed: [hostdb.config] : reinitializing 
> database
> [Jul 18 16:40:41.979] Server {0x7fd969a10780} NOTE:  
> reconfiguring host database
> [Jul 18 16:40:42.025] Server {0x7fd969a10780} WARNING:  (ClusterMachine)> unable to DNS DESKTOP-9TV9KQF: 1
> [Jul 18 16:40:42.027] Server {0x7fd969a10780} NOTE:  (init)> cache clustering disabled
> [Jul 18 16:40:42.029] Server {0x7fd969a10780} NOTE:  (init_when_enabled)> logging initialized[3], logging_mode = 3
> [Jul 18 16:40:42.049] Server {0x7fd969a10780} NOTE:  (read_xml_log_config)> Error parsing log config file 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/logs_xml.config;
>  ensure that it is XML-based
> [Jul 18 16:40:42.049] Server {0x7fd969a10780} WARNING:  (plugin_init)> unable to open plugin config file 
> '/mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/plugin.config':
>  2, No such file or directory
> [Jul 18 16:40:42.051] Server {0x7fd969a10780} NOTE:  (SSLParseCertificateConfiguration)> loading SSL certificate configuration 
> from 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ssl_multicert.config
> [Jul 18 16:40:42.051] Server {0x7fd969a10780} ERROR:  (readIntoBuffer)> SSLParseCertificateConfiguration Can not open 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ssl_multicert.config
>  file : No such file or directory
> [Jul 18 16:40:42.051] Server {0x7fd969a10780} ERROR:  (SSLParseCertificateConfiguration)> failed to read SSL certificate 
> configuration from 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/ssl_multicert.config
> [Jul 18 16:40:42.052] Server {0x7fd969a10780} ERROR:  (readIntoBuffer)> [CacheVolition] Can not open 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/volume.config
>  file : No such file or directory
> [Jul 18 16:40:42.053] Server {0x7fd969a10780} WARNING:  (read_config_file)> Cannot read the config file: 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/config/volume.config
> [Jul 18 16:40:42.060] Server {0x7fd965900700} WARNING:  (openStart)> disk header different for disk 
> /mnt/c/Users/drago/code/tests/tester/_sandbox/copy_config/ts1/var/trafficserver/cache.db:
>  clearing 

[jira] [Updated] (TS-4669) HttpSM should use hsm_release_assert consistently

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4669:
--
Issue Type: Improvement  (was: Bug)

> HttpSM should use hsm_release_assert consistently
> -
>
> Key: TS-4669
> URL: https://issues.apache.org/jira/browse/TS-4669
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup, Core
>Reporter: James Peach
> Fix For: sometime
>
>
> {{hsm_release_assert}} dumps the internal state of the {{HttpSM}} object. 
> Everywhere there is a {{ink_release_assert}}, we really ought to be using 
> {{hsm_release_assert}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4679) Allow ssl_multicert line to have no ssl_cert_name specified

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4679:
--
Issue Type: Improvement  (was: Bug)

> Allow ssl_multicert line to have no ssl_cert_name specified
> ---
>
> Key: TS-4679
> URL: https://issues.apache.org/jira/browse/TS-4679
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> It is reasonable to not specify a ssl_cert_name if the action=tunnel is 
> specified.  As the code currently stands you must enter a dummy ssl_cert_name 
> even in the blind tunnel case because of sanity checks in the ssl_multicert 
> loading code.
> The following should be an allowable entry
> {code}
> dest_ip=10.10.10.10 action=tunnel
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4671) Revisit Machine::ip

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4671?focusedWorklogId=25813=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25813
 ]

ASF GitHub Bot logged work on TS-4671:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 17:40
Start Date: 21/Jul/16 17:40
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/810
  
@shinrich  I think you linked this to the wrong Jira number? It should be 
TS-4679, right ?


Issue Time Tracking
---

Worklog Id: (was: 25813)
Time Spent: 50m  (was: 40m)

> Revisit Machine::ip
> ---
>
> Key: TS-4671
> URL: https://issues.apache.org/jira/browse/TS-4671
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup, Core
>Reporter: James Peach
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {{Machine::ip}} is used in ICP, logging and loop detection. The latter two 
> use cases can be largely handled by the machine UUID now. Since 
> {{Machine::ip}} doesn't play nicely with multi-homed servers, consider 
> whether we should remove it and deal with the remaining use cases differently?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #810: TS-4671: Allow multicert line with action but no s...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/810
  
@shinrich  I think you linked this to the wrong Jira number? It should be 
TS-4679, right ?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4690) Logging to ascii_pipe fails in 6.2.x

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4690:
--
Backport to Version: 6.2.1

> Logging to ascii_pipe fails in 6.2.x
> 
>
> Key: TS-4690
> URL: https://issues.apache.org/jira/browse/TS-4690
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Haritha Haridas
>  Labels: regression
> Fix For: 7.0.0
>
>
> Seeing the following stack trace when trying to log to an ascii_pipe in the 
> new code :
> {code}
> /lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
> /lib64/libc.so.6(gsignal+0x35)[0x2ba4ac134625]
> /lib64/libc.so.6(abort+0x175)[0x2ba4ac135e05]
> ..//lib64/libtsutil.so.6(signal_crash_handler(int, siginfo*, 
> void*)+0x54)[0x2ba4aa053184]
> ../bin/traffic_server(crash_logger_invoke(int, siginfo*, 
> void*)+0x8e)[0x4af11e]
> /lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
> ../bin/traffic_server(LogFile::preproc_and_try_delete(LogBuffer*)+0x3f)[0x5cbeef]
> ../bin/traffic_server(LogBufferManager::preproc_buffers(LogBufferSink*)+0xb3)[0x5d5ba3]
> ../bin/traffic_server(LogObjectManager::preproc_buffers(int)+0x53)[0x5d7a33]
> ../bin/traffic_server(Log::preproc_thread_main(void*)+0x8f)[0x5b644f]
> ../bin/traffic_server(LoggingPreprocContinuation::mainEvent(int, 
> void*)+0xd)[0x5bb4cd]
> ../bin/traffic_server(EThread::execute()+0x83)[0x6fc4c3]
> ../bin/traffic_server[0x6fb9ea]
> /lib64/libpthread.so.0(+0x7aa1)[0x2ba4ab4f1aa1]
> /lib64/libc.so.6(clone+0x6d)[0x2ba4ac1ea93d]
> traffic_server - STACK TRACE:
> {code}
> seems to crash at the line   if (!m_log->m_start_time) and from the 
> constructor looks like it will be NULL for the pipes:
> {code}
>  if (m_file_format != LOG_FILE_PIPE) {
> m_log = new BaseLogFile(name, m_signature);
> m_log->set_hostname(Machine::instance()->hostname);
>   } else {
> m_log = NULL;
>   }
> {code}
> im still unsure how this wasn in a problem in 5.3.x, but im seeing this only 
> in the newest code 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4679) Allow ssl_multicert line to have no ssl_cert_name specified

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4679:
--
Fix Version/s: 7.0.0

> Allow ssl_multicert line to have no ssl_cert_name specified
> ---
>
> Key: TS-4679
> URL: https://issues.apache.org/jira/browse/TS-4679
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> It is reasonable to not specify a ssl_cert_name if the action=tunnel is 
> specified.  As the code currently stands you must enter a dummy ssl_cert_name 
> even in the blind tunnel case because of sanity checks in the ssl_multicert 
> loading code.
> The following should be an allowable entry
> {code}
> dest_ip=10.10.10.10 action=tunnel
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4690) Logging to ascii_pipe fails in 6.2.x

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4690:
---

marking this as a candidate for 6.2.1 back port for now.

> Logging to ascii_pipe fails in 6.2.x
> 
>
> Key: TS-4690
> URL: https://issues.apache.org/jira/browse/TS-4690
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Haritha Haridas
>  Labels: regression
> Fix For: 7.0.0
>
>
> Seeing the following stack trace when trying to log to an ascii_pipe in the 
> new code :
> {code}
> /lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
> /lib64/libc.so.6(gsignal+0x35)[0x2ba4ac134625]
> /lib64/libc.so.6(abort+0x175)[0x2ba4ac135e05]
> ..//lib64/libtsutil.so.6(signal_crash_handler(int, siginfo*, 
> void*)+0x54)[0x2ba4aa053184]
> ../bin/traffic_server(crash_logger_invoke(int, siginfo*, 
> void*)+0x8e)[0x4af11e]
> /lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
> ../bin/traffic_server(LogFile::preproc_and_try_delete(LogBuffer*)+0x3f)[0x5cbeef]
> ../bin/traffic_server(LogBufferManager::preproc_buffers(LogBufferSink*)+0xb3)[0x5d5ba3]
> ../bin/traffic_server(LogObjectManager::preproc_buffers(int)+0x53)[0x5d7a33]
> ../bin/traffic_server(Log::preproc_thread_main(void*)+0x8f)[0x5b644f]
> ../bin/traffic_server(LoggingPreprocContinuation::mainEvent(int, 
> void*)+0xd)[0x5bb4cd]
> ../bin/traffic_server(EThread::execute()+0x83)[0x6fc4c3]
> ../bin/traffic_server[0x6fb9ea]
> /lib64/libpthread.so.0(+0x7aa1)[0x2ba4ab4f1aa1]
> /lib64/libc.so.6(clone+0x6d)[0x2ba4ac1ea93d]
> traffic_server - STACK TRACE:
> {code}
> seems to crash at the line   if (!m_log->m_start_time) and from the 
> constructor looks like it will be NULL for the pipes:
> {code}
>  if (m_file_format != LOG_FILE_PIPE) {
> m_log = new BaseLogFile(name, m_signature);
> m_log->set_hostname(Machine::instance()->hostname);
>   } else {
> m_log = NULL;
>   }
> {code}
> im still unsure how this wasn in a problem in 5.3.x, but im seeing this only 
> in the newest code 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4690) Logging to ascii_pipe fails in 6.2.x

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4690:
--
Labels: regression  (was: )

> Logging to ascii_pipe fails in 6.2.x
> 
>
> Key: TS-4690
> URL: https://issues.apache.org/jira/browse/TS-4690
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Haritha Haridas
>  Labels: regression
> Fix For: 7.0.0
>
>
> Seeing the following stack trace when trying to log to an ascii_pipe in the 
> new code :
> {code}
> /lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
> /lib64/libc.so.6(gsignal+0x35)[0x2ba4ac134625]
> /lib64/libc.so.6(abort+0x175)[0x2ba4ac135e05]
> ..//lib64/libtsutil.so.6(signal_crash_handler(int, siginfo*, 
> void*)+0x54)[0x2ba4aa053184]
> ../bin/traffic_server(crash_logger_invoke(int, siginfo*, 
> void*)+0x8e)[0x4af11e]
> /lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
> ../bin/traffic_server(LogFile::preproc_and_try_delete(LogBuffer*)+0x3f)[0x5cbeef]
> ../bin/traffic_server(LogBufferManager::preproc_buffers(LogBufferSink*)+0xb3)[0x5d5ba3]
> ../bin/traffic_server(LogObjectManager::preproc_buffers(int)+0x53)[0x5d7a33]
> ../bin/traffic_server(Log::preproc_thread_main(void*)+0x8f)[0x5b644f]
> ../bin/traffic_server(LoggingPreprocContinuation::mainEvent(int, 
> void*)+0xd)[0x5bb4cd]
> ../bin/traffic_server(EThread::execute()+0x83)[0x6fc4c3]
> ../bin/traffic_server[0x6fb9ea]
> /lib64/libpthread.so.0(+0x7aa1)[0x2ba4ab4f1aa1]
> /lib64/libc.so.6(clone+0x6d)[0x2ba4ac1ea93d]
> traffic_server - STACK TRACE:
> {code}
> seems to crash at the line   if (!m_log->m_start_time) and from the 
> constructor looks like it will be NULL for the pipes:
> {code}
>  if (m_file_format != LOG_FILE_PIPE) {
> m_log = new BaseLogFile(name, m_signature);
> m_log->set_hostname(Machine::instance()->hostname);
>   } else {
> m_log = NULL;
>   }
> {code}
> im still unsure how this wasn in a problem in 5.3.x, but im seeing this only 
> in the newest code 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4690) Logging to ascii_pipe fails in 6.2.x

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4690:
--
Description: 
Seeing the following stack trace when trying to log to an ascii_pipe in the new 
code :

{code}
/lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
/lib64/libc.so.6(gsignal+0x35)[0x2ba4ac134625]
/lib64/libc.so.6(abort+0x175)[0x2ba4ac135e05]
..//lib64/libtsutil.so.6(signal_crash_handler(int, siginfo*, 
void*)+0x54)[0x2ba4aa053184]
../bin/traffic_server(crash_logger_invoke(int, siginfo*, void*)+0x8e)[0x4af11e]
/lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
../bin/traffic_server(LogFile::preproc_and_try_delete(LogBuffer*)+0x3f)[0x5cbeef]
../bin/traffic_server(LogBufferManager::preproc_buffers(LogBufferSink*)+0xb3)[0x5d5ba3]
../bin/traffic_server(LogObjectManager::preproc_buffers(int)+0x53)[0x5d7a33]
../bin/traffic_server(Log::preproc_thread_main(void*)+0x8f)[0x5b644f]
../bin/traffic_server(LoggingPreprocContinuation::mainEvent(int, 
void*)+0xd)[0x5bb4cd]
../bin/traffic_server(EThread::execute()+0x83)[0x6fc4c3]
../bin/traffic_server[0x6fb9ea]
/lib64/libpthread.so.0(+0x7aa1)[0x2ba4ab4f1aa1]
/lib64/libc.so.6(clone+0x6d)[0x2ba4ac1ea93d]
traffic_server - STACK TRACE:
{code}

seems to crash at the line   if (!m_log->m_start_time) and from the constructor 
looks like it will be NULL for the pipes:

{code}
 if (m_file_format != LOG_FILE_PIPE) {
m_log = new BaseLogFile(name, m_signature);
m_log->set_hostname(Machine::instance()->hostname);
  } else {
m_log = NULL;
  }
{code}

im still unsure how this wasn in a problem in 5.3.x, but im seeing this only in 
the newest code 


  was:
Seeing the following stack trace when trying to log to an ascii_pipe in the new 
code :


/lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
/lib64/libc.so.6(gsignal+0x35)[0x2ba4ac134625]
/lib64/libc.so.6(abort+0x175)[0x2ba4ac135e05]
..//lib64/libtsutil.so.6(_Z20signal_crash_handleriP7siginfoPv+0x54)[0x2ba4aa053184]
../bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x8e)[0x4af11e]
/lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
../bin/traffic_server(_ZN7LogFile22preproc_and_try_deleteEP9LogBuffer+0x3f)[0x5cbeef]
../bin/traffic_server(_ZN16LogBufferManager15preproc_buffersEP13LogBufferSink+0xb3)[0x5d5ba3]
../bin/traffic_server(_ZN16LogObjectManager15preproc_buffersEi+0x53)[0x5d7a33]
../bin/traffic_server(_ZN3Log19preproc_thread_mainEPv+0x8f)[0x5b644f]
../bin/traffic_server(_ZN26LoggingPreprocContinuation9mainEventEiPv+0xd)[0x5bb4cd]
../bin/traffic_server(_ZN7EThread7executeEv+0x83)[0x6fc4c3]
../bin/traffic_server[0x6fb9ea]
/lib64/libpthread.so.0(+0x7aa1)[0x2ba4ab4f1aa1]
/lib64/libc.so.6(clone+0x6d)[0x2ba4ac1ea93d]
traffic_server - STACK TRACE:


seems to crash at the line   if (!m_log->m_start_time)

and from the constructor looks like it will be NULL for the pipes:
 if (m_file_format != LOG_FILE_PIPE) {
m_log = new BaseLogFile(name, m_signature);
m_log->set_hostname(Machine::instance()->hostname);
  } else {
m_log = NULL;
  }

im still unsure how this wasn in a problem in 5.3.x, but im seeing this only in 
the newest code 



> Logging to ascii_pipe fails in 6.2.x
> 
>
> Key: TS-4690
> URL: https://issues.apache.org/jira/browse/TS-4690
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Haritha Haridas
> Fix For: 7.0.0
>
>
> Seeing the following stack trace when trying to log to an ascii_pipe in the 
> new code :
> {code}
> /lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
> /lib64/libc.so.6(gsignal+0x35)[0x2ba4ac134625]
> /lib64/libc.so.6(abort+0x175)[0x2ba4ac135e05]
> ..//lib64/libtsutil.so.6(signal_crash_handler(int, siginfo*, 
> void*)+0x54)[0x2ba4aa053184]
> ../bin/traffic_server(crash_logger_invoke(int, siginfo*, 
> void*)+0x8e)[0x4af11e]
> /lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
> ../bin/traffic_server(LogFile::preproc_and_try_delete(LogBuffer*)+0x3f)[0x5cbeef]
> ../bin/traffic_server(LogBufferManager::preproc_buffers(LogBufferSink*)+0xb3)[0x5d5ba3]
> ../bin/traffic_server(LogObjectManager::preproc_buffers(int)+0x53)[0x5d7a33]
> ../bin/traffic_server(Log::preproc_thread_main(void*)+0x8f)[0x5b644f]
> ../bin/traffic_server(LoggingPreprocContinuation::mainEvent(int, 
> void*)+0xd)[0x5bb4cd]
> ../bin/traffic_server(EThread::execute()+0x83)[0x6fc4c3]
> ../bin/traffic_server[0x6fb9ea]
> /lib64/libpthread.so.0(+0x7aa1)[0x2ba4ab4f1aa1]
> /lib64/libc.so.6(clone+0x6d)[0x2ba4ac1ea93d]
> traffic_server - STACK TRACE:
> {code}
> seems to crash at the line   if (!m_log->m_start_time) and from the 
> constructor looks like it will be NULL for the pipes:
> {code}
>  if (m_file_format != LOG_FILE_PIPE) {
> m_log = new BaseLogFile(name, m_signature);
> m_log->set_hostname(Machine::instance()->hostname);
>   } else {
> m_log = NULL;
>   }
> {code}
> im still 

[jira] [Updated] (TS-4690) Logging to ascii_pipe fails in 6.2.x

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4690:
--
Fix Version/s: 7.0.0

> Logging to ascii_pipe fails in 6.2.x
> 
>
> Key: TS-4690
> URL: https://issues.apache.org/jira/browse/TS-4690
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Haritha Haridas
> Fix For: 7.0.0
>
>
> Seeing the following stack trace when trying to log to an ascii_pipe in the 
> new code :
> {code}
> /lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
> /lib64/libc.so.6(gsignal+0x35)[0x2ba4ac134625]
> /lib64/libc.so.6(abort+0x175)[0x2ba4ac135e05]
> ..//lib64/libtsutil.so.6(signal_crash_handler(int, siginfo*, 
> void*)+0x54)[0x2ba4aa053184]
> ../bin/traffic_server(crash_logger_invoke(int, siginfo*, 
> void*)+0x8e)[0x4af11e]
> /lib64/libpthread.so.0(+0xf7e0)[0x2ba4ab4f97e0]
> ../bin/traffic_server(LogFile::preproc_and_try_delete(LogBuffer*)+0x3f)[0x5cbeef]
> ../bin/traffic_server(LogBufferManager::preproc_buffers(LogBufferSink*)+0xb3)[0x5d5ba3]
> ../bin/traffic_server(LogObjectManager::preproc_buffers(int)+0x53)[0x5d7a33]
> ../bin/traffic_server(Log::preproc_thread_main(void*)+0x8f)[0x5b644f]
> ../bin/traffic_server(LoggingPreprocContinuation::mainEvent(int, 
> void*)+0xd)[0x5bb4cd]
> ../bin/traffic_server(EThread::execute()+0x83)[0x6fc4c3]
> ../bin/traffic_server[0x6fb9ea]
> /lib64/libpthread.so.0(+0x7aa1)[0x2ba4ab4f1aa1]
> /lib64/libc.so.6(clone+0x6d)[0x2ba4ac1ea93d]
> traffic_server - STACK TRACE:
> {code}
> seems to crash at the line   if (!m_log->m_start_time) and from the 
> constructor looks like it will be NULL for the pipes:
> {code}
>  if (m_file_format != LOG_FILE_PIPE) {
> m_log = new BaseLogFile(name, m_signature);
> m_log->set_hostname(Machine::instance()->hostname);
>   } else {
> m_log = NULL;
>   }
> {code}
> im still unsure how this wasn in a problem in 5.3.x, but im seeing this only 
> in the newest code 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4682) HostDB caching of SOA responses doesn't honor TTL

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4682:
--
Fix Version/s: sometime

> HostDB caching of SOA responses doesn't honor TTL
> -
>
> Key: TS-4682
> URL: https://issues.apache.org/jira/browse/TS-4682
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: sometime
>
>
> HostDB categorizes all DNS responses as "failed" and "not failed", "failed" 
> being any response that doesn't have an answer to the question sent. This 
> means that SOA responses are considered "failed" and therefore the response 
> isn't cached for the TTL defined in the SOA record. "failed" responses TTL 
> are configured by "proxy.config.hostdb.fail.timeout" (default to 0). With the 
> value set to default the record will be immediately considered stale and 
> require a lookup. To fix this we should have the "failed" response honor the 
> TTL if the response had a TTL defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4685) Strict round robin isn't followed for KA connections

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4685:
--
Fix Version/s: 7.0.0

> Strict round robin isn't followed for KA connections
> 
>
> Key: TS-4685
> URL: https://issues.apache.org/jira/browse/TS-4685
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>
> ATS doesn't honor "strict round robin" for KA connections-- it first re-uses 
> available connections then creates new connections following the origin 
> selection algo (rr, etc.). This effectively makes it "least connections" 
> which is almost the opposite of what was configured. 
> We should make ATS honor the selection we've configured it to use-- and then 
> it can KA with that real selection.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4670) Document SSL lifecycle hooks

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4670:
---

Giving to [~jsime], feel free to take it back if you are working on this.

> Document SSL lifecycle hooks
> 
>
> Key: TS-4670
> URL: https://issues.apache.org/jira/browse/TS-4670
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: James Peach
>Assignee: Jon Sime
> Fix For: Docs
>
>
> The lifecycle hooks are documented in {{TSLifecycleHookAdd.en.rst}}. There 
> are a few undocumented hooks:
> * TS_LIFECYCLE_SERVER_SSL_CTX_INITIALIZED_HOOK
> * TS_LIFECYCLE_CLIENT_SSL_CTX_INITIALIZED_HOOK



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4670) Document SSL lifecycle hooks

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4670:
--
Fix Version/s: Docs

> Document SSL lifecycle hooks
> 
>
> Key: TS-4670
> URL: https://issues.apache.org/jira/browse/TS-4670
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: James Peach
>Assignee: Jon Sime
> Fix For: Docs
>
>
> The lifecycle hooks are documented in {{TSLifecycleHookAdd.en.rst}}. There 
> are a few undocumented hooks:
> * TS_LIFECYCLE_SERVER_SSL_CTX_INITIALIZED_HOOK
> * TS_LIFECYCLE_CLIENT_SSL_CTX_INITIALIZED_HOOK



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4680) Not thread safe initialization in TS*DirGet() functions

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4680:
--
Assignee: Pavlo Yatsukhnenko

> Not thread safe initialization in TS*DirGet() functions
> ---
>
> Key: TS-4680
> URL: https://issues.apache.org/jira/browse/TS-4680
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Pavlo Yatsukhnenko
>Assignee: Pavlo Yatsukhnenko
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-4680) Not thread safe initialization in TS*DirGet() functions

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-4680.
---
Resolution: Fixed

> Not thread safe initialization in TS*DirGet() functions
> ---
>
> Key: TS-4680
> URL: https://issues.apache.org/jira/browse/TS-4680
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Pavlo Yatsukhnenko
>Assignee: Pavlo Yatsukhnenko
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4680) Not thread safe initialization in TS*DirGet() functions

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4680:
--
Fix Version/s: 7.0.0

> Not thread safe initialization in TS*DirGet() functions
> ---
>
> Key: TS-4680
> URL: https://issues.apache.org/jira/browse/TS-4680
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Pavlo Yatsukhnenko
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4669) HttpSM should use hsm_release_assert consistently

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4669:
--
Fix Version/s: sometime

> HttpSM should use hsm_release_assert consistently
> -
>
> Key: TS-4669
> URL: https://issues.apache.org/jira/browse/TS-4669
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, Core
>Reporter: James Peach
> Fix For: sometime
>
>
> {{hsm_release_assert}} dumps the internal state of the {{HttpSM}} object. 
> Everywhere there is a {{ink_release_assert}}, we really ought to be using 
> {{hsm_release_assert}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4670) Document SSL lifecycle hooks

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4670:
--
Assignee: Jon Sime

> Document SSL lifecycle hooks
> 
>
> Key: TS-4670
> URL: https://issues.apache.org/jira/browse/TS-4670
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: James Peach
>Assignee: Jon Sime
>
> The lifecycle hooks are documented in {{TSLifecycleHookAdd.en.rst}}. There 
> are a few undocumented hooks:
> * TS_LIFECYCLE_SERVER_SSL_CTX_INITIALIZED_HOOK
> * TS_LIFECYCLE_CLIENT_SSL_CTX_INITIALIZED_HOOK



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #815: TS-4680: thread safe initialization in TS*D...

[zwoop]

Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/815


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4680) Not thread safe initialization in TS*DirGet() functions

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4680?focusedWorklogId=25812=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25812
 ]

ASF GitHub Bot logged work on TS-4680:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 17:35
Start Date: 21/Jul/16 17:35
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

https://github.com/apache/trafficserver/pull/815


Issue Time Tracking
---

Worklog Id: (was: 25812)
Time Spent: 2h 10m  (was: 2h)

> Not thread safe initialization in TS*DirGet() functions
> ---
>
> Key: TS-4680
> URL: https://issues.apache.org/jira/browse/TS-4680
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Pavlo Yatsukhnenko
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4683) header_rewrite: warning if you use a hook that predates "remap" in a remap mode

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4683?focusedWorklogId=25811=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25811
 ]

ASF GitHub Bot logged work on TS-4683:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 17:32
Start Date: 21/Jul/16 17:32
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/818
  
Made the changes per Gancho's suggestions.


Issue Time Tracking
---

Worklog Id: (was: 25811)
Time Spent: 1h 40m  (was: 1.5h)

> header_rewrite: warning if you use a hook that predates "remap" in a remap 
> mode
> ---
>
> Key: TS-4683
> URL: https://issues.apache.org/jira/browse/TS-4683
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> It's rather confusing, but since remap happens after several of the hooks 
> that header_rewrite supports (in global mode), we should warn the user that 
> this is a no-op (or maybe even error out).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #818: TS-4683 Adds better error handling on config probl...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/818
  
Made the changes per Gancho's suggestions.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4311) Remove SPDY protocol support

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4311?focusedWorklogId=25810=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25810
 ]

ASF GitHub Bot logged work on TS-4311:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 17:30
Start Date: 21/Jul/16 17:30
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/819#discussion_r71749709
  
--- Diff: lib/ts/ink_config.h.in ---
@@ -127,5 +127,6 @@
 #define TS_BUILD_CANONICAL_HOST "@host@"
 
 #define TS_BUILD_DEFAULT_LOOPBACK_IFACE "@default_loopback_iface@"
+/* clang-format off */
--- End diff --

Thanks, yeah, should be on (copy-paste failure). So yeah, we don't 
necessarily need this, however, I ended up screwing this up myself since I 
edited this file, and wanted to make sure clang-format didn't change anything. 
And then of course, the entire file gets foobared. I think it's a good measure 
to prevent zwoop from screwing it up again.


Issue Time Tracking
---

Worklog Id: (was: 25810)
Time Spent: 50m  (was: 40m)

> Remove SPDY protocol support
> 
>
> Key: TS-4311
> URL: https://issues.apache.org/jira/browse/TS-4311
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> With the high adoption rate of HTTP/2 and support for HTTP/2 in ATS since 
> 5.3.0 (experimental) and 6.0.0 (stable) it would be a good time to remove 
> SPDY in ATS 7.0.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #819: TS-4311 Removes support for SPDY completely

[zwoop]

Github user zwoop commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/819#discussion_r71749709
  
--- Diff: lib/ts/ink_config.h.in ---
@@ -127,5 +127,6 @@
 #define TS_BUILD_CANONICAL_HOST "@host@"
 
 #define TS_BUILD_DEFAULT_LOOPBACK_IFACE "@default_loopback_iface@"
+/* clang-format off */
--- End diff --

Thanks, yeah, should be on (copy-paste failure). So yeah, we don't 
necessarily need this, however, I ended up screwing this up myself since I 
edited this file, and wanted to make sure clang-format didn't change anything. 
And then of course, the entire file gets foobared. I think it's a good measure 
to prevent zwoop from screwing it up again.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Assigned] (TS-4692) SRV weights don't work

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4692:
--

Assignee: Thomas Jackson

> SRV weights don't work
> --
>
> Key: TS-4692
> URL: https://issues.apache.org/jira/browse/TS-4692
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> Although weights are stored in hostdb-- from some black-box testing it seems 
> that the weighting isn't taken into consideration for LB.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4693) SRV priorities don't work

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4693:
--

Assignee: Thomas Jackson

> SRV priorities don't work
> -
>
> Key: TS-4693
> URL: https://issues.apache.org/jira/browse/TS-4693
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> Although priorities are stored in hostdb-- from some black-box testing it 
> seems that the priorities aren't taken into consideration for LB.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4693) SRV priorities don't work

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4693:
--

 Summary: SRV priorities don't work
 Key: TS-4693
 URL: https://issues.apache.org/jira/browse/TS-4693
 Project: Traffic Server
  Issue Type: Bug
  Components: HostDB
Reporter: Thomas Jackson


Although priorities are stored in hostdb-- from some black-box testing it seems 
that the priorities aren't taken into consideration for LB.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4692) SRV weights don't work

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4692:
--

 Summary: SRV weights don't work
 Key: TS-4692
 URL: https://issues.apache.org/jira/browse/TS-4692
 Project: Traffic Server
  Issue Type: Bug
  Components: HostDB
Reporter: Thomas Jackson


Although weights are stored in hostdb-- from some black-box testing it seems 
that the weighting isn't taken into consideration for LB.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-4615) Dynamic SRV lookups

[Thomas Jackson (JIRA)]

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

Thomas Jackson resolved TS-4615.

Resolution: Fixed

> Dynamic SRV lookups
> ---
>
> Key: TS-4615
> URL: https://issues.apache.org/jira/browse/TS-4615
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Right now all SRV lookups are `_http._tcp.NAME`, it'd be better if we 
> switched between the various protocols we support (http/https/ws/wss).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work started] (TS-4615) Dynamic SRV lookups

[Thomas Jackson (JIRA)]

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

Work on TS-4615 started by Thomas Jackson.
--
> Dynamic SRV lookups
> ---
>
> Key: TS-4615
> URL: https://issues.apache.org/jira/browse/TS-4615
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Right now all SRV lookups are `_http._tcp.NAME`, it'd be better if we 
> switched between the various protocols we support (http/https/ws/wss).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4615) Dynamic SRV lookups

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4615?focusedWorklogId=25808=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25808
 ]

ASF GitHub Bot logged work on TS-4615:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 16:05
Start Date: 21/Jul/16 16:05
Worklog Time Spent: 10m 
  Work Description: Github user jacksontj closed the pull request at:

https://github.com/apache/trafficserver/pull/768


Issue Time Tracking
---

Worklog Id: (was: 25808)
Time Spent: 40m  (was: 0.5h)

> Dynamic SRV lookups
> ---
>
> Key: TS-4615
> URL: https://issues.apache.org/jira/browse/TS-4615
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Right now all SRV lookups are `_http._tcp.NAME`, it'd be better if we 
> switched between the various protocols we support (http/https/ws/wss).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4683) header_rewrite: warning if you use a hook that predates "remap" in a remap mode

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4683?focusedWorklogId=25809=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-25809
 ]

ASF GitHub Bot logged work on TS-4683:
--

Author: ASF GitHub Bot
Created on: 21/Jul/16 16:06
Start Date: 21/Jul/16 16:06
Worklog Time Spent: 10m 
  Work Description: Github user gtenev commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/818#discussion_r71735386
  
--- Diff: plugins/header_rewrite/ruleset.cc ---
@@ -51,7 +51,7 @@ RuleSet::add_condition(Parser , const char *filename)
 if (!c->set_hook(_hook)) {
   TSError("[%s] in %s: can't use this condition in hook=%d: %%{%s} 
with arg: %s", PLUGIN_NAME, filename, _hook,
--- End diff --

@zwoop, do you think it would make sense to print the hook name instead of 
the number? 
Having the number is a great help for the developers but the operators 
would not know what it means.


Issue Time Tracking
---

Worklog Id: (was: 25809)
Time Spent: 1.5h  (was: 1h 20m)

> header_rewrite: warning if you use a hook that predates "remap" in a remap 
> mode
> ---
>
> Key: TS-4683
> URL: https://issues.apache.org/jira/browse/TS-4683
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> It's rather confusing, but since remap happens after several of the hooks 
> that header_rewrite supports (in global mode), we should warn the user that 
> this is a no-op (or maybe even error out).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4615) Dynamic SRV lookups

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4615:
--

Assignee: Thomas Jackson

> Dynamic SRV lookups
> ---
>
> Key: TS-4615
> URL: https://issues.apache.org/jira/browse/TS-4615
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HostDB
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Right now all SRV lookups are `_http._tcp.NAME`, it'd be better if we 
> switched between the various protocols we support (http/https/ws/wss).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)