Failed: trafficserver (17d4c15b)

[Read the Docs]

Build Failed for trafficserver (latest)



You can find out more about this failure here:
https://readthedocs.org/projects/trafficserver/builds/4643128/

If you have questions, a good place to start is the FAQ:
https://docs.readthedocs.org/en/latest/faq.html



Keep documenting,
Read the Docs
--
http://readthedocs.org

Failed: trafficserver (17d4c15b)

[Read the Docs]

Build Failed for trafficserver (latest)



You can find out more about this failure here:
https://readthedocs.org/projects/trafficserver/builds/4643118/

If you have questions, a good place to start is the FAQ:
https://docs.readthedocs.org/en/latest/faq.html



Keep documenting,
Read the Docs
--
http://readthedocs.org

Failed: trafficserver (latest)

[Read the Docs]

Build Failed for trafficserver (latest)



Error:
Version locked, retrying in 5 minutes.

You can find out more about this failure here:
https://readthedocs.org/projects/trafficserver/builds/4643128/

If you have questions, a good place to start is the FAQ:
https://docs.readthedocs.org/en/latest/faq.html



Keep documenting,
Read the Docs
--
http://readthedocs.org

[jira] [Resolved] (TS-5040) Forward CONNECT methods without parent proxying.

[James Peach (JIRA)]

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

James Peach resolved TS-5040.
-
   Resolution: Fixed
Fix Version/s: 7.1.0

> Forward CONNECT methods without parent proxying.
> 
>
> Key: TS-5040
> URL: https://issues.apache.org/jira/browse/TS-5040
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Parent Proxy
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Parent proxy can forward {{CONNECT}} method requests to the next hop, but the 
> normal remap path cannot. Bring this capability to the remap state machine so 
> that plugins can do the same thing.



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

[jira] [Work logged] (TS-5040) Forward CONNECT methods without parent proxying.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 10/Nov/16 03:46
Start Date: 10/Nov/16 03:46
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

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

> Forward CONNECT methods without parent proxying.
> 
>
> Key: TS-5040
> URL: https://issues.apache.org/jira/browse/TS-5040
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Parent Proxy
>Reporter: James Peach
>Assignee: James Peach
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Parent proxy can forward {{CONNECT}} method requests to the next hop, but the 
> normal remap path cannot. Bring this capability to the remap state machine so 
> that plugins can do the same thing.



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

[GitHub] trafficserver pull request #1202: TS-5040: Forward CONNECT without parent pr...

[jpeach]

Github user jpeach closed the pull request at:

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


---
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] [Resolved] (TS-5045) Add ws and wss scheme constants.

[James Peach (JIRA)]

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

James Peach resolved TS-5045.
-
   Resolution: Fixed
Fix Version/s: 7.1.0

> Add ws and wss scheme constants.
> 
>
> Key: TS-5045
> URL: https://issues.apache.org/jira/browse/TS-5045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We have well known strings for "ws" and "wss" schemes, but no TS API 
> constants. Let's add these for completeness.



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

[jira] [Work logged] (TS-5045) Add ws and wss scheme constants.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 10/Nov/16 03:44
Start Date: 10/Nov/16 03:44
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

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

> Add ws and wss scheme constants.
> 
>
> Key: TS-5045
> URL: https://issues.apache.org/jira/browse/TS-5045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We have well known strings for "ws" and "wss" schemes, but no TS API 
> constants. Let's add these for completeness.



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

[GitHub] trafficserver pull request #1211: TS-5045: Add ws and wss scheme constants.

[jpeach]

Github user jpeach closed the pull request at:

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


---
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-4728) Null pointer error in LogHost.cc.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 10/Nov/16 02:14
Start Date: 10/Nov/16 02:14
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon closed the pull request at:

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


Issue Time Tracking
---

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

> Null pointer error in LogHost.cc.
> -
>
> Key: TS-4728
> URL: https://issues.apache.org/jira/browse/TS-4728
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 7.0.0
>Reporter: Peter Chou
>Assignee: James Peach
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> [~jpe...@apache.org] I am getting a null pointer access error with the 
> following assertion at the time of traffic_server start-up with log collation 
> enabled (client-side). I was able to get around it by just commenting it out, 
> but perhaps a better fix is required.
> {noformat}
> LogHost::create_orphan_LogFile_object()
> {
>   // We expect that no-one else is holding any refcounts on the
>   // orphan file so that is will be releases when we replace it
>   // below.
>   ink_assert(m_orphan_file->refcount() == 1);
> {noformat}
> Back-trace --
> {noformat}
> #0  0x0053e772 in RefCountObj::refcount (this=0x8) at 
> ../lib/ts/Ptr.h:80
> #1  0x00692f9f in LogHost::create_orphan_LogFile_object 
> (this=0x2268d80) at LogHost.cc:235
> #2  0x00692a45 in LogHost::set_ipstr_port (this=0x2268d80, 
> ipstr=0x2265d40 "127.0.0.1", pt=8085) at LogHost.cc:135
> #3  0x00692b92 in LogHost::set_name_or_ipstr (this=0x2268d80, 
> name_or_ip=0x2265d40 "127.0.0.1") at LogHost.cc:155
> #4  0x00684046 in LogConfig::read_xml_log_config (this=0x21e4110) at 
> LogConfig.cc:1472
> #5  0x0067ff73 in LogConfig::setup_log_objects (this=0x21e4110) at 
> LogConfig.cc:510
> #6  0x0067f858 in LogConfig::init (this=0x21e4110, prev_config=0x0) 
> at LogConfig.cc:395
> #7  0x006721fe in Log::init (flags=0) at Log.cc:925
> #8  0x00542552 in main (argv=0x7ffcc853abd8) at Main.cc:1828
> {noformat}
> I made minimal changes to logs_xml.config to set as client --
> {noformat}
> 
> 
>  : % : %"/>
> 
> 
> 
> 
> 
> 
> {noformat}



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

[jira] [Updated] (TS-4728) Null pointer error in LogHost.cc.

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4728:

Backport to Version:   (was: 6.2.1)

> Null pointer error in LogHost.cc.
> -
>
> Key: TS-4728
> URL: https://issues.apache.org/jira/browse/TS-4728
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 7.0.0
>Reporter: Peter Chou
>Assignee: James Peach
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> [~jpe...@apache.org] I am getting a null pointer access error with the 
> following assertion at the time of traffic_server start-up with log collation 
> enabled (client-side). I was able to get around it by just commenting it out, 
> but perhaps a better fix is required.
> {noformat}
> LogHost::create_orphan_LogFile_object()
> {
>   // We expect that no-one else is holding any refcounts on the
>   // orphan file so that is will be releases when we replace it
>   // below.
>   ink_assert(m_orphan_file->refcount() == 1);
> {noformat}
> Back-trace --
> {noformat}
> #0  0x0053e772 in RefCountObj::refcount (this=0x8) at 
> ../lib/ts/Ptr.h:80
> #1  0x00692f9f in LogHost::create_orphan_LogFile_object 
> (this=0x2268d80) at LogHost.cc:235
> #2  0x00692a45 in LogHost::set_ipstr_port (this=0x2268d80, 
> ipstr=0x2265d40 "127.0.0.1", pt=8085) at LogHost.cc:135
> #3  0x00692b92 in LogHost::set_name_or_ipstr (this=0x2268d80, 
> name_or_ip=0x2265d40 "127.0.0.1") at LogHost.cc:155
> #4  0x00684046 in LogConfig::read_xml_log_config (this=0x21e4110) at 
> LogConfig.cc:1472
> #5  0x0067ff73 in LogConfig::setup_log_objects (this=0x21e4110) at 
> LogConfig.cc:510
> #6  0x0067f858 in LogConfig::init (this=0x21e4110, prev_config=0x0) 
> at LogConfig.cc:395
> #7  0x006721fe in Log::init (flags=0) at Log.cc:925
> #8  0x00542552 in main (argv=0x7ffcc853abd8) at Main.cc:1828
> {noformat}
> I made minimal changes to logs_xml.config to set as client --
> {noformat}
> 
> 
>  : % : %"/>
> 
> 
> 
> 
> 
> 
> {noformat}



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

[jira] [Updated] (TS-4728) Null pointer error in LogHost.cc.

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4728:

Fix Version/s: 6.2.1

> Null pointer error in LogHost.cc.
> -
>
> Key: TS-4728
> URL: https://issues.apache.org/jira/browse/TS-4728
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 7.0.0
>Reporter: Peter Chou
>Assignee: James Peach
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> [~jpe...@apache.org] I am getting a null pointer access error with the 
> following assertion at the time of traffic_server start-up with log collation 
> enabled (client-side). I was able to get around it by just commenting it out, 
> but perhaps a better fix is required.
> {noformat}
> LogHost::create_orphan_LogFile_object()
> {
>   // We expect that no-one else is holding any refcounts on the
>   // orphan file so that is will be releases when we replace it
>   // below.
>   ink_assert(m_orphan_file->refcount() == 1);
> {noformat}
> Back-trace --
> {noformat}
> #0  0x0053e772 in RefCountObj::refcount (this=0x8) at 
> ../lib/ts/Ptr.h:80
> #1  0x00692f9f in LogHost::create_orphan_LogFile_object 
> (this=0x2268d80) at LogHost.cc:235
> #2  0x00692a45 in LogHost::set_ipstr_port (this=0x2268d80, 
> ipstr=0x2265d40 "127.0.0.1", pt=8085) at LogHost.cc:135
> #3  0x00692b92 in LogHost::set_name_or_ipstr (this=0x2268d80, 
> name_or_ip=0x2265d40 "127.0.0.1") at LogHost.cc:155
> #4  0x00684046 in LogConfig::read_xml_log_config (this=0x21e4110) at 
> LogConfig.cc:1472
> #5  0x0067ff73 in LogConfig::setup_log_objects (this=0x21e4110) at 
> LogConfig.cc:510
> #6  0x0067f858 in LogConfig::init (this=0x21e4110, prev_config=0x0) 
> at LogConfig.cc:395
> #7  0x006721fe in Log::init (flags=0) at Log.cc:925
> #8  0x00542552 in main (argv=0x7ffcc853abd8) at Main.cc:1828
> {noformat}
> I made minimal changes to logs_xml.config to set as client --
> {noformat}
> 
> 
>  : % : %"/>
> 
> 
> 
> 
> 
> 
> {noformat}



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

[GitHub] trafficserver pull request #1213: TS-4728 Null pointer error in LogHost.cc (...

[PSUdaemon]

Github user PSUdaemon closed the pull request at:

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


---
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-4728) Null pointer error in LogHost.cc.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Null pointer error in LogHost.cc.
> -
>
> Key: TS-4728
> URL: https://issues.apache.org/jira/browse/TS-4728
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 7.0.0
>Reporter: Peter Chou
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> [~jpe...@apache.org] I am getting a null pointer access error with the 
> following assertion at the time of traffic_server start-up with log collation 
> enabled (client-side). I was able to get around it by just commenting it out, 
> but perhaps a better fix is required.
> {noformat}
> LogHost::create_orphan_LogFile_object()
> {
>   // We expect that no-one else is holding any refcounts on the
>   // orphan file so that is will be releases when we replace it
>   // below.
>   ink_assert(m_orphan_file->refcount() == 1);
> {noformat}
> Back-trace --
> {noformat}
> #0  0x0053e772 in RefCountObj::refcount (this=0x8) at 
> ../lib/ts/Ptr.h:80
> #1  0x00692f9f in LogHost::create_orphan_LogFile_object 
> (this=0x2268d80) at LogHost.cc:235
> #2  0x00692a45 in LogHost::set_ipstr_port (this=0x2268d80, 
> ipstr=0x2265d40 "127.0.0.1", pt=8085) at LogHost.cc:135
> #3  0x00692b92 in LogHost::set_name_or_ipstr (this=0x2268d80, 
> name_or_ip=0x2265d40 "127.0.0.1") at LogHost.cc:155
> #4  0x00684046 in LogConfig::read_xml_log_config (this=0x21e4110) at 
> LogConfig.cc:1472
> #5  0x0067ff73 in LogConfig::setup_log_objects (this=0x21e4110) at 
> LogConfig.cc:510
> #6  0x0067f858 in LogConfig::init (this=0x21e4110, prev_config=0x0) 
> at LogConfig.cc:395
> #7  0x006721fe in Log::init (flags=0) at Log.cc:925
> #8  0x00542552 in main (argv=0x7ffcc853abd8) at Main.cc:1828
> {noformat}
> I made minimal changes to logs_xml.config to set as client --
> {noformat}
> 
> 
>  : % : %"/>
> 
> 
> 
> 
> 
> 
> {noformat}



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

[GitHub] trafficserver issue #1213: TS-4728 Null pointer error in LogHost.cc (backpor...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1213
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1198/ 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-4728) Null pointer error in LogHost.cc.

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Null pointer error in LogHost.cc.
> -
>
> Key: TS-4728
> URL: https://issues.apache.org/jira/browse/TS-4728
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 7.0.0
>Reporter: Peter Chou
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> [~jpe...@apache.org] I am getting a null pointer access error with the 
> following assertion at the time of traffic_server start-up with log collation 
> enabled (client-side). I was able to get around it by just commenting it out, 
> but perhaps a better fix is required.
> {noformat}
> LogHost::create_orphan_LogFile_object()
> {
>   // We expect that no-one else is holding any refcounts on the
>   // orphan file so that is will be releases when we replace it
>   // below.
>   ink_assert(m_orphan_file->refcount() == 1);
> {noformat}
> Back-trace --
> {noformat}
> #0  0x0053e772 in RefCountObj::refcount (this=0x8) at 
> ../lib/ts/Ptr.h:80
> #1  0x00692f9f in LogHost::create_orphan_LogFile_object 
> (this=0x2268d80) at LogHost.cc:235
> #2  0x00692a45 in LogHost::set_ipstr_port (this=0x2268d80, 
> ipstr=0x2265d40 "127.0.0.1", pt=8085) at LogHost.cc:135
> #3  0x00692b92 in LogHost::set_name_or_ipstr (this=0x2268d80, 
> name_or_ip=0x2265d40 "127.0.0.1") at LogHost.cc:155
> #4  0x00684046 in LogConfig::read_xml_log_config (this=0x21e4110) at 
> LogConfig.cc:1472
> #5  0x0067ff73 in LogConfig::setup_log_objects (this=0x21e4110) at 
> LogConfig.cc:510
> #6  0x0067f858 in LogConfig::init (this=0x21e4110, prev_config=0x0) 
> at LogConfig.cc:395
> #7  0x006721fe in Log::init (flags=0) at Log.cc:925
> #8  0x00542552 in main (argv=0x7ffcc853abd8) at Main.cc:1828
> {noformat}
> I made minimal changes to logs_xml.config to set as client --
> {noformat}
> 
> 
>  : % : %"/>
> 
> 
> 
> 
> 
> 
> {noformat}



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

[GitHub] trafficserver issue #1213: TS-4728 Null pointer error in LogHost.cc (backpor...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1213
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1091/ 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.
---

[GitHub] trafficserver issue #1215: TS-5027: Replace readdir_r with readdir.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1215
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1197/ 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-5027) Replace readdir_r with readdir

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Replace readdir_r with readdir
> --
>
> Key: TS-5027
> URL: https://issues.apache.org/jira/browse/TS-5027
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> glibc deprecated {{readdir_r}} for reasons explained in the [man 
> page|http://man7.org/linux/man-pages/man3/readdir_r.3.html].
> {noformat}
> ../../mgmt/Rollback.cc  -fPIC -DPIC -o .libs/Rollback.o
> ../../mgmt/FileManager.cc: In member function 'SnapResult 
> FileManager::removeSnap(const char*, const char*)':
> ../../mgmt/FileManager.cc:394:10: error: 'int readdir_r(DIR*, dirent*, 
> dirent**)' is deprecated [-Werror=deprecated-declarations]
>   while (readdir_r(dir, dirEntrySpace, ) == 0) {
>  ^
> In file included from ../../lib/ts/ink_platform.h:130:0,
> from ../../mgmt/FileManager.cc:24:
> /usr/include/dirent.h:183:12: note: declared here
> extern int readdir_r (DIR *__restrict __dirp,
>^
> {noformat}



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

[jira] [Work logged] (TS-5027) Replace readdir_r with readdir

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Replace readdir_r with readdir
> --
>
> Key: TS-5027
> URL: https://issues.apache.org/jira/browse/TS-5027
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> glibc deprecated {{readdir_r}} for reasons explained in the [man 
> page|http://man7.org/linux/man-pages/man3/readdir_r.3.html].
> {noformat}
> ../../mgmt/Rollback.cc  -fPIC -DPIC -o .libs/Rollback.o
> ../../mgmt/FileManager.cc: In member function 'SnapResult 
> FileManager::removeSnap(const char*, const char*)':
> ../../mgmt/FileManager.cc:394:10: error: 'int readdir_r(DIR*, dirent*, 
> dirent**)' is deprecated [-Werror=deprecated-declarations]
>   while (readdir_r(dir, dirEntrySpace, ) == 0) {
>  ^
> In file included from ../../lib/ts/ink_platform.h:130:0,
> from ../../mgmt/FileManager.cc:24:
> /usr/include/dirent.h:183:12: note: declared here
> extern int readdir_r (DIR *__restrict __dirp,
>^
> {noformat}



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

[GitHub] trafficserver issue #1215: TS-5027: Replace readdir_r with readdir.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1215
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1090/ 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-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4514:

Fix Version/s: 6.2.1

> Transaction hangs when no_dns_just_forward is configured but parent proxy is 
> unresolvable
> -
>
> Key: TS-4514
> URL: https://issues.apache.org/jira/browse/TS-4514
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS, Parent Proxy
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When ATS is configured with:
> {code}
> CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
> {code}
> And a transaction comes in that has an unresolvable parent in parents.config 
> ATS will keep retrying to resolve the same parent.



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

[jira] [Updated] (TS-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4514:

Backport to Version:   (was: 6.2.1)

> Transaction hangs when no_dns_just_forward is configured but parent proxy is 
> unresolvable
> -
>
> Key: TS-4514
> URL: https://issues.apache.org/jira/browse/TS-4514
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS, Parent Proxy
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When ATS is configured with:
> {code}
> CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
> {code}
> And a transaction comes in that has an unresolvable parent in parents.config 
> ATS will keep retrying to resolve the same parent.



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

[jira] [Work logged] (TS-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 10/Nov/16 02:00
Start Date: 10/Nov/16 02:00
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon closed the pull request at:

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


Issue Time Tracking
---

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

> Transaction hangs when no_dns_just_forward is configured but parent proxy is 
> unresolvable
> -
>
> Key: TS-4514
> URL: https://issues.apache.org/jira/browse/TS-4514
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS, Parent Proxy
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When ATS is configured with:
> {code}
> CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
> {code}
> And a transaction comes in that has an unresolvable parent in parents.config 
> ATS will keep retrying to resolve the same parent.



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

[GitHub] trafficserver pull request #1208: TS-4514: Transaction hangs when no_dns_jus...

[PSUdaemon]

Github user PSUdaemon closed the pull request at:

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


---
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-4728) Null pointer error in LogHost.cc.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 10/Nov/16 01:58
Start Date: 10/Nov/16 01:58
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon commented on the issue:

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


Issue Time Tracking
---

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

> Null pointer error in LogHost.cc.
> -
>
> Key: TS-4728
> URL: https://issues.apache.org/jira/browse/TS-4728
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 7.0.0
>Reporter: Peter Chou
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> [~jpe...@apache.org] I am getting a null pointer access error with the 
> following assertion at the time of traffic_server start-up with log collation 
> enabled (client-side). I was able to get around it by just commenting it out, 
> but perhaps a better fix is required.
> {noformat}
> LogHost::create_orphan_LogFile_object()
> {
>   // We expect that no-one else is holding any refcounts on the
>   // orphan file so that is will be releases when we replace it
>   // below.
>   ink_assert(m_orphan_file->refcount() == 1);
> {noformat}
> Back-trace --
> {noformat}
> #0  0x0053e772 in RefCountObj::refcount (this=0x8) at 
> ../lib/ts/Ptr.h:80
> #1  0x00692f9f in LogHost::create_orphan_LogFile_object 
> (this=0x2268d80) at LogHost.cc:235
> #2  0x00692a45 in LogHost::set_ipstr_port (this=0x2268d80, 
> ipstr=0x2265d40 "127.0.0.1", pt=8085) at LogHost.cc:135
> #3  0x00692b92 in LogHost::set_name_or_ipstr (this=0x2268d80, 
> name_or_ip=0x2265d40 "127.0.0.1") at LogHost.cc:155
> #4  0x00684046 in LogConfig::read_xml_log_config (this=0x21e4110) at 
> LogConfig.cc:1472
> #5  0x0067ff73 in LogConfig::setup_log_objects (this=0x21e4110) at 
> LogConfig.cc:510
> #6  0x0067f858 in LogConfig::init (this=0x21e4110, prev_config=0x0) 
> at LogConfig.cc:395
> #7  0x006721fe in Log::init (flags=0) at Log.cc:925
> #8  0x00542552 in main (argv=0x7ffcc853abd8) at Main.cc:1828
> {noformat}
> I made minimal changes to logs_xml.config to set as client --
> {noformat}
> 
> 
>  : % : %"/>
> 
> 
> 
> 
> 
> 
> {noformat}



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

[GitHub] trafficserver issue #1213: TS-4728 Null pointer error in LogHost.cc (backpor...

[PSUdaemon]

Github user PSUdaemon commented on the issue:

https://github.com/apache/trafficserver/pull/1213
  
[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] [Commented] (TS-4801) Are we marking parents down too aggressively?

[Phil Sorber (JIRA)]

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

Phil Sorber commented on TS-4801:
-

[~jrushford] said that this was backported with TS-3419 back port so I am 
marking this as back ported but taking no further action.

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[jira] [Updated] (TS-4801) Are we marking parents down too aggressively?

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4801:

Fix Version/s: 6.2.1

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[jira] [Updated] (TS-4801) Are we marking parents down too aggressively?

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4801:

Backport to Version:   (was: 6.2.1)

> Are we marking parents down too aggressively?
> -
>
> Key: TS-4801
> URL: https://issues.apache.org/jira/browse/TS-4801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.2.1, 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> [~jrushford] and I were looking at some code, and found this piece which 
> looks suspicious:
> {code}
> } else if (s->current.attempts < s->txn_conf->parent_connect_attempts) {
>   s->current.attempts++;
>   // Are we done with this particular parent?
>   if ((s->current.attempts - 1) % 
> s->http_config_param->per_parent_connect_attempts != 0) {
> // No we are not done with this parent so retry
> s->next_action = how_to_open_connection(s);
> DebugTxn("http_trans", "%s Retrying parent for attempt %d, max %" 
> PRId64, "[handle_response_from_parent]",
>  s->current.attempts, 
> s->http_config_param->per_parent_connect_attempts);
> return;
>   } else {
> DebugTxn("http_trans", "%s %d per parent attempts exhausted", 
> "[handle_response_from_parent]", s->current.attempts);
> // Only mark the parent down if we failed to connect
> //  to the parent otherwise slow origin servers cause
> //  us to mark the parent down
> if (s->current.state == CONNECTION_ERROR) {
>   s->parent_params->markParentDown(>parent_result);
> }
> // We are done so look for another parent if any
> next_lookup = find_server_and_update_current_info(s);
>   }
> } else {
>   // Done trying parents... fail over to origin server if that is
>   //   appropriate
>   DebugTxn("http_trans", "[handle_response_from_parent] Error. No more 
> retries.");
>   s->parent_params->markParentDown(>parent_result);
>   s->parent_result.result = PARENT_FAIL;
>   next_lookup = find_server_and_update_current_info(s);
> }
> {code}
> Here's my thinking: It seems that if we exhaust parent_connect_attempts 
> (which is proxy.config.http.parent_proxy.total_connect_attempts, default 4), 
> we end up always marking whatever the current parent is as potentially down.
> This seems wrong, because it might do this even if the number of tries 
> against that particular parent has not been exhausted (that is the 
> proxy.config.http.parent_proxy.per_parent_connect_attempts setting, tested 
> inside the loop).
> Looking at this, it feels that we should either remove that markParentDown() 
> entirely, or at a minimum add the same checks as above, i.e.
> {code}
> -  s->parent_params->markParentDown(>parent_result);
> +  if (s->current.state == CONNECTION_ERROR) {
> +s->parent_params->markParentDown(>parent_result);
> +  }
> {code}
> I'm still doing some more tests, one concern is that it's unclear if the 
> earlier comment is correct, and that we can detect the difference between a 
> connection failure to parent, vs an origin server response to the parent is 
> just being slow (resulting in a timeout and no response to child).



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

[jira] [Work logged] (TS-5027) Replace readdir_r with readdir

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 10/Nov/16 01:52
Start Date: 10/Nov/16 01:52
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon commented on the issue:

https://github.com/apache/trafficserver/pull/1215
  
@zwoop & @jpeach - can you guys give this a thumbs up if it looks like I 
did the backport correctly? Mostly `nullptr` and `{}` that was providing 
conflicts.

Thanks.


Issue Time Tracking
---

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

> Replace readdir_r with readdir
> --
>
> Key: TS-5027
> URL: https://issues.apache.org/jira/browse/TS-5027
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> glibc deprecated {{readdir_r}} for reasons explained in the [man 
> page|http://man7.org/linux/man-pages/man3/readdir_r.3.html].
> {noformat}
> ../../mgmt/Rollback.cc  -fPIC -DPIC -o .libs/Rollback.o
> ../../mgmt/FileManager.cc: In member function 'SnapResult 
> FileManager::removeSnap(const char*, const char*)':
> ../../mgmt/FileManager.cc:394:10: error: 'int readdir_r(DIR*, dirent*, 
> dirent**)' is deprecated [-Werror=deprecated-declarations]
>   while (readdir_r(dir, dirEntrySpace, ) == 0) {
>  ^
> In file included from ../../lib/ts/ink_platform.h:130:0,
> from ../../mgmt/FileManager.cc:24:
> /usr/include/dirent.h:183:12: note: declared here
> extern int readdir_r (DIR *__restrict __dirp,
>^
> {noformat}



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

[GitHub] trafficserver issue #1215: TS-5027: Replace readdir_r with readdir.

[PSUdaemon]

Github user PSUdaemon commented on the issue:

https://github.com/apache/trafficserver/pull/1215
  
@zwoop & @jpeach - can you guys give this a thumbs up if it looks like I 
did the backport correctly? Mostly `nullptr` and `{}` that was providing 
conflicts.

Thanks.


---
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 #1215: TS-5027: Replace readdir_r with readdir.

[PSUdaemon]

GitHub user PSUdaemon opened a pull request:

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

TS-5027: Replace readdir_r with readdir.

Glibc deprecated readdir_r(3), so replace it with readdir(3). We
were already using readdir(3) in many places so this is just accepting
the inevitable.

(cherry picked from commit 25b16f763267546c0585fb15f43da4a7803ac984)

 Conflicts:
mgmt/FileManager.cc
mgmt/MultiFile.cc
mgmt/Rollback.cc
mgmt/WebMgmtUtils.cc
proxy/http/HttpBodyFactory.cc
proxy/logging/LogConfig.cc

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PSUdaemon/trafficserver ts-5027-bp

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1215.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1215


commit 94708ff7ad1b4fe74d6f37b47d3d298e3e926c26
Author: James Peach 
Date:   2016-11-03T04:30:47Z

TS-5027: Replace readdir_r with readdir.

Glibc deprecated readdir_r(3), so replace it with readdir(3). We
were already using readdir(3) in many places so this is just accepting
the inevitable.

(cherry picked from commit 25b16f763267546c0585fb15f43da4a7803ac984)

 Conflicts:
mgmt/FileManager.cc
mgmt/MultiFile.cc
mgmt/Rollback.cc
mgmt/WebMgmtUtils.cc
proxy/http/HttpBodyFactory.cc
proxy/logging/LogConfig.cc




---
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-5027) Replace readdir_r with readdir

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 10/Nov/16 01:51
Start Date: 10/Nov/16 01:51
Worklog Time Spent: 10m 
  Work Description: GitHub user PSUdaemon opened a pull request:

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

TS-5027: Replace readdir_r with readdir.

Glibc deprecated readdir_r(3), so replace it with readdir(3). We
were already using readdir(3) in many places so this is just accepting
the inevitable.

(cherry picked from commit 25b16f763267546c0585fb15f43da4a7803ac984)

 Conflicts:
mgmt/FileManager.cc
mgmt/MultiFile.cc
mgmt/Rollback.cc
mgmt/WebMgmtUtils.cc
proxy/http/HttpBodyFactory.cc
proxy/logging/LogConfig.cc

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PSUdaemon/trafficserver ts-5027-bp

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1215.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1215


commit 94708ff7ad1b4fe74d6f37b47d3d298e3e926c26
Author: James Peach 
Date:   2016-11-03T04:30:47Z

TS-5027: Replace readdir_r with readdir.

Glibc deprecated readdir_r(3), so replace it with readdir(3). We
were already using readdir(3) in many places so this is just accepting
the inevitable.

(cherry picked from commit 25b16f763267546c0585fb15f43da4a7803ac984)

 Conflicts:
mgmt/FileManager.cc
mgmt/MultiFile.cc
mgmt/Rollback.cc
mgmt/WebMgmtUtils.cc
proxy/http/HttpBodyFactory.cc
proxy/logging/LogConfig.cc




Issue Time Tracking
---

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

> Replace readdir_r with readdir
> --
>
> Key: TS-5027
> URL: https://issues.apache.org/jira/browse/TS-5027
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> glibc deprecated {{readdir_r}} for reasons explained in the [man 
> page|http://man7.org/linux/man-pages/man3/readdir_r.3.html].
> {noformat}
> ../../mgmt/Rollback.cc  -fPIC -DPIC -o .libs/Rollback.o
> ../../mgmt/FileManager.cc: In member function 'SnapResult 
> FileManager::removeSnap(const char*, const char*)':
> ../../mgmt/FileManager.cc:394:10: error: 'int readdir_r(DIR*, dirent*, 
> dirent**)' is deprecated [-Werror=deprecated-declarations]
>   while (readdir_r(dir, dirEntrySpace, ) == 0) {
>  ^
> In file included from ../../lib/ts/ink_platform.h:130:0,
> from ../../mgmt/FileManager.cc:24:
> /usr/include/dirent.h:183:12: note: declared here
> extern int readdir_r (DIR *__restrict __dirp,
>^
> {noformat}



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

Failed: trafficserver (6fd307f0)

[Read the Docs]

Build Failed for trafficserver (latest)



You can find out more about this failure here:
https://readthedocs.org/projects/trafficserver/builds/4642101/

If you have questions, a good place to start is the FAQ:
https://docs.readthedocs.org/en/latest/faq.html



Keep documenting,
Read the Docs
--
http://readthedocs.org

[jira] [Resolved] (TS-5047) Unmapped url log fields sometimes do not have a host

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll resolved TS-5047.
-
Resolution: Fixed

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[jira] [Work logged] (TS-5047) Unmapped url log fields sometimes do not have a host

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 09/Nov/16 22:02
Start Date: 09/Nov/16 22:02
Worklog Time Spent: 10m 
  Work Description: Github user SolidWallOfCode closed the pull request at:

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


Issue Time Tracking
---

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

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[GitHub] trafficserver pull request #1214: TS-5047: Fix unmapped URL logging tags.

[SolidWallOfCode]

Github user SolidWallOfCode closed the pull request at:

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


---
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] [Resolved] (TS-4872) clang-analyzer: Memory leak LogObject.cc _checkout_write

[James Peach (JIRA)]

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

James Peach resolved TS-4872.
-
Resolution: Fixed

> clang-analyzer: Memory leak LogObject.cc _checkout_write
> 
>
> Key: TS-4872
> URL: https://issues.apache.org/jira/browse/TS-4872
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: James Peach
>  Labels: clang-analyzer
> Fix For: 7.1.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> We could not quite figure out why it reports this (smells almost like a bug 
> in clang-analyzer), but [~jpe...@apache.org] has a refactoring that avoids 
> the warning, and cleans up the code overall.



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

[jira] [Resolved] (TS-4927) Coverity issues in passthru example plugin

[James Peach (JIRA)]

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

James Peach resolved TS-4927.
-
Resolution: Fixed

> Coverity issues in passthru example plugin
> --
>
> Key: TS-4927
> URL: https://issues.apache.org/jira/browse/TS-4927
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: James Peach
> Fix For: 7.1.0
>
>
> {code}
> *** CID 1363659:  Null pointer dereferences  (REVERSE_INULL)
> /example/passthru/passthru.cc: 214 in PassthruSessionEvent(tsapi_cont *, 
> TSEvent, void *)()
> 208 
> 209   // Start the server end of the IO before we write any data.
> 210   sp->server.readio.read(sp->server.vconn, sp->contp);
> 211   sp->server.writeio.write(sp->server.vconn, sp->contp);
> 212 }
> 213 
>CID 1363659:  Null pointer dereferences  (REVERSE_INULL)
>Null-checking "sp->server.vconn" suggests that it may be null, but it has 
> already been dereferenced on all paths leading to the check.
> 214 if (sp->server.vconn != nullptr) {
> 215   int64_t nbytes;
> 216 
> 217   nbytes = sp->client.readio.transfer_to(sp->server.writeio);
> 218   PassthruSessionDebug(sp, "proxied %" PRId64 " bytes from client 
> vconn=%p to server vconn=%p", nbytes, sp->client.vconn,
> 219sp->server.vconn);
> ** CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 97 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 
> *** CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 97 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 91   void
> 92   write(TSVConn vconn, TSCont contp)
> 93   {
> 94 TSReleaseAssert(this->vio == NULL);
> 95 
> 96 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
>CID 1363658:  Incorrect expression  (ASSERT_SIDE_EFFECT)
>Assignment "this->reader = TSIOBufferReaderAlloc(this->iobuf)" has a side 
> effect.  This code will work differently in a non-debug build.
> 97 TSReleaseAssert((this->reader = 
> TSIOBufferReaderAlloc(this->iobuf)));
> 98 
> 99 this->vio = TSVConnWrite(vconn, contp, this->reader, INT64_MAX);
> 100   }
> 101 
> 102   // Transfer data from this IO object to the target IO object.
> ** CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 84 in PassthruIO::read(tsapi_cont *, 
> tsapi_cont *)()
> 
> *** CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 84 in PassthruIO::read(tsapi_cont *, 
> tsapi_cont *)()
> 78   // Start a read operation.
> 79   void
> 80   read(TSVConn vconn, TSCont contp)
> 81   {
> 82 TSReleaseAssert(this->vio == NULL);
> 83 
>CID 1363657:  Incorrect expression  (ASSERT_SIDE_EFFECT)
>Assignment "this->iobuf = TSIOBufferCreate()" has a side effect.  This 
> code will work differently in a non-debug build.
> 84 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
> 85 TSReleaseAssert((this->reader = 
> TSIOBufferReaderAlloc(this->iobuf)));
> 86 
> 87 this->vio = TSVConnRead(vconn, contp, this->iobuf, INT64_MAX);
> 88   }
> 89 
> ** CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 96 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 
> *** CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 96 in PassthruIO::write(tsapi_cont *, 
> tsapi_cont *)()
> 90   // Start a write operation.
> 91   void
> 92   write(TSVConn vconn, TSCont contp)
> 93   {
> 94 TSReleaseAssert(this->vio == NULL);
> 95 
>CID 1363656:  Incorrect expression  (ASSERT_SIDE_EFFECT)
>Assignment "this->iobuf = TSIOBufferCreate()" has a side effect.  This 
> code will work differently in a non-debug build.
> 96 TSReleaseAssert((this->iobuf = TSIOBufferCreate()));
> 97 TSReleaseAssert((this->reader = 
> TSIOBufferReaderAlloc(this->iobuf)));
> 98 
> 99 this->vio = TSVConnWrite(vconn, contp, this->reader, INT64_MAX);
> 100   }
> 101 
> ** CID 1363655:  Incorrect expression  (ASSERT_SIDE_EFFECT)
> /example/passthru/passthru.cc: 85 in PassthruIO::read(tsapi_cont *, 
> tsapi_cont *)()
> 

[jira] [Resolved] (TS-4840) Crash when reattaching to C++ API Stats.

[James Peach (JIRA)]

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

James Peach resolved TS-4840.
-
Resolution: Fixed

> Crash when reattaching to C++ API Stats.
> 
>
> Key: TS-4840
> URL: https://issues.apache.org/jira/browse/TS-4840
> Project: Traffic Server
>  Issue Type: Bug
>  Components: CPP API, Metrics
>Affects Versions: 7.0.0
>Reporter: James Peach
>Assignee: James Peach
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGSEGV, Segmentation fault.
> 0x007f733c in ink_atomic_swap (mem=0x0, value=1) at 
> ../../lib/ts/ink_atomic.h:76
> 76  return __sync_lock_test_and_set(mem, value);
> (gdb) where
> #0  0x007f733c in ink_atomic_swap (mem=0x0, value=1) at 
> ../../lib/ts/ink_atomic.h:76
> #1  0x007f6e56 in RecSetGlobalRawStatSum (rsb=0x2f16290, id=6, 
> data=1) at RecRawStats.cc:482
> #2  0x005372c9 in TSStatIntSet (the_stat=6, value=1) at InkAPI.cc:6944
> #3  0x2ae6d3398bb1 in atscppapi::Stat::set (this=0x2ae6d37c2890 <...>, 
> value=1) at Stat.cc:78
> #4  0x2ae6d35bb826 in TSPluginInit (argc=1, argv=0x7ffd0613bfe0) at 
> /home/jpeach/n/cc:753
> #5  0x005550e5 in plugin_load (argc=1, argv=0x7ffd0613bfe0, 
> validateOnly=false) at Plugin.cc:137
> {noformat}
> The change in TS-4793 regressed the C++ API Stat object. What happens is that 
> if you restart {{traffic_server}} without {{traffic_manager}}, the 
> {{TSStatFindName}} call finds the metric in the records hash table, but 
> {{traffic_server}} has not set up the RSB entry so actually incrementing it 
> crashes.
> If you call {{TSStatCreate}} twice for the same metric, you will end up with 
> multiple RSB slots being consumed which is almost as bad.



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

[jira] [Work logged] (TS-5047) Unmapped url log fields sometimes do not have a host

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[jira] [Updated] (TS-5028) ATS 6.2.0 don't start with read-only /etc

[Bryan Call (JIRA)]

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

Bryan Call updated TS-5028:
---
Affects Version/s: 6.2.0

> ATS 6.2.0 don't start with read-only /etc
> -
>
> Key: TS-5028
> URL: https://issues.apache.org/jira/browse/TS-5028
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.2.0
>Reporter: Reindl Harald
>
> can we *please* get rid of that nonsense after that many years - /etc is 
> admin-area and software which tries to touch it at start is broken by design 
> in general, until 6.2.0 at least it did start which is no longer the case
> [root@buildserver:/var/log/trafficserver]$ cat 
> /etc/trafficserver/records.config | grep disable_configuration_modification
> CONFIG proxy.config.disable_configuration_modification 1
> [root@buildserver:/var/log/trafficserver]$ cat *
> [Aug  5 17:35:32.031] {0x2b6c81f2bf40} STATUS: opened 
> /var/log/trafficserver/diags.log
> [Aug  5 17:35:32.032] {0x2b6c81f2bf40} NOTE:  (reconfigure_diags)> updated diags config
> [Aug  5 17:35:32.038] Server {0x2b6c81f2bf40} NOTE:  
> cache clustering disabled
> [Aug  5 17:35:32.044] Server {0x2b6c81f2bf40} NOTE:  (reconfigure)> ip_allow.config updated, reloading
> [Aug  5 17:35:32.051] Server {0x2b6c81f2bf40} NOTE:  (init)> cache clustering disabled
> [Aug  5 17:35:32.054] Server {0x2b6c81f2bf40} NOTE:  (init_when_enabled)> logging initialized[3], logging_mode = 1
> [Aug  5 17:35:32.058] Server {0x2b6c81f2bf40} NOTE:  (SSLParseCertificateConfiguration)> loading SSL certificate configuration 
> from /etc/trafficserver/ssl_multicert.config
> [Aug  5 17:35:32.092] Server {0x2b6c81f2bf40} NOTE:  
> traffic server running
> [Aug  5 17:35:32.113] Server {0x2b6c87312700} NOTE:  (cacheInitialized)> cache enabled
> [Aug  5 17:35:27.934] {0x7f2183e76900} STATUS: opened 
> /var/log/trafficserver/manager.log
> [Aug  5 17:35:27.934] {0x7f2183e76900} NOTE:  (reconfigure_diags)> updated diags config
> [Aug  5 17:35:27.935] Manager {0x7f2183e76900} NOTE: [Rollback::openFile] 
> Open of log_hosts.config failed: Permission denied
> [Aug  5 17:35:27.935] Manager {0x7f2183e76900} NOTE: 
> [Rollback::internalUpdate] Unable to create new version of log_hosts.config : 
> Permission denied
> [Aug  5 17:35:27.936] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback] 
> Automatic Roll of Version 1 failed: log_hosts.config
> [Aug  5 17:35:27.936] Manager {0x7f2183e76900} NOTE: [Rollback::openFile] 
> Open of log_hosts.config failed: Permission denied
> [Aug  5 17:35:27.936] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback] 
> Config file is read-only : log_hosts.config
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile] 
> Open of logs_xml.config failed: Permission denied
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: 
> [Rollback::internalUpdate] Unable to create new version of logs_xml.config : 
> Permission denied
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback] 
> Automatic Roll of Version 1 failed: logs_xml.config
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile] 
> Open of logs_xml.config failed: Permission denied
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback] 
> Config file is read-only : logs_xml.config
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile] 
> Open of storage.config failed: Permission denied
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: 
> [Rollback::internalUpdate] Unable to create new version of storage.config : 
> Permission denied
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback] 
> Automatic Roll of Version 1 failed: storage.config
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile] 
> Open of storage.config failed: Permission denied
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback] 
> Config file is read-only : storage.config
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile] 
> Open of socks.config failed: Permission denied
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: 
> [Rollback::internalUpdate] Unable to create new version of socks.config : 
> Permission denied
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback] 
> Automatic Roll of Version 1 failed: socks.config
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile] 
> Open of socks.config failed: Permission denied
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::Rollback] 
> Config file is read-only : socks.config
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: [Rollback::openFile] 
> Open of records.config failed: Permission denied
> [Aug  5 17:35:27.937] Manager {0x7f2183e76900} NOTE: 
> [Rollback::internalUpdate] Unable to create new 

[GitHub] trafficserver issue #1214: TS-5047: Fix unmapped URL logging tags.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1214
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1196/ 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.
---

[GitHub] trafficserver issue #1214: TS-5047: Fix unmapped URL logging tags.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1214
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1089/ 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-5047) Unmapped url log fields sometimes do not have a host

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[jira] [Created] (TS-5049) Parent.config keynames are confusing

[Miles Libbey (JIRA)]

Miles Libbey created TS-5049:


 Summary: Parent.config keynames are confusing
 Key: TS-5049
 URL: https://issues.apache.org/jira/browse/TS-5049
 Project: Traffic Server
  Issue Type: Improvement
  Components: Parent Proxy
Reporter: Miles Libbey


In parent.config, we have a series of key names that are either confusing, or 
have been expanded well beyond what the name implies:

- round_robin. This now describes a selection strategy.
- parent. Origins can be described here too. Not sure what a good descriptor 
would be.
- parent_is_proxy describes how the request will be made from the child node -- 
eg, 'true,' means the request will be a proxy style request (GET 
http://example.com/foo); 'false' means a traditional style request (GET /foo\n 
Host: example.com)

In addition, there are several options that only apply when other settings are 
used. For instance,  secondary_parent only applies to the consistent_hash 
strategy. Similarly, today, "qstring" only applies to consistent_hash, as the 
URI is not considered for any other existing selection strategy.



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

[jira] [Updated] (TS-5048) parent.config: add weighting to other selection strategies

[Miles Libbey (JIRA)]

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

Miles Libbey updated TS-5048:
-
Issue Type: Improvement  (was: Bug)

> parent.config: add weighting to other selection strategies
> --
>
> Key: TS-5048
> URL: https://issues.apache.org/jira/browse/TS-5048
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Miles Libbey
>
> The consistent_hash selection strategy allows for a weighting of the parents. 
> So, a config like,
> parent="p1.x.com:80|2,p2.x.com:80|1" round_robin=consistent_hash
> would have p1 placed in the ring twice as many times as p1, and thus should 
> received 2x more URIs as p1. (Note that traffic associated with URIs can vary 
> considerably, so this weighting can be randomly associated with traffic 
> levels).
> This weighting should be extended to the round robin selection strategies 
> (strict|true)-- weighted round robin is a common load balancing strategy. In 
> these cases, the weightings would likely cause selection to cycle amongst the 
> parents such that each target would roughly end up with N/(sum of Ns) % of 
> the total traffic.



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

[jira] [Created] (TS-5048) parent.config: add weighting to other selection strategies

[Miles Libbey (JIRA)]

Miles Libbey created TS-5048:


 Summary: parent.config: add weighting to other selection strategies
 Key: TS-5048
 URL: https://issues.apache.org/jira/browse/TS-5048
 Project: Traffic Server
  Issue Type: Bug
  Components: Parent Proxy
Reporter: Miles Libbey


The consistent_hash selection strategy allows for a weighting of the parents. 
So, a config like,
parent="p1.x.com:80|2,p2.x.com:80|1" round_robin=consistent_hash
would have p1 placed in the ring twice as many times as p1, and thus should 
received 2x more URIs as p1. (Note that traffic associated with URIs can vary 
considerably, so this weighting can be randomly associated with traffic levels).

This weighting should be extended to the round robin selection strategies 
(strict|true)-- weighted round robin is a common load balancing strategy. In 
these cases, the weightings would likely cause selection to cycle amongst the 
parents such that each target would roughly end up with N/(sum of Ns) % of the 
total traffic.



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

[jira] [Resolved] (TS-5023) Allow diags.log and traffic.out to be rotated by size or time

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll resolved TS-5023.
-
Resolution: Fixed

> Allow diags.log and traffic.out to be rotated by size or time
> -
>
> Key: TS-5023
> URL: https://issues.apache.org/jira/browse/TS-5023
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Create a 3rd option for diags.log and traffic.out to be rolled by time OR 
> size. Currently access logs have this feature and diagnostic logs don't.



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

[jira] [Work logged] (TS-5023) Allow diags.log and traffic.out to be rotated by size or time

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 09/Nov/16 17:03
Start Date: 09/Nov/16 17:03
Worklog Time Spent: 10m 
  Work Description: Github user SolidWallOfCode closed the pull request at:

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


Issue Time Tracking
---

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

> Allow diags.log and traffic.out to be rotated by size or time
> -
>
> Key: TS-5023
> URL: https://issues.apache.org/jira/browse/TS-5023
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Create a 3rd option for diags.log and traffic.out to be rolled by time OR 
> size. Currently access logs have this feature and diagnostic logs don't.



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

[GitHub] trafficserver pull request #1165: TS-5023 Allow diags.log and traffic.out to...

[SolidWallOfCode]

Github user SolidWallOfCode closed the pull request at:

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


---
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-5023) Allow diags.log and traffic.out to be rotated by size or time

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 09/Nov/16 16:36
Start Date: 09/Nov/16 16:36
Worklog Time Spent: 10m 
  Work Description: Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/1165
  
Ship it.


Issue Time Tracking
---

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

> Allow diags.log and traffic.out to be rotated by size or time
> -
>
> Key: TS-5023
> URL: https://issues.apache.org/jira/browse/TS-5023
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Create a 3rd option for diags.log and traffic.out to be rolled by time OR 
> size. Currently access logs have this feature and diagnostic logs don't.



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

[GitHub] trafficserver issue #1165: TS-5023 Allow diags.log and traffic.out to be rot...

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/1165
  
Ship it.


---
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-5030) Proposal: Add API to get the client request UUID directly from a TSHttpTx

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 09/Nov/16 16:32
Start Date: 09/Nov/16 16:32
Worklog Time Spent: 10m 
  Work Description: Github user calavera commented on the issue:

https://github.com/apache/trafficserver/pull/1184
  
I made some changes to not use the TS API internally and use the arena for 
memory allocation. I'd really appreciate another review.

I tagged the issue in Jira with `TS API`, should I add any other tags?


Issue Time Tracking
---

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

> Proposal: Add API to get the client request UUID directly from a TSHttpTx
> -
>
> Key: TS-5030
> URL: https://issues.apache.org/jira/browse/TS-5030
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: David Calavera
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The new UUID api introduced in 
> https://github.com/apache/trafficserver/pull/736 is great for tracing 
> operations and requests. However, the most useful information for plugin 
> developers, the unique client request id, is not exposed as an api endpoint. 
> People need to understand very well how TrafficServer works internally to 
> generate this value. By not having the API directly exposed, people need to 
> repeat the same code every time they want to generate this unique identifier.
> I'd like to add an API enpoint to generate this identifier based in a given 
> http transaction for plugins to use.
> This would be the signature:
> tsapi const char * TSClientRequestUuidGet(TSHttpTxn txnp);



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

[GitHub] trafficserver issue #1184: TS-5030: Add API to get the unique client request...

[calavera]

Github user calavera commented on the issue:

https://github.com/apache/trafficserver/pull/1184
  
I made some changes to not use the TS API internally and use the arena for 
memory allocation. I'd really appreciate another review.

I tagged the issue in Jira with `TS API`, should I add any other tags?


---
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 #1210: Create log_requests plugin

[danobi]

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

https://github.com/apache/trafficserver/pull/1210#discussion_r87227079
  
--- Diff: plugins/experimental/log_requests/log_requests.c ---
@@ -0,0 +1,301 @@
+/** @file
+
+  Logs full request/response headers on an error response code (4xx/5xx)
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+
+#include "ts/ts.h"
+#include "ts/ink_defs.h"
+
+#define PLUGIN_NAME log_requests
+
+// we log the set of errors in {errors} - {blacklist}
+static TSHttpStatus *blacklist;
+static int blacklist_size; // number of entries in blacklist
+static TSHttpStatus errors[] = {TS_HTTP_STATUS_BAD_REQUEST,
+TS_HTTP_STATUS_UNAUTHORIZED,
+TS_HTTP_STATUS_PAYMENT_REQUIRED,
+TS_HTTP_STATUS_FORBIDDEN,
+TS_HTTP_STATUS_NOT_FOUND,
+TS_HTTP_STATUS_METHOD_NOT_ALLOWED,
+TS_HTTP_STATUS_NOT_ACCEPTABLE,
+
TS_HTTP_STATUS_PROXY_AUTHENTICATION_REQUIRED,
+TS_HTTP_STATUS_REQUEST_TIMEOUT,
+TS_HTTP_STATUS_CONFLICT,
+TS_HTTP_STATUS_GONE,
+TS_HTTP_STATUS_LENGTH_REQUIRED,
+TS_HTTP_STATUS_PRECONDITION_FAILED,
+TS_HTTP_STATUS_REQUEST_ENTITY_TOO_LARGE,
+TS_HTTP_STATUS_REQUEST_URI_TOO_LONG,
+TS_HTTP_STATUS_UNSUPPORTED_MEDIA_TYPE,
+
TS_HTTP_STATUS_REQUESTED_RANGE_NOT_SATISFIABLE,
+TS_HTTP_STATUS_EXPECTATION_FAILED,
+TS_HTTP_STATUS_UNPROCESSABLE_ENTITY,
+TS_HTTP_STATUS_LOCKED,
+TS_HTTP_STATUS_FAILED_DEPENDENCY,
+TS_HTTP_STATUS_UPGRADE_REQUIRED,
+TS_HTTP_STATUS_PRECONDITION_REQUIRED,
+TS_HTTP_STATUS_TOO_MANY_REQUESTS,
+
TS_HTTP_STATUS_REQUEST_HEADER_FIELDS_TOO_LARGE,
+TS_HTTP_STATUS_INTERNAL_SERVER_ERROR,
+TS_HTTP_STATUS_NOT_IMPLEMENTED,
+TS_HTTP_STATUS_BAD_GATEWAY,
+TS_HTTP_STATUS_SERVICE_UNAVAILABLE,
+TS_HTTP_STATUS_GATEWAY_TIMEOUT,
+TS_HTTP_STATUS_HTTPVER_NOT_SUPPORTED,
+TS_HTTP_STATUS_VARIANT_ALSO_NEGOTIATES,
+TS_HTTP_STATUS_INSUFFICIENT_STORAGE,
+TS_HTTP_STATUS_LOOP_DETECTED,
+TS_HTTP_STATUS_NOT_EXTENDED,
+
TS_HTTP_STATUS_NETWORK_AUTHENTICATION_REQUIRED};
+
+static bool should_log(TSHttpTxn txnp);
+static void log_request_line(TSMBuffer bufp, TSMLoc loc, const char 
*output_header);
+static void log_response_status_line(TSMBuffer bufp, TSMLoc loc, const 
char *output_header);
+static void log_headers(TSMBuffer bufp, TSMLoc loc, const char 
*output_header);
+static void log_full_transaction(TSHttpTxn txnp);
+static int log_requests_plugin(TSCont contp ATS_UNUSED, TSEvent event, 
void *edata);
+
+static bool
+should_log(TSHttpTxn txnp)
+{
+  TSMBuffer txn_resp_bufp;
+  TSMLoc txn_resp_loc;
+  TSHttpStatus resp_status;
+
+  if (TSHttpTxnClientRespGet(txnp, _resp_bufp, _resp_loc) != 
TS_SUCCESS) {
+TSError("[log_requests] Couldn't retrieve server response header.");
+return false;
+  }
+
+  // if resp_status is 

[GitHub] trafficserver pull request #1210: Create log_requests plugin

[SolidWallOfCode]

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

https://github.com/apache/trafficserver/pull/1210#discussion_r87219292
  
--- Diff: plugins/experimental/log_requests/log_requests.c ---
@@ -0,0 +1,301 @@
+/** @file
+
+  Logs full request/response headers on an error response code (4xx/5xx)
+
+  @section license License
+
+  Licensed to the Apache Software Foundation (ASF) under one
+  or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+ */
+
+#include 
+#include 
+#include 
+
+#include "ts/ts.h"
+#include "ts/ink_defs.h"
+
+#define PLUGIN_NAME log_requests
+
+// we log the set of errors in {errors} - {blacklist}
+static TSHttpStatus *blacklist;
+static int blacklist_size; // number of entries in blacklist
+static TSHttpStatus errors[] = {TS_HTTP_STATUS_BAD_REQUEST,
+TS_HTTP_STATUS_UNAUTHORIZED,
+TS_HTTP_STATUS_PAYMENT_REQUIRED,
+TS_HTTP_STATUS_FORBIDDEN,
+TS_HTTP_STATUS_NOT_FOUND,
+TS_HTTP_STATUS_METHOD_NOT_ALLOWED,
+TS_HTTP_STATUS_NOT_ACCEPTABLE,
+
TS_HTTP_STATUS_PROXY_AUTHENTICATION_REQUIRED,
+TS_HTTP_STATUS_REQUEST_TIMEOUT,
+TS_HTTP_STATUS_CONFLICT,
+TS_HTTP_STATUS_GONE,
+TS_HTTP_STATUS_LENGTH_REQUIRED,
+TS_HTTP_STATUS_PRECONDITION_FAILED,
+TS_HTTP_STATUS_REQUEST_ENTITY_TOO_LARGE,
+TS_HTTP_STATUS_REQUEST_URI_TOO_LONG,
+TS_HTTP_STATUS_UNSUPPORTED_MEDIA_TYPE,
+
TS_HTTP_STATUS_REQUESTED_RANGE_NOT_SATISFIABLE,
+TS_HTTP_STATUS_EXPECTATION_FAILED,
+TS_HTTP_STATUS_UNPROCESSABLE_ENTITY,
+TS_HTTP_STATUS_LOCKED,
+TS_HTTP_STATUS_FAILED_DEPENDENCY,
+TS_HTTP_STATUS_UPGRADE_REQUIRED,
+TS_HTTP_STATUS_PRECONDITION_REQUIRED,
+TS_HTTP_STATUS_TOO_MANY_REQUESTS,
+
TS_HTTP_STATUS_REQUEST_HEADER_FIELDS_TOO_LARGE,
+TS_HTTP_STATUS_INTERNAL_SERVER_ERROR,
+TS_HTTP_STATUS_NOT_IMPLEMENTED,
+TS_HTTP_STATUS_BAD_GATEWAY,
+TS_HTTP_STATUS_SERVICE_UNAVAILABLE,
+TS_HTTP_STATUS_GATEWAY_TIMEOUT,
+TS_HTTP_STATUS_HTTPVER_NOT_SUPPORTED,
+TS_HTTP_STATUS_VARIANT_ALSO_NEGOTIATES,
+TS_HTTP_STATUS_INSUFFICIENT_STORAGE,
+TS_HTTP_STATUS_LOOP_DETECTED,
+TS_HTTP_STATUS_NOT_EXTENDED,
+
TS_HTTP_STATUS_NETWORK_AUTHENTICATION_REQUIRED};
+
+static bool should_log(TSHttpTxn txnp);
+static void log_request_line(TSMBuffer bufp, TSMLoc loc, const char 
*output_header);
+static void log_response_status_line(TSMBuffer bufp, TSMLoc loc, const 
char *output_header);
+static void log_headers(TSMBuffer bufp, TSMLoc loc, const char 
*output_header);
+static void log_full_transaction(TSHttpTxn txnp);
+static int log_requests_plugin(TSCont contp ATS_UNUSED, TSEvent event, 
void *edata);
+
+static bool
+should_log(TSHttpTxn txnp)
+{
+  TSMBuffer txn_resp_bufp;
+  TSMLoc txn_resp_loc;
+  TSHttpStatus resp_status;
+
+  if (TSHttpTxnClientRespGet(txnp, _resp_bufp, _resp_loc) != 
TS_SUCCESS) {
+TSError("[log_requests] Couldn't retrieve server response header.");
+return false;
+  }
+
+  // if resp_status 

[jira] [Work logged] (TS-5047) Unmapped url log fields sometimes do not have a host

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 09/Nov/16 15:31
Start Date: 09/Nov/16 15:31
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

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



Issue Time Tracking
---

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

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[GitHub] trafficserver issue #1214: TS-5047: Fix unmapped URL logging tags.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1214
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1088/ 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-5047) Unmapped url log fields sometimes do not have a host

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 09/Nov/16 15:26
Start Date: 09/Nov/16 15:26
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1214
  
I'm going to test this on Docs.


Issue Time Tracking
---

Worklog Id: (was: 31873)
Time Spent: 0.5h  (was: 20m)

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[GitHub] trafficserver issue #1214: TS-5047: Fix unmapped URL logging tags.

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1214
  
I'm going to test this on Docs.


---
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 #1214: TS-5047: Fix unmapped URL logging tags.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1214
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1195/ 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-5047) Unmapped url log fields sometimes do not have a host

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

Worklog Id: (was: 31872)
Time Spent: 20m  (was: 10m)

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[jira] [Work logged] (TS-5047) Unmapped url log fields sometimes do not have a host

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 09/Nov/16 15:07
Start Date: 09/Nov/16 15:07
Worklog Time Spent: 10m 
  Work Description: GitHub user SolidWallOfCode opened a pull request:

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

TS-5047: Fix unmapped URL logging tags.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SolidWallOfCode/trafficserver ts-5047

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1214.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1214


commit 8ee35df10c2f147d0308aba46fa070d40b17822b
Author: Alan M. Carroll 
Date:   2016-11-09T15:04:38Z

TS-5047: Fix unmapped URL logging tags.




Issue Time Tracking
---

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

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[GitHub] trafficserver pull request #1214: TS-5047: Fix unmapped URL logging tags.

[SolidWallOfCode]

GitHub user SolidWallOfCode opened a pull request:

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

TS-5047: Fix unmapped URL logging tags.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SolidWallOfCode/trafficserver ts-5047

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1214.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1214


commit 8ee35df10c2f147d0308aba46fa070d40b17822b
Author: Alan M. Carroll 
Date:   2016-11-09T15:04:38Z

TS-5047: Fix unmapped URL logging tags.




---
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-5047) Unmapped url log fields sometimes do not have a host

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-5047:
---

I agree. This would also nicely make certain log entries be a lot more 
intelligible. Instead of logging the cquc URL as http:///  when e.g. there is 
no remap rule for the host in the request, we'd know get the real unmapped 
request URL in the access logs. Granted, the error log logs the offending 
hosts, but we really shouldn't log that in the error log IMO.

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[jira] [Updated] (TS-5047) Unmapped url log fields sometimes do not have a host

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-5047:

Priority: Minor  (was: Major)

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[jira] [Updated] (TS-5047) Unmapped url log fields sometimes do not have a host

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-5047:
--
Fix Version/s: 7.1.0

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
> Fix For: 7.1.0
>
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[jira] [Commented] (TS-5047) Unmapped url log fields sometimes do not have a host

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-5047:
-

Long discussion with [~zwoop] about this. I now think the correct approach is 
to always put the host in the pristine URL data. It's not really pristine, it's 
"unmapped" and so could reasonably be treated as the "effective" URL of the 
request before remapping.

> Unmapped url log fields sometimes do not have a host
> 
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Alan M. Carroll
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
> This occurs when the client request URL does not have a host and there is 
> either no remap rule for the URL, or caching is disabled, or there is an 
> error.



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

[jira] [Created] (TS-5047) Unmapped url log fields sometimes do not have a host

[Alan M. Carroll (JIRA)]

Alan M. Carroll created TS-5047:
---

 Summary: Unmapped url log fields sometimes do not have a host
 Key: TS-5047
 URL: https://issues.apache.org/jira/browse/TS-5047
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Alan M. Carroll


Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host. 
This occurs when the client request URL does not have a host and there is 
either no remap rule for the URL, or caching is disabled, or there is an error.



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