[jira] [Created] (TS-4056) MemLeak: ～NetAccept() do not free alloc_cache(vc)

[Oknet Xu (JIRA)]

Oknet Xu created TS-4056:


 Summary: MemLeak: ～NetAccept() do not free alloc_cache(vc)
 Key: TS-4056
 URL: https://issues.apache.org/jira/browse/TS-4056
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Oknet Xu


NetAccpet::alloc_cache is a void pointor is used in net_accept().

the alloc_cache does not release after NetAccept canceled.

I'm looking for all code, believe the "alloc_cache" is a bad idea here.

I create a pull request on github: 
https://github.com/apache/trafficserver/pull/366

also add a condition check for vc==NULL after allocate_vc()



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

[jira] [Updated] (TS-4056) MemLeak: ～NetAccept() do not free alloc_cache(vc)

[Zhao Yongming (JIRA)]

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

Zhao Yongming updated TS-4056:
--
Affects Version/s: 6.1.0

> MemLeak: ～NetAccept() do not free alloc_cache(vc)
> -
>
> Key: TS-4056
> URL: https://issues.apache.org/jira/browse/TS-4056
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.0
>Reporter: Oknet Xu
>
> NetAccpet::alloc_cache is a void pointor is used in net_accept().
> the alloc_cache does not release after NetAccept canceled.
> I'm looking for all code, believe the "alloc_cache" is a bad idea here.
> I create a pull request on github: 
> https://github.com/apache/trafficserver/pull/366
> also add a condition check for vc==NULL after allocate_vc()



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

[jira] [Commented] (TS-4047) multiple -rpath options are not handled correctly

[ASF subversion and git services (JIRA)]

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

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

Commit cb3d5f4eaee238e349e68bee34bde5764d94a3b0 in trafficserver's branch 
refs/heads/master from [~jaaju]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=cb3d5f4 ]

TS-4047: consistently handle multiple RPATH options

Using TS_ADDTO to add the custom locations of libraries results in
incorrect "-rpath" directive to the linker. This is because TS_ADDTO
creates a unique list of tokens that it adds to its target.

e.g. ./configure --with-openssl=/usr/local/openssl --with-zlib=/usr/local/zlib

The above results in LIBTOOL_LINK_FLAGS:
  -rpath /usr/local/openssl/lib /usr/local/zlib/lib

The absence of "-rpath" in front of the second path causes an error
in the linker. This is fixed by introducing a new macro TS_ADD_RPATH_TO
that takes a path and adds it with the "-R " prefix.

Also added the influential environmental variable RPATH that can
be used to give an additional value for the rpath.

This closes #324.


> multiple -rpath options are not handled correctly
> -
>
> Key: TS-4047
> URL: https://issues.apache.org/jira/browse/TS-4047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
>
> https://github.com/apache/trafficserver/pull/324
> {quote}
> Using TS_ADDTO to add the custom locations of libraries results in incorrect 
> "-rpath" directive to the linker. This is because TS_ADDTO creates a unique 
> list of tokens that it adds to its target. E.g.,
> ./configure --with-openssl=/usr/local/openssl --with-zlib=/usr/local/zlib
> the above should result in
> LIBTOOL_LINK_FLAGS: -rpath /usr/local/openssl/lib /usr/local/zlib/lib
> The absence of "-rpath" in front of the second path causes an error in the 
> linker!
> This is fixed by introducing a new macro TS_ADD_RPATH_TO that takes a path 
> and adds it with the "-rpath " prefix.
> Also added influential environmental variable RPATH that can be used to give 
> a base value for the rpath. So, the following
> ./configure --with-openssl=/usr/local/openssl --with-zlib=/usr/local/zlib 
> RPATH=/foo
> will result in
> LIBTOOL_LINK_FLAGS: -rpath /foo -rpath /usr/local/zlib/lib -rpath 
> /usr/local/openssl/lib
> {quote}



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

[jira] [Created] (TS-4057) Missing check for system call error

[Daniel Xu (JIRA)]

Daniel Xu created TS-4057:
-

 Summary: Missing check for system call error
 Key: TS-4057
 URL: https://issues.apache.org/jira/browse/TS-4057
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Daniel Xu


`elevating_open()` doesn't check for EACCES in the failure case of `open()`.



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

[jira] [Commented] (TS-4057) Missing check for system call error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4057:


GitHub user danobi opened a pull request:

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

TS-4057 Missing check for system call error

EPERM and EACCES are often consfused for each other.

EPERM means "operation not permitted", ie doing this would not be
in your best interest.
EACCES means "permission denied", meaning if you run this command
as sudo it will work.

Opening a log file will _probably_ never be bad, and even if the
system says so, it shouldn't be bad. So in this case it doesn't
hurt to leave both conditions in here.

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

$ git pull https://github.com/danobi/trafficserver TS-4057

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

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


commit 1a996d5a750b854c2d492ac2f6d20d9e5049cb5b
Author: Daniel Xu 
Date:   2015-12-07T17:03:14Z

TS-4057 Missing check for system call error

EPERM and EACCES are often consfused for each other.

EPERM means "operation not permitted", ie doing this would not be
in your best interest.
EACCES means "permission denied", meaning if you run this command
as sudo it will work.

Opening a log file will _probably_ never be bad, and even if the
system says so, it shouldn't be bad. So in this case it doesn't
hurt to leave both conditions in here.




> Missing check for system call error
> ---
>
> Key: TS-4057
> URL: https://issues.apache.org/jira/browse/TS-4057
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>
> `elevating_open()` doesn't check for EACCES in the failure case of `open()`.



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

[jira] [Commented] (TS-4057) Missing check for system call error

[ASF subversion and git services (JIRA)]

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

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

Commit 59cb070654a6e6a7acdd6509a770478d413f79a6 in trafficserver's branch 
refs/heads/master from [~danobi]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=59cb070 ]

TS-4057: missing check for system call error

EPERM and EACCES are often consfused for each other.

EPERM means "operation not permitted", ie doing this would not be
in your best interest.  EACCES means "permission denied", meaning
if you run this command as sudo it will work. Posix specifies that
open(2) returns EACCES.

Opening a log file will _probably_ never be bad, and even if the
system says so, it shouldn't be bad. So in this case it doesn't
hurt to leave both conditions in here.


> Missing check for system call error
> ---
>
> Key: TS-4057
> URL: https://issues.apache.org/jira/browse/TS-4057
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>
> `elevating_open()` doesn't check for EACCES in the failure case of `open()`.



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

[jira] [Commented] (TS-4057) Missing check for system call error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4057:


Github user asfgit closed the pull request at:

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


> Missing check for system call error
> ---
>
> Key: TS-4057
> URL: https://issues.apache.org/jira/browse/TS-4057
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>
> `elevating_open()` doesn't check for EACCES in the failure case of `open()`.



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

[jira] [Resolved] (TS-4057) Missing check for system call error

[James Peach (JIRA)]

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

James Peach resolved TS-4057.
-
   Resolution: Fixed
 Assignee: James Peach
Fix Version/s: 6.1.0

> Missing check for system call error
> ---
>
> Key: TS-4057
> URL: https://issues.apache.org/jira/browse/TS-4057
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> `elevating_open()` doesn't check for EACCES in the failure case of `open()`.



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

[jira] [Commented] (TS-3418) Second hash ring for consistently hashed parent selection

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3418:


Github user jrushf1239k commented on the pull request:

https://github.com/apache/trafficserver/pull/359#issuecomment-162602947
  
Hi James,

I've squashed several commits and cleaned up the history, I'll be more 
descriptive in the future.  Also, I found that I had left in some code for the 
multi-site origin feature.  I've removed this code and the branch only includes 
the refactor for the secondary hash ring and it's regression tests.  All 
re-testing in my QA environment and regression tests are good.

Thanks
--
John J. Rushford
IPCDN Engineering
1400 Wewatta Street, Denver Colorado 80202
john_rushf...@cable.comcast.com











From: James Peach 
mailto:notificati...@github.com>>
Reply-To: apache/trafficserver 
mailto:re...@reply.github.com>>
Date: Sunday, December 6, 2015 at 5:31 PM
To: apache/trafficserver 
mailto:trafficser...@noreply.github.com>>
Cc: John Rushford 
mailto:john_rushf...@cable.comcast.com>>
Subject: Re: [trafficserver] TS-3418: Second hash ring for consistently 
hashed parent selection (#359)


Hi John. First, let's clean up the commit history on this branch.

  *   please squash the "clang format" and "updated comments" commits into 
their respective previous commits.
  *   for each commit, the subject should be a short description like 
TS-3418: what this commit does"
  *   for each commit, add a longer description in the commit message for 
future generations. What are all the changes in this commit? Why are they 
necessary? Try to include enough description for someone to understand what is 
going on in the commit.

-
Reply to this email directly or view it on 
GitHub.



> Second hash ring for consistently hashed parent selection 
> --
>
> Key: TS-3418
> URL: https://issues.apache.org/jira/browse/TS-3418
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Parent Proxy
>Reporter: Leif Hedstrom
>Assignee: John Rushford
> Fix For: 6.1.0
>
>  Time Spent: 336h
>  Remaining Estimate: 0h
>
> It would be incredibly useful if we allowed for an (optional) second hash 
> ring in the consistent hashing in parent selection. Imagine a setup where you 
> have two set of parent proxies. A child would prefer to always use a parent 
>  in ring  for a set of URLs, . In the case of parent  not being 
> available, instead of rehashing  to the surviving members of ring , we 
> could now hash the URLs to parent  in ring . Upon failure there, we'd 
> then go back and rehash on the primary ring again ().
> This sounds complicated, but is simple in principle. Instead of immediately 
> rehashing content upon a parent failure, we have a backup pool (potentially 
> remote) of parents, that are likely to have the content. The idea is to 
> minimize origin server traffic at all cost.



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

[jira] [Updated] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu updated TS-4058:
--
Summary: Logging doesn't work when TS is compiled and run w/ --with-user  
(was: Logging doesn't work with TS is compiled and run w/ --with-user)

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors



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

[jira] [Created] (TS-4058) Logging doesn't work with TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

Daniel Xu created TS-4058:
-

 Summary: Logging doesn't work with TS is compiled and run w/ 
--with-user
 Key: TS-4058
 URL: https://issues.apache.org/jira/browse/TS-4058
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Reporter: Daniel Xu


ie. we run this _without_ sudo. 

traffic_cop output seems to point to permission errors



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

[jira] [Updated] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-4058:

Assignee: Daniel Xu

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors



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

[jira] [Updated] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu updated TS-4058:
--
Description: 
ie. we run this _without_ sudo. 

traffic_cop output seems to point to permission errors that occur within 
traffic_manager

  was:
ie. we run this _without_ sudo. 

traffic_cop output seems to point to permission errors


> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu commented on TS-4058:
---

The issue is in `Diags::set_std{out,err}_output()` because we indiscriminately 
call `ElevateAccess()`. There are a few issues preventing us from an "easy" 
fix. We need root access for the whole function because there's a bunch of 
`BaseLogFile` logic that assumes we have access to the log files we want. The 
best way (in my opinion) would be to make a function in `ink_cap.cc` that can 
check to see if we are able to elevate to root. We could then just use that 
function to decide if we want to call `ElevateAccess` at all. 

I'm not sure how to implement that feature and I probably won't be able to get 
around to this again for a few weeks.

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu edited comment on TS-4058 at 12/7/15 9:57 PM:


The issue is in `Diags::set_std {out,err} _output()` because we 
indiscriminately call `ElevateAccess()`. There are a few issues preventing us 
from an "easy" fix. We need root access for the whole function because there's 
a bunch of `BaseLogFile` logic that assumes we have access to the log files we 
want. That is to say, we don't have a way to tell if we ran TS as root or as 
some other user. The best way (in my opinion) would be to make a function in 
`ink_cap.cc` that can check to see if we are able to elevate to root. We could 
then just use that function to decide if we want to call `ElevateAccess` at 
all. 

I'm not sure how to implement that feature and I probably won't be able to get 
around to this again for a few weeks.


was (Author: danobi):
The issue is in `Diags::set_std {out,err} _output()` because we 
indiscriminately call `ElevateAccess()`. There are a few issues preventing us 
from an "easy" fix. We need root access for the whole function because there's 
a bunch of `BaseLogFile` logic that assumes we have access to the log files we 
want. The best way (in my opinion) would be to make a function in `ink_cap.cc` 
that can check to see if we are able to elevate to root. We could then just use 
that function to decide if we want to call `ElevateAccess` at all. 

I'm not sure how to implement that feature and I probably won't be able to get 
around to this again for a few weeks.

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu edited comment on TS-4058 at 12/7/15 9:56 PM:


The issue is in `Diags::set_std {out,err} _output()` because we 
indiscriminately call `ElevateAccess()`. There are a few issues preventing us 
from an "easy" fix. We need root access for the whole function because there's 
a bunch of `BaseLogFile` logic that assumes we have access to the log files we 
want. The best way (in my opinion) would be to make a function in `ink_cap.cc` 
that can check to see if we are able to elevate to root. We could then just use 
that function to decide if we want to call `ElevateAccess` at all. 

I'm not sure how to implement that feature and I probably won't be able to get 
around to this again for a few weeks.


was (Author: danobi):
The issue is in `Diags::set_std{out,err}_output()` because we indiscriminately 
call `ElevateAccess()`. There are a few issues preventing us from an "easy" 
fix. We need root access for the whole function because there's a bunch of 
`BaseLogFile` logic that assumes we have access to the log files we want. The 
best way (in my opinion) would be to make a function in `ink_cap.cc` that can 
check to see if we are able to elevate to root. We could then just use that 
function to decide if we want to call `ElevateAccess` at all. 

I'm not sure how to implement that feature and I probably won't be able to get 
around to this again for a few weeks.

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[James Peach (JIRA)]

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

James Peach commented on TS-4058:
-

What is the actual problem here? The description is pretty unclear to me.

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu commented on TS-4058:
---

If you run: 
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && cd 
~ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied. 

The reason it does that is because we always try to elevate our permissions to 
root in Diags without checking if we even have the ability to do that. We can't 
easily fix this problem unless we know if we are allowed to elevate to root. I 
can't figure out how to check if we are allowed to elevate to root. 

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu edited comment on TS-4058 at 12/7/15 10:37 PM:
-

If you run: 
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && cd 
~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied. 

The reason it does that is because we always try to elevate our permissions to 
root in Diags without checking if we even have the ability to do that. We can't 
easily fix this problem unless we know if we are allowed to elevate to root. I 
can't figure out how to check if we are allowed to elevate to root. 


was (Author: danobi):
If you run: 
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && cd 
~ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied. 

The reason it does that is because we always try to elevate our permissions to 
root in Diags without checking if we even have the ability to do that. We can't 
easily fix this problem unless we know if we are allowed to elevate to root. I 
can't figure out how to check if we are allowed to elevate to root. 

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu edited comment on TS-4058 at 12/7/15 10:37 PM:
-

If you run: 
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && make 
install && cd ~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied. 

The reason it does that is because we always try to elevate our permissions to 
root in Diags without checking if we even have the ability to do that. We can't 
easily fix this problem unless we know if we are allowed to elevate to root. I 
can't figure out how to check if we are allowed to elevate to root. 


was (Author: danobi):
If you run: 
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && cd 
~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied. 

The reason it does that is because we always try to elevate our permissions to 
root in Diags without checking if we even have the ability to do that. We can't 
easily fix this problem unless we know if we are allowed to elevate to root. I 
can't figure out how to check if we are allowed to elevate to root. 

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu edited comment on TS-4058 at 12/7/15 10:39 PM:
-

If you run: 
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && make 
install && cd ~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied. 

That happens because we always try to elevate our permissions to root in Diags 
without checking if we have the ability to do that. We can't fix this problem 
unless we know if we are allowed to elevate to root. I can't figure out how to 
check if we are allowed to elevate to root. 


was (Author: danobi):
If you run: 
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && make 
install && cd ~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied. 

The reason it does that is because we always try to elevate our permissions to 
root in Diags without checking if we even have the ability to do that. We can't 
easily fix this problem unless we know if we are allowed to elevate to root. I 
can't figure out how to check if we are allowed to elevate to root. 

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu edited comment on TS-4058 at 12/7/15 10:41 PM:
-

If you run: 
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && make 
install && cd ~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied. You won't see `traffic.out` 
or `diags.log` created or populated in ~/ats-test-env/var/log/trafficserver 
either.

That happens because we always try to elevate our permissions to root in Diags 
without checking if we have the ability to do that. We can't fix this problem 
unless we know if we are allowed to elevate to root. I can't figure out how to 
check if we are allowed to elevate to root. 


was (Author: danobi):
If you run: 
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && make 
install && cd ~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied. 

That happens because we always try to elevate our permissions to root in Diags 
without checking if we have the ability to do that. We can't fix this problem 
unless we know if we are allowed to elevate to root. I can't figure out how to 
check if we are allowed to elevate to root. 

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[James Peach (JIRA)]

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

James Peach commented on TS-4058:
-

This is the {{ElevateAccess}} introduced in TS-306?

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu commented on TS-4058:
---

Yes. It wasn't caught earlier because there's no tests to catch it. 

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Created] (TS-4059) Default value for proxy.config.bin_path does not use value from config.layout

[Craig Forbes (JIRA)]

Craig Forbes created TS-4059:


 Summary: Default value for proxy.config.bin_path does not use 
value from config.layout
 Key: TS-4059
 URL: https://issues.apache.org/jira/browse/TS-4059
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration
Reporter: Craig Forbes


The default value for proxy.config.bin_path defined in RecordsConfig.cc is hard 
coded to "bin".

The value should be TS_BUILD_BINDIR so the value specified at configure time is 
used.



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

[jira] [Created] (TS-4060) traffic_layout JSON option does't always work

[James Peach (JIRA)]

James Peach created TS-4060:
---

 Summary: traffic_layout JSON option does't always work
 Key: TS-4060
 URL: https://issues.apache.org/jira/browse/TS-4060
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration, Tools
Reporter: James Peach


{{traffic_layout --json}} doesn't seem to do anything different to unadorned 
{{traffic_layout}}. I think that it should emit a JSON dictionary like 
{{traffic_layout -f -j}} does.



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

[jira] [Assigned] (TS-4060) traffic_layout JSON option does't always work

[James Peach (JIRA)]

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

James Peach reassigned TS-4060:
---

Assignee: Leif Hedstrom

[~zwoop] I think this is yours ;)

> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Resolved] (TS-4059) Default value for proxy.config.bin_path does not use value from config.layout

[James Peach (JIRA)]

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

James Peach resolved TS-4059.
-
Resolution: Invalid

This is correct. {{bin_dir}} is a directory relative to the installation prefix 
or {{TS_ROOT}}. {{traffic_layout}} will show you the fully expanded value.

> Default value for proxy.config.bin_path does not use value from config.layout
> -
>
> Key: TS-4059
> URL: https://issues.apache.org/jira/browse/TS-4059
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Craig Forbes
>
> The default value for proxy.config.bin_path defined in RecordsConfig.cc is 
> hard coded to "bin".
> The value should be TS_BUILD_BINDIR so the value specified at configure time 
> is used.



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

[jira] [Commented] (TS-4018) Use the huffman encode in HPACK

[ASF subversion and git services (JIRA)]

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

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

Commit 5115a6fd569893428890c925267c8dd0dba848ac in trafficserver's branch 
refs/heads/master from [~maskit]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5115a6f ]

TS-4018: Use HPACK huffman encoding always

This closes #362


> Use the huffman encode in HPACK
> ---
>
> Key: TS-4018
> URL: https://issues.apache.org/jira/browse/TS-4018
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
> Fix For: 6.1.0
>
>
> A huffman encoder is exist in the HPACK implementation (TS-3852) but it 
> doesn't seem to be used. It isn't included in TS-3478 also.
> We could use the huffman encoder.



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

[jira] [Updated] (TS-4018) Use the huffman encode in HPACK

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4018:
---
Assignee: Masakazu Kitajo

> Use the huffman encode in HPACK
> ---
>
> Key: TS-4018
> URL: https://issues.apache.org/jira/browse/TS-4018
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.1.0
>
>
> A huffman encoder is exist in the HPACK implementation (TS-3852) but it 
> doesn't seem to be used. It isn't included in TS-3478 also.
> We could use the huffman encoder.



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

[jira] [Resolved] (TS-4018) Use the huffman encode in HPACK

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4018.

Resolution: Fixed

> Use the huffman encode in HPACK
> ---
>
> Key: TS-4018
> URL: https://issues.apache.org/jira/browse/TS-4018
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.1.0
>
>
> A huffman encoder is exist in the HPACK implementation (TS-3852) but it 
> doesn't seem to be used. It isn't included in TS-3478 also.
> We could use the huffman encoder.



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

[jira] [Commented] (TS-4018) Use the huffman encode in HPACK

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4018:


Github user asfgit closed the pull request at:

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


> Use the huffman encode in HPACK
> ---
>
> Key: TS-4018
> URL: https://issues.apache.org/jira/browse/TS-4018
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.1.0
>
>
> A huffman encoder is exist in the HPACK implementation (TS-3852) but it 
> doesn't seem to be used. It isn't included in TS-3478 also.
> We could use the huffman encoder.



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

[jira] [Commented] (TS-4059) Default value for proxy.config.bin_path does not use value from config.layout

[Zhao Yongming (JIRA)]

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

Zhao Yongming commented on TS-4059:
---

I think that Craig Forbes want the building & installation honor the 
'--bindir=DIRuser executables [EPREFIX/bin]',  which is default to 
'EPREFIX/bin' if not specified, I think you may submit patch if that does not 
work as you wish.

IMO, all the _path config options should be removed as those are binary 
releasing options, as we are now open sourced with all layout configurable, we 
should remove them (or hardcode to the configure specified directory) from 
records config.

patch welcome

FYI

> Default value for proxy.config.bin_path does not use value from config.layout
> -
>
> Key: TS-4059
> URL: https://issues.apache.org/jira/browse/TS-4059
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Craig Forbes
>
> The default value for proxy.config.bin_path defined in RecordsConfig.cc is 
> hard coded to "bin".
> The value should be TS_BUILD_BINDIR so the value specified at configure time 
> is used.



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

[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Zhao Yongming (JIRA)]

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

Zhao Yongming commented on TS-4058:
---

good catch, _cop is design to be run as root, and --with-user=danielxu 
specified the _server to be run as danielxu, that is the current setup. 
currently one unprivileged user should not run _cop, in the past it even fail 
if you want to make install as no-root, haha. in most case we would advice to 
run with _server directly for small testing with _server.

It would be nice if you want can make _cop run with unprivileged user.

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Commented] (TS-4060) traffic_layout JSON option does't always work

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4060:
---

{code}
root@loki 54/1 # ./bin/traffic_layout --json
{
"PREFIX": "/opt/ats",
"BINDIR": "bin",
"SYSCONFDIR": "etc/trafficserver",
"LIBDIR": "/opt/ats/lib",
"LOGDIR": "var/log/trafficserver",
"RUNTIMEDIR": "var/trafficserver",
"PLUGINDIR": "libexec/trafficserver",
"INCLUDEDIR": "/opt/ats/include",
"SNAPSHOTDIR": "etc/trafficserver/snapshots",
"records.config": "etc/trafficserver/records.config",
"remap.config": "etc/trafficserver/remap.config",
"plugin.config": "etc/trafficserver/plugin.config",
"ssl_multicert.config": "etc/trafficserver/ssl_multicert.config",
"storage.config": "etc/trafficserver/storage.config",
"hosting.config": "etc/trafficserver/hosting.config",
"volume.config": "etc/trafficserver/volume.config",
"ip_allow.config": "etc/trafficserver/ip_allow.config"
}
{code}

> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[James Peach (JIRA)]

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

James Peach commented on TS-4058:
-

Running {{traffic_cop}} as an unprivileged user works and is supported. I 
specifically fixed it some time ago and would be quite sad if it was broken in 
the interim. TSQA is designed to run {{traffic_cop}} and also run unprivileged.

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Commented] (TS-4060) traffic_layout JSON option does't always work

[James Peach (JIRA)]

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

James Peach commented on TS-4060:
-

{code}
oarfish:~ jpeach$ /opt/ats/bin/traffic_layout --json
PREFIX: /opt/ats
BINDIR: /opt/ats/bin
SYSCONFDIR: /opt/ats/etc/trafficserver
LIBDIR: /opt/ats/lib
LOGDIR: /opt/ats/var/log/trafficserver
RUNTIMEDIR: /opt/ats/var/trafficserver
PLUGINDIR: /opt/ats/libexec/trafficserver
INCLUDEDIR: /opt/ats/include
SNAPSHOTDIR: /opt/ats/etc/trafficserver/snapshots
records.config: /opt/ats/etc/trafficserver/records.config
remap.config: /opt/ats/etc/trafficserver/remap.config
plugin.config: /opt/ats/etc/trafficserver/plugin.config
ssl_multicert.config: /opt/ats/etc/trafficserver/ssl_multicert.config
storage.config: /opt/ats/etc/trafficserver/storage.config
hosting.config: /opt/ats/etc/trafficserver/hosting.config
volume.config: /opt/ats/etc/trafficserver/volume.config
ip_allow.config: /opt/ats/etc/trafficserver/ip_allow.config
oarfish:~ jpeach$ /opt/ats/bin/traffic_layout --version
Apache Traffic Server - traffic_layout - 6.1.0 - (build # 120321 on Dec  3 2015 
at 21:23:04)
{code}

I built this from HEAD a few days ago.

> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Reopened] (TS-4059) Default value for proxy.config.bin_path does not use value from config.layout

[James Peach (JIRA)]

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

James Peach reopened TS-4059:
-
  Assignee: James Peach

I think I was too hasty here. Thank [~zym] for getting me to re-read the 
description.

{code}
lib/ts/ink_config.h.in:#define TS_BUILD_BINDIR "@rel_bindir@"
{code}

{code}
mgmt/RecordsConfig.cc:  {RECT_CONFIG, "proxy.config.bin_path", RECD_STRING, 
"bin", RECU_NULL, RR_REQUIRED, RECC_NULL, NULL, RECA_READ_ONLY}
{code}

I think [~cpforbes] is correct and we should be using {{TS_BUILD_BINDIR}} here.

> Default value for proxy.config.bin_path does not use value from config.layout
> -
>
> Key: TS-4059
> URL: https://issues.apache.org/jira/browse/TS-4059
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Craig Forbes
>Assignee: James Peach
>
> The default value for proxy.config.bin_path defined in RecordsConfig.cc is 
> hard coded to "bin".
> The value should be TS_BUILD_BINDIR so the value specified at configure time 
> is used.



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

[jira] [Commented] (TS-4060) traffic_layout JSON option does't always work

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4060:
---

I know, the above is with the patch.

> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Commented] (TS-4060) traffic_layout JSON option does't always work

[James Peach (JIRA)]

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

James Peach commented on TS-4060:
-

Oh nice!

> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Updated] (TS-4060) traffic_layout JSON option does't always work

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4060:
--
Fix Version/s: 6.1.0

> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Comment Edited] (TS-4060) traffic_layout JSON option does't always work

[James Peach (JIRA)]

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

James Peach edited comment on TS-4060 at 12/8/15 3:36 AM:
--

Oh nice!

It's surprising that your output has relative paths though. I though they 
should all be absolute?


was (Author: jamespeach):
Oh nice!

> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Commented] (TS-4053) Add hit rate and memory usage regressions for RAM cache, tune CLFUS.

[ASF subversion and git services (JIRA)]

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

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

Commit 9087a4fa39145e799fc66e7d7255f0341eb7d3e3 in trafficserver's branch 
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9087a4f ]

TS-4053 Ignore coverity warning on drand48()

CID 1341740


> Add hit rate and memory usage regressions for RAM cache, tune CLFUS.
> 
>
> Key: TS-4053
> URL: https://issues.apache.org/jira/browse/TS-4053
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: John Plevyak
>Assignee: John Plevyak
>Priority: Minor
> Fix For: 6.1.0
>
>
> It would be nice to have a hit rate and memory usage regression tests for the 
> RAM cache.  In particular comparing LRU and CLFUS.  Once we have this we can 
> tune the CLFUS implementation.



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

[jira] [Commented] (TS-4060) traffic_layout JSON option does't always work

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-4060:
---

Yeah, it's a bug, thanks :).

> traffic_layout JSON option does't always work
> -
>
> Key: TS-4060
> URL: https://issues.apache.org/jira/browse/TS-4060
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Tools
>Reporter: James Peach
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
>
> {{traffic_layout --json}} doesn't seem to do anything different to unadorned 
> {{traffic_layout}}. I think that it should emit a JSON dictionary like 
> {{traffic_layout -f -j}} does.



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

[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu commented on TS-4058:
---

Noted. I'll think about some ideas to avoid these permission issues

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Created] (TS-4061) Optimize HPACK Encoder

[Masaori Koshiba (JIRA)]

Masaori Koshiba created TS-4061:
---

 Summary: Optimize HPACK Encoder
 Key: TS-4061
 URL: https://issues.apache.org/jira/browse/TS-4061
 Project: Traffic Server
  Issue Type: Improvement
  Components: HTTP/2
Reporter: Masaori Koshiba


TS always encode Response Header with Huffman. In some cases, huffman encoded 
data is longer than plain text. It is better to avoid those cases and make 
compression ratio high.

Comparison of compression ratios are in [Compression 
Ratio|https://github.com/http2jp/hpack-test-case/wiki/Compression-Ratio]



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

[jira] [Updated] (TS-4061) Optimize HPACK Encoder

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba updated TS-4061:

Fix Version/s: 6.2.0

> Optimize HPACK Encoder
> --
>
> Key: TS-4061
> URL: https://issues.apache.org/jira/browse/TS-4061
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masaori Koshiba
> Fix For: 6.2.0
>
>
> TS always encode Response Header with Huffman. In some cases, huffman encoded 
> data is longer than plain text. It is better to avoid those cases and make 
> compression ratio high.
> Comparison of compression ratios are in [Compression 
> Ratio|https://github.com/http2jp/hpack-test-case/wiki/Compression-Ratio]



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

[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user

[Daniel Xu (JIRA)]

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

Daniel Xu edited comment on TS-4058 at 12/8/15 6:31 AM:


Noted. I'll think about some ideas to avoid these permission issues. In the 
meantime, an appropriate workaround would just be to run TS as a privileged 
user.


was (Author: danobi):
Noted. I'll think about some ideas to avoid these permission issues

> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo. 
> traffic_cop output seems to point to permission errors that occur within 
> traffic_manager



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

[jira] [Commented] (TS-3478) Indexing header representations on HPACK encoder

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba commented on TS-3478:
-

[~rokubo] Could you resolve conflicts and send a Pull-Request on github?

> Indexing header representations on HPACK encoder
> 
>
> Key: TS-3478
> URL: https://issues.apache.org/jira/browse/TS-3478
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Ryo Okubo
>Assignee: Ryo Okubo
>  Labels: review
> Fix For: 6.1.0
>
> Attachments: indexing.patch
>
>
> Support other header field representations on HPACK encoder.
> http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-12#section-6
> Currently the encoder supports only [Literal Header Field never 
> Indexed|http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-12#section-6.2.3].



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