[jira] [Commented] (TS-3417) Use madvise() with MADV_DONTDUMP option to limit core sizes

[ASF subversion and git services (JIRA)]

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

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

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

TS-3417: Fix MADV_DONTDUMP feature for reclaimable freelist


> Use madvise() with MADV_DONTDUMP option to limit core sizes
> ---
>
> Key: TS-3417
> URL: https://issues.apache.org/jira/browse/TS-3417
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 5.3.0
>
>
> When ATS crashes it often leaves behind very large core files, in the 
> hundreds of gigabytes. A large percentage of these core files are useless 
> data in the IO buffers. We can limit the pages that the kernel dumps with 
> madvise().
> Note: This will only work on Linux 3.4+.



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

[jira] [Updated] (TS-3176) Some DNS stats don't persist through restart.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3176:
--
Assignee: James Peach  (was: Leif Hedstrom)

> Some DNS stats don't persist through restart.
> -
>
> Key: TS-3176
> URL: https://issues.apache.org/jira/browse/TS-3176
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Affects Versions: 5.1.1
> Environment: CentOS Linux 7.0 (Virtual Machine)
>Reporter: Adam W. Dace
>Assignee: James Peach
>Priority: Minor
>  Labels: review
> Fix For: 5.3.0
>
> Attachments: TS-3176.patch
>
>
> I can't speak for all of these, but I've noticed over time when viewing stats 
> through traffic_top the "DNS lookup" stat will happily persist through a 
> restart but at the very least "DNS hits" and the "DNS Hit" percentage will 
> not.
> I'm not really sure what the scoop with "DNS Time" is...for me it's always 
> 0.0.
> Please let me know if there's any testing I can do to help out, I'd offer up 
> a patch but C++ just isn't my cup of tea.



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

[jira] [Commented] (TS-3408) Add a "config describe" command to traffic_ctl

[ASF subversion and git services (JIRA)]

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

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

Commit 45eeaec109220e34395470cad0111d71c407d5a6 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=45eeaec ]

TS-3408: fix typo that mysteriously compiled


> Add a "config describe" command to traffic_ctl
> --
>
> Key: TS-3408
> URL: https://issues.apache.org/jira/browse/TS-3408
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Configuration, Management API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.3.0
>
>
> Add a {{config describe}} command to {{traffic_ctl}} so that operators can 
> get easy access to everything that the records system knows about a 
> configuration variable.



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

[jira] [Commented] (TS-3427) compilation error of atscppapi when configured for a out-of-tree build

[James Peach (JIRA)]

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

James Peach commented on TS-3427:
-

Nope :)

{code}
oarfish:trafficserver.git jpeach$ ./ci/regression --enable-cppapi
...
ld: library not found for -latscppapi
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [HelloWorldPlugin.la] Error 1
{code}

> compilation error of atscppapi when configured for a out-of-tree build
> --
>
> Key: TS-3427
> URL: https://issues.apache.org/jira/browse/TS-3427
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build, CPP API
>Reporter: Bin
>Assignee: Brian Geffon
> Fix For: 6.0.0
>
> Attachments: atscppapi_1.diff
>
>
> Header file not found error when --enable-cppapi is enabled for an 
> out-of-tree build on RHEL 6.4. It has no complaints if it is a in-tree build. 



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

[jira] [Commented] (TS-2325) remap.config .include should support directories

[James Peach (JIRA)]

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

James Peach commented on TS-2325:
-

I'll review and land this on Friday (please poke me). I would like to add a 
config option to make the sorting optional (enabled by default) because I 
guarantee that someone will use this with a foolishly large number entries in a 
directory.

> remap.config .include should support directories
> 
>
> Key: TS-2325
> URL: https://issues.apache.org/jira/browse/TS-2325
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core
>Reporter: James Peach
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: ts2325.diff
>
>
> The remap.config .include directive should support including a directory. The 
> implementation for this would be to simply read all the files in the 
> directory and include each one.
> I don't think the files in the directory should be sorted, since that 
> requires us to read all the names into memory, and there might be a very 
> large number of them. Typical ordering constraints can be expressed using 
> multiple directories.



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

[jira] [Commented] (TS-3432) XDebug X-Cache header erroneously reports "hit-fresh" for mismatched HTTP methods

[James Peach (JIRA)]

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

James Peach commented on TS-3432:
-

The {{xdebug}} plugin gets this value from {{TSHttpTxnCacheLookupStatusGet}}. 
So in this case, it's telling us that the cache lookup was a hit, though 
subsequently the cache value must have been invalidated due to the {{POST}}. I 
agree that this is misleading. The notion of "cache hit" needs to be a bit more 
sophisticated to deal with this.

> XDebug X-Cache header erroneously reports "hit-fresh" for mismatched HTTP 
> methods
> -
>
> Key: TS-3432
> URL: https://issues.apache.org/jira/browse/TS-3432
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 5.2.0
>Reporter: Nick Muerdter
>Priority: Trivial
> Fix For: 6.0.0
>
>
> I noticed the XDebug experimental plugin can sometimes give what appears to 
> be incorrect responses to POST requests if there is a cached GET response at 
> the same URL endpoint. If a GET response is cached at a specific URL, and 
> then a POST request is made to the same URL, the XDebug plugin reports that 
> it's a cache hit according to the "X-Cache: hit-fresh" header. However, 
> TrafficServer is correctly not serving up the cached GET request in response 
> to the POST, so the issue appears to simply be XDebug's "X-Cache" header 
> returning incorrect information.
> Here's a some example scripts that demonstrate the issue. First here's a 
> simple nodejs backend server that will respond to both GET and POST requests:
> {code}
> var http = require("http");
> http.createServer(function(request, response) {
>   if(request.method == 'GET') {
> response.writeHead(200, { 'Cache-Control': 'max-age=300' });
>   } else {
> response.writeHead(200);
>   }
>   response.write('example response');
>   response.end();
> }).listen(3000);
> {code}
> Here's the response to the initial GET request:
> {code}
> $ curl -v -H "X-Debug: X-Cache" "http://127.0.0.1:8080/test";
> * About to connect() to 127.0.0.1 port 8080 (#0)
> *   Trying 127.0.0.1... connected
> * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> > GET /test HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1 
> > Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Host: 127.0.0.1:8080
> > Accept: */*
> > X-Debug: X-Cache
> > 
> < HTTP/1.1 200 OK
> < Cache-Control: max-age=300
> < Date: Sun, 08 Mar 2015 22:12:07 GMT
> < Age: 0
> < Transfer-Encoding: chunked
> < Connection: keep-alive
> < Via: http/1.1  (ApacheTrafficServer/5.2.0 [uScMsSfWpSeN:t cCMi 
> p sS])
> < Server: ATS/5.2.0
> < X-Cache: miss
> < 
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection #0
> example response - HTTP method: GET
> {code}
> Here's the response to a subsequent POST request. Note the "X-Cache: 
> hit-fresh" response header despite the fact that it's not delivering a cached 
> response.
> {code}
> $ curl --data "foo=bar" -H "X-Debug: X-Cache" -v "http://127.0.0.1:8080/test";
> * About to connect() to 127.0.0.1 port 8080 (#0)
> *   Trying 127.0.0.1... connected
> * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> > POST /test HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1 
> > Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Host: 127.0.0.1:8080
> > Accept: */*
> > X-Debug: X-Cache
> > Content-Length: 7
> > Content-Type: application/x-www-form-urlencoded
> > 
> < HTTP/1.1 200 OK
> < Date: Sun, 08 Mar 2015 22:12:32 GMT
> < Age: 0
> < Transfer-Encoding: chunked
> < Connection: keep-alive
> < Via: http/1.1  (ApacheTrafficServer/5.2.0 [uScSsSfDpSeN:t cCDi 
> p sS])
> < Server: ATS/5.2.0
> < X-Cache: hit-fresh
> < 
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection #0
> example response - HTTP method: POST
> {code}
> In this case, I have the detailed Via response headers turned on, and 
> according to the cache-lookup value in there, the POST response is "in cache, 
> stale (a cache “MISS”)" ("cS" code).



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

[jira] [Commented] (TS-3417) Use madvise() with MADV_DONTDUMP option to limit core sizes

[ASF subversion and git services (JIRA)]

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

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

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

TS-3417: Add MADV_DONTDUMP capability


> Use madvise() with MADV_DONTDUMP option to limit core sizes
> ---
>
> Key: TS-3417
> URL: https://issues.apache.org/jira/browse/TS-3417
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 5.3.0
>
>
> When ATS crashes it often leaves behind very large core files, in the 
> hundreds of gigabytes. A large percentage of these core files are useless 
> data in the IO buffers. We can limit the pages that the kernel dumps with 
> madvise().
> Note: This will only work on Linux 3.4+.



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

[jira] [Commented] (TS-3430) why cpu 100% on a occasion?

[Zhaonanli (JIRA)]

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

Zhaonanli commented on TS-3430:
---

i have found this function [ do  while (retry && write_offset);  ] retry 
11108 times in "LogObject::_checkout_write".

> why cpu 100% on a occasion?
> ---
>
> Key: TS-3430
> URL: https://issues.apache.org/jira/browse/TS-3430
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Zhaonanli
> Fix For: sometime
>
>
> trafficserver 4.2.2; Centos 6.5 64bit; 32G mem.
> 1. top:
> Cpu0  : 99.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
> Cpu1  :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu2  : 99.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
> Cpu3  :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu4  :  0.0%us,100.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu5  : 99.0%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu6  :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu7  : 99.0%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu8  : 99.0%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu9  : 99.0%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu10 :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu11 :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu12 :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu13 :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu14 :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Cpu15 :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:  32819596k total, 32507016k used,   312580k free,   325852k buffers
> Swap: 16777212k total,25276k used, 16751936k free, 11826164k cached
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND  
>
> 21089 traffics  20   0 22.2g  18g  29m R 100.1 58.9  17:20.61 [ET_NET 0]  
>
> 21091 traffics  20   0 22.2g  18g  29m R 100.1 58.9  17:11.08 [ET_NET 1]  
> all thread is 100%.
> 2. perf top:
>  58.50%  traffic_server   [.] LogObject::_checkout_write(unsigned 
> long*, unsigned long)
>  34.01%  traffic_server   [.] bool 
> ink_atomic_cas<__int128>(__int128 volatile*, __int128, __int128)
> is log questions?



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

[jira] [Commented] (TS-3176) Some DNS stats don't persist through restart.

[Adam W. Dace (JIRA)]

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

Adam W. Dace commented on TS-3176:
--

Thank you!  :)

> Some DNS stats don't persist through restart.
> -
>
> Key: TS-3176
> URL: https://issues.apache.org/jira/browse/TS-3176
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Affects Versions: 5.1.1
> Environment: CentOS Linux 7.0 (Virtual Machine)
>Reporter: Adam W. Dace
>Assignee: Leif Hedstrom
>Priority: Minor
>  Labels: review
> Fix For: 5.3.0
>
> Attachments: TS-3176.patch
>
>
> I can't speak for all of these, but I've noticed over time when viewing stats 
> through traffic_top the "DNS lookup" stat will happily persist through a 
> restart but at the very least "DNS hits" and the "DNS Hit" percentage will 
> not.
> I'm not really sure what the scoop with "DNS Time" is...for me it's always 
> 0.0.
> Please let me know if there's any testing I can do to help out, I'd offer up 
> a patch but C++ just isn't my cup of tea.



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

[jira] [Commented] (TS-3211) Add support for modifying the SCHEME via header_rewrite

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3211:


Github user sc0ttbeardsley commented on the pull request:

https://github.com/apache/trafficserver/pull/152#issuecomment-77976924
  
Thx guys. As long as it got done I am happy :)


> Add support for modifying the SCHEME via header_rewrite
> ---
>
> Key: TS-3211
> URL: https://issues.apache.org/jira/browse/TS-3211
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Scott Beardsley
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I need a way to rewrite the destination scheme based on a request header. It 
> looks like it was partially added before (I see URL_QUAL_SCHEME in 
> statement.h already) but the actual implementation was missing.
> I will send a PR shortly



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

[jira] [Commented] (TS-3036) Add logging field to define the cache medium used to serve a HIT

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3036:
---








Ah, yeah, the pull request is not what was committed, I took the spirit of the 
pull request, and modified it to fit better in with what we have in the core.

— Leif



> Add logging field to define the cache medium used to serve a HIT
> 
>
> Key: TS-3036
> URL: https://issues.apache.org/jira/browse/TS-3036
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Ryan Frantz
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I want to be able to differentiate between RAM cache HITs and disk cache 
> HITs. Add a logging field to inform the administrator if the HIT came from 
> RAM, at least.



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

[jira] [Commented] (TS-3036) Add logging field to define the cache medium used to serve a HIT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3036:


Github user jacksontj commented on the pull request:

https://github.com/apache/trafficserver/pull/104#issuecomment-77976157
  
That would make sense too, I'm just going off the docs:

```
with a ``chm`` value of
+``-`` the medium was disk cache.
```

Seems odd for it to say "ram" and "-"


> Add logging field to define the cache medium used to serve a HIT
> 
>
> Key: TS-3036
> URL: https://issues.apache.org/jira/browse/TS-3036
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Ryan Frantz
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I want to be able to differentiate between RAM cache HITs and disk cache 
> HITs. Add a logging field to inform the administrator if the HIT came from 
> RAM, at least.



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

[jira] [Commented] (TS-3036) Add logging field to define the cache medium used to serve a HIT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3036:


Github user zwoop commented on the pull request:

https://github.com/apache/trafficserver/pull/104#issuecomment-77975742
  
Hmmm that feels like it'd be a different log tag, no? The intent with this 
field is to show which cache level we are serving out of, e.g RAM vs rotational 
disk vs SSD vs cache cluster etc

Not sure why it's logging - when you get a disk hit, that sounds like a 
big. It should log HIT_DISK. Please reopen the bug if this is not working.

-- Leif 



> On Mar 9, 2015, at 5:40 PM, Thomas Jackson  
wrote:
> 
> Is it possible to log the volume that served the cache response? Right 
now it seems that you log "-" when it hits disk, but it would be nice if we 
could know which disk.
> 
> —
> Reply to this email directly or view it on GitHub.
> 



> Add logging field to define the cache medium used to serve a HIT
> 
>
> Key: TS-3036
> URL: https://issues.apache.org/jira/browse/TS-3036
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Ryan Frantz
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I want to be able to differentiate between RAM cache HITs and disk cache 
> HITs. Add a logging field to inform the administrator if the HIT came from 
> RAM, at least.



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

[jira] [Commented] (TS-3036) Add logging field to define the cache medium used to serve a HIT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3036:


Github user jacksontj commented on the pull request:

https://github.com/apache/trafficserver/pull/104#issuecomment-77974860
  
Is it possible to log the volume that served the cache response? Right now 
it seems that you log "-" when it hits disk, but it would be nice if we could 
know which disk.


> Add logging field to define the cache medium used to serve a HIT
> 
>
> Key: TS-3036
> URL: https://issues.apache.org/jira/browse/TS-3036
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Ryan Frantz
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I want to be able to differentiate between RAM cache HITs and disk cache 
> HITs. Add a logging field to inform the administrator if the HIT came from 
> RAM, at least.



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

[jira] [Commented] (TS-3285) Seg fault when 100 CONT handling is enabled

[Thomas Jackson (JIRA)]

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

Thomas Jackson commented on TS-3285:


This should probably get backported to 5.2. If you do have expect 100 continued 
enabled it crashes *all* the time. We had to backport it to our internal 
release.

> Seg fault when 100 CONT handling is enabled
> ---
>
> Key: TS-3285
> URL: https://issues.apache.org/jira/browse/TS-3285
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 5.3.0
>
>
> With 100 CONT handling enabled in our ats5 production hosts, we are seeing 
> the below seg fault.
> {code}
> (gdb) bt
> #0  0x00316e432925 in raise (sig=6) at 
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1  0x00316e434105 in abort () at abort.c:92
> #2  0x2b6869944458 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3  0x2b6869944525 in ink_fatal_va(int, const char *, typedef 
> __va_list_tag __va_list_tag *) (return_code=1, 
> message_format=0x2b68699518d8 "%s:%d: failed assert `%s`", 
> ap=0x2b686bb1bf00) at ink_error.cc:65
> #4  0x2b68699445ee in ink_fatal (return_code=1, 
> message_format=0x2b68699518d8 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5  0x2b6869943160 in _ink_assert (expression=0x7a984e "buf_index_inout 
> == NULL", file=0x7a96e3 "MIME.cc", line=2676) at ink_assert.cc:37
> #6  0x0068212d in mime_mem_print (src_d=0x2b686bb1c090 "HTTP/1.1", 
> src_l=8, buf_start=0x0, buf_length=-1811908575, 
> buf_index_inout=0x2b686bb1c1bc, buf_chars_to_skip_inout=0x2b686bb1c1b8) 
> at MIME.cc:2676
> #7  0x00671df3 in http_version_print (version=65537, buf=0x0, 
> bufsize=-1811908575, bufindex=0x2b686bb1c1bc, dumpoffset=0x2b686bb1c1b8)
> at HTTP.cc:415
> #8  0x006724fb in http_hdr_print (heap=0x2b6881019010, 
> hdr=0x2b6881019098, buf=0x0, bufsize=-1811908575, bufindex=0x2b686bb1c1bc, 
> dumpoffset=0x2b686bb1c1b8) at HTTP.cc:539
> #9  0x004f259b in HTTPHdr::print (this=0x2b68ac06f058, buf=0x0, 
> bufsize=-1811908575, bufindex=0x2b686bb1c1bc, dumpoffset=0x2b686bb1c1b8)
> at ./hdrs/HTTP.h:897
> #10 0x005da903 in HttpSM::write_header_into_buffer 
> (this=0x2b68ac06e910, h=0x2b68ac06f058, b=0x2f163e0) at HttpSM.cc:5554
> #11 0x005e5129 in HttpSM::write_response_header_into_buffer 
> (this=0x2b68ac06e910, h=0x2b68ac06f058, b=0x2f163e0) at HttpSM.h:594
> #12 0x005dcef2 in HttpSM::setup_server_transfer (this=0x2b68ac06e910) 
> at HttpSM.cc:6295
> #13 0x005cd336 in HttpSM::handle_api_return (this=0x2b68ac06e910) at 
> HttpSM.cc:1554
> #14 0x005cd040 in HttpSM::state_api_callout (this=0x2b68ac06e910, 
> event=0, data=0x0) at HttpSM.cc:1446
> #15 0x005d89b7 in HttpSM::do_api_callout_internal 
> (this=0x2b68ac06e910) at HttpSM.cc:4858
> #16 0x005dfdec in HttpSM::set_next_state (this=0x2b68ac06e910) at 
> HttpSM.cc:7115
> #17 0x005df0ec in HttpSM::call_transact_and_set_next_state 
> (this=0x2b68ac06e910, f=0) at HttpSM.cc:6900
> #18 0x005cd1e3 in HttpSM::handle_api_return (this=0x2b68ac06e910) at 
> HttpSM.cc:1514
> #19 0x005cd040 in HttpSM::state_api_callout (this=0x2b68ac06e910, 
> event=6, data=0x0) at HttpSM.cc:1446
> #20 0x005cc7d6 in HttpSM::state_api_callback (this=0x2b68ac06e910, 
> event=6, data=0x0) at HttpSM.cc:1264
> #21 0x00515bb5 in TSHttpTxnReenable (txnp=0x2b68ac06e910, 
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5554
> #22 0x2b68806f945b in transform_plugin 
> (event=TS_EVENT_HTTP_READ_RESPONSE_HDR, edata=0x2b68ac06e910) at gzip.cc:693
> #23 0x0050a40c in INKContInternal::handle_event (this=0x2ea2bb0, 
> event=60006, edata=0x2b68ac06e910) at InkAPI.cc:1000
> #24 0x004f597e in Continuation::handleEvent (this=0x2ea2bb0, 
> event=60006, data=0x2b68ac06e910) at 
> ../iocore/eventsystem/I_Continuation.h:146
> #25 0x0050ac53 in APIHook::invoke (this=0x2ea3c80, event=60006, 
> edata=0x2b68ac06e910) at InkAPI.cc:1219
> #26 0x005ccda9 in HttpSM::state_api_callout (this=0x2b68ac06e910, 
> event=0, data=0x0) at HttpSM.cc:1371
> #27 0x005d89b7 in HttpSM::do_api_callout_internal 
> (this=0x2b68ac06e910) at HttpSM.cc:4858
> #28 0x005e54fc in HttpSM::do_api_callout (this=0x2b68ac06e910) at 
> HttpSM.cc:448
> #29 0x005ce277 in HttpSM::state_read_server_response_header 
> (this=0x2b68ac06e910, event=100, data=0x2b68a802afc0) at HttpSM.cc:1861
> #30 0x005d0582 in HttpSM::main_handler (this=0x2b68ac06e910, 
> event=100, data=0x2b68a802afc0) at HttpSM.cc:2507
> #31 0x004f597e in Continuation::handleEvent (this=0x2b68ac06e910,

[jira] [Commented] (TS-3211) Add support for modifying the SCHEME via header_rewrite

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3211:


Github user zwoop commented on the pull request:

https://github.com/apache/trafficserver/pull/152#issuecomment-77973714
  
Yeah, it's all good, just wanted to make sure we close the Jira and this 
pull request properly, the only thing I did was to add the CHANGES entry, and 
appropriate recognition.

Cheers,

-- Leif



> Add support for modifying the SCHEME via header_rewrite
> ---
>
> Key: TS-3211
> URL: https://issues.apache.org/jira/browse/TS-3211
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Scott Beardsley
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I need a way to rewrite the destination scheme based on a request header. It 
> looks like it was partially added before (I see URL_QUAL_SCHEME in 
> statement.h already) but the actual implementation was missing.
> I will send a PR shortly



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

[jira] [Commented] (TS-3211) Add support for modifying the SCHEME via header_rewrite

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3211:


Github user jacksontj commented on the pull request:

https://github.com/apache/trafficserver/pull/152#issuecomment-77973245
  
Sorry about the miss there on my side, I was mostly confused because the 
diff didn't show my patch ;) But it looks like it merged correctly anyways.


> Add support for modifying the SCHEME via header_rewrite
> ---
>
> Key: TS-3211
> URL: https://issues.apache.org/jira/browse/TS-3211
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Scott Beardsley
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I need a way to rewrite the destination scheme based on a request header. It 
> looks like it was partially added before (I see URL_QUAL_SCHEME in 
> statement.h already) but the actual implementation was missing.
> I will send a PR shortly



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

[jira] [Commented] (TS-3211) Add support for modifying the SCHEME via header_rewrite

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3211:


Github user zwoop commented on the pull request:

https://github.com/apache/trafficserver/pull/152#issuecomment-77971725
  

> On Mar 9, 2015, at 4:59 PM, Thomas Jackson  
wrote:
> 
> @zwoop  I had already added this feature last 
month:
> 


I know, but you a) didn’t commit it against a Jira and b) didn’t notice 
that it was already patched in a Jira. I’m giving credit as where it was due 
:-).

For future references please don’t commit non-trivial changes without a 
Jira, it’s important for forensics in the future. It’s possible I missed 
another Jira somewhere, but I couldn’t find it.

Thanks!

— Leif

> c61e7d2 



> Add support for modifying the SCHEME via header_rewrite
> ---
>
> Key: TS-3211
> URL: https://issues.apache.org/jira/browse/TS-3211
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Scott Beardsley
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I need a way to rewrite the destination scheme based on a request header. It 
> looks like it was partially added before (I see URL_QUAL_SCHEME in 
> statement.h already) but the actual implementation was missing.
> I will send a PR shortly



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

[jira] [Commented] (TS-3036) Add logging field to define the cache medium used to serve a HIT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3036:


Github user asfgit closed the pull request at:

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


> Add logging field to define the cache medium used to serve a HIT
> 
>
> Key: TS-3036
> URL: https://issues.apache.org/jira/browse/TS-3036
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Ryan Frantz
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I want to be able to differentiate between RAM cache HITs and disk cache 
> HITs. Add a logging field to inform the administrator if the HIT came from 
> RAM, at least.



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

[jira] [Commented] (TS-3036) Add logging field to define the cache medium used to serve a HIT

[ASF subversion and git services (JIRA)]

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

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

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

TS-3036 Add a new log tag format for cache medium


> Add logging field to define the cache medium used to serve a HIT
> 
>
> Key: TS-3036
> URL: https://issues.apache.org/jira/browse/TS-3036
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Ryan Frantz
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I want to be able to differentiate between RAM cache HITs and disk cache 
> HITs. Add a logging field to inform the administrator if the HIT came from 
> RAM, at least.



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

[jira] [Commented] (TS-3036) Add logging field to define the cache medium used to serve a HIT

[ASF subversion and git services (JIRA)]

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

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

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

TS-3036 Add "chm" to the docs.


> Add logging field to define the cache medium used to serve a HIT
> 
>
> Key: TS-3036
> URL: https://issues.apache.org/jira/browse/TS-3036
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Ryan Frantz
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I want to be able to differentiate between RAM cache HITs and disk cache 
> HITs. Add a logging field to inform the administrator if the HIT came from 
> RAM, at least.



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

[jira] [Commented] (TS-3036) Add logging field to define the cache medium used to serve a HIT

[ASF subversion and git services (JIRA)]

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

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

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

TS-3036 Add logging field to define the cache medium used to serve a HIT

This closes #104


> Add logging field to define the cache medium used to serve a HIT
> 
>
> Key: TS-3036
> URL: https://issues.apache.org/jira/browse/TS-3036
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Ryan Frantz
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I want to be able to differentiate between RAM cache HITs and disk cache 
> HITs. Add a logging field to inform the administrator if the HIT came from 
> RAM, at least.



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

[jira] [Commented] (TS-3211) Add support for modifying the SCHEME via header_rewrite

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3211:


Github user jacksontj commented on the pull request:

https://github.com/apache/trafficserver/pull/152#issuecomment-77970353
  
@zwoop I had already added this feature last month: c61e7d2


> Add support for modifying the SCHEME via header_rewrite
> ---
>
> Key: TS-3211
> URL: https://issues.apache.org/jira/browse/TS-3211
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Scott Beardsley
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I need a way to rewrite the destination scheme based on a request header. It 
> looks like it was partially added before (I see URL_QUAL_SCHEME in 
> statement.h already) but the actual implementation was missing.
> I will send a PR shortly



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

[jira] [Commented] (TS-2894) Spdy slow start..

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-2894:
---

Hi Leif - We have an internal patch running in prod (although, I am not sure if 
it was ever needed to be activated, since, the flapping issues didn't occur, 
following a h/w upgrade). If someone can review the patch and provide feedback 
on whether this is needed upstream, I can commit/push it.  

> Spdy slow start..
> -
>
> Key: TS-2894
> URL: https://issues.apache.org/jira/browse/TS-2894
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>  Labels: yahoo
> Fix For: 5.3.0
>
> Attachments: TS-2894.diff
>
>
> When production testing with spdy/5.0.0, we ran into an issue in some of our 
> systems, where, the spdy hosts would flap constantly due to the flood of 
> requests. We further noticed that, where the 4.0.x version or 5.0.0 w/ spdy 
> turned off, would recover quickly following a restart, spdy enabled hosts 
> would continue to receive flood of requests and continue to flap. During this 
> time, traffic server is generally busy reading from the disk and can not 
> handle too many requests, and is made miserable by spdy's support of multiple 
> concurrent streams. 
> To handle such a sudden flood of requests, I'm implementing a simple slow 
> start mechanism with spdy. The idea is to increase the 
> max_concurrent_streams_in gradually based on a configured timer, rather than 
> use the configured value right away. The steps I chose to implement are 1, 
> 25, 50, 75 and 100% of the configured max_concurrent_streams_in. Note that, 
> currently,
> max_concurrent_streams_in only affects new spdy sessions. Existing sessions 
> (if any) would continue to use their older values.
> Not too sure, if everyone would be interested in this..but, thought of still 
> uploading my patch, incase, someone is interested.



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

[jira] [Commented] (TS-3417) Use madvise() with MADV_DONTDUMP option to limit core sizes

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3417:
---

Land it, it's rock solid.

> Use madvise() with MADV_DONTDUMP option to limit core sizes
> ---
>
> Key: TS-3417
> URL: https://issues.apache.org/jira/browse/TS-3417
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 5.3.0
>
>
> When ATS crashes it often leaves behind very large core files, in the 
> hundreds of gigabytes. A large percentage of these core files are useless 
> data in the IO buffers. We can limit the pages that the kernel dumps with 
> madvise().
> Note: This will only work on Linux 3.4+.



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

[jira] [Commented] (TS-3331) negative responses cached even when headers indicate otherwise

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3331:
---

William, you going to land this?

> negative responses cached even when headers indicate otherwise
> --
>
> Key: TS-3331
> URL: https://issues.apache.org/jira/browse/TS-3331
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: William Bardwell
>Assignee: William Bardwell
>  Labels: review
> Fix For: 5.3.0
>
>
> Negative type status codes get cached even when there are Cache-Control: 
> no-store or the like headers and positive caching would be paying attention 
> to that.  So the fix is to apply response headers (and general caching 
> config) to negative caching choices too.
> My patch might fix [TS-2633] 406 negative responses being cached for too long



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

[jira] [Commented] (TS-2894) Spdy slow start..

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-2894:
---

Sudheer, what's the word on this ?

> Spdy slow start..
> -
>
> Key: TS-2894
> URL: https://issues.apache.org/jira/browse/TS-2894
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>  Labels: yahoo
> Fix For: 5.3.0
>
> Attachments: TS-2894.diff
>
>
> When production testing with spdy/5.0.0, we ran into an issue in some of our 
> systems, where, the spdy hosts would flap constantly due to the flood of 
> requests. We further noticed that, where the 4.0.x version or 5.0.0 w/ spdy 
> turned off, would recover quickly following a restart, spdy enabled hosts 
> would continue to receive flood of requests and continue to flap. During this 
> time, traffic server is generally busy reading from the disk and can not 
> handle too many requests, and is made miserable by spdy's support of multiple 
> concurrent streams. 
> To handle such a sudden flood of requests, I'm implementing a simple slow 
> start mechanism with spdy. The idea is to increase the 
> max_concurrent_streams_in gradually based on a configured timer, rather than 
> use the configured value right away. The steps I chose to implement are 1, 
> 25, 50, 75 and 100% of the configured max_concurrent_streams_in. Note that, 
> currently,
> max_concurrent_streams_in only affects new spdy sessions. Existing sessions 
> (if any) would continue to use their older values.
> Not too sure, if everyone would be interested in this..but, thought of still 
> uploading my patch, incase, someone is interested.



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

[jira] [Commented] (TS-3342) Non-standard method in bad request can cause crash

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3342:
---

William, you going to land this?

> Non-standard method in bad request can cause crash
> --
>
> Key: TS-3342
> URL: https://issues.apache.org/jira/browse/TS-3342
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: William Bardwell
>Assignee: William Bardwell
>  Labels: review
> Fix For: 5.3.0
>
> Attachments: TS-3342.diff
>
>
> Fix is to check for a normal sort of method (that would actually need a cache 
> lookup) in HttpTransact::HandleCacheOpenReadMiss() to do
> {code}
>  s->cache_info.action = CACHE_DO_NO_ACTION;
> {code}
> instead of
> {code}
>  s->cache_info.action = CACHE_PREPARE_TO_WRITE;
> {code}
> for anything weird.  But I am concerned that this might cause problems if 
> someone wants to add support for a weird method...but maybe that never works 
> right with the cache anyway...



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

[jira] [Updated] (TS-3142) It could be support a range query for HTTP 1.0

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3142:
--
Fix Version/s: (was: 5.3.0)
   6.0.0

> It could be support a range query for HTTP 1.0
> --
>
> Key: TS-3142
> URL: https://issues.apache.org/jira/browse/TS-3142
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP
>Reporter: Eric Ahn
>Assignee: Alan M. Carroll
> Fix For: 6.0.0
>
> Attachments: HttpSM.cc.diff
>
>
> Some Application and Smart TV Platform use a HTTP 1.0 spec.
> and I have no idea why they use HTTP 1.0 spec(HTTP Header HTTP/1.0).
> It may be use wrong a library of http.



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

[jira] [Commented] (TS-3137) Enhance header_rewrite to support set-redirect operator when used in global mode

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3137:
---

moving out to 6.0.0


> Enhance header_rewrite to support set-redirect operator when used in global 
> mode
> 
>
> Key: TS-3137
> URL: https://issues.apache.org/jira/browse/TS-3137
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.0.0
>
> Attachments: TS-3137.diff
>
>
> We have a use case to redirect all incoming users of certain type (e.g. old 
> version of certain browsers) to some pre-determined site. 
> header_rewrite supports the set-redirect operator to achieve this, but, 
> currently, this only works on a remap mode. We have a very large number of 
> remap rules (in the order of 20K+), so, supporting set-redirect in global 
> mode would make it easier for operation. 



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

[jira] [Updated] (TS-3137) Enhance header_rewrite to support set-redirect operator when used in global mode

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3137:
--
Fix Version/s: (was: 5.3.0)
   6.0.0

> Enhance header_rewrite to support set-redirect operator when used in global 
> mode
> 
>
> Key: TS-3137
> URL: https://issues.apache.org/jira/browse/TS-3137
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.0.0
>
> Attachments: TS-3137.diff
>
>
> We have a use case to redirect all incoming users of certain type (e.g. old 
> version of certain browsers) to some pre-determined site. 
> header_rewrite supports the set-redirect operator to achieve this, but, 
> currently, this only works on a remap mode. We have a very large number of 
> remap rules (in the order of 20K+), so, supporting set-redirect in global 
> mode would make it easier for operation. 



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

[jira] [Commented] (TS-3176) Some DNS stats don't persist through restart.

[ASF subversion and git services (JIRA)]

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

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

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

TS-3176: some DNS stats don't persist through restart

Over time when viewing stats through traffic_top the "DNS lookup"
stat will happily persist through a restart but at the very least
"DNS hits" and the "DNS Hit" percentage will not.


> Some DNS stats don't persist through restart.
> -
>
> Key: TS-3176
> URL: https://issues.apache.org/jira/browse/TS-3176
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Affects Versions: 5.1.1
> Environment: CentOS Linux 7.0 (Virtual Machine)
>Reporter: Adam W. Dace
>Assignee: Leif Hedstrom
>Priority: Minor
>  Labels: review
> Fix For: 5.3.0
>
> Attachments: TS-3176.patch
>
>
> I can't speak for all of these, but I've noticed over time when viewing stats 
> through traffic_top the "DNS lookup" stat will happily persist through a 
> restart but at the very least "DNS hits" and the "DNS Hit" percentage will 
> not.
> I'm not really sure what the scoop with "DNS Time" is...for me it's always 
> 0.0.
> Please let me know if there's any testing I can do to help out, I'd offer up 
> a patch but C++ just isn't my cup of tea.



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

[jira] [Updated] (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-608:
-
Fix Version/s: (was: 5.3.0)
   6.0.0

> Is HttpSessionManager::purge_keepalives()  too aggressive?
> --
>
> Key: TS-608
> URL: https://issues.apache.org/jira/browse/TS-608
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Bryan Call
> Fix For: 6.0.0
>
> Attachments: TS-608.patch
>
>
> It seems that if we trigger the "max server connections", we call this purge 
> function in the session manager, which will close all currently open 
> keep-alive connections. This seems very aggressive, why not limit it to say 
> only removing 10% of each "bucket" or some such? Also, how does this work 
> together with per-origin limits? Ideally, if the per-origin limits are in 
> place, we would only purge sessions that are for the IP we wish to connect to 
> ?



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

[jira] [Updated] (TS-1453) remove InactivityCop and enable define INACTIVITY_TIMEOUT

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-1453:
--
Fix Version/s: (was: 5.3.0)
   6.0.0

> remove InactivityCop and enable define INACTIVITY_TIMEOUT
> -
>
> Key: TS-1453
> URL: https://issues.apache.org/jira/browse/TS-1453
> Project: Traffic Server
>  Issue Type: Sub-task
>  Components: Core
>Affects Versions: 3.2.0
>Reporter: Bin Chen
>Assignee: Bryan Call
>  Labels: A, review
> Fix For: 6.0.0
>
> Attachments: TS-1453.patch, TS-1453_v2.patch
>
>
> when we have O(1), then we can be enable define INACTIVITY_TIMEOUT



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

[jira] [Updated] (TS-2914) LogField cquuh does not work for TSSkipRemappingSet

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-2914:
--
Fix Version/s: (was: 5.3.0)
   6.0.0

> LogField cquuh does not work for TSSkipRemappingSet
> ---
>
> Key: TS-2914
> URL: https://issues.apache.org/jira/browse/TS-2914
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging, TS API
>Reporter: xiongzongtao
>Assignee: Leif Hedstrom
>  Labels: Review
> Fix For: 6.0.0
>
> Attachments: quickfix.diff
>
>
> if cquuh is set in logs_xml.config and  TSSkipRemappingSet called in plugin
>   log entry related to that plugin is not correct and not readable



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

[jira] [Updated] (TS-2968) CLONE - Make proxy.config.http.doc_in_cache_skip_dns overridable

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-2968:
--
Fix Version/s: (was: 5.3.0)
   6.0.0

> CLONE - Make proxy.config.http.doc_in_cache_skip_dns overridable
> 
>
> Key: TS-2968
> URL: https://issues.apache.org/jira/browse/TS-2968
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: A
> Fix For: 6.0.0
>
>
> Make this overridable per remap rule / plugin.



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

[jira] [Updated] (TS-3123) Make proxy.config.http.transaction_active_timeout_in overridable

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3123:
--
Fix Version/s: (was: 5.3.0)
   6.0.0

> Make proxy.config.http.transaction_active_timeout_in overridable
> 
>
> Key: TS-3123
> URL: https://issues.apache.org/jira/browse/TS-3123
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 6.0.0
>
>
> This also requires moving the setup to a slightly later state in the HttpSM.



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

[jira] [Commented] (TS-3211) Add support for modifying the SCHEME via header_rewrite

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3211:
---

It looks like this was committed in c61e7d2a3c6796543dfabcd5b9ea47f193d2ca8f. 
I'm going to resolve this and add the appropriate CHANGES entry.


> Add support for modifying the SCHEME via header_rewrite
> ---
>
> Key: TS-3211
> URL: https://issues.apache.org/jira/browse/TS-3211
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Scott Beardsley
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I need a way to rewrite the destination scheme based on a request header. It 
> looks like it was partially added before (I see URL_QUAL_SCHEME in 
> statement.h already) but the actual implementation was missing.
> I will send a PR shortly



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

[jira] [Commented] (TS-3211) Add support for modifying the SCHEME via header_rewrite

[ASF subversion and git services (JIRA)]

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

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

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

Add TS-3211

This closes #152


> Add support for modifying the SCHEME via header_rewrite
> ---
>
> Key: TS-3211
> URL: https://issues.apache.org/jira/browse/TS-3211
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Scott Beardsley
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I need a way to rewrite the destination scheme based on a request header. It 
> looks like it was partially added before (I see URL_QUAL_SCHEME in 
> statement.h already) but the actual implementation was missing.
> I will send a PR shortly



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

[jira] [Commented] (TS-3211) Add support for modifying the SCHEME via header_rewrite

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3211:


Github user asfgit closed the pull request at:

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


> Add support for modifying the SCHEME via header_rewrite
> ---
>
> Key: TS-3211
> URL: https://issues.apache.org/jira/browse/TS-3211
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Scott Beardsley
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 5.3.0
>
>
> I need a way to rewrite the destination scheme based on a request header. It 
> looks like it was partially added before (I see URL_QUAL_SCHEME in 
> statement.h already) but the actual implementation was missing.
> I will send a PR shortly



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

[jira] [Updated] (TS-3434) Remove unnecessary usage of "squid" from the code

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-3434:

Fix Version/s: sometime

> Remove unnecessary usage of "squid" from the code
> -
>
> Key: TS-3434
> URL: https://issues.apache.org/jira/browse/TS-3434
> Project: Traffic Server
>  Issue Type: Wish
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
> Fix For: sometime
>
>
> This term is used heavily in the code in areas that were presumably meant to 
> be compatible with squid. I think we should remove it where possible and move 
> things like the squid log format into a default config file instead of being 
> in the code.



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

[jira] [Updated] (TS-3434) Remove unnecessary usage of "squid" from the code

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-3434:

Priority: Trivial  (was: Major)

> Remove unnecessary usage of "squid" from the code
> -
>
> Key: TS-3434
> URL: https://issues.apache.org/jira/browse/TS-3434
> Project: Traffic Server
>  Issue Type: Wish
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
>Priority: Trivial
> Fix For: sometime
>
>
> This term is used heavily in the code in areas that were presumably meant to 
> be compatible with squid. I think we should remove it where possible and move 
> things like the squid log format into a default config file instead of being 
> in the code.



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

[jira] [Created] (TS-3434) Remove unnecessary usage of "squid" from the code

[Phil Sorber (JIRA)]

Phil Sorber created TS-3434:
---

 Summary: Remove unnecessary usage of "squid" from the code
 Key: TS-3434
 URL: https://issues.apache.org/jira/browse/TS-3434
 Project: Traffic Server
  Issue Type: Wish
Reporter: Phil Sorber


This term is used heavily in the code in areas that were presumably meant to be 
compatible with squid. I think we should remove it where possible and move 
things like the squid log format into a default config file instead of being in 
the code.



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

[jira] [Updated] (TS-3434) Remove unnecessary usage of "squid" from the code

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-3434:

Assignee: Leif Hedstrom

> Remove unnecessary usage of "squid" from the code
> -
>
> Key: TS-3434
> URL: https://issues.apache.org/jira/browse/TS-3434
> Project: Traffic Server
>  Issue Type: Wish
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
>
> This term is used heavily in the code in areas that were presumably meant to 
> be compatible with squid. I think we should remove it where possible and move 
> things like the squid log format into a default config file instead of being 
> in the code.



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

[jira] [Commented] (TS-3408) Add a "config describe" command to traffic_ctl

[ASF subversion and git services (JIRA)]

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

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

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

TS-3408: minor bug fixes


> Add a "config describe" command to traffic_ctl
> --
>
> Key: TS-3408
> URL: https://issues.apache.org/jira/browse/TS-3408
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Configuration, Management API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.3.0
>
>
> Add a {{config describe}} command to {{traffic_ctl}} so that operators can 
> get easy access to everything that the records system knows about a 
> configuration variable.



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