[jira] [Closed] (TS-5052) Segfault in HostDB sync if something fails while not holding the parent continuation mutex

[Thomas Jackson (JIRA)]

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

Thomas Jackson closed TS-5052.
--
Resolution: Cannot Reproduce

Turns out this is only applicable to some backport builds I've made-- not 
upstream (yay!)

> Segfault in HostDB sync if something fails while not holding the parent 
> continuation mutex
> --
>
> Key: TS-5052
> URL: https://issues.apache.org/jira/browse/TS-5052
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> What we noticed was the following in traffic.out:
> {code}
> Server {0x2af761e0d700} WARNING:  
> Unable to create temporary file /var/trafficserver/
> host.db.syncing, unable to persist hostdb: -13 error:Permission denied
> traffic_server: Segmentation fault (Address not mapped to object 
> [0x28])traffic_server - STACK TRACE: 
> {code}
> Which lead me to dig into it-- and it turns out the issue is related to 
> changes after the HostDB rewrite to move syncing outside of the main NET 
> threads. Before all calls to this syncer where done in a single net thread 
> wherever it was initially scheduled. Now we bounce between ET_TASK threads 
> and ET_NET threads (to avoid switching, lock contention, etc.)-- but the 
> error handlers weren't updated to handle this situation.
> So to fix this, I've created a "set_error" and "return_error" method to the 
> RefCountCacheSerializer which will take this into consideration-- 
> specifically that it will immediately return the error if scheduled in the 
> calling thread-- otherwise it'll reschedule onto that thread *then* return 
> the error.



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

[jira] [Assigned] (TS-5052) Segfault in HostDB sync if something fails while not holding the parent continuation mutex

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-5052:
--

Assignee: Thomas Jackson

> Segfault in HostDB sync if something fails while not holding the parent 
> continuation mutex
> --
>
> Key: TS-5052
> URL: https://issues.apache.org/jira/browse/TS-5052
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> What we noticed was the following in traffic.out:
> {code}
> Server {0x2af761e0d700} WARNING:  
> Unable to create temporary file /var/trafficserver/
> host.db.syncing, unable to persist hostdb: -13 error:Permission denied
> traffic_server: Segmentation fault (Address not mapped to object 
> [0x28])traffic_server - STACK TRACE: 
> {code}
> Which lead me to dig into it-- and it turns out the issue is related to 
> changes after the HostDB rewrite to move syncing outside of the main NET 
> threads. Before all calls to this syncer where done in a single net thread 
> wherever it was initially scheduled. Now we bounce between ET_TASK threads 
> and ET_NET threads (to avoid switching, lock contention, etc.)-- but the 
> error handlers weren't updated to handle this situation.
> So to fix this, I've created a "set_error" and "return_error" method to the 
> RefCountCacheSerializer which will take this into consideration-- 
> specifically that it will immediately return the error if scheduled in the 
> calling thread-- otherwise it'll reschedule onto that thread *then* return 
> the error.



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

[jira] [Created] (TS-5052) Segfault in HostDB sync if something fails while not holding the parent continuation mutex

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-5052:
--

 Summary: Segfault in HostDB sync if something fails while not 
holding the parent continuation mutex
 Key: TS-5052
 URL: https://issues.apache.org/jira/browse/TS-5052
 Project: Traffic Server
  Issue Type: Bug
Reporter: Thomas Jackson


What we noticed was the following in traffic.out:

{code}
Server {0x2af761e0d700} WARNING:  
Unable to create temporary file /var/trafficserver/
host.db.syncing, unable to persist hostdb: -13 error:Permission denied
traffic_server: Segmentation fault (Address not mapped to object 
[0x28])traffic_server - STACK TRACE: 
{code}

Which lead me to dig into it-- and it turns out the issue is related to changes 
after the HostDB rewrite to move syncing outside of the main NET threads. 
Before all calls to this syncer where done in a single net thread wherever it 
was initially scheduled. Now we bounce between ET_TASK threads and ET_NET 
threads (to avoid switching, lock contention, etc.)-- but the error handlers 
weren't updated to handle this situation.

So to fix this, I've created a "set_error" and "return_error" method to the 
RefCountCacheSerializer which will take this into consideration-- specifically 
that it will immediately return the error if scheduled in the calling thread-- 
otherwise it'll reschedule onto that thread *then* return the error.



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

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

[Leif Hedstrom (JIRA)]

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

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

> 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
> Fix For: 7.1.0
>
>
> 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] [Work logged] (TS-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1218
  
@jrushford Since you are fixing this, please make sure that the new 
behavior is consistent with other plugins that load files. IIRC absolute paths 
are consumes as is, relative paths are relative to the config directory.


Issue Time Tracking
---

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

> The background_fetch plugin fails to check for config files relative to the 
> config dir etc/trafficserver
> 
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0, 7.0.0, 7.1.0
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[GitHub] trafficserver issue #1218: TS-5050: The background_fetch plugin fails to che...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1218
  
@jrushford Since you are fixing this, please make sure that the new 
behavior is consistent with other plugins that load files. IIRC absolute paths 
are consumes as is, relative paths are relative to the config directory.


---
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-5039) Crash when connecting to downed parent.

[Leif Hedstrom (JIRA)]

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

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

> Crash when connecting to downed parent.
> ---
>
> Key: TS-5039
> URL: https://issues.apache.org/jira/browse/TS-5039
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: James Peach
>Assignee: Thomas Jackson
>Priority: Blocker
> Fix For: 7.1.0
>
>
> If you configure a parent proxy on {{127.0.0.1:}} and never start the 
> service, Traffic Server will crash when it fails to connect. Looks like this 
> regression was introduced in TS-4796.



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

[jira] [Work logged] (TS-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1218
  
@zwoop I just put back the code used previous to TS-2682 in 
background_fetch.cc.  Didn't spend too much time on it, just wanted our configs 
to be read wen we deploy 6.2.  I can go back and clean it up.

@jpeach I haven't looked at every remap plugin  to see how they open and 
read they're config files.  Just put back the code from before the regression.


Issue Time Tracking
---

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

> The background_fetch plugin fails to check for config files relative to the 
> config dir etc/trafficserver
> 
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0, 7.0.0, 7.1.0
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[GitHub] trafficserver issue #1218: TS-5050: The background_fetch plugin fails to che...

[jrushford]

Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/1218
  
@zwoop I just put back the code used previous to TS-2682 in 
background_fetch.cc.  Didn't spend too much time on it, just wanted our configs 
to be read wen we deploy 6.2.  I can go back and clean it up.

@jpeach I haven't looked at every remap plugin  to see how they open and 
read they're config files.  Just put back the code from before the regression.


---
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 #1218: TS-5050: The background_fetch plugin fails to che...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/1218
  
Is this change consistent with other plugins are doing?

> On Nov 11, 2016, at 1:07 PM, Leif Hedstrom  
wrote:
> 
> @zwoop approved this pull request.
> 
> I'm ok with this, but it feels a little clunky that we duplicate the 
codes / error checking nested like this. Since it's C++, couldn't we iterate 
over a vector of candidate directories?
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 



---
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-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1218
  
Is this change consistent with other plugins are doing?

> On Nov 11, 2016, at 1:07 PM, Leif Hedstrom  
wrote:
> 
> @zwoop approved this pull request.
> 
> I'm ok with this, but it feels a little clunky that we duplicate the 
codes / error checking nested like this. Since it's C++, couldn't we iterate 
over a vector of candidate directories?
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 



Issue Time Tracking
---

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

> The background_fetch plugin fails to check for config files relative to the 
> config dir etc/trafficserver
> 
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0, 7.0.0, 7.1.0
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[jira] [Work logged] (TS-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> The background_fetch plugin fails to check for config files relative to the 
> config dir etc/trafficserver
> 
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0, 7.0.0, 7.1.0
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[GitHub] trafficserver issue #1218: TS-5050: The background_fetch plugin fails to che...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1218
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1201/ 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-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/1218
  
Please add Milestones, Labels etc...


Issue Time Tracking
---

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

> The background_fetch plugin fails to check for config files relative to the 
> config dir etc/trafficserver
> 
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0, 7.0.0, 7.1.0
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[jira] [Work logged] (TS-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> The background_fetch plugin fails to check for config files relative to the 
> config dir etc/trafficserver
> 
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0, 7.0.0, 7.1.0
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[GitHub] trafficserver issue #1218: TS-5050: The background_fetch plugin fails to che...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1218
  
Please add Milestones, Labels etc...


---
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 #1218: TS-5050: The background_fetch plugin fails to che...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1218
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1094/ 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 #1216: Localized version of Boost.String_Ref.

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/1216
  
I've been working with this, because it was suggested as a replacement for 
`ts::ConstBuffer` which was standard (or would become so) rather than custom 
code. However, my experience so far is it is not a sufficiently rich API to be 
a reasonable replacement for `ts::ConstBuffer`. A primary use for the latter is 
token based parsing and that's noticeably more challenging with these variants 
of string references. Perhaps adding global overloaded functions to do the 
missing parts is the better approach?


---
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-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 11/Nov/16 20:46
Start Date: 11/Nov/16 20:46
Worklog Time Spent: 10m 
  Work Description: GitHub user jrushford opened a pull request:

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

TS-5050: The background_fetch plugin fails to check for config files …

This may be from a regression with TS-2682.  Anyway, with the following 
remap config that we've been using with ATS 5.3.2, the background_fetch config 
file could not be found and read.  The config file is located at 
/opt/trafficserver/etc/trafficserver/bg_fetch.config

@plugin=background_fetch.so @pparam=bg_fetch.config

This works:

@plugin=background_fetch.so @pparam=etc/trafficserver/bg_fetch.config

This PR restores the original behavior so that both configurations shown 
above work.


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

$ git pull https://github.com/jrushford/trafficserver TS-5050

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

https://github.com/apache/trafficserver/pull/1218.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 #1218


commit 42ffc818416a5486d42bb51190f064db05e7e4e5
Author: John J. Rushford 
Date:   2016-11-11T20:31:33Z

TS-5050: The background_fetch plugin fails to check for config files 
relative to the config dir etc/trafficserver.




Issue Time Tracking
---

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

> The background_fetch plugin fails to check for config files relative to the 
> config dir etc/trafficserver
> 
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0, 7.0.0, 7.1.0
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[GitHub] trafficserver pull request #1218: TS-5050: The background_fetch plugin fails...

[jrushford]

GitHub user jrushford opened a pull request:

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

TS-5050: The background_fetch plugin fails to check for config files …

This may be from a regression with TS-2682.  Anyway, with the following 
remap config that we've been using with ATS 5.3.2, the background_fetch config 
file could not be found and read.  The config file is located at 
/opt/trafficserver/etc/trafficserver/bg_fetch.config

@plugin=background_fetch.so @pparam=bg_fetch.config

This works:

@plugin=background_fetch.so @pparam=etc/trafficserver/bg_fetch.config

This PR restores the original behavior so that both configurations shown 
above work.


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

$ git pull https://github.com/jrushford/trafficserver TS-5050

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

https://github.com/apache/trafficserver/pull/1218.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 #1218


commit 42ffc818416a5486d42bb51190f064db05e7e4e5
Author: John J. Rushford 
Date:   2016-11-11T20:31:33Z

TS-5050: The background_fetch plugin fails to check for config files 
relative to the config dir etc/trafficserver.




---
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.
---

Re: [jira] [Created] (TS-5051) Adds a new log tag, proxy server build_number

[James Peach]

You can add this in using the Lua config without adding a custom tag.

> On Nov 11, 2016, at 10:29 AM, Masa Sekimura (JIRA)  wrote:
> 
> Masa Sekimura created TS-5051:
> -
> 
> Summary: Adds a new log tag, proxy server build_number
> Key: TS-5051
> URL: https://issues.apache.org/jira/browse/TS-5051
> Project: Traffic Server
>  Issue Type: Wish
>Reporter: Masa Sekimura
> 
> 
> For A/B testing and such, it would be nice if we can log build_number (eg 
> "6.2.1-12.31").
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

[jira] [Updated] (TS-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver

[John Rushford (JIRA)]

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

John Rushford updated TS-5050:
--
Affects Version/s: 7.1.0
   7.0.0
   6.2.0

> The background_fetch plugin fails to check for config files relative to the 
> config dir etc/trafficserver
> 
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 6.2.0, 7.0.0, 7.1.0
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[jira] [Work started] (TS-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver

[John Rushford (JIRA)]

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

Work on TS-5050 started by John Rushford.
-
> The background_fetch plugin fails to check for config files relative to the 
> config dir etc/trafficserver
> 
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[jira] [Updated] (TS-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver

[John Rushford (JIRA)]

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

John Rushford updated TS-5050:
--
Fix Version/s: 7.1.0

> The background_fetch plugin fails to check for config files relative to the 
> config dir etc/trafficserver
> 
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[jira] [Created] (TS-5051) Adds a new log tag, proxy server build_number

[Masa Sekimura (JIRA)]

Masa Sekimura created TS-5051:
-

 Summary: Adds a new log tag, proxy server build_number
 Key: TS-5051
 URL: https://issues.apache.org/jira/browse/TS-5051
 Project: Traffic Server
  Issue Type: Wish
Reporter: Masa Sekimura


For A/B testing and such, it would be nice if we can log build_number (eg 
"6.2.1-12.31").



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

[jira] [Updated] (TS-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver

[John Rushford (JIRA)]

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

John Rushford updated TS-5050:
--
Summary: The background_fetch plugin fails to check for config files 
relative to the config dir etc/trafficserver  (was: The background_fetch plugin 
no-longer checks for config files in the config dir etc/trafficserver)

> The background_fetch plugin fails to check for config files relative to the 
> config dir etc/trafficserver
> 
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: John Rushford
>Assignee: John Rushford
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[jira] [Created] (TS-5050) The background_fetch plugin no-longer checks for config files in the config dir etc/trafficserver

[John Rushford (JIRA)]

John Rushford created TS-5050:
-

 Summary: The background_fetch plugin no-longer checks for config 
files in the config dir etc/trafficserver
 Key: TS-5050
 URL: https://issues.apache.org/jira/browse/TS-5050
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Reporter: John Rushford


We are currently using the background_fetch plugin with ATS 5.3.2 per remap.   
We configure the background_fetch plugin in remap.config using the relative 
path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
configs, I found that the background_fetch plugin no-longer looks for config 
files relative to the etc/trafficserver configuration directory.

I think that this is a regression from 5.3.2 to 6.2.x and master.  I found that 
in configs.cc, TSConfigDirGet() is no-longer used to check for a config file 
relative to etc/trafficserver.

I'm testing a patch to fix this.



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

[jira] [Assigned] (TS-5050) The background_fetch plugin no-longer checks for config files in the config dir etc/trafficserver

[John Rushford (JIRA)]

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

John Rushford reassigned TS-5050:
-

Assignee: John Rushford

> The background_fetch plugin no-longer checks for config files in the config 
> dir etc/trafficserver
> -
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: John Rushford
>Assignee: John Rushford
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.  
>  We configure the background_fetch plugin in remap.config using the relative 
> path to a config file in etc/trafficserver.  While testing ATS 6.2.1 with our 
> configs, I found that the background_fetch plugin no-longer looks for config 
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master.  I found 
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config 
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.



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

[GitHub] trafficserver issue #1216: Localized version of Boost.String_Ref.

[SolidWallOfCode]

Github user SolidWallOfCode commented on the issue:

https://github.com/apache/trafficserver/pull/1216
  
A derivative of the Boost library has been adopted in to the standard 
library for C++17 making this forward compatible but ATS won't be able to 
depend on that for quite a while. Based on C++11 probably not until 2022 or so. 
Therefore I think it well worth the small effort to put this in now and clean 
it up later.


---
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-5041) CID 1365416: Leak in ts_lua plugin

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> CID 1365416: Leak in ts_lua plugin
> --
>
> Key: TS-5041
> URL: https://issues.apache.org/jira/browse/TS-5041
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {code}
> *** CID 1365416:  Resource leaks  (RESOURCE_LEAK)
> /plugins/experimental/ts_lua/ts_lua_http.c: 458 in 
> ts_lua_http_set_parent_proxy()
> 452 port = luaL_checkinteger(L, 2);
> 453 TSHttpTxnParentProxySet(http_ctx->txnp, target, port);
> 454   } else {
> 455 return luaL_error(L, "incorrect # of arguments for 
> set_parent_proxy, receiving %d instead of 2", n);
> 456   }
> 457
> >>> CID 1365416:  Resource leaks  (RESOURCE_LEAK)
> >>> Variable "target" going out of scope leaks the storage it points to.
> 458   return 0;
> 459 }
> 460
> 461 static int
> 462 ts_lua_http_get_parent_selection_url(lua_State *L)
> 463 {
> {code}



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

[GitHub] trafficserver issue #1217: TS-5041: fix resource leak in ts_lua

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1217
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/1093/ 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-5041) CID 1365416: Leak in ts_lua plugin

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> CID 1365416: Leak in ts_lua plugin
> --
>
> Key: TS-5041
> URL: https://issues.apache.org/jira/browse/TS-5041
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {code}
> *** CID 1365416:  Resource leaks  (RESOURCE_LEAK)
> /plugins/experimental/ts_lua/ts_lua_http.c: 458 in 
> ts_lua_http_set_parent_proxy()
> 452 port = luaL_checkinteger(L, 2);
> 453 TSHttpTxnParentProxySet(http_ctx->txnp, target, port);
> 454   } else {
> 455 return luaL_error(L, "incorrect # of arguments for 
> set_parent_proxy, receiving %d instead of 2", n);
> 456   }
> 457
> >>> CID 1365416:  Resource leaks  (RESOURCE_LEAK)
> >>> Variable "target" going out of scope leaks the storage it points to.
> 458   return 0;
> 459 }
> 460
> 461 static int
> 462 ts_lua_http_get_parent_selection_url(lua_State *L)
> 463 {
> {code}



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

[GitHub] trafficserver issue #1217: TS-5041: fix resource leak in ts_lua

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1217
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/1200/ 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-5041) CID 1365416: Leak in ts_lua plugin

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 11/Nov/16 14:53
Start Date: 11/Nov/16 14:53
Worklog Time Spent: 10m 
  Work Description: GitHub user shukitchan opened a pull request:

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

TS-5041: fix resource leak in ts_lua

@zwoop please take a look. Thanks.

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

$ git pull https://github.com/shukitchan/trafficserver ts5041

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

https://github.com/apache/trafficserver/pull/1217.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 #1217


commit b70cc48e8286ee21e67f586082c3821a5daa3f55
Author: Kit Chan 
Date:   2016-11-11T14:51:52Z

TS-5041: fix resource leak in ts_lua




Issue Time Tracking
---

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

> CID 1365416: Leak in ts_lua plugin
> --
>
> Key: TS-5041
> URL: https://issues.apache.org/jira/browse/TS-5041
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {code}
> *** CID 1365416:  Resource leaks  (RESOURCE_LEAK)
> /plugins/experimental/ts_lua/ts_lua_http.c: 458 in 
> ts_lua_http_set_parent_proxy()
> 452 port = luaL_checkinteger(L, 2);
> 453 TSHttpTxnParentProxySet(http_ctx->txnp, target, port);
> 454   } else {
> 455 return luaL_error(L, "incorrect # of arguments for 
> set_parent_proxy, receiving %d instead of 2", n);
> 456   }
> 457
> >>> CID 1365416:  Resource leaks  (RESOURCE_LEAK)
> >>> Variable "target" going out of scope leaks the storage it points to.
> 458   return 0;
> 459 }
> 460
> 461 static int
> 462 ts_lua_http_get_parent_selection_url(lua_State *L)
> 463 {
> {code}



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

[GitHub] trafficserver pull request #1217: TS-5041: fix resource leak in ts_lua

[shukitchan]

GitHub user shukitchan opened a pull request:

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

TS-5041: fix resource leak in ts_lua

@zwoop please take a look. Thanks.

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

$ git pull https://github.com/shukitchan/trafficserver ts5041

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

https://github.com/apache/trafficserver/pull/1217.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 #1217


commit b70cc48e8286ee21e67f586082c3821a5daa3f55
Author: Kit Chan 
Date:   2016-11-11T14:51:52Z

TS-5041: fix resource leak in ts_lua




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

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-5027:

Fix Version/s: 6.2.1

> 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: 6.2.1, 7.1.0
>
>  Time Spent: 1.5h
>  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=31984=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31984
 ]

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

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

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


Issue Time Tracking
---

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

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

[PSUdaemon]

Github user PSUdaemon closed the pull request at:

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


---
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.
---