[jira] [Resolved] (TS-4376) Header_rewrite: allow variable expansion in set-header

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-4376.
---
   Resolution: Fixed
Fix Version/s: (was: 7.2.0)
   7.0.0

> Header_rewrite: allow variable expansion in set-header
> --
>
> Key: TS-4376
> URL: https://issues.apache.org/jira/browse/TS-4376
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Miles Libbey
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/header_rewrite.en.html#variable-expansion
> indicates that Variable Expansion is only allowed in add-header.  Minimally, 
> set-header should also be able to use Variable Expansion.



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

[jira] [Updated] (TS-4376) Header_rewrite: allow variable expansion in set-header

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4376:
--
Assignee: Eric Schwartz

> Header_rewrite: allow variable expansion in set-header
> --
>
> Key: TS-4376
> URL: https://issues.apache.org/jira/browse/TS-4376
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Miles Libbey
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/header_rewrite.en.html#variable-expansion
> indicates that Variable Expansion is only allowed in add-header.  Minimally, 
> set-header should also be able to use Variable Expansion.



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

[jira] [Work logged] (TS-4376) Header_rewrite: allow variable expansion in set-header

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 04:15
Start Date: 30/Aug/16 04:15
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

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


Issue Time Tracking
---

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

> Header_rewrite: allow variable expansion in set-header
> --
>
> Key: TS-4376
> URL: https://issues.apache.org/jira/browse/TS-4376
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Miles Libbey
> Fix For: 7.2.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/header_rewrite.en.html#variable-expansion
> indicates that Variable Expansion is only allowed in add-header.  Minimally, 
> set-header should also be able to use Variable Expansion.



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

[GitHub] trafficserver pull request #922: TS-4376: Support variable extension in set-...

[zwoop]

Github user zwoop closed the pull request at:

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


---
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 #922: TS-4376: Support variable extension in set-header

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/922
  
:+1:


---
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-4376) Header_rewrite: allow variable expansion in set-header

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 04:06
Start Date: 30/Aug/16 04:06
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/922
  
:+1:


Issue Time Tracking
---

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

> Header_rewrite: allow variable expansion in set-header
> --
>
> Key: TS-4376
> URL: https://issues.apache.org/jira/browse/TS-4376
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Miles Libbey
> Fix For: 7.2.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/header_rewrite.en.html#variable-expansion
> indicates that Variable Expansion is only allowed in add-header.  Minimally, 
> set-header should also be able to use Variable Expansion.



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

[jira] [Work logged] (TS-3577) ATS with --enable-static-proxy does not compile

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 03:59
Start Date: 30/Aug/16 03:59
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/941
  
:+1:


Issue Time Tracking
---

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

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704: 
> undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:711: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:774: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:718: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:737: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:738: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:760: 

[jira] [Work logged] (TS-2482) Problems with SOCKS

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/937
  
:+1:


Issue Time Tracking
---

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

> Problems with SOCKS
> ---
>
> Key: TS-2482
> URL: https://issues.apache.org/jira/browse/TS-2482
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SOCKS
>Reporter: Radim Kolar
>Assignee: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> There are several problems with using SOCKS. I am interested in case when TF 
> is sock client. Client sends HTTP request and TF uses SOCKS server to make 
> connection to internet.
> a/ - not documented enough in default configs
> From default configs comments it seems that for running 
> TF 4.1.2 as socks client, it is sufficient to add one line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="10.0.0.7:9050"
> but socks proxy is not used. If i run tcpdump sniffing packets  TF never 
> tries to connect to that SOCKS.
> From source code - 
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it 
> looks that is needed to set "proxy.config.socks.socks_needed" to activate 
> socks support. This should be documented in both sample files: socks.config 
> and record.config
> b/
> after enabling socks, i am hit by this assert:
> Assertion failed: (ats_is_ip4(_addr)), function init, file Socks.cc, 
> line 65.
> i run on dual stack system (ip4,ip6). 
> This code is setting default destination for SOCKS request? Can not you use 
> just 127.0.0.1 for case if client gets connected over IP6?
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66



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

[GitHub] trafficserver issue #937: TS-2482: Should use target_addr instead of server_...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/937
  
:+1:


---
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 #941: TS-3577: Remove the --enable-static-proxy build op...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/941
  
:+1:


---
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-3577) ATS with --enable-static-proxy does not compile

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 03:50
Start Date: 30/Aug/16 03:50
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/941
  
Yeh, I'm fine with removing it, but maybe at least change the commit 
message (and ideally the Jira Summary too). Such that we an easily release-note 
that we removed this option as well.


Issue Time Tracking
---

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

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704: 
> undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:711: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:774: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:718: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:737: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> 

[GitHub] trafficserver issue #941: TS-3577: Remove the --enable-static-proxy build op...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/941
  
Yeh, I'm fine with removing it, but maybe at least change the commit 
message (and ideally the Jira Summary too). Such that we an easily release-note 
that we removed this option as well.


---
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-3577) ATS with --enable-static-proxy does not compile

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704: 
> undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:711: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:774: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:718: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:737: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:738: 
> undefined reference to 

[jira] [Work logged] (TS-3577) ATS with --enable-static-proxy does not compile

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704: 
> undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:711: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:774: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:718: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:737: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:738: 
> undefined reference to 

[GitHub] trafficserver issue #941: TS-3577: Remove the --enable-static-proxy build op...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/941
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/536/ 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 #941: TS-3577: Remove the --enable-static-proxy build op...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/941
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/640/ 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-3577) ATS with --enable-static-proxy does not compile

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 03:44
Start Date: 30/Aug/16 03:44
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/941
  
@zwoop AFAICT ``--enable-remote-cov-commit`` does nothing. I can nuke it 
too?


Issue Time Tracking
---

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

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704: 
> undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:711: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:774: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:718: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:737: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:738: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> 

[GitHub] trafficserver issue #941: TS-3577: Remove the --enable-static-proxy build op...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/941
  
@zwoop AFAICT ``--enable-remote-cov-commit`` does nothing. I can nuke it 
too?


---
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-4530) Enable proxy.config.hostdb.host_file.path by default

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Enable proxy.config.hostdb.host_file.path by default
> 
>
> Key: TS-4530
> URL: https://issues.apache.org/jira/browse/TS-4530
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: James Peach
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> {{proxy.config.hostdb.host_file.path}} is disabled by default. For 7.0 we 
> should enable it do that Traffic Server meets operators expectations in the 
> default config.



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

[jira] [Work logged] (TS-4263) Session tickets keys in ssl_multicert.config do not work with SNI discovered hosts

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Session tickets keys in ssl_multicert.config do not work with SNI discovered 
> hosts
> --
>
> Key: TS-4263
> URL: https://issues.apache.org/jira/browse/TS-4263
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, SSL
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
>  Labels: A
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> If you have a ssl_multicert.config without dest_ip= rules, i.e. requiring SNI 
> negotiation to get a TLS session, then you can not configure the session 
> ticket keys block, at all. Meaning, there's no way to share the keys across 
> more than one machine.
> I went down a bit of a rathole trying to fix this, but it's somewhat ugly. At 
> the point of resuming a session, the SSL call back provides the 16 byte 
> key-name, but the SNI name is seemingly not available at this point.
> A possible solution is to change the lookups to always be on the 16-byte 
> key-name, and keep a separate lookup table for the key blocks. This is in 
> itself a little ugly, because the ownerships around SSLCertContext is a 
> little murky. But it seems the cleanest, and definitely seemed to have been 
> the intent from OpenSSL's callback signature.
> Another option, which could not be done in the 6.x release cycle, is to 
> remove the ticket_key_name= option from ssl_multicert.config entirely, and 
> only have a single, global key block configured via records.config.



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

[GitHub] trafficserver issue #940: [TS-4530] Enable hostdb.host_file.path by default

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/940
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/534/ 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 #938: TS-4263: Global key block configurable via Records...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/938
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/639/ 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-3577) ATS with --enable-static-proxy does not compile

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 03:34
Start Date: 30/Aug/16 03:34
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/941#discussion_r76725945
  
--- Diff: configure.ac ---
@@ -231,33 +231,6 @@ TS_ARG_ENABLE_VAR([has], [tests])
 AM_CONDITIONAL([BUILD_TESTS], [test 0 -ne $has_tests])
 
 #
-# Force some static linkage (for testing / development only)
-#
-AC_MSG_CHECKING([whether to build a static traffic_server binary])
-AC_ARG_ENABLE([static-proxy], 
[AS_HELP_STRING([--enable-static-proxy],[build a static traffic_server 
binary])], [
-AC_ENABLE_STATIC
-  ], [
-AC_DISABLE_STATIC
-enable_static_proxy=no
-  ]
-)
-AC_MSG_RESULT([$enable_static_proxy])
-TS_ARG_ENABLE_VAR([has],[static-proxy])
-AM_CONDITIONAL([BUILD_STATIC_PROXY], [test 0 -ne $has_static_proxy])
-
-#
--- End diff --

Oops, thanks!


Issue Time Tracking
---

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

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704: 
> undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> 

[jira] [Work logged] (TS-3577) ATS with --enable-static-proxy does not compile

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/trafficserver/pull/941#discussion_r76725878
  
--- Diff: configure.ac ---
@@ -231,33 +231,6 @@ TS_ARG_ENABLE_VAR([has], [tests])
 AM_CONDITIONAL([BUILD_TESTS], [test 0 -ne $has_tests])
 
 #
-# Force some static linkage (for testing / development only)
-#
-AC_MSG_CHECKING([whether to build a static traffic_server binary])
-AC_ARG_ENABLE([static-proxy], 
[AS_HELP_STRING([--enable-static-proxy],[build a static traffic_server 
binary])], [
-AC_ENABLE_STATIC
-  ], [
-AC_DISABLE_STATIC
-enable_static_proxy=no
-  ]
-)
-AC_MSG_RESULT([$enable_static_proxy])
-TS_ARG_ENABLE_VAR([has],[static-proxy])
-AM_CONDITIONAL([BUILD_STATIC_PROXY], [test 0 -ne $has_static_proxy])
-
-#
--- End diff --

Did you intend to remove this as well?


Issue Time Tracking
---

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

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704: 
> undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710: 
> undefined reference to `textBuffer::copyFrom(void 

[GitHub] trafficserver pull request #941: TS-3577: Remove the --enable-static-proxy b...

[jpeach]

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

https://github.com/apache/trafficserver/pull/941#discussion_r76725945
  
--- Diff: configure.ac ---
@@ -231,33 +231,6 @@ TS_ARG_ENABLE_VAR([has], [tests])
 AM_CONDITIONAL([BUILD_TESTS], [test 0 -ne $has_tests])
 
 #
-# Force some static linkage (for testing / development only)
-#
-AC_MSG_CHECKING([whether to build a static traffic_server binary])
-AC_ARG_ENABLE([static-proxy], 
[AS_HELP_STRING([--enable-static-proxy],[build a static traffic_server 
binary])], [
-AC_ENABLE_STATIC
-  ], [
-AC_DISABLE_STATIC
-enable_static_proxy=no
-  ]
-)
-AC_MSG_RESULT([$enable_static_proxy])
-TS_ARG_ENABLE_VAR([has],[static-proxy])
-AM_CONDITIONAL([BUILD_STATIC_PROXY], [test 0 -ne $has_static_proxy])
-
-#
--- End diff --

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

[jira] [Work logged] (TS-4530) Enable proxy.config.hostdb.host_file.path by default

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Enable proxy.config.hostdb.host_file.path by default
> 
>
> Key: TS-4530
> URL: https://issues.apache.org/jira/browse/TS-4530
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: James Peach
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {{proxy.config.hostdb.host_file.path}} is disabled by default. For 7.0 we 
> should enable it do that Traffic Server meets operators expectations in the 
> default config.



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

[GitHub] trafficserver issue #940: [TS-4530] Enable hostdb.host_file.path by default

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/940
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/638/ 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 pull request #941: TS-3577: Remove the --enable-static-proxy b...

[zwoop]

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

https://github.com/apache/trafficserver/pull/941#discussion_r76725878
  
--- Diff: configure.ac ---
@@ -231,33 +231,6 @@ TS_ARG_ENABLE_VAR([has], [tests])
 AM_CONDITIONAL([BUILD_TESTS], [test 0 -ne $has_tests])
 
 #
-# Force some static linkage (for testing / development only)
-#
-AC_MSG_CHECKING([whether to build a static traffic_server binary])
-AC_ARG_ENABLE([static-proxy], 
[AS_HELP_STRING([--enable-static-proxy],[build a static traffic_server 
binary])], [
-AC_ENABLE_STATIC
-  ], [
-AC_DISABLE_STATIC
-enable_static_proxy=no
-  ]
-)
-AC_MSG_RESULT([$enable_static_proxy])
-TS_ARG_ENABLE_VAR([has],[static-proxy])
-AM_CONDITIONAL([BUILD_STATIC_PROXY], [test 0 -ne $has_static_proxy])
-
-#
--- End diff --

Did you intend to remove this as well?


---
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-4263) Session tickets keys in ssl_multicert.config do not work with SNI discovered hosts

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 03:30
Start Date: 30/Aug/16 03:30
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/938
  
make clang-format


Issue Time Tracking
---

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

> Session tickets keys in ssl_multicert.config do not work with SNI discovered 
> hosts
> --
>
> Key: TS-4263
> URL: https://issues.apache.org/jira/browse/TS-4263
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, SSL
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
>  Labels: A
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> If you have a ssl_multicert.config without dest_ip= rules, i.e. requiring SNI 
> negotiation to get a TLS session, then you can not configure the session 
> ticket keys block, at all. Meaning, there's no way to share the keys across 
> more than one machine.
> I went down a bit of a rathole trying to fix this, but it's somewhat ugly. At 
> the point of resuming a session, the SSL call back provides the 16 byte 
> key-name, but the SNI name is seemingly not available at this point.
> A possible solution is to change the lookups to always be on the 16-byte 
> key-name, and keep a separate lookup table for the key blocks. This is in 
> itself a little ugly, because the ownerships around SSLCertContext is a 
> little murky. But it seems the cleanest, and definitely seemed to have been 
> the intent from OpenSSL's callback signature.
> Another option, which could not be done in the 6.x release cycle, is to 
> remove the ticket_key_name= option from ssl_multicert.config entirely, and 
> only have a single, global key block configured via records.config.



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

[GitHub] trafficserver issue #938: TS-4263: Global key block configurable via Records...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/938
  
make clang-format


---
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-4263) Session tickets keys in ssl_multicert.config do not work with SNI discovered hosts

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Session tickets keys in ssl_multicert.config do not work with SNI discovered 
> hosts
> --
>
> Key: TS-4263
> URL: https://issues.apache.org/jira/browse/TS-4263
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, SSL
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
>  Labels: A
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> If you have a ssl_multicert.config without dest_ip= rules, i.e. requiring SNI 
> negotiation to get a TLS session, then you can not configure the session 
> ticket keys block, at all. Meaning, there's no way to share the keys across 
> more than one machine.
> I went down a bit of a rathole trying to fix this, but it's somewhat ugly. At 
> the point of resuming a session, the SSL call back provides the 16 byte 
> key-name, but the SNI name is seemingly not available at this point.
> A possible solution is to change the lookups to always be on the 16-byte 
> key-name, and keep a separate lookup table for the key blocks. This is in 
> itself a little ugly, because the ownerships around SSLCertContext is a 
> little murky. But it seems the cleanest, and definitely seemed to have been 
> the intent from OpenSSL's callback signature.
> Another option, which could not be done in the 6.x release cycle, is to 
> remove the ticket_key_name= option from ssl_multicert.config entirely, and 
> only have a single, global key block configured via records.config.



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

[GitHub] trafficserver issue #938: TS-4263: Global key block configurable via Records...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/938
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/535/ 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 #938: TS-4263: Global key block configurable via Records...

[jpeach]

Github user jpeach commented on the issue:

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


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

[jira] [Work logged] (TS-4263) Session tickets keys in ssl_multicert.config do not work with SNI discovered hosts

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 03:26
Start Date: 30/Aug/16 03:26
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

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


Issue Time Tracking
---

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

> Session tickets keys in ssl_multicert.config do not work with SNI discovered 
> hosts
> --
>
> Key: TS-4263
> URL: https://issues.apache.org/jira/browse/TS-4263
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, SSL
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
>  Labels: A
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> If you have a ssl_multicert.config without dest_ip= rules, i.e. requiring SNI 
> negotiation to get a TLS session, then you can not configure the session 
> ticket keys block, at all. Meaning, there's no way to share the keys across 
> more than one machine.
> I went down a bit of a rathole trying to fix this, but it's somewhat ugly. At 
> the point of resuming a session, the SSL call back provides the 16 byte 
> key-name, but the SNI name is seemingly not available at this point.
> A possible solution is to change the lookups to always be on the 16-byte 
> key-name, and keep a separate lookup table for the key blocks. This is in 
> itself a little ugly, because the ownerships around SSLCertContext is a 
> little murky. But it seems the cleanest, and definitely seemed to have been 
> the intent from OpenSSL's callback signature.
> Another option, which could not be done in the 6.x release cycle, is to 
> remove the ticket_key_name= option from ssl_multicert.config entirely, and 
> only have a single, global key block configured via records.config.



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

[jira] [Work logged] (TS-4530) Enable proxy.config.hostdb.host_file.path by default

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 03:24
Start Date: 30/Aug/16 03:24
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/940
  
I'm +1 on this. @jacksontj ? @SolidWallOfCode ?


Issue Time Tracking
---

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

> Enable proxy.config.hostdb.host_file.path by default
> 
>
> Key: TS-4530
> URL: https://issues.apache.org/jira/browse/TS-4530
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: James Peach
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {{proxy.config.hostdb.host_file.path}} is disabled by default. For 7.0 we 
> should enable it do that Traffic Server meets operators expectations in the 
> default config.



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

[GitHub] trafficserver issue #940: [TS-4530] Enable hostdb.host_file.path by default

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/940
  
I'm +1 on this. @jacksontj ? @SolidWallOfCode ?


---
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-2482) Problems with SOCKS

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 03:24
Start Date: 30/Aug/16 03:24
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/937
  
@oknet the code is fine, it was just a FYI :)


Issue Time Tracking
---

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

> Problems with SOCKS
> ---
>
> Key: TS-2482
> URL: https://issues.apache.org/jira/browse/TS-2482
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SOCKS
>Reporter: Radim Kolar
>Assignee: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> There are several problems with using SOCKS. I am interested in case when TF 
> is sock client. Client sends HTTP request and TF uses SOCKS server to make 
> connection to internet.
> a/ - not documented enough in default configs
> From default configs comments it seems that for running 
> TF 4.1.2 as socks client, it is sufficient to add one line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="10.0.0.7:9050"
> but socks proxy is not used. If i run tcpdump sniffing packets  TF never 
> tries to connect to that SOCKS.
> From source code - 
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it 
> looks that is needed to set "proxy.config.socks.socks_needed" to activate 
> socks support. This should be documented in both sample files: socks.config 
> and record.config
> b/
> after enabling socks, i am hit by this assert:
> Assertion failed: (ats_is_ip4(_addr)), function init, file Socks.cc, 
> line 65.
> i run on dual stack system (ip4,ip6). 
> This code is setting default destination for SOCKS request? Can not you use 
> just 127.0.0.1 for case if client gets connected over IP6?
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66



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

[jira] [Work logged] (TS-4530) Enable proxy.config.hostdb.host_file.path by default

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 03:24
Start Date: 30/Aug/16 03:24
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

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


Issue Time Tracking
---

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

> Enable proxy.config.hostdb.host_file.path by default
> 
>
> Key: TS-4530
> URL: https://issues.apache.org/jira/browse/TS-4530
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: James Peach
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {{proxy.config.hostdb.host_file.path}} is disabled by default. For 7.0 we 
> should enable it do that Traffic Server meets operators expectations in the 
> default config.



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

[GitHub] trafficserver issue #940: [TS-4530] Enable hostdb.host_file.path by default

[jpeach]

Github user jpeach commented on the issue:

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

[GitHub] trafficserver issue #937: TS-2482: Should use target_addr instead of server_...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/937
  
@oknet the code is fine, it was just a FYI :)


---
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-2482) Problems with SOCKS

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 03:22
Start Date: 30/Aug/16 03:22
Worklog Time Spent: 10m 
  Work Description: Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/937
  
@jpeach It is conditional assert on lock check. Do u means keep the if 
statement and ink_abort inside it ?


Issue Time Tracking
---

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

> Problems with SOCKS
> ---
>
> Key: TS-2482
> URL: https://issues.apache.org/jira/browse/TS-2482
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SOCKS
>Reporter: Radim Kolar
>Assignee: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> There are several problems with using SOCKS. I am interested in case when TF 
> is sock client. Client sends HTTP request and TF uses SOCKS server to make 
> connection to internet.
> a/ - not documented enough in default configs
> From default configs comments it seems that for running 
> TF 4.1.2 as socks client, it is sufficient to add one line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="10.0.0.7:9050"
> but socks proxy is not used. If i run tcpdump sniffing packets  TF never 
> tries to connect to that SOCKS.
> From source code - 
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it 
> looks that is needed to set "proxy.config.socks.socks_needed" to activate 
> socks support. This should be documented in both sample files: socks.config 
> and record.config
> b/
> after enabling socks, i am hit by this assert:
> Assertion failed: (ats_is_ip4(_addr)), function init, file Socks.cc, 
> line 65.
> i run on dual stack system (ip4,ip6). 
> This code is setting default destination for SOCKS request? Can not you use 
> just 127.0.0.1 for case if client gets connected over IP6?
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66



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

[GitHub] trafficserver issue #937: TS-2482: Should use target_addr instead of server_...

[oknet]

Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/937
  
@jpeach It is conditional assert on lock check. Do u means keep the if 
statement and ink_abort inside 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] [Assigned] (TS-4796) ATS not closing origin connections on first RST from client

[Thomas Jackson (JIRA)]

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

Thomas Jackson reassigned TS-4796:
--

Assignee: Thomas Jackson

> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (state_watch_for_client_abort)> (http) [0] 
> [::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http 
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] 
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent 
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather 
> on the next set of bytes from the origin to send-- which end up tripping a 
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event -- 
> which the HTTPTunnel consumer ignores completely. It seems then that when we 
> recieve the WRITE_READY event we need to determine if we are already in the 
> writing state-- and if so, then we should stop the transaction (since we are 
> already edge-triggered).



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

[jira] [Updated] (TS-4796) ATS not closing origin connections on first RST from client

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4796:
---
Description: 
*TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
closing*

As a continuation of TS-4720, while testing that the session is closed when we 
expect-- I found that it isn't.

Although we are now closing the sessions, we aren't doing it as quickly as we 
should. In this client abort case we expect the client to abort, and ATS should 
initially continue to send bytes to the client-- as we are in the half-open 
state. After the first set of bytes are sent to the client-- the client will 
send an RST-- which should signal ATS to stop sending the request (and tear 
down the origin connection etc.).

I'm able to reproduce this locally, and the debug output (with some additional 
comments) looks like below:

{code}
< FIN FROM CLIENT >
[Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
[Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (http) [0] 
[::state_watch_for_client_abort, VC_EVENT_EOS]



< RST FROM CLIENT >
Got an HttpTunnel event 100 
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_tunnel) [0] producer_handler [http server 
VC_EVENT_READ_READY]
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_tunnel) [0] producer_handler_chunked [http 
server VC_EVENT_READ_READY]
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_chunk) read chunk size of 15 bytes
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_chunk) completed read of chunk of 15 bytes
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_redirect) [HttpTunnel::producer_handler] 
enable_redirection: [1 0 0] event: 100
Got an HttpTunnel event 101 
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_tunnel) [0] consumer_handler [user agent 
VC_EVENT_WRITE_READY]
write ready consumer_handler

{code}


In this situation the connection doesn't close here at the RST-- but rather on 
the next set of bytes from the origin to send-- which end up tripping a 
VC_EVENT_ERROR-- and tearing down the connection.

When the client sends the first RST epoll returns a WRITE_READY event -- which 
the HTTPTunnel consumer ignores completely. It seems then that when we recieve 
the WRITE_READY event we need to determine if we are already in the writing 
state-- and if so, then we should stop the transaction (since we are already 
edge-triggered).

  was:
As a continuation of TS-4720, while testing that the session is closed when we 
expect-- I found that it isn't.

Although we are now closing the sessions, we aren't doing it as quickly as we 
should. In this client abort case we expect the client to abort, and ATS should 
initially continue to send bytes to the client-- as we are in the half-open 
state. After the first set of bytes are sent to the client-- the client will 
send an RST-- which should signal ATS to stop sending the request (and tear 
down the origin connection etc.).

I'm able to reproduce this locally, and the debug output (with some additional 
comments) looks like below:

{code}
< FIN FROM CLIENT >
[Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
[Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (http) [0] 
[::state_watch_for_client_abort, VC_EVENT_EOS]



< RST FROM CLIENT >
Got an HttpTunnel event 100 
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_tunnel) [0] producer_handler [http server 
VC_EVENT_READ_READY]
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_tunnel) [0] producer_handler_chunked [http 
server VC_EVENT_READ_READY]
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_chunk) read chunk size of 15 bytes
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_chunk) completed read of chunk of 15 bytes
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_redirect) [HttpTunnel::producer_handler] 
enable_redirection: [1 0 0] event: 100
Got an HttpTunnel event 101 
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_tunnel) [0] consumer_handler [user agent 
VC_EVENT_WRITE_READY]
write ready consumer_handler

{code}


In this situation the connection doesn't close here at the RST-- but rather on 
the next set of bytes from the origin to send-- which end up tripping a 
VC_EVENT_ERROR-- and tearing down the connection.

When the client sends the first RST epoll returns a WRITE_READY event -- which 
the HTTPTunnel consumer ignores completely. It seems then that when we recieve 
the WRITE_READY event we need to determine if we are already in the writing 
state-- and if so, then we should stop the transaction (since we are already 
edge-triggered).


> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
>   

[jira] [Created] (TS-4796) ATS not closing origin connections on first RST from client

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-4796:
--

 Summary: ATS not closing origin connections on first RST from 
client
 Key: TS-4796
 URL: https://issues.apache.org/jira/browse/TS-4796
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Thomas Jackson


As a continuation of TS-4720, while testing that the session is closed when we 
expect-- I found that it isn't.

Although we are now closing the sessions, we aren't doing it as quickly as we 
should. In this client abort case we expect the client to abort, and ATS should 
initially continue to send bytes to the client-- as we are in the half-open 
state. After the first set of bytes are sent to the client-- the client will 
send an RST-- which should signal ATS to stop sending the request (and tear 
down the origin connection etc.).

I'm able to reproduce this locally, and the debug output (with some additional 
comments) looks like below:

{code}
< FIN FROM CLIENT >
[Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
[Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (http) [0] 
[::state_watch_for_client_abort, VC_EVENT_EOS]



< RST FROM CLIENT >
Got an HttpTunnel event 100 
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_tunnel) [0] producer_handler [http server 
VC_EVENT_READ_READY]
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_tunnel) [0] producer_handler_chunked [http 
server VC_EVENT_READ_READY]
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_chunk) read chunk size of 15 bytes
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_chunk) completed read of chunk of 15 bytes
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_redirect) [HttpTunnel::producer_handler] 
enable_redirection: [1 0 0] event: 100
Got an HttpTunnel event 101 
[Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (http_tunnel) [0] consumer_handler [user agent 
VC_EVENT_WRITE_READY]
write ready consumer_handler

{code}


In this situation the connection doesn't close here at the RST-- but rather on 
the next set of bytes from the origin to send-- which end up tripping a 
VC_EVENT_ERROR-- and tearing down the connection.

When the client sends the first RST epoll returns a WRITE_READY event -- which 
the HTTPTunnel consumer ignores completely. It seems then that when we recieve 
the WRITE_READY event we need to determine if we are already in the writing 
state-- and if so, then we should stop the transaction (since we are already 
edge-triggered).



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

[jira] [Updated] (TS-4720) ATS not properly closing origin connections in client abort situations

[Thomas Jackson (JIRA)]

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

Thomas Jackson updated TS-4720:
---
Summary: ATS not properly closing origin connections in client abort 
situations  (was: ATS not properly closing origin connections in client abort 
situationsounce L0proxy in ela4 and idb2 for memory leak)

> ATS not properly closing origin connections in client abort situations
> --
>
> Key: TS-4720
> URL: https://issues.apache.org/jira/browse/TS-4720
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We've noticed that there are some scenarios that ATS doesn't close the origin 
> connection when the client aborts. To reproduce I set up an http server which 
> would return a text/stream sending a message every 10s. In this case, if I do 
> a GET request to the endpoint and then immediately kill the client, the 
> connection to the origin doesn't close until the transaction active timer 
> kicks in. 
> After digging into this, it seems that this is actually due to a bug in the 
> HttpSM-- specifically in how it checks whether a request has a body. The 
> default value for content-length is `-1`, but some checks are `== 0` -- which 
> means that if the request had no content-length header it is treated as a 
> request with a content-length. 
> The particular place that was problematic was the section that enables the 
> vio reader to watch for client aborts-- which specifically isn't enabled for 
> POST/chunked requests as it is enabled later down the call chain (since it 
> needs to handle the buffers itself).



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

[jira] [Commented] (TS-4747) if the connection of parent is not alive, not make the parent host down,which will select the the unavailable host again

[xiangdong chen (JIRA)]

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

xiangdong chen commented on TS-4747:


yes,you are right.because my version is not the laterest version on github,so i 
ignore some detail.you can fix the bug.

> if the connection of parent is not alive, not make the parent host down,which 
> will select the the unavailable host again
> 
>
> Key: TS-4747
> URL: https://issues.apache.org/jira/browse/TS-4747
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> the parent.config is like this:
> dest_domain=www.cxdtest.com parent=“dnstest1.com:80”;round_bin=strict
> and the dnstest1.com contains two ip:
> 192.168.1.1 （but it was down）
> 192.168.1.2
> if the request go to the parent, and the parent is domain,which contains 
> multi ip. if one ip is down,but we not make the host down ,if the next 
> request is comming, it will choice this ip again. we should make the host 
> down.
> fix code on HttpTransact::handle_response_from_parent(State *s) 
> default: {
> LookingUp_t next_lookup = UNDEFINED_LOOKUP;
> DebugTxn("http_trans", "[hrfp] connection not alive");
> s->state_machine->do_hostdb_update_if_necessary();//added by xdchen, make 
> the host down,line:3606



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

[jira] [Work logged] (TS-4744) ParentConsistentHash::selectParent may select the unavailable parent

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 30/Aug/16 00:20
Start Date: 30/Aug/16 00:20
Worklog Time Spent: 10m 
  Work Description: Github user keith2008 commented on the issue:

https://github.com/apache/trafficserver/pull/939
  
good job.


Issue Time Tracking
---

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

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



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

[GitHub] trafficserver issue #939: TS-4744: ParentConsistentHash::selectParent may se...

[keith2008]

Github user keith2008 commented on the issue:

https://github.com/apache/trafficserver/pull/939
  
good job.


---
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 #941: TS-3577: Remove the --enable-static-proxy build op...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/941
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/533/ 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-3577) ATS with --enable-static-proxy does not compile

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704: 
> undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:711: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:774: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:718: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:737: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:738: 
> undefined reference to 

[jira] [Work logged] (TS-3577) ATS with --enable-static-proxy does not compile

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:704: 
> undefined reference to `ink_rwlock_rdlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:710: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:711: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:774: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:718: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:737: 
> undefined reference to `textBuffer::copyFrom(void const*, unsigned int)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:738: 
> undefined reference to 

[GitHub] trafficserver issue #941: TS-3577: Remove the --enable-static-proxy build op...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/941
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/637/ 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-3577) ATS with --enable-static-proxy does not compile

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Aug/16 23:09
Start Date: 29/Aug/16 23:09
Worklog Time Spent: 10m 
  Work Description: GitHub user jpeach opened a pull request:

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

TS-3577: Remove the --enable-static-proxy build option.

The --enable-static-proxy build option was theorized to help
performance on register-starved 32bit architectures. We don't support
32bit any more and no-one uses this option.

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

$ git pull https://github.com/jpeach/trafficserver fix/3577

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

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


commit 24f529be75bd988cef7ff91f5e397037b164f5d4
Author: James Peach 
Date:   2016-08-29T23:07:15Z

TS-3577: Remove the --enable-static-proxy build option.

The --enable-static-proxy build option was theorized to help
performance on register-starved 32bit architectures. We don't support
32bit any more and no-one uses this option.




Issue Time Tracking
---

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

> ATS with --enable-static-proxy does not compile
> ---
>
> Key: TS-3577
> URL: https://issues.apache.org/jira/browse/TS-3577
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Thomas Jackson
>Assignee: James Peach
>  Labels: yahoo
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Lots of errors in the build:
> {code}
> libtool: link: warning: complete static linking is impossible in this 
> configuration
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord(RecT, 
> char const*, RecDataT, RecData*, RecRawStat*, bool, bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecSetRecord':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:465: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:376: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function `RecReadStatsFile()':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:525: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:562: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecReadConfigFile(bool)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:633: 
> undefined reference to `ink_rwlock_wrlock(ink_rwlock*)'
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:639: 
> undefined reference to `ink_rwlock_unlock(ink_rwlock*)'
> ../lib/records/librecords_p.a(P_RecCore.o): In function 
> `RecSyncConfigToTB(textBuffer*, bool*)':
> /var/jenkins/workspace/tsqa-master/src/lib/records/P_RecCore.cc:702: 
> undefined reference to `textBuffer::reUse()'
> 

[GitHub] trafficserver pull request #941: TS-3577: Remove the --enable-static-proxy b...

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-3577: Remove the --enable-static-proxy build option.

The --enable-static-proxy build option was theorized to help
performance on register-starved 32bit architectures. We don't support
32bit any more and no-one uses this option.

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

$ git pull https://github.com/jpeach/trafficserver fix/3577

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

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


commit 24f529be75bd988cef7ff91f5e397037b164f5d4
Author: James Peach 
Date:   2016-08-29T23:07:15Z

TS-3577: Remove the --enable-static-proxy build option.

The --enable-static-proxy build option was theorized to help
performance on register-starved 32bit architectures. We don't support
32bit any more and no-one uses this option.




---
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-4621) Add proxy.config.disable_configuration_modification to default records.config

[James Peach (JIRA)]

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

James Peach commented on TS-4621:
-

Yes.

> Add proxy.config.disable_configuration_modification to default records.config
> -
>
> Key: TS-4621
> URL: https://issues.apache.org/jira/browse/TS-4621
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> I think that {{proxy.config.disable_configuration_modification}} is a pretty 
> common setting to want to toggle since most operators will manage 
> {{records.config}} with automation. Maybe we should add it to the default 
> {{records.config}}.



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

[jira] [Resolved] (TS-4336) Rename MIMEParseResult constant

[James Peach (JIRA)]

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

James Peach resolved TS-4336.
-
Resolution: Fixed

> Rename MIMEParseResult constant
> ---
>
> Key: TS-4336
> URL: https://issues.apache.org/jira/browse/TS-4336
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: MIME
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> {{MIMEParseResult}} has a common value {{PARSE_ERROR}} which is difficult to 
> distinguish from the the {{ServerState_t}} of the same name. We should rename 
> these for clarity.



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

[jira] [Resolved] (TS-4768) Remove log collation feature

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4768.

Resolution: Won't Fix

We decided to keep log collation in the 7.0.0 release.

> Remove log collation feature
> 
>
> Key: TS-4768
> URL: https://issues.apache.org/jira/browse/TS-4768
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: incompatible
>
> An alternative solution to log collation is to log to a pipe and have an 
> external process take care of log collation.  Here is the documentation for 
> log collation:
> https://docs.trafficserver.apache.org/en/latest/admin-guide/monitoring/logging/log-collation.en.html
>  
> The proposal is to remove the configurations options, statistics, and code 
> for log collation.



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

[jira] [Updated] (TS-4768) Remove log collation feature

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4768:
---
Fix Version/s: (was: 7.0.0)

> Remove log collation feature
> 
>
> Key: TS-4768
> URL: https://issues.apache.org/jira/browse/TS-4768
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: incompatible
>
> An alternative solution to log collation is to log to a pipe and have an 
> external process take care of log collation.  Here is the documentation for 
> log collation:
> https://docs.trafficserver.apache.org/en/latest/admin-guide/monitoring/logging/log-collation.en.html
>  
> The proposal is to remove the configurations options, statistics, and code 
> for log collation.



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

[jira] [Commented] (TS-4747) if the connection of parent is not alive, not make the parent host down,which will select the the unavailable host again

[John Rushford (JIRA)]

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

John Rushford commented on TS-4747:
---

[~keith2008] - Did this change test okay?  I am wondering if 
do_hostdb_update_if_necessary() should be called after 
s->current.server->connect_result = ENOTCONN; on line 3616 as 
do_hostdb_update_if_necessary() checks "connect_result" through a call to:  
t_state.current.server->had_connect_fail().

So in other words, should we call do_hostdb_update_if_necessary() only after 
connect_result is updated to ENOTCONN?

> if the connection of parent is not alive, not make the parent host down,which 
> will select the the unavailable host again
> 
>
> Key: TS-4747
> URL: https://issues.apache.org/jira/browse/TS-4747
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> the parent.config is like this:
> dest_domain=www.cxdtest.com parent=“dnstest1.com:80”;round_bin=strict
> and the dnstest1.com contains two ip:
> 192.168.1.1 （but it was down）
> 192.168.1.2
> if the request go to the parent, and the parent is domain,which contains 
> multi ip. if one ip is down,but we not make the host down ,if the next 
> request is comming, it will choice this ip again. we should make the host 
> down.
> fix code on HttpTransact::handle_response_from_parent(State *s) 
> default: {
> LookingUp_t next_lookup = UNDEFINED_LOOKUP;
> DebugTxn("http_trans", "[hrfp] connection not alive");
> s->state_machine->do_hostdb_update_if_necessary();//added by xdchen, make 
> the host down,line:3606



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

[jira] [Commented] (TS-4778) CID 1361874: Null pointer dereferences (REVERSE_INULL) /mgmt/api/CfgContextManager.cc:

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-4778:
---

This is from Coverity? Do we know where it's being dereferenced? 

> CID 1361874:  Null pointer dereferences  (REVERSE_INULL) 
> /mgmt/api/CfgContextManager.cc:
> 
>
> Key: TS-4778
> URL: https://issues.apache.org/jira/browse/TS-4778
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> Not sure why this showed up now, but it did...
> {code}
> *** CID 1361874:  Null pointer dereferences  (REVERSE_INULL)
> /mgmt/api/CfgContextManager.cc: 201 in CfgContextGet(CfgContext *)()
> 195   ats_free(old_text); // need to free memory
> 196   return ret;
> 197 }
> 198   }
> 199   delete (rule_list); // free RuleList memory
> 200   // TODO: Hmmm, this looks almost like a memory leak, why the strcmp 
> ??
>CID 1361874:  Null pointer dereferences  (REVERSE_INULL)
>Null-checking "old_text" suggests that it may be null, but it has already 
> been dereferenced on all paths leading to the check.
> 201   if (old_text && strcmp(old_text, "") != 0) {
> 202 ats_free(old_text); // need to free memory
> 203   }
> 204   return TS_ERR_OKAY;
> 205 }
> 206 
> {code}



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

[jira] [Work logged] (TS-4530) Enable proxy.config.hostdb.host_file.path by default

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Aug/16 21:20
Start Date: 29/Aug/16 21:20
Worklog Time Spent: 10m 
  Work Description: GitHub user ericcarlschwartz opened a pull request:

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

[TS-4530] Enable hostdb.host_file.path by default



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

$ git pull https://github.com/ericcarlschwartz/trafficserver TS-4530

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

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


commit ef8759f6372c4a7447c34fe2c3eee0ee87453b28
Author: Eric Schwartz 
Date:   2016-08-29T21:19:17Z

[TS-4530] Enable hostdb.host_file.path by default




Issue Time Tracking
---

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

> Enable proxy.config.hostdb.host_file.path by default
> 
>
> Key: TS-4530
> URL: https://issues.apache.org/jira/browse/TS-4530
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: James Peach
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{proxy.config.hostdb.host_file.path}} is disabled by default. For 7.0 we 
> should enable it do that Traffic Server meets operators expectations in the 
> default config.



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

[GitHub] trafficserver pull request #940: [TS-4530] Enable hostdb.host_file.path by d...

[ericcarlschwartz]

GitHub user ericcarlschwartz opened a pull request:

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

[TS-4530] Enable hostdb.host_file.path by default



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

$ git pull https://github.com/ericcarlschwartz/trafficserver TS-4530

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

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


commit ef8759f6372c4a7447c34fe2c3eee0ee87453b28
Author: Eric Schwartz 
Date:   2016-08-29T21:19:17Z

[TS-4530] Enable hostdb.host_file.path by default




---
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 #928: Ts 4423

[ericcarlschwartz]

Github user ericcarlschwartz commented on the issue:

https://github.com/apache/trafficserver/pull/928
  
That sounds good to me. Will try to adhere to in the future. I just went 
with "Update Show Location Options" for this guy


---
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-4744) ParentConsistentHash::selectParent may select the unavailable parent

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



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

[GitHub] trafficserver issue #939: TS-4744: ParentConsistentHash::selectParent may se...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/939
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/532/ 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-4744) ParentConsistentHash::selectParent may select the unavailable parent

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



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

[GitHub] trafficserver issue #939: TS-4744: ParentConsistentHash::selectParent may se...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/939
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/636/ 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-4744) ParentConsistentHash::selectParent may select the unavailable parent

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



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

[GitHub] trafficserver issue #939: TS-4744: ParentConsistentHash::selectParent may se...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/939
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/531/ 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-4744) ParentConsistentHash::selectParent may select the unavailable parent

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



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

[GitHub] trafficserver issue #939: TS-4744: ParentConsistentHash::selectParent may se...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/939
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/635/ 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-4744) ParentConsistentHash::selectParent may select the unavailable parent

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Aug/16 20:24
Start Date: 29/Aug/16 20:24
Worklog Time Spent: 10m 
  Work Description: Github user jrushford commented on the issue:

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


Issue Time Tracking
---

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

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



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

[GitHub] trafficserver issue #939: TS-4744: ParentConsistentHash::selectParent may se...

[jrushford]

Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/939
  
[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-4744) ParentConsistentHash::selectParent may select the unavailable parent

[John Rushford (JIRA)]

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

John Rushford commented on TS-4744:
---

I created a new pull request for @keith2008, #939.  #900 had merge conflicts.

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



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

[jira] [Work logged] (TS-4744) ParentConsistentHash::selectParent may select the unavailable parent

[ASF GitHub Bot (JIRA)]

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

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

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

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

TS-4744: ParentConsistentHash::selectParent may select the unavailable 
parent.

I've created this pull request on behalf of @keith2008 who found the issue 
and opened the JIRA.  His pull request had merge conflicts and he has asked me 
to resolve them and submit this new PR for TS-4744.

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

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

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

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


commit 1112b6c958669815fcd8c78e49d060b2664f815d
Author: John J. Rushford 
Date:   2016-08-29T20:07:23Z

TS-4744: ParentConsistentHash::selectParent may select the unavailable 
parent.




Issue Time Tracking
---

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

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



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

[GitHub] trafficserver pull request #939: TS-4744: ParentConsistentHash::selectParent...

[jrushford]

GitHub user jrushford opened a pull request:

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

TS-4744: ParentConsistentHash::selectParent may select the unavailable 
parent.

I've created this pull request on behalf of @keith2008 who found the issue 
and opened the JIRA.  His pull request had merge conflicts and he has asked me 
to resolve them and submit this new PR for TS-4744.

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

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

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

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


commit 1112b6c958669815fcd8c78e49d060b2664f815d
Author: John J. Rushford 
Date:   2016-08-29T20:07:23Z

TS-4744: ParentConsistentHash::selectParent may select the unavailable 
parent.




---
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-4744) ParentConsistentHash::selectParent may select the unavailable parent

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Aug/16 20:12
Start Date: 29/Aug/16 20:12
Worklog Time Spent: 10m 
  Work Description: Github user jrushford closed the pull request at:

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


Issue Time Tracking
---

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

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



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

[jira] [Work logged] (TS-4744) ParentConsistentHash::selectParent may select the unavailable parent

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Aug/16 20:12
Start Date: 29/Aug/16 20:12
Worklog Time Spent: 10m 
  Work Description: Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/900
  
Traded emails with keith2008 and he asked me to resolvle the merge 
conflict.  I'm going to close ths PR and open another one with his code 
changes.  I'm +1 on the changes.


Issue Time Tracking
---

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

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



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

[GitHub] trafficserver issue #900: TS-4744: ParentConsistentHash::selectParent may se...

[jrushford]

Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/900
  
Traded emails with keith2008 and he asked me to resolvle the merge 
conflict.  I'm going to close ths PR and open another one with his code 
changes.  I'm +1 on the changes.


---
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 #900: TS-4744: ParentConsistentHash::selectParent...

[jrushford]

Github user jrushford closed the pull request at:

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


---
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-4707) Parent Consistent Hash Selection - add fname and maxdirs options.

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Aug/16 19:12
Start Date: 29/Aug/16 19:12
Worklog Time Spent: 10m 
  Work Description: Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/834
  
@zwoop @pbchou - This looks okay to me but, what do you think of modifying 
the parent selection API to pass the Http transaction state then there would be 
no need for the mime header.  Currently the parent selection functions look 
like this:

```
s->parent_params->findParent(>request_data, >parent_result);
s->parent_params->nextParent(>request_data, >parent_result);
s->parent_params->apiParentExists(>request_data)
s->parent_params->parentExists(>request_data)

new API calls:

s->parent_params->findParent(s);
s->parent_params->nextParent(s);
s->parent_params->apiParentExists(s)
s->parent_params->parentExists(s)
```


Issue Time Tracking
---

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

> Parent Consistent Hash Selection - add fname and maxdirs options.
> -
>
> Key: TS-4707
> URL: https://issues.apache.org/jira/browse/TS-4707
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: Peter Chou
>Assignee: Peter Chou
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> This enhancement adds two options, "fname" and "maxdirs", which can be used 
> to exclude the file-name and some of the directories in the path. The 
> remaining portions of the path are then used as part of the hash computation 
> for selecting among multiple parent caches.
> For our usage, it was desirable from an operational perspective to direct all 
> components of particular sub-tree to a single parent cache (to simplify 
> trouble-shooting, pre-loading, etc.). This can be achieved by excluding the 
> query-string, file-name, and right-most portions of the path from the hash 
> computation.



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

[GitHub] trafficserver issue #834: TS-4707 : Parent Consistent Hash Selection - add f...

[jrushford]

Github user jrushford commented on the issue:

https://github.com/apache/trafficserver/pull/834
  
@zwoop @pbchou - This looks okay to me but, what do you think of modifying 
the parent selection API to pass the Http transaction state then there would be 
no need for the mime header.  Currently the parent selection functions look 
like this:

```
s->parent_params->findParent(>request_data, >parent_result);
s->parent_params->nextParent(>request_data, >parent_result);
s->parent_params->apiParentExists(>request_data)
s->parent_params->parentExists(>request_data)

new API calls:

s->parent_params->findParent(s);
s->parent_params->nextParent(s);
s->parent_params->apiParentExists(s)
s->parent_params->parentExists(s)
```


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

[jira] [Created] (TS-4795) No way to copy Url objects

[James Peach (JIRA)]

James Peach created TS-4795:
---

 Summary: No way to copy Url objects
 Key: TS-4795
 URL: https://issues.apache.org/jira/browse/TS-4795
 Project: Traffic Server
  Issue Type: Bug
  Components: CPP API
Reporter: James Peach
Assignee: Brian Geffon


When using the C++ API, there's no clean way to copy {{Url}} objects. The 
closest you can get is piece-wise copying of all the components. I'd like to 
just be able to {{TSUrlCopy}} the pristine URL into the server request URL.



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

[jira] [Updated] (TS-802) Unique KA pools for SOCKS/src IP parameters

[James Peach (JIRA)]

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

James Peach updated TS-802:
---
Component/s: SOCKS

> Unique KA pools for SOCKS/src IP parameters
> ---
>
> Key: TS-802
> URL: https://issues.apache.org/jira/browse/TS-802
> Project: Traffic Server
>  Issue Type: Wish
>  Components: HTTP, SOCKS
>Reporter: M. Nunberg
>
> From what I've observed, ATS' keepalive/connection cache only indexes by the 
> OS server or next proxy server, but not by other types of 
> connection/transport/socket parameters, specifically in my case, negotiated 
> SOCKS connections and outgoing connections which are bound to a specific 
> source IP
> Is it possible to have such functionality in the near future? Currently I've 
> been forced to write my own 'KA gateway' which pretends to be an HTTP server 
> (to which ATS can maintain unique connections) and have that do SOCKS/source 
> ip bind()ing for me. 



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

[jira] [Commented] (TS-803) Fix SOCKS breakage and allow for setting next-hop SOCKS

[James Peach (JIRA)]

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

James Peach commented on TS-803:


[~oknet] Are you interested in taking a look at this patch?

> Fix SOCKS breakage and allow for setting next-hop SOCKS
> ---
>
> Key: TS-803
> URL: https://issues.apache.org/jira/browse/TS-803
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network, SOCKS
>Affects Versions: 3.0.0
> Environment: Wherever ATS might run
>Reporter: M. Nunberg
>
> Here is a patch I drew up a few months ago against a snapshot of ATS/2.1.7 
> unstable/git. There are some quirks here, and I'm not that sure any more what 
> this patch does exactly. However it:
> 1) Does fix SOCKS connections in general
> 2) Allows setting next-hop SOCKS proxy via the API
> Problems:
> See https://issues.apache.org/jira/browse/TS-802
> This has no effect on connections which are drawn from the connection pool, 
> as it seems ATS currently doesn't maintain unique identities for peripheral 
> connection params (source IP, SOCKS etc); i.e. this only affects new TCP 
> connections to an OS.
> diff -x '*.o' -ru tsorig/iocore/net/I_NetVConnection.h 
> tsgit217/iocore/net/I_NetVConnection.h
> --- tsorig/iocore/net/I_NetVConnection.h2011-03-09 21:43:58.0 
> +
> +++ tsgit217/iocore/net/I_NetVConnection.h2011-03-17 14:37:18.0 
> +
> @@ -120,6 +120,13 @@
>/// Version of SOCKS to use.
>unsigned char socks_version;
> +  struct {
> +  unsigned int ip;
> +  int port;
> +  char *username;
> +  char *password;
> +  } socks_override;
> +
>int socket_recv_bufsize;
>int socket_send_bufsize;
> Only in tsgit217/iocore/net: Makefile
> Only in tsgit217/iocore/net: Makefile.in
> diff -x '*.o' -ru tsorig/iocore/net/P_Socks.h tsgit217/iocore/net/P_Socks.h
> --- tsorig/iocore/net/P_Socks.h2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/P_Socks.h2011-03-17 13:17:20.0 +
> @@ -126,7 +126,7 @@
>unsigned char version;
>bool write_done;
> -
> +  bool manual_parent_selection;
>SocksAuthHandler auth_handler;
>unsigned char socks_cmd;
> @@ -145,7 +145,8 @@
>  SocksEntry():Continuation(NULL), netVConnection(0),
>  ip(0), port(0), server_ip(0), server_port(0), nattempts(0),
> -lerrno(0), timeout(0), version(5), write_done(false), 
> auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
> +lerrno(0), timeout(0), version(5), write_done(false), 
> manual_parent_selection(false),
> +auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
>{
>}
>  };
> diff -x '*.o' -ru tsorig/iocore/net/Socks.cc tsgit217/iocore/net/Socks.cc
> --- tsorig/iocore/net/Socks.cc2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/Socks.cc2011-03-17 13:46:07.0 +
> @@ -73,7 +73,8 @@
>nattempts = 0;
>findServer();
> -  timeout = this_ethread()->schedule_in(this, 
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> +//  timeout = this_ethread()->schedule_in(this, 
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> +  timeout = this_ethread()->schedule_in(this, HRTIME_SECONDS(5));
>write_done = false;
>  }
> @@ -81,6 +82,15 @@
>  SocksEntry::findServer()
>  {
>nattempts++;
> +  if(manual_parent_selection) {
> +  if(nattempts > 1) {
> +  //Nullify IP and PORT
> +  server_ip = -1;
> +  server_port = 0;
> +  }
> +  Debug("mndebug(Socks)", "findServer() is a noop with manual socks 
> selection");
> +  return;
> +  }
>  #ifdef SOCKS_WITH_TS
>if (nattempts == 1) {
> @@ -187,7 +197,6 @@
>  }
>  Debug("Socks", "Failed to connect to %u.%u.%u.%u:%d", 
> PRINT_IP(server_ip), server_port);
> -
>  findServer();
>  if (server_ip == (uint32_t) - 1) {
> diff -x '*.o' -ru tsorig/iocore/net/UnixNetProcessor.cc 
> tsgit217/iocore/net/UnixNetProcessor.cc
> --- tsorig/iocore/net/UnixNetProcessor.cc2011-03-09 21:43:58.0 
> +
> +++ tsgit217/iocore/net/UnixNetProcessor.cc2011-03-17 15:48:38.0 
> +
> @@ -228,6 +228,11 @@
>!socks_conf_stuff->ip_range.match(ip))
>  #endif
>  );
> +  if(opt->socks_override.ip >= 1) {
> +  using_socks = true;
> +  Debug("mndebug", "trying to set using_socks to true");
> +  }
> +
>SocksEntry *socksEntry = NULL;
>  #endif
>NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, 1);
> @@ -242,6 +247,16 @@
>if (using_socks) {
>  Debug("Socks", "Using Socks ip: %u.%u.%u.%u:%d\n", PRINT_IP(ip), port);
>  socksEntry = socksAllocator.alloc();
> +
> +if (opt->socks_override.ip) {
> +//Needs to be done before socksEntry->init()
> +socksEntry->server_ip = 

[jira] [Updated] (TS-818) Assertion/abort when starting TS with SOCKS proxy enabled

[James Peach (JIRA)]

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

James Peach updated TS-818:
---
Component/s: SOCKS

> Assertion/abort when starting TS with SOCKS proxy enabled
> -
>
> Key: TS-818
> URL: https://issues.apache.org/jira/browse/TS-818
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SOCKS
>Affects Versions: 2.1.9, 2.1.8
> Environment: Linux x86-64
>Reporter: Yakov Markovitch
>Assignee: Leif Hedstrom
> Fix For: 3.1.0, 3.0.0
>
> Attachments: trafficserver.2.1.8.socks-reg-stat.patch
>
>
> When attempting to start TS with
> CONFIG proxy.config.socks.socks_needed INT 1
> CONFIG proxy.config.socks.socks_version INT 5
> TS aborts at startup with the following message:
> FATAL: RecProcess.cc:738: failed assert `false`



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

[jira] [Updated] (TS-803) Fix SOCKS breakage and allow for setting next-hop SOCKS

[James Peach (JIRA)]

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

James Peach updated TS-803:
---
Component/s: SOCKS

> Fix SOCKS breakage and allow for setting next-hop SOCKS
> ---
>
> Key: TS-803
> URL: https://issues.apache.org/jira/browse/TS-803
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network, SOCKS
>Affects Versions: 3.0.0
> Environment: Wherever ATS might run
>Reporter: M. Nunberg
>
> Here is a patch I drew up a few months ago against a snapshot of ATS/2.1.7 
> unstable/git. There are some quirks here, and I'm not that sure any more what 
> this patch does exactly. However it:
> 1) Does fix SOCKS connections in general
> 2) Allows setting next-hop SOCKS proxy via the API
> Problems:
> See https://issues.apache.org/jira/browse/TS-802
> This has no effect on connections which are drawn from the connection pool, 
> as it seems ATS currently doesn't maintain unique identities for peripheral 
> connection params (source IP, SOCKS etc); i.e. this only affects new TCP 
> connections to an OS.
> diff -x '*.o' -ru tsorig/iocore/net/I_NetVConnection.h 
> tsgit217/iocore/net/I_NetVConnection.h
> --- tsorig/iocore/net/I_NetVConnection.h2011-03-09 21:43:58.0 
> +
> +++ tsgit217/iocore/net/I_NetVConnection.h2011-03-17 14:37:18.0 
> +
> @@ -120,6 +120,13 @@
>/// Version of SOCKS to use.
>unsigned char socks_version;
> +  struct {
> +  unsigned int ip;
> +  int port;
> +  char *username;
> +  char *password;
> +  } socks_override;
> +
>int socket_recv_bufsize;
>int socket_send_bufsize;
> Only in tsgit217/iocore/net: Makefile
> Only in tsgit217/iocore/net: Makefile.in
> diff -x '*.o' -ru tsorig/iocore/net/P_Socks.h tsgit217/iocore/net/P_Socks.h
> --- tsorig/iocore/net/P_Socks.h2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/P_Socks.h2011-03-17 13:17:20.0 +
> @@ -126,7 +126,7 @@
>unsigned char version;
>bool write_done;
> -
> +  bool manual_parent_selection;
>SocksAuthHandler auth_handler;
>unsigned char socks_cmd;
> @@ -145,7 +145,8 @@
>  SocksEntry():Continuation(NULL), netVConnection(0),
>  ip(0), port(0), server_ip(0), server_port(0), nattempts(0),
> -lerrno(0), timeout(0), version(5), write_done(false), 
> auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
> +lerrno(0), timeout(0), version(5), write_done(false), 
> manual_parent_selection(false),
> +auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
>{
>}
>  };
> diff -x '*.o' -ru tsorig/iocore/net/Socks.cc tsgit217/iocore/net/Socks.cc
> --- tsorig/iocore/net/Socks.cc2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/Socks.cc2011-03-17 13:46:07.0 +
> @@ -73,7 +73,8 @@
>nattempts = 0;
>findServer();
> -  timeout = this_ethread()->schedule_in(this, 
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> +//  timeout = this_ethread()->schedule_in(this, 
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> +  timeout = this_ethread()->schedule_in(this, HRTIME_SECONDS(5));
>write_done = false;
>  }
> @@ -81,6 +82,15 @@
>  SocksEntry::findServer()
>  {
>nattempts++;
> +  if(manual_parent_selection) {
> +  if(nattempts > 1) {
> +  //Nullify IP and PORT
> +  server_ip = -1;
> +  server_port = 0;
> +  }
> +  Debug("mndebug(Socks)", "findServer() is a noop with manual socks 
> selection");
> +  return;
> +  }
>  #ifdef SOCKS_WITH_TS
>if (nattempts == 1) {
> @@ -187,7 +197,6 @@
>  }
>  Debug("Socks", "Failed to connect to %u.%u.%u.%u:%d", 
> PRINT_IP(server_ip), server_port);
> -
>  findServer();
>  if (server_ip == (uint32_t) - 1) {
> diff -x '*.o' -ru tsorig/iocore/net/UnixNetProcessor.cc 
> tsgit217/iocore/net/UnixNetProcessor.cc
> --- tsorig/iocore/net/UnixNetProcessor.cc2011-03-09 21:43:58.0 
> +
> +++ tsgit217/iocore/net/UnixNetProcessor.cc2011-03-17 15:48:38.0 
> +
> @@ -228,6 +228,11 @@
>!socks_conf_stuff->ip_range.match(ip))
>  #endif
>  );
> +  if(opt->socks_override.ip >= 1) {
> +  using_socks = true;
> +  Debug("mndebug", "trying to set using_socks to true");
> +  }
> +
>SocksEntry *socksEntry = NULL;
>  #endif
>NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, 1);
> @@ -242,6 +247,16 @@
>if (using_socks) {
>  Debug("Socks", "Using Socks ip: %u.%u.%u.%u:%d\n", PRINT_IP(ip), port);
>  socksEntry = socksAllocator.alloc();
> +
> +if (opt->socks_override.ip) {
> +//Needs to be done before socksEntry->init()
> +socksEntry->server_ip = opt->socks_override.ip;
> +socksEntry->server_port = opt->socks_override.port;
> +

[jira] [Updated] (TS-2513) Missing SOCKS documentation

[James Peach (JIRA)]

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

James Peach updated TS-2513:

Component/s: SOCKS

> Missing SOCKS documentation
> ---
>
> Key: TS-2513
> URL: https://issues.apache.org/jira/browse/TS-2513
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Documentation, SOCKS
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: Docs
>
>
> There's a set of SOCKS related configurations and features, neither of which 
> are currently documented in our admin guides, or reference. However, the old 
> PDF Admin Guide has a number of pages related to SOCKS, which should be 
> converted to Sphinx.



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

[jira] [Updated] (TS-2482) Problems with SOCKS

[James Peach (JIRA)]

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

James Peach updated TS-2482:

Component/s: SOCKS

> Problems with SOCKS
> ---
>
> Key: TS-2482
> URL: https://issues.apache.org/jira/browse/TS-2482
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SOCKS
>Reporter: Radim Kolar
>Assignee: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> There are several problems with using SOCKS. I am interested in case when TF 
> is sock client. Client sends HTTP request and TF uses SOCKS server to make 
> connection to internet.
> a/ - not documented enough in default configs
> From default configs comments it seems that for running 
> TF 4.1.2 as socks client, it is sufficient to add one line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="10.0.0.7:9050"
> but socks proxy is not used. If i run tcpdump sniffing packets  TF never 
> tries to connect to that SOCKS.
> From source code - 
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it 
> looks that is needed to set "proxy.config.socks.socks_needed" to activate 
> socks support. This should be documented in both sample files: socks.config 
> and record.config
> b/
> after enabling socks, i am hit by this assert:
> Assertion failed: (ats_is_ip4(_addr)), function init, file Socks.cc, 
> line 65.
> i run on dual stack system (ip4,ip6). 
> This code is setting default destination for SOCKS request? Can not you use 
> just 127.0.0.1 for case if client gets connected over IP6?
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66



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

[GitHub] trafficserver issue #937: TS-2482: Should use target_addr instead of server_...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/937
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/530/ 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 #937: TS-2482: Should use target_addr instead of server_...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/937
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/634/ 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-2482) Problems with SOCKS

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Problems with SOCKS
> ---
>
> Key: TS-2482
> URL: https://issues.apache.org/jira/browse/TS-2482
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Radim Kolar
>Assignee: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> There are several problems with using SOCKS. I am interested in case when TF 
> is sock client. Client sends HTTP request and TF uses SOCKS server to make 
> connection to internet.
> a/ - not documented enough in default configs
> From default configs comments it seems that for running 
> TF 4.1.2 as socks client, it is sufficient to add one line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="10.0.0.7:9050"
> but socks proxy is not used. If i run tcpdump sniffing packets  TF never 
> tries to connect to that SOCKS.
> From source code - 
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it 
> looks that is needed to set "proxy.config.socks.socks_needed" to activate 
> socks support. This should be documented in both sample files: socks.config 
> and record.config
> b/
> after enabling socks, i am hit by this assert:
> Assertion failed: (ats_is_ip4(_addr)), function init, file Socks.cc, 
> line 65.
> i run on dual stack system (ip4,ip6). 
> This code is setting default destination for SOCKS request? Can not you use 
> just 127.0.0.1 for case if client gets connected over IP6?
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66



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

[jira] [Work logged] (TS-2482) Problems with SOCKS

[ASF GitHub Bot (JIRA)]

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

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

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

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



Issue Time Tracking
---

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

> Problems with SOCKS
> ---
>
> Key: TS-2482
> URL: https://issues.apache.org/jira/browse/TS-2482
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Radim Kolar
>Assignee: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> There are several problems with using SOCKS. I am interested in case when TF 
> is sock client. Client sends HTTP request and TF uses SOCKS server to make 
> connection to internet.
> a/ - not documented enough in default configs
> From default configs comments it seems that for running 
> TF 4.1.2 as socks client, it is sufficient to add one line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="10.0.0.7:9050"
> but socks proxy is not used. If i run tcpdump sniffing packets  TF never 
> tries to connect to that SOCKS.
> From source code - 
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it 
> looks that is needed to set "proxy.config.socks.socks_needed" to activate 
> socks support. This should be documented in both sample files: socks.config 
> and record.config
> b/
> after enabling socks, i am hit by this assert:
> Assertion failed: (ats_is_ip4(_addr)), function init, file Socks.cc, 
> line 65.
> i run on dual stack system (ip4,ip6). 
> This code is setting default destination for SOCKS request? Can not you use 
> just 127.0.0.1 for case if client gets connected over IP6?
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66



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

[jira] [Work logged] (TS-2482) Problems with SOCKS

[ASF GitHub Bot (JIRA)]

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

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

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

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


Issue Time Tracking
---

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

> Problems with SOCKS
> ---
>
> Key: TS-2482
> URL: https://issues.apache.org/jira/browse/TS-2482
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Radim Kolar
>Assignee: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> There are several problems with using SOCKS. I am interested in case when TF 
> is sock client. Client sends HTTP request and TF uses SOCKS server to make 
> connection to internet.
> a/ - not documented enough in default configs
> From default configs comments it seems that for running 
> TF 4.1.2 as socks client, it is sufficient to add one line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="10.0.0.7:9050"
> but socks proxy is not used. If i run tcpdump sniffing packets  TF never 
> tries to connect to that SOCKS.
> From source code - 
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it 
> looks that is needed to set "proxy.config.socks.socks_needed" to activate 
> socks support. This should be documented in both sample files: socks.config 
> and record.config
> b/
> after enabling socks, i am hit by this assert:
> Assertion failed: (ats_is_ip4(_addr)), function init, file Socks.cc, 
> line 65.
> i run on dual stack system (ip4,ip6). 
> This code is setting default destination for SOCKS request? Can not you use 
> just 127.0.0.1 for case if client gets connected over IP6?
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66



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

[GitHub] trafficserver issue #937: TS-2482: Should use target_addr instead of server_...

[jpeach]

Github user jpeach commented on the issue:

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


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

[jira] [Work logged] (TS-2482) Problems with SOCKS

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Aug/16 15:00
Start Date: 29/Aug/16 15:00
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/937
  
@oknet FWIW if you need to assert unconditionally, you can use 
``ink_abort``, which just aborts with a message.


Issue Time Tracking
---

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

> Problems with SOCKS
> ---
>
> Key: TS-2482
> URL: https://issues.apache.org/jira/browse/TS-2482
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Radim Kolar
>Assignee: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> There are several problems with using SOCKS. I am interested in case when TF 
> is sock client. Client sends HTTP request and TF uses SOCKS server to make 
> connection to internet.
> a/ - not documented enough in default configs
> From default configs comments it seems that for running 
> TF 4.1.2 as socks client, it is sufficient to add one line to socks.config:
> dest_ip=0.0.0.0-255.255.255.255 parent="10.0.0.7:9050"
> but socks proxy is not used. If i run tcpdump sniffing packets  TF never 
> tries to connect to that SOCKS.
> From source code - 
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc it 
> looks that is needed to set "proxy.config.socks.socks_needed" to activate 
> socks support. This should be documented in both sample files: socks.config 
> and record.config
> b/
> after enabling socks, i am hit by this assert:
> Assertion failed: (ats_is_ip4(_addr)), function init, file Socks.cc, 
> line 65.
> i run on dual stack system (ip4,ip6). 
> This code is setting default destination for SOCKS request? Can not you use 
> just 127.0.0.1 for case if client gets connected over IP6?
> https://github.com/apache/trafficserver/blob/master/iocore/net/Socks.cc#L66



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

[GitHub] trafficserver issue #937: TS-2482: Should use target_addr instead of server_...

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/937
  
@oknet FWIW if you need to assert unconditionally, you can use 
``ink_abort``, which just aborts with a message.


---
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-4263) Session tickets keys in ssl_multicert.config do not work with SNI discovered hosts

[ASF GitHub Bot (JIRA)]

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

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

Author: ASF GitHub Bot
Created on: 29/Aug/16 14:29
Start Date: 29/Aug/16 14:29
Worklog Time Spent: 10m 
  Work Description: GitHub user persiaAziz opened a pull request:

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

TS-4263: Global key block configurable via Records.config



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

$ git pull https://github.com/persiaAziz/trafficserver TS-4263

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

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


commit 63aca0a5749cf7d77f49e22bbbf82336f70f55e8
Author: Persia Aziz 
Date:   2016-08-26T18:15:12Z

TS-4263: Global key block configurable via Records.config




Issue Time Tracking
---

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

> Session tickets keys in ssl_multicert.config do not work with SNI discovered 
> hosts
> --
>
> Key: TS-4263
> URL: https://issues.apache.org/jira/browse/TS-4263
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, SSL
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
>  Labels: A
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> If you have a ssl_multicert.config without dest_ip= rules, i.e. requiring SNI 
> negotiation to get a TLS session, then you can not configure the session 
> ticket keys block, at all. Meaning, there's no way to share the keys across 
> more than one machine.
> I went down a bit of a rathole trying to fix this, but it's somewhat ugly. At 
> the point of resuming a session, the SSL call back provides the 16 byte 
> key-name, but the SNI name is seemingly not available at this point.
> A possible solution is to change the lookups to always be on the 16-byte 
> key-name, and keep a separate lookup table for the key blocks. This is in 
> itself a little ugly, because the ownerships around SSLCertContext is a 
> little murky. But it seems the cleanest, and definitely seemed to have been 
> the intent from OpenSSL's callback signature.
> Another option, which could not be done in the 6.x release cycle, is to 
> remove the ticket_key_name= option from ssl_multicert.config entirely, and 
> only have a single, global key block configured via records.config.



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

[GitHub] trafficserver pull request #938: TS-4263: Global key block configurable via ...

[persiaAziz]

GitHub user persiaAziz opened a pull request:

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

TS-4263: Global key block configurable via Records.config



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

$ git pull https://github.com/persiaAziz/trafficserver TS-4263

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

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


commit 63aca0a5749cf7d77f49e22bbbf82336f70f55e8
Author: Persia Aziz 
Date:   2016-08-26T18:15:12Z

TS-4263: Global key block configurable via Records.config




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