[jira] [Resolved] (TS-3684) Support TSHttpTxnServerRespNoStoreSet in ts_lua plugin
[ https://issues.apache.org/jira/browse/TS-3684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kit Chan resolved TS-3684. -- Resolution: Fixed Support TSHttpTxnServerRespNoStoreSet in ts_lua plugin -- Key: TS-3684 URL: https://issues.apache.org/jira/browse/TS-3684 Project: Traffic Server Issue Type: Improvement Components: Lua, Plugins Reporter: Kit Chan Assignee: Kit Chan Fix For: 6.0.0 We want to support TSHttpTxnTxnServerRespNoStoreSet in ts_lua plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[
https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581692#comment-14581692
]
ASF GitHub Bot commented on TS-1125:
Github user ffcai commented on the pull request:
https://github.com/apache/trafficserver/pull/216#issuecomment-111045489
Hi @adityaumrani , for *POST/PUT* method, `Content-Length` should present
or use Chunked Transfer Encoding (present `Transfer-Encoding: chunked`). And,
ATS has a dedicated function - `HttpTransact::check_request_validity` for this
check.
```cpp
// Require Content-Length/Transfer-Encoding for POST/PUSH/PUT
if ((scheme == URL_WKSIDX_HTTP || scheme == URL_WKSIDX_HTTPS)
(method == HTTP_WKSIDX_POST || method == HTTP_WKSIDX_PUSH || method
== HTTP_WKSIDX_PUT)
s-client_info.transfer_encoding != CHUNKED_ENCODING) {
if ((s-txn_conf-post_check_content_length_enabled)
!incoming_hdr-presence(MIME_PRESENCE_CONTENT_LENGTH)) {
return NO_POST_CONTENT_LENGTH;
}
if (HTTP_UNDEFINED_CL == s-hdr_info.request_content_length) {
return INVALID_POST_CONTENT_LENGTH;
}
}
}
```
https://github.com/apache/trafficserver/blob/master/proxy/http/HttpTransact.cc#L5282
I think we can just skip doing this here and let the function check it some
later.
POST's with Expect: 100-continue are slowed by delayed 100 response.
Key: TS-1125
URL: https://issues.apache.org/jira/browse/TS-1125
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.0.2
Environment: TS 3.0.2 going to Apache 2.2 web server
Reporter: William Bardwell
Assignee: Bryan Call
Priority: Minor
Labels: yahoo
Fix For: 5.0.0
Attachments: TS-1125.diff, TS-1125.diff, ts1125.diff, ts1125.diff,
ts1125.diff
Sending a post like:
POST / HTTP/1.1
Host: www.example.com
Content-Length: 10
Expect: 100-continue
directly to the web server immediately sends back:
HTTP/1.1 100 Continue
And then when the post data is sent, a status 200 response comes back.
But when going through ATS the HTTP/1.1 100 Continue is not sent
immediately, and instead is sent after the POST data has been received. This
is legal, but it makes clients that are hoping for a 100 continue to wait a
little while hoping to get that, ATS should forward that response through
immediately.
Note: I see curl using Expect: 100-continue with 1024 bytes of post data,
but web searching indicates that some Microsoft products also use it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582002#comment-14582002 ] ASF GitHub Bot commented on TS-1125: Github user sudheerv commented on the pull request: https://github.com/apache/trafficserver/pull/216#issuecomment-57498 @ffcai : I think you should delay the sending of 100 CONT to at least until after calling *is_request_valid()*, which occurs in *HttpTransact::HandleRequest*. It doesn't make sense to send back a 100 CONT for a request that may end up returning an error (due to http header validation failures). At that point, you have all the information (e.g transfer-encoding, or content-length etc) that is needed to preserve the conditional checks as they existed before. POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Assignee: Bryan Call Priority: Minor Labels: yahoo Fix For: 5.0.0 Attachments: TS-1125.diff, TS-1125.diff, ts1125.diff, ts1125.diff, ts1125.diff Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3527) Add plugin hooks for SSL Session state access
[ https://issues.apache.org/jira/browse/TS-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582032#comment-14582032 ] ASF GitHub Bot commented on TS-3527: GitHub user shinrich opened a pull request: https://github.com/apache/trafficserver/pull/217 TS-3527: Plugin API for SSL Session state changes See http://network-geographics.com/ats/docs/ssl-session-api.en.html for a discussion of the API. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shinrich/trafficserver TS-3527 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/217.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 #217 commit cd679436ce73918bfaf80d196404ae4767776fc5 Author: shinrich shinr...@yahoo-inc.com Date: 2015-05-20T14:06:26Z TS-3527: Plugin API for SSL Session state changes Add plugin hooks for SSL Session state access - Key: TS-3527 URL: https://issues.apache.org/jira/browse/TS-3527 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: Susan Hinrichs Assignee: Susan Hinrichs Fix For: 6.0.0 Add plugin hook functionality to allow hook into the SSL session state lifecycle. This enables session state communication between ATS deployments and additional statistical analysis. One API proposal is at http://network-geographics.com/ats/docs/ssl-session-api.en.html [~briang] suggested merging this with the existing TS_SSL_SNI_HOOK. Will have to look in more detail with the openssl implementations to see if we can hook into to a single point that has access to the functionality needed by both. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2018) Cache never gets enabled if ATS is under heavy load during startup
[ https://issues.apache.org/jira/browse/TS-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call closed TS-2018. -- Resolution: Won't Fix Fix Version/s: (was: sometime) The work around is to set this config option: proxy.config.http.wait_for_cache Cache never gets enabled if ATS is under heavy load during startup -- Key: TS-2018 URL: https://issues.apache.org/jira/browse/TS-2018 Project: Traffic Server Issue Type: Bug Reporter: Phil Sorber Labels: C Under 5Gb/s+ load the cache never gets enabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2020) Add check to evacuation code to do RAM cache lookup and evacuate on a hit
[ https://issues.apache.org/jira/browse/TS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2020: Labels: C newbie (was: C) Add check to evacuation code to do RAM cache lookup and evacuate on a hit - Key: TS-2020 URL: https://issues.apache.org/jira/browse/TS-2020 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Alan M. Carroll Labels: C, newbie Fix For: 6.2.0 This will allow us to keep hotter items in the disk cache longer. It's not a full LRU but it's cheap and will help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2020) Add check to evacuation code to do RAM cache lookup and evacuate on a hit
[ https://issues.apache.org/jira/browse/TS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2020: Fix Version/s: (was: 6.0.0) sometime Add check to evacuation code to do RAM cache lookup and evacuate on a hit - Key: TS-2020 URL: https://issues.apache.org/jira/browse/TS-2020 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Labels: C, newbie Fix For: 6.2.0 This will allow us to keep hotter items in the disk cache longer. It's not a full LRU but it's cheap and will help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2020) Add check to evacuation code to do RAM cache lookup and evacuate on a hit
[ https://issues.apache.org/jira/browse/TS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2020: Assignee: (was: Alan M. Carroll) Add check to evacuation code to do RAM cache lookup and evacuate on a hit - Key: TS-2020 URL: https://issues.apache.org/jira/browse/TS-2020 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Labels: C, newbie Fix For: 6.2.0 This will allow us to keep hotter items in the disk cache longer. It's not a full LRU but it's cheap and will help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2020) Add check to evacuation code to do RAM cache lookup and evacuate on a hit
[ https://issues.apache.org/jira/browse/TS-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2020: Fix Version/s: (was: sometime) 6.2.0 Add check to evacuation code to do RAM cache lookup and evacuate on a hit - Key: TS-2020 URL: https://issues.apache.org/jira/browse/TS-2020 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Labels: C, newbie Fix For: 6.2.0 This will allow us to keep hotter items in the disk cache longer. It's not a full LRU but it's cheap and will help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2024) HTTP Violation: proxies MUST handle 65536byte-long URIs
[
https://issues.apache.org/jira/browse/TS-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2024:
---
Fix Version/s: (was: 6.0.0)
HTTP Violation: proxies MUST handle 65536byte-long URIs
---
Key: TS-2024
URL: https://issues.apache.org/jira/browse/TS-2024
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Igor Galić
Assignee: Alan M. Carroll
citing the RFC:
{quote}
The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).
Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.
{quote}
Section 3.1.1 of HTTPbis recommends for everyone at least 8k octets:
https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-3.1.1
- CoAdvisor recommends 65k for proxies.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2024) HTTP Violation: proxies MUST handle 65536byte-long URIs
[
https://issues.apache.org/jira/browse/TS-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2024:
---
Assignee: (was: Alan M. Carroll)
HTTP Violation: proxies MUST handle 65536byte-long URIs
---
Key: TS-2024
URL: https://issues.apache.org/jira/browse/TS-2024
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Igor Galić
citing the RFC:
{quote}
The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).
Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.
{quote}
Section 3.1.1 of HTTPbis recommends for everyone at least 8k octets:
https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-3.1.1
- CoAdvisor recommends 65k for proxies.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2025) HTTP Violation: caches must attach a Warning (113) if hit is older than 24h
[
https://issues.apache.org/jira/browse/TS-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2025:
---
Labels: newbie (was: )
HTTP Violation: caches must attach a Warning (113) if hit is older than 24h
---
Key: TS-2025
URL: https://issues.apache.org/jira/browse/TS-2025
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Igor Galić
Labels: newbie
Fix For: sometime
reference: https://tools.ietf.org/html/rfc2616#section-14.46
To quote the RFC:
{quote}
113 Heuristic expiration
MUST be included if the cache heuristically chose a freshness
lifetime greater than 24 hours and the response's age is greater
than 24 hours.
{quote}
HTTPbis downgrades this to a SHOULD:
https://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-22#section-7.5.4
{quote}
7.5.4. 113 Heuristic Expiration
A cache SHOULD generate this if it heuristically chose a freshness
lifetime greater than 24 hours and the response's age is greater than
24 hours.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2025) HTTP Violation: caches must attach a Warning (113) if hit is older than 24h
[
https://issues.apache.org/jira/browse/TS-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2025:
---
Fix Version/s: (was: sometime)
6.3.0
HTTP Violation: caches must attach a Warning (113) if hit is older than 24h
---
Key: TS-2025
URL: https://issues.apache.org/jira/browse/TS-2025
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Igor Galić
Labels: newbie
Fix For: 6.3.0
reference: https://tools.ietf.org/html/rfc2616#section-14.46
To quote the RFC:
{quote}
113 Heuristic expiration
MUST be included if the cache heuristically chose a freshness
lifetime greater than 24 hours and the response's age is greater
than 24 hours.
{quote}
HTTPbis downgrades this to a SHOULD:
https://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-22#section-7.5.4
{quote}
7.5.4. 113 Heuristic Expiration
A cache SHOULD generate this if it heuristically chose a freshness
lifetime greater than 24 hours and the response's age is greater than
24 hours.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2038) Add CoAdvisor automation in our CI
[ https://issues.apache.org/jira/browse/TS-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2038: -- Assignee: (was: Phil Sorber) Add CoAdvisor automation in our CI -- Key: TS-2038 URL: https://issues.apache.org/jira/browse/TS-2038 Project: Traffic Server Issue Type: New Feature Components: Quality Reporter: Leif Hedstrom Fix For: Infrastructure -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2056) When proxy.config.http.negative_caching_enabled = 1 we cache errors even if Cache-Control: no-cache is sent from the origin
[
https://issues.apache.org/jira/browse/TS-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2056:
---
Labels: C newbie (was: C)
When proxy.config.http.negative_caching_enabled = 1 we cache errors even if
Cache-Control: no-cache is sent from the origin
---
Key: TS-2056
URL: https://issues.apache.org/jira/browse/TS-2056
Project: Traffic Server
Issue Type: Bug
Reporter: Phil Sorber
Labels: C, newbie
Fix For: 6.1.0
{noformat}
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Cache-Control: no-cache
Date: Sun, 21 Jul 2013 17:20:00 GMT
Expires: Sun, 21 Jul 2013 17:50:00 GMT
Age: 38
Content-Length: 40
Connection: keep-alive
Via: http/1.1 XX (ApacheTrafficServer/3.3.5-dev [uScHs f p eN:t cCHi
p s ])
Server: ATS/3.3.5-dev
{noformat}
While this is a grey area since we are already breaking the spec by negative
caching, I think we should still not cache this when explicitly told not to
by the origin and [~zwoop] agrees!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2056) When proxy.config.http.negative_caching_enabled = 1 we cache errors even if Cache-Control: no-cache is sent from the origin
[
https://issues.apache.org/jira/browse/TS-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2056:
---
Fix Version/s: (was: 6.0.0)
6.1.0
When proxy.config.http.negative_caching_enabled = 1 we cache errors even if
Cache-Control: no-cache is sent from the origin
---
Key: TS-2056
URL: https://issues.apache.org/jira/browse/TS-2056
Project: Traffic Server
Issue Type: Bug
Reporter: Phil Sorber
Labels: C, newbie
Fix For: 6.1.0
{noformat}
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Cache-Control: no-cache
Date: Sun, 21 Jul 2013 17:20:00 GMT
Expires: Sun, 21 Jul 2013 17:50:00 GMT
Age: 38
Content-Length: 40
Connection: keep-alive
Via: http/1.1 XX (ApacheTrafficServer/3.3.5-dev [uScHs f p eN:t cCHi
p s ])
Server: ATS/3.3.5-dev
{noformat}
While this is a grey area since we are already breaking the spec by negative
caching, I think we should still not cache this when explicitly told not to
by the origin and [~zwoop] agrees!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2062) LogHost orphaned log does not honor log-buffer configs
[
https://issues.apache.org/jira/browse/TS-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2062:
---
Fix Version/s: (was: 6.0.0)
sometime
LogHost orphaned log does not honor log-buffer configs
--
Key: TS-2062
URL: https://issues.apache.org/jira/browse/TS-2062
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Labels: A
Fix For: sometime
It looks like when we setup remote logging, the LogHost orphan log is always
created with the default configurations (9216 bytes). This ignores e.g.
{code}
proxy.config.log.log_buffer_size
proxy.config.log.max_line_size
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2085) Can't put url in ram
[ https://issues.apache.org/jira/browse/TS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2085: --- Description: 1.when ram size = max_bytes(proxy.config.cache.ram_cache.size), the ram is full. 2. one size_bucket[i] is empty 3. the from url is putted in size_bucket[i] this condition url won't be put in ram. was: 1.when ram size = max_bytes(proxy.config.cache.ram_cache.size), the ram is full. 2. one size_bucket[i] is empty 3. the from url is putted in size_bucket[i] this condition url won't be putted in ram. Can't put url in ram Key: TS-2085 URL: https://issues.apache.org/jira/browse/TS-2085 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Bin Chen Assignee: Phil Sorber Fix For: 6.0.0 1.when ram size = max_bytes(proxy.config.cache.ram_cache.size), the ram is full. 2. one size_bucket[i] is empty 3. the from url is putted in size_bucket[i] this condition url won't be put in ram. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2085) Can't put url in ram
[ https://issues.apache.org/jira/browse/TS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2085: --- Description: 1.when ram size = max_bytes(proxy.config.cache.ram_cache.size), the ram is full. 2. one size_bucket[i] is empty 3. the from url is put in size_bucket[i] this condition url won't be put in ram. was: 1.when ram size = max_bytes(proxy.config.cache.ram_cache.size), the ram is full. 2. one size_bucket[i] is empty 3. the from url is putted in size_bucket[i] this condition url won't be put in ram. Can't put url in ram Key: TS-2085 URL: https://issues.apache.org/jira/browse/TS-2085 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Bin Chen Assignee: Phil Sorber Fix For: 6.0.0 1.when ram size = max_bytes(proxy.config.cache.ram_cache.size), the ram is full. 2. one size_bucket[i] is empty 3. the from url is put in size_bucket[i] this condition url won't be put in ram. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2085) Can't put url in ram
[ https://issues.apache.org/jira/browse/TS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2085: --- Fix Version/s: (was: 6.0.0) Can't put url in ram Key: TS-2085 URL: https://issues.apache.org/jira/browse/TS-2085 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Bin Chen Assignee: Phil Sorber 1.when ram size = max_bytes(proxy.config.cache.ram_cache.size), the ram is full. 2. one size_bucket[i] is empty 3. the from url is put in size_bucket[i] this condition url won't be put in ram. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2085) Can't put url in ram
[ https://issues.apache.org/jira/browse/TS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2085. --- Resolution: Cannot Reproduce Can't put url in ram Key: TS-2085 URL: https://issues.apache.org/jira/browse/TS-2085 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Bin Chen Assignee: Phil Sorber 1.when ram size = max_bytes(proxy.config.cache.ram_cache.size), the ram is full. 2. one size_bucket[i] is empty 3. the from url is put in size_bucket[i] this condition url won't be put in ram. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2101) Segmentation fault collation log server
[
https://issues.apache.org/jira/browse/TS-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2101:
---
Fix Version/s: (was: 6.0.0)
sometime
Segmentation fault collation log server
Key: TS-2101
URL: https://issues.apache.org/jira/browse/TS-2101
Project: Traffic Server
Issue Type: Bug
Reporter: bettydramit
Labels: crash
Fix For: sometime
gitmaster centos 6 x86_64
{code}
zym@zymtest1 /tmp $ c++filt c
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b324c3a5500]
/usr/bin/traffic_server(LogObjectManager::get_object_with_signature(unsigned
long)+0x24)[0x5a28e4]
/usr/bin/traffic_server(Log::match_logobject(LogBufferHeader*)+0x3b)[0x58b98b]
/usr/bin/traffic_server(LogCollationHostSM::host_recv(int,
void*)+0x1e0)[0x5ad940]
/usr/bin/traffic_server[0x671291]
/usr/bin/traffic_server[0x673f8a]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66c422]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x696b64]
/usr/bin/traffic_server(EThread::execute()+0x4bb)[0x69754b]
/usr/bin/traffic_server[0x695ae2]
/lib64/libpthread.so.0(+0x7851)[0x2b324c39d851]
/lib64/libc.so.6(clone+0x6d)[0x2b324ea2f11d]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2085) Can't put url in ram
[ https://issues.apache.org/jira/browse/TS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2085: Assignee: (was: Phil Sorber) Can't put url in ram Key: TS-2085 URL: https://issues.apache.org/jira/browse/TS-2085 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Bin Chen 1.when ram size = max_bytes(proxy.config.cache.ram_cache.size), the ram is full. 2. one size_bucket[i] is empty 3. the from url is put in size_bucket[i] this condition url won't be put in ram. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2103) Better regression test configurations
[ https://issues.apache.org/jira/browse/TS-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call closed TS-2103. -- Resolution: Won't Fix Fix Version/s: (was: 6.0.0) This is resolved by tsqa Better regression test configurations - Key: TS-2103 URL: https://issues.apache.org/jira/browse/TS-2103 Project: Traffic Server Issue Type: Improvement Components: Quality Reporter: Leif Hedstrom It would be useful to have a set of configurations (e.g. remap.config.Reg, plugins.config.Reg etc.), which are used up on running traffic_server -R. This would allow us to do more elaborate regression tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1153) On Solaris, link with libumem by default
[ https://issues.apache.org/jira/browse/TS-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582490#comment-14582490 ] Eric Sproul commented on TS-1153: - Ah ok, a fun foray into Autotools. ;) So do we need to follow the jemalloc/tcmalloc example as stated above, or just do a basic AC_CHECK_LIB or some such? On Solaris, link with libumem by default Key: TS-1153 URL: https://issues.apache.org/jira/browse/TS-1153 Project: Traffic Server Issue Type: Improvement Components: Performance Environment: Solaris Reporter: Igor Galić Assignee: Eric Sproul Labels: memory Fix For: sometime http://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html We should make use of this and link to libumem by default on Solaris and Illumos. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2140) Stats module is showing proxy.process.cache.direntries.used greater then proxy.process.cache.direntries.total
[
https://issues.apache.org/jira/browse/TS-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2140:
--
Fix Version/s: (was: 6.0.0)
7.0.0
Stats module is showing proxy.process.cache.direntries.used greater then
proxy.process.cache.direntries.total
-
Key: TS-2140
URL: https://issues.apache.org/jira/browse/TS-2140
Project: Traffic Server
Issue Type: Bug
Components: Metrics
Affects Versions: 3.3.4
Reporter: Adam Twardowski
Assignee: Alan M. Carroll
Priority: Minor
Fix For: 7.0.0
using the stats_over_http.so module, reported
proxy.process.cache.direntries.used is greater then
proxy.process.cache.direntries.total
Also, direntries.used is continuously increasing over time. traffic_line -r
key gives the same numbers as the http stats.
{ global: {
proxy.process.version.server.short: 3.3.4-dev,
proxy.process.version.server.long: Apache Traffic Server - traffic_server
- 3.3.4-dev - (build # 63013 on Jul 30 2013 at 13:23:55),
proxy.process.version.server.build_number: 63013,
proxy.process.version.server.build_time: 13:23:55,
proxy.process.version.server.build_date: Jul 30 2013,
proxy.process.version.server.build_machine: X,
proxy.process.version.server.build_person: root,
proxy.process.http.completed_requests: 1771631878,
proxy.process.http.total_incoming_connections: 1771779452,
proxy.process.http.total_client_connections: 1771779452,
proxy.process.http.total_client_connections_ipv4: 1771779452,
proxy.process.http.total_client_connections_ipv6: 0,
proxy.process.http.total_server_connections: 486478731,
proxy.process.http.total_parent_proxy_connections: 0,
proxy.process.http.avg_transactions_per_client_connection: 1.15,
proxy.process.http.avg_transactions_per_server_connection: 1.00,
proxy.process.http.avg_transactions_per_parent_connection: 0.00,
proxy.process.http.client_connection_time: 0,
proxy.process.http.parent_proxy_connection_time: 0,
proxy.process.http.server_connection_time: 0,
proxy.process.http.cache_connection_time: 0,
proxy.process.http.transaction_counts.errors.pre_accept_hangups: 0,
proxy.process.http.transaction_totaltime.errors.pre_accept_hangups:
0.00,
proxy.process.http.transaction_counts.errors.empty_hangups: 0,
proxy.process.http.transaction_totaltime.errors.empty_hangups: 0.00,
proxy.process.http.transaction_counts.errors.early_hangups: 0,
proxy.process.http.transaction_totaltime.errors.early_hangups: 0.00,
proxy.process.http.incoming_requests: 1766073976,
proxy.process.http.outgoing_requests: 484585207,
proxy.process.http.incoming_responses: 486478535,
proxy.process.http.invalid_client_requests: 240,
proxy.process.http.missing_host_hdr: 0,
proxy.process.http.get_requests: 1765677046,
proxy.process.http.head_requests: 392884,
proxy.process.http.trace_requests: 8,
proxy.process.http.options_requests: 1562,
proxy.process.http.post_requests: 662,
proxy.process.http.put_requests: 7,
proxy.process.http.push_requests: 0,
proxy.process.http.delete_requests: 0,
proxy.process.http.purge_requests: 0,
proxy.process.http.connect_requests: 0,
proxy.process.http.extension_method_requests: 1807,
proxy.process.http.client_no_cache_requests: 0,
proxy.process.http.broken_server_connections: 63475,
proxy.process.http.cache_lookups: 1765896837,
proxy.process.http.cache_writes: 119147534,
proxy.process.http.cache_updates: 7812961,
proxy.process.http.cache_deletes: 60058,
proxy.process.http.tunnels: 5017,
proxy.process.http.throttled_proxy_only: 0,
proxy.process.http.request_taxonomy.i0_n0_m0: 0,
proxy.process.http.request_taxonomy.i1_n0_m0: 0,
proxy.process.http.request_taxonomy.i0_n1_m0: 0,
proxy.process.http.request_taxonomy.i1_n1_m0: 0,
proxy.process.http.request_taxonomy.i0_n0_m1: 0,
proxy.process.http.request_taxonomy.i1_n0_m1: 0,
proxy.process.http.request_taxonomy.i0_n1_m1: 0,
proxy.process.http.request_taxonomy.i1_n1_m1: 0,
proxy.process.http.icp_suggested_lookups: 0,
proxy.process.http.client_transaction_time: 0,
proxy.process.http.client_write_time: 0,
proxy.process.http.server_read_time: 0,
proxy.process.http.icp_transaction_time: 0,
proxy.process.http.icp_raw_transaction_time: 0,
proxy.process.http.parent_proxy_transaction_time: 0,
proxy.process.http.parent_proxy_raw_transaction_time: 0,
proxy.process.http.server_transaction_time: 0,
proxy.process.http.server_raw_transaction_time: 0,
proxy.process.http.user_agent_request_header_total_size: 797103745655,
proxy.process.http.user_agent_response_header_total_size: 697699513781,
proxy.process.http.user_agent_request_document_total_size: 419549,
[jira] [Updated] (TS-2164) Race condition between NetProcessor and api_init()
[ https://issues.apache.org/jira/browse/TS-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2164: Fix Version/s: (was: 6.0.0) 6.1.0 Race condition between NetProcessor and api_init() -- Key: TS-2164 URL: https://issues.apache.org/jira/browse/TS-2164 Project: Traffic Server Issue Type: Bug Components: Core, HTTP Reporter: Tomasz Kuzemko Assignee: Alan M. Carroll Fix For: 6.1.0 In proxy/Main.cc starting of NetProcessor before calling api_init() can lead to a segfault when an early connection is served because of accessing http_global_hooks in HttpClientSession::new_connection(): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe5019700 (LWP 21479)] 0x00564add in HttpClientSession::new_connection (this=0x15073c0, new_vc=0x152df20, backdoor=false) at HttpClientSession.cc:228 228 hooks_set = http_global_hooks-hooks_set; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2208) LogFilter does not have a way to configure conjunction
[
https://issues.apache.org/jira/browse/TS-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2208:
Fix Version/s: (was: 6.0.0)
sometime
LogFilter does not have a way to configure conjunction
Key: TS-2208
URL: https://issues.apache.org/jira/browse/TS-2208
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Leif Hedstrom
Labels: A
Fix For: sometime
In the LogFilter implementation details, there's code to deal with OR and
AND such that you can express either
REJECT if x AND y
or
REJECT if x OR y
However, there's no way to configure this in logs_xml.config,
m_does_conjunction is always true afaik (so only the OR case above is
supported). So even though the code supports both of the above, there's no
way to express it:
{code}
bool m_does_conjunction;
// If m_does_conjunction = true
// toss_this_entry returns true
// if ANY filter tosses entry away.
// If m_does_conjunction = false,
// toss this entry returns true if
// ALL filters toss away entry
{code}
This seems properly implemented in the LogFilterList::toss_this_entry()
method:
{code}
bool LogFilterList::toss_this_entry(LogAccess * lad)
{
if (m_does_conjunction) {
// toss if any filter rejects the entry (all filters should accept)
//
for (LogFilter * f = first(); f; f = next(f)) {
if (f-toss_this_entry(lad)) {
return true;
}
}
return false;
} else {
// toss if all filters reject the entry (any filter accepts)
//
for (LogFilter * f = first(); f; f = next(f)) {
if (!f-toss_this_entry(lad)) {
return false;
}
}
return true;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2258) Verify that all fields are correct in RecordsConfig.cc
[ https://issues.apache.org/jira/browse/TS-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2258: Fix Version/s: (was: 6.0.0) sometime Verify that all fields are correct in RecordsConfig.cc -- Key: TS-2258 URL: https://issues.apache.org/jira/browse/TS-2258 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Labels: newbie Fix For: sometime We should go through every configuration in RecordsConfig.cc, and assure that fields such as if it's dynamically reloadable or not, validation regexes etc. are all set 100% correct. Once this file is accurate, and will be the one true authoritative source for everything configuration; it can be used for command line help (e.g. traffic_line can say if a config is reloadable), and we can even use it as a source for the Sphinx documentation. A bonus would be to add a one-line helper line for each configuration in RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new type of tools to help managing configurations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2241) Add plugin API to see status of remap
[ https://issues.apache.org/jira/browse/TS-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2241: Assignee: (was: Phil Sorber) Add plugin API to see status of remap - Key: TS-2241 URL: https://issues.apache.org/jira/browse/TS-2241 Project: Traffic Server Issue Type: New Feature Reporter: Phil Sorber Labels: newbie Fix For: sometime Whether or not a Host header matched something in remap.config is useful to know for a plugin. It's tracked in the state machine, but not exposed. Right now plugins need to look at side effects to decide if it was valid or not. I think we need an API to expose that. TSHttpRemapValid() or similar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2240) traffic_ctl reload doesn't return result
[ https://issues.apache.org/jira/browse/TS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2240: --- Fix Version/s: sometime traffic_ctl reload doesn't return result Key: TS-2240 URL: https://issues.apache.org/jira/browse/TS-2240 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Ask Bjørn Hansen Labels: A Fix For: sometime It'd be nice if there was a variation of traffic_line -x that waits for the result of the reload and returns an appropriate exit code (and error information if applicable). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2282) Allow ATS to run with empty config
[ https://issues.apache.org/jira/browse/TS-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2282. --- Resolution: Won't Fix Fix Version/s: (was: 6.0.0) Allow ATS to run with empty config -- Key: TS-2282 URL: https://issues.apache.org/jira/browse/TS-2282 Project: Traffic Server Issue Type: Sub-task Components: Configuration Reporter: Phil Sorber Assignee: Leif Hedstrom Traffic server should start and run with empty config files using the defaults. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2288) Convert to TSConfig as a unified configuration store
[ https://issues.apache.org/jira/browse/TS-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2288. --- Resolution: Won't Fix Fix Version/s: (was: sometime) Convert to TSConfig as a unified configuration store Key: TS-2288 URL: https://issues.apache.org/jira/browse/TS-2288 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Phil Sorber Assignee: Alan M. Carroll TSConfig is presently only used in one place. We committed to making it the unified configuration store for the future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2324) monitor included remap files for updates
[
https://issues.apache.org/jira/browse/TS-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2324:
Fix Version/s: (was: 6.0.0)
sometime
monitor included remap files for updates
Key: TS-2324
URL: https://issues.apache.org/jira/browse/TS-2324
Project: Traffic Server
Issue Type: Improvement
Components: Configuration, Core
Reporter: James Peach
Fix For: sometime
The remap.config file supports a .include directive, but files that are
.included are not registered with the configuration system. This means that
{{traffic_line -x}} will not notice when they get updated.
We should register .included remap config files, but we will also have to
unregister them when they are removed. Since the logic of remapping it
global, we have to reload all the remap config when any of the files changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2134) SRV lookup does not handle failover correctly
[ https://issues.apache.org/jira/browse/TS-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2134: Fix Version/s: (was: 6.0.0) 6.1.0 SRV lookup does not handle failover correctly - Key: TS-2134 URL: https://issues.apache.org/jira/browse/TS-2134 Project: Traffic Server Issue Type: Bug Components: DNS, HTTP Reporter: Thach Tran Assignee: Alan M. Carroll Labels: review Fix For: 6.1.0 Attachments: ats.log, ts2134.patch I'm seeing an issue with SRV lookup in ATS in which the proxy doesn't fail over to alternative origins once the first choice is marked as down. To reproduce this, I'm running dnsmasq as a local resolver to serve up the test SRV records. My configuration is as follows. h4. records.config CONFIG proxy.config.dns.nameservers STRING 127.0.0.1 CONFIG proxy.config.dns.resolv_conf STRING NULL CONFIG proxy.config.srv_enabled INT 1 h4. remap.config regex_remap http://.*:8080/ https://noexample.com/ h4. dnsmasq.conf (srv records config) srv-host=_http._tcp.noexample.com,abc.com,443,0,100 srv-host=_http._tcp.noexample.com,google.com,443,1,100 The intention is since the srv lookup for _http._tcp.noexample.com returns abc.com:443 and google.com:443 with abc.com:443 being the one with higher priority, the proxy should try that first and once the connection to abc.com:443 is marked as down (up to 6 retries by default), google.com:443 should be tried next and the connection should succeed then. However, testing with the following curl command multiple times still gives back 502. $ curl -v http://localhost:8080/ Debug log seems to suggest it always attempts abc.com:443. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2152) Create a tag that logs the destination IP of the client connection
[ https://issues.apache.org/jira/browse/TS-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2152: -- Fix Version/s: (was: 6.1.0) Create a tag that logs the destination IP of the client connection -- Key: TS-2152 URL: https://issues.apache.org/jira/browse/TS-2152 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Leif Hedstrom Assignee: Eric Schwartz Labels: newbie This would log the IP of the proxy server, as the client connected to. This is useful for two reasons: 1) A box can be multi-homed 2) In a IPv4 / IPv6, you can then tell which endpoint the client connected to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2150) Add Milestone log tags
[
https://issues.apache.org/jira/browse/TS-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2150:
--
Fix Version/s: (was: 6.1.0)
Add Milestone log tags
--
Key: TS-2150
URL: https://issues.apache.org/jira/browse/TS-2150
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Leif Hedstrom
Assignee: John
We have a notion of milestones in the core, and plugin APIs
(TSHttpTxnMilestoneGet() ). It'd be useful to expose these milestone timers
as a log tag, something like:
{code}
%{UA_BEGIN}mtms
{code}
mtms is just an example / suggestion, MilestoneTimeMilliSecond, we can make
it whatever we like.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2171) cluster.config is undocumented
[
https://issues.apache.org/jira/browse/TS-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2171:
Assignee: Jon Sime
cluster.config is undocumented
--
Key: TS-2171
URL: https://issues.apache.org/jira/browse/TS-2171
Project: Traffic Server
Issue Type: Bug
Components: Documentation
Reporter: Igor Galić
Assignee: Jon Sime
Fix For: Docs
Ignoring its default configuration file in our tree, {cluster.config} is
undocumented.
We should change this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2106) Normalize TSError messages in plugins (and examples)
[
https://issues.apache.org/jira/browse/TS-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582502#comment-14582502
]
Jun Jie Ng commented on TS-2106:
Commenting so that I can get assigned this ticket
Normalize TSError messages in plugins (and examples)
Key: TS-2106
URL: https://issues.apache.org/jira/browse/TS-2106
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Igor Galić
Labels: newbie
Fix For: sometime
right now many of plugins send error messages without prefixing the plugin
they come from, this bad practice is also continued in our examples.
many error messages also close with {{\n}}, although this is not necessary.
We should fix this by normalizing the way we send those error messages.
Our proposal is either:
{code}
TSError(%s: cannot parse file %s, PLUGIN_NAME, filename);
{code}
or:
{code}
TSError([%s] cannot parse file %s, PLUGIN_NAME, filename);
{code}
I have no strong leanings towards either. BUT: We should have one consistent
format between examples and plugins and newly imported code. The word error
should not be repeated, as it is already in the severity ({{TSError()}}.
There should be *no* {{\n}} at the end of the message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2220) add proxy.config.http.insert_client_ip
[ https://issues.apache.org/jira/browse/TS-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2220: Fix Version/s: (was: 6.0.0) sometime add proxy.config.http.insert_client_ip -- Key: TS-2220 URL: https://issues.apache.org/jira/browse/TS-2220 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 4.0.1 Reporter: Zhao Yongming Fix For: sometime this is for V4 branch changes, add the new proxy.config.http.insert_client_ip. we should name proxy.config.http.anonymize_insert_client_ip as 'proxy.config.http.insert_request_client_ip' or just 'proxy.config.http.insert_client_ip' and the current implement of the insert client ip works only if the client request do not have a 'Client-ip' header, but sometimes we need to replace it even if someone send us a fake 'Client-ip': proxy.config.http.insert_client_ip INT 1 When disabled(0), do nothing. When enabled (1), Traffic Server inserts Client-IP headers to retain the client IP address, if there is no such headers. When forced (2), Traffic Server inserts Client-IP, or replace the origin Client-IP header if it is already there. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2213) Body log tags have a default value of 0, should they be -1 now?
[ https://issues.apache.org/jira/browse/TS-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2213: Fix Version/s: (was: 6.0.0) sometime Body log tags have a default value of 0, should they be -1 now? --- Key: TS-2213 URL: https://issues.apache.org/jira/browse/TS-2213 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Leif Hedstrom Labels: compatibility Fix For: sometime In our logging tags that provides a value for the body length, we default to 0 in the absence of a value. This is somewhat bad now, because we actually supports caching objects with a zero length body. Hence, it's not distinguishable between a zero length body entry, or one where we couldn't retrieve a body length (for whatever reason). I'm wondering if we should change all the defaults for all byte counts in logging from 0 to -1? This would be an incompatible change, so marking this for v5.0.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1153) On Solaris, link with libumem by default
[ https://issues.apache.org/jira/browse/TS-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582511#comment-14582511 ] Phil Sorber commented on TS-1153: - [~esproul], Yeah, good point. I think we only want to do this on demand and not by default. So follow the pattern with tcmalloc/jemalloc. On Solaris, link with libumem by default Key: TS-1153 URL: https://issues.apache.org/jira/browse/TS-1153 Project: Traffic Server Issue Type: Improvement Components: Performance Environment: Solaris Reporter: Igor Galić Assignee: Eric Sproul Labels: memory Fix For: sometime http://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html We should make use of this and link to libumem by default on Solaris and Illumos. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2223) Incorrect timezone offset when using %cqtn
[
https://issues.apache.org/jira/browse/TS-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2223:
Labels: newbie (was: )
Incorrect timezone offset when using %cqtn
Key: TS-2223
URL: https://issues.apache.org/jira/browse/TS-2223
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Adam Twardowski
Labels: newbie
Fix For: sometime
My logs are showing the incorrect timezone offset for EDT (Eastern Daylight
time). ATS logs are showing -0500 when it should be -0400. Apache returns
the correct timezone.
It looks like the problem is somewhere in the
LogUtils::timestamp_to_netscape_str function.
ATS:
{code}
13/Sep/2013:13:08:36 -0500...
{code}
Apache:
{code}
[13/Sep/2013:13:07:59 -0400]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2222) mgmt/api/CfgContextImpl.cc duplicates the effort of lib/ts/MatcherUtils.cc specifically for SplitDNS
[
https://issues.apache.org/jira/browse/TS-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-:
---
Fix Version/s: (was: 6.0.0)
sometime
mgmt/api/CfgContextImpl.cc duplicates the effort of lib/ts/MatcherUtils.cc
specifically for SplitDNS
Key: TS-
URL: https://issues.apache.org/jira/browse/TS-
Project: Traffic Server
Issue Type: Bug
Components: Cleanup, Configuration, DNS
Reporter: Igor Galić
Fix For: sometime
In trying to answer a user's question of whether {{url_regex}} matches the
Scheme, or just the host, I crawled through our source-code and decided that
the answer is: Maybe. It depends on where you're putting that {{url_regex}}.
In {{splitdns.config}} it definitely only just matches the host.
Speaking of which. Why *is* there a duplicate implementation of this for
splitdns specifically?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2223) Incorrect timezone offset when using %cqtn
[
https://issues.apache.org/jira/browse/TS-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2223:
Fix Version/s: (was: 6.0.0)
sometime
Incorrect timezone offset when using %cqtn
Key: TS-2223
URL: https://issues.apache.org/jira/browse/TS-2223
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Adam Twardowski
Labels: newbie
Fix For: sometime
My logs are showing the incorrect timezone offset for EDT (Eastern Daylight
time). ATS logs are showing -0500 when it should be -0400. Apache returns
the correct timezone.
It looks like the problem is somewhere in the
LogUtils::timestamp_to_netscape_str function.
ATS:
{code}
13/Sep/2013:13:08:36 -0500...
{code}
Apache:
{code}
[13/Sep/2013:13:07:59 -0400]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2237) URL encoding wrong in squid.blog
[ https://issues.apache.org/jira/browse/TS-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2237: --- Assignee: (was: Alan M. Carroll) URL encoding wrong in squid.blog Key: TS-2237 URL: https://issues.apache.org/jira/browse/TS-2237 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: David Carlin Priority: Minor Labels: yahoo Fix For: sometime Attachments: TS-2237.diff I was replaying URLs captured from squid.blog and I noticed I was getting 404's for some of them when squid.blog showed a 200 for that request. Turns out there is an issue with URL encoding. For example: Requesting file 'duck%20sports%20authority.gif' via curl will put this in the logs: duck%2520sports%2520authority.gif The % from %20 (space) in the request is being converted to %25 resulting in %2520 I tested both the %cquc and %cquuc log fields - same thing happens. I tested on ATS 3.2.0 and 3.3.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2240) traffic_line -x reload doesn't return result
[ https://issues.apache.org/jira/browse/TS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2240: --- Fix Version/s: (was: sometime) traffic_line -x reload doesn't return result Key: TS-2240 URL: https://issues.apache.org/jira/browse/TS-2240 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Ask Bjørn Hansen Assignee: James Peach Labels: A It'd be nice if there was a variation of traffic_line -x that waits for the result of the reload and returns an appropriate exit code (and error information if applicable). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2225) Add line/record id to traffic_logcat
[ https://issues.apache.org/jira/browse/TS-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582523#comment-14582523 ] Leif Hedstrom commented on TS-2225: --- traffic_logstats has a similar feature, where it can save the position in an external file. There's then an option to say continue from this last known position. Having an ID or line number is not easily doable, because of the way logging works, you have to pick up on buffer boundaries. Add line/record id to traffic_logcat Key: TS-2225 URL: https://issues.apache.org/jira/browse/TS-2225 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Ask Bjørn Hansen Fix For: 6.2.0 For tailing the binary log it'll be useful with a concept roughly equivalent to line number in a text file. traffic_logcat will optionally output this and then have a feature to say start following from line/record X. The record id a numeric increment for the particular log file or the request ID (if/when that's available). The immediate objective is for log readers to continue reading from where they last read if they're restarted.  -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2237) URL encoding wrong in squid.blog
[ https://issues.apache.org/jira/browse/TS-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2237: Fix Version/s: (was: 6.0.0) sometime URL encoding wrong in squid.blog Key: TS-2237 URL: https://issues.apache.org/jira/browse/TS-2237 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: David Carlin Assignee: Alan M. Carroll Priority: Minor Labels: yahoo Fix For: sometime Attachments: TS-2237.diff I was replaying URLs captured from squid.blog and I noticed I was getting 404's for some of them when squid.blog showed a 200 for that request. Turns out there is an issue with URL encoding. For example: Requesting file 'duck%20sports%20authority.gif' via curl will put this in the logs: duck%2520sports%2520authority.gif The % from %20 (space) in the request is being converted to %25 resulting in %2520 I tested both the %cquc and %cquuc log fields - same thing happens. I tested on ATS 3.2.0 and 3.3.5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1153) On Solaris, link with libumem by default
[ https://issues.apache.org/jira/browse/TS-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582522#comment-14582522 ] Eric Sproul commented on TS-1153: - Maybe [~i.galic] would like to weigh in again on the by-default question. The ability to just turn on the libumem debug features without a rebuild would seem a win, in any case. On Solaris, link with libumem by default Key: TS-1153 URL: https://issues.apache.org/jira/browse/TS-1153 Project: Traffic Server Issue Type: Improvement Components: Performance Environment: Solaris Reporter: Igor Galić Assignee: Eric Sproul Labels: memory Fix For: sometime http://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html We should make use of this and link to libumem by default on Solaris and Illumos. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2240) traffic_line -x reload doesn't return result
[ https://issues.apache.org/jira/browse/TS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2240: Fix Version/s: (was: 6.0.0) sometime traffic_line -x reload doesn't return result Key: TS-2240 URL: https://issues.apache.org/jira/browse/TS-2240 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Ask Bjørn Hansen Assignee: James Peach Labels: A It'd be nice if there was a variation of traffic_line -x that waits for the result of the reload and returns an appropriate exit code (and error information if applicable). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1153) On Solaris, link with libumem by default
[ https://issues.apache.org/jira/browse/TS-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582537#comment-14582537 ] Phil Sorber commented on TS-1153: - My concern is the takeover of malloc()/free(). If that is not on by default then I am OK with it. On Solaris, link with libumem by default Key: TS-1153 URL: https://issues.apache.org/jira/browse/TS-1153 Project: Traffic Server Issue Type: Improvement Components: Performance Environment: Solaris Reporter: Igor Galić Assignee: Eric Sproul Labels: memory Fix For: sometime http://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html We should make use of this and link to libumem by default on Solaris and Illumos. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2334) --with-tcmalloc does not test whether the found library actually exists
[
https://issues.apache.org/jira/browse/TS-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582541#comment-14582541
]
Phil Sorber commented on TS-2334:
-
[~esproul], Can you include this fix as well with TS-1153?
--with-tcmalloc does not test whether the found library actually exists
-
Key: TS-2334
URL: https://issues.apache.org/jira/browse/TS-2334
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 4.1.2, 4.2.0
Reporter: Igor Galić
Assignee: Eric Sproul
Fix For: sometime
Our {{TS_CHECK_TCMALLOC}} does not work.
I found this when compiling --with-tcmalloc on Ubuntu, where the {{tcmalloc}}
library is called {{tcmalloc_minimal}}. (And its corresponding -dev package,
will, intuitively be named {{libgoogle-perftools-dev}}. )
But none of this actually matters. I don't need to have any tcmalloc
libraries installed for this to fail horribly: {{-ltcmalloc}} will be added
to the build simply because I specified {{--with-tcmalloc}} this causes
pretty much everything in the configure run to break, or at least run with
defaults. (e.g.: glibc2 is not recognized to have a reentrant
{{gethostbyname()}}, see TS-2331)
proposal: ACTUALLY check if {{tcmalloc}} can be found, abort {{configure}} if
it can't.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-2110) Cleanup ts/experimental.h
[ https://issues.apache.org/jira/browse/TS-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2110. --- Resolution: Duplicate Fix Version/s: (was: 6.0.0) This is broken up into individual Jira's. Cleanup ts/experimental.h - Key: TS-2110 URL: https://issues.apache.org/jira/browse/TS-2110 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: api-change We should go through the APIs in experimental.h, and do one of 1. Remove 2. Move to ts/ts.h.in 3. Leave as is, assuming it's still considered experimental. I know there are arguments for and against having an experimental.h include file. I guess I don't have a strong opinion, another solution is to simply keep everything in ts.h.in, but mark APIs that are experimental as such. I do believe having APIs in an experimental state has benefits (such as we can modify such APIs as we see fit, there is no ABI/API compatibility promise). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2109) Cache-Control: no-cache responses are not stored the cache
[ https://issues.apache.org/jira/browse/TS-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2109. --- Resolution: Cannot Reproduce Fix Version/s: (was: 6.0.0) At least in 5.2.0 we do store no-cache in the cache so it must have been fixed at some point. Cache-Control: no-cache responses are not stored the cache -- Key: TS-2109 URL: https://issues.apache.org/jira/browse/TS-2109 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Igor Brezac This can be duplicated using 3.3.5-dev (trunk). Cache-Control: must-revalidate suffers from the same issue. Cache-Control: max-age=0,must-revalidate works correctly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2118) memcached plugin is in the source tree but does not build
[
https://issues.apache.org/jira/browse/TS-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2118:
Assignee: John (was: Eric Balsa)
memcached plugin is in the source tree but does not build
-
Key: TS-2118
URL: https://issues.apache.org/jira/browse/TS-2118
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Assignee: John
Labels: newbie
Fix For: 6.1.0
The memcached_remap plugin is currently in our experimental plugin tree, but
doesn't build even with {{--enable-experimental}}.
This should be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2118) memcached plugin is in the source tree but does not build
[
https://issues.apache.org/jira/browse/TS-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2118:
Labels: newbie (was: )
memcached plugin is in the source tree but does not build
-
Key: TS-2118
URL: https://issues.apache.org/jira/browse/TS-2118
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Assignee: John
Labels: newbie
Fix For: 6.1.0
The memcached_remap plugin is currently in our experimental plugin tree, but
doesn't build even with {{--enable-experimental}}.
This should be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2118) memcached plugin is in the source tree but does not build
[
https://issues.apache.org/jira/browse/TS-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2118:
Fix Version/s: (was: 6.0.0)
6.1.0
memcached plugin is in the source tree but does not build
-
Key: TS-2118
URL: https://issues.apache.org/jira/browse/TS-2118
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Assignee: John
Labels: newbie
Fix For: 6.1.0
The memcached_remap plugin is currently in our experimental plugin tree, but
doesn't build even with {{--enable-experimental}}.
This should be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2152) Create a tag that logs the destination IP of the client connection
[ https://issues.apache.org/jira/browse/TS-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2152: -- Fix Version/s: 6.1.0 Create a tag that logs the destination IP of the client connection -- Key: TS-2152 URL: https://issues.apache.org/jira/browse/TS-2152 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Leif Hedstrom Assignee: Eric Schwartz Labels: newbie Fix For: 6.1.0 This would log the IP of the proxy server, as the client connected to. This is useful for two reasons: 1) A box can be multi-homed 2) In a IPv4 / IPv6, you can then tell which endpoint the client connected to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2153) traffic_manager -tsArgs without -M is fatal error
[
https://issues.apache.org/jira/browse/TS-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2153:
--
Assignee: (was: Jack Bates)
traffic_manager -tsArgs without -M is fatal error
-
Key: TS-2153
URL: https://issues.apache.org/jira/browse/TS-2153
Project: Traffic Server
Issue Type: Bug
Components: Manager
Reporter: Adam Twardowski
Fix For: sometime
traffic_manager -tsArgs -T 'log.*'
Running the above command on the 4.0.0 branch commit
c8931df15e33924bb459d40859a0b49331a6dbaf
resulted in no running traffic_server and the following ps output
nobody 16807 0.1 0.9 410884 18272 pts/0Sl+ 16:58 0:00
traffic_manager -tsArgs -T log.*
nobody 16816 0.0 0.0 0 0 pts/0Z+ 16:58 0:00
[traffic_manager] defunct
root 16818 0.0 0.0 103240 864 pts/1S+ 16:59 0:00 grep tr
manger.log output
--
[Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
[Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server
Args: ' -T log.*'
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom]
Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE:
[LocalManager::listenForProxy] Listening on port: 80
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup
complete
[Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE:
[LocalManager::startProxy] Launching ts process
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:
[LocalManager::startProxy] ts options must contain -M
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: (last system error 0:
Success)
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2153) traffic_manager -tsArgs without -M is fatal error
[
https://issues.apache.org/jira/browse/TS-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2153:
--
Fix Version/s: (was: 6.0.0)
sometime
traffic_manager -tsArgs without -M is fatal error
-
Key: TS-2153
URL: https://issues.apache.org/jira/browse/TS-2153
Project: Traffic Server
Issue Type: Bug
Components: Manager
Reporter: Adam Twardowski
Fix For: sometime
traffic_manager -tsArgs -T 'log.*'
Running the above command on the 4.0.0 branch commit
c8931df15e33924bb459d40859a0b49331a6dbaf
resulted in no running traffic_server and the following ps output
nobody 16807 0.1 0.9 410884 18272 pts/0Sl+ 16:58 0:00
traffic_manager -tsArgs -T log.*
nobody 16816 0.0 0.0 0 0 pts/0Z+ 16:58 0:00
[traffic_manager] defunct
root 16818 0.0 0.0 103240 864 pts/1S+ 16:59 0:00 grep tr
manger.log output
--
[Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened
/usr/local/var/log/trafficserver/manager.log
[Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server
Args: ' -T log.*'
[Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom]
Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE:
[LocalManager::listenForProxy] Listening on port: 80
[Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup
complete
[Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE:
[LocalManager::startProxy] Launching ts process
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:
[LocalManager::startProxy] ts options must contain -M
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: (last system error 0:
Success)
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2152) Create a tag that logs the destination IP of the client connection
[ https://issues.apache.org/jira/browse/TS-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2152: Fix Version/s: (was: 6.0.0) 6.1.0 Create a tag that logs the destination IP of the client connection -- Key: TS-2152 URL: https://issues.apache.org/jira/browse/TS-2152 Project: Traffic Server Issue Type: New Feature Components: Logging Reporter: Leif Hedstrom Assignee: Eric Schwartz Labels: newbie This would log the IP of the proxy server, as the client connected to. This is useful for two reasons: 1) A box can be multi-homed 2) In a IPv4 / IPv6, you can then tell which endpoint the client connected to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2205) AIO caused system hang
[
https://issues.apache.org/jira/browse/TS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2205:
Assignee: (was: weijin)
AIO caused system hang
--
Key: TS-2205
URL: https://issues.apache.org/jira/browse/TS-2205
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 4.0.1
Reporter: Zhao Yongming
the system may hang with AIO thread CPU usage rising:
{code}
top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2205) AIO caused system hang
[
https://issues.apache.org/jira/browse/TS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2205:
Fix Version/s: (was: 6.0.0)
sometime
AIO caused system hang
--
Key: TS-2205
URL: https://issues.apache.org/jira/browse/TS-2205
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 4.0.1
Reporter: Zhao Yongming
the system may hang with AIO thread CPU usage rising:
{code}
top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2225) Add line/record id to traffic_logcat
[ https://issues.apache.org/jira/browse/TS-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2225: -- Fix Version/s: (was: 6.0.0) 6.2.0 Add line/record id to traffic_logcat Key: TS-2225 URL: https://issues.apache.org/jira/browse/TS-2225 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Ask Bjørn Hansen Fix For: 6.2.0 For tailing the binary log it'll be useful with a concept roughly equivalent to line number in a text file. traffic_logcat will optionally output this and then have a feature to say start following from line/record X. The record id a numeric increment for the particular log file or the request ID (if/when that's available). The immediate objective is for log readers to continue reading from where they last read if they're restarted.  -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3686) Implement Lua scriptlets, as discussed at the Austin 2015 Summit
Leif Hedstrom created TS-3686: - Summary: Implement Lua scriptlets, as discussed at the Austin 2015 Summit Key: TS-3686 URL: https://issues.apache.org/jira/browse/TS-3686 Project: Traffic Server Issue Type: New Feature Components: Configuration, Lua Reporter: Leif Hedstrom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2240) traffic_ctl reload doesn't return result
[ https://issues.apache.org/jira/browse/TS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call closed TS-2240. -- Resolution: Won't Fix Fix Version/s: (was: sometime) The configuration reload happens asynchronously and there is no acknowledgment that the configuration was reloaded for each of the configuration callbacks. It would be complex to add acknowledgments. traffic_ctl reload doesn't return result Key: TS-2240 URL: https://issues.apache.org/jira/browse/TS-2240 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Ask Bjørn Hansen Labels: A It'd be nice if there was a variation of traffic_line -x that waits for the result of the reload and returns an appropriate exit code (and error information if applicable). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2286) Make config files pretty with comments
[ https://issues.apache.org/jira/browse/TS-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2286. --- Resolution: Won't Fix Fix Version/s: (was: 6.0.0) Make config files pretty with comments -- Key: TS-2286 URL: https://issues.apache.org/jira/browse/TS-2286 Project: Traffic Server Issue Type: Sub-task Reporter: Phil Sorber Assignee: Alan M. Carroll Basically what the summary says. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2285) Embed LUA with bindings to configuration points
[ https://issues.apache.org/jira/browse/TS-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2285. --- Resolution: Won't Fix Fix Version/s: (was: 6.0.0) Embed LUA with bindings to configuration points --- Key: TS-2285 URL: https://issues.apache.org/jira/browse/TS-2285 Project: Traffic Server Issue Type: Sub-task Reporter: Phil Sorber Assignee: Leif Hedstrom We want to allow ATS to be configured by a LUA script. This requires embedding LUA and exposing config points to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2299) ATS seg faults in MIMEScanner::mime_scanner_get
[
https://issues.apache.org/jira/browse/TS-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2299:
Fix Version/s: (was: 6.0.0)
sometime
ATS seg faults in MIMEScanner::mime_scanner_get
---
Key: TS-2299
URL: https://issues.apache.org/jira/browse/TS-2299
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP, MIME
Affects Versions: 4.0.1
Environment: RHEL 5.9
Reporter: John Paul Vasicek
Labels: Crash
Fix For: sometime
I'm seeing segmentation faults in ATS 4.0.1, these seem to happen randomly:
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x2aafe810eca0]
/usr/local/bin/traffic_server(_Z16mime_scanner_getP11MIMEScannerPPKcS2_S3_S3_Pbbi+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(_Z21http_parser_parse_reqP10HTTPParserP7HdrHeapP11HTTPHdrImplPPKcS6_bb+0x113)[0x5c4e73]
/usr/local/bin/traffic_server(_ZN7HTTPHdr9parse_reqEP10HTTPParserP14IOBufferReaderPib+0x1a7)[0x5c11d7]
/usr/local/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x100)[0x5311c0]
/usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x425)[0x4d1535]
/usr/local/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x5ac)[0x4d1e6c]
/usr/local/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x46e)[0x4d389e]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x238)[0x6cb258]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x3a9)[0x6cb979]
/usr/local/bin/traffic_server[0x6cad1e]
/lib64/libpthread.so.0[0x2aafe810683d]
/lib64/libc.so.6(clone+0x6d)[0x313bad503d]
{code}
(demangled)
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x2aafe810eca0]
/usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
/lib64/libpthread.so.0[0x2ba86e67aca0]
/usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x100)[0x5311c0]
/usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
/usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
/usr/local/bin/traffic_server(PluginVC::process_read_side(bool)+0x425)[0x4d1535]
/usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x100)[0x5311c0]
/usr/local/bin/traffic_server(PluginVC::main_handler(int,
void*)+0x39f)[0x4d37cf]
/usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(_ZN8Plu
ginVC17process_read_sideEb+0x425)[0x4d1535]
/usr/local/bin/traffic_server(EThread::process_event(Event*,
int)+0x238)[0x6cb258]
/usr/local/bin/traffic_server(EThread::execute()+0x707)[0x6cbcd7]
/usr/local/bin/traffic_server[0x6cad1e]
/lib64/libpthread.so.0[0x2ba86e67283d]
/usr/local/bin/traffic_server(PluginVC::process_write_side(bool)+0x5ac)[0x4d1e6c]
/usr/local/bin/traffic_server(PluginVC::main_handler(int,
void*)+0x46e)[0x4d389e]
/lib64/libc.so.6(clone+0x6d)[0x313bad503d]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2354) improve documentation about different type of timeouts
[ https://issues.apache.org/jira/browse/TS-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2354: Assignee: Jon Sime improve documentation about different type of timeouts -- Key: TS-2354 URL: https://issues.apache.org/jira/browse/TS-2354 Project: Traffic Server Issue Type: Task Components: Documentation Reporter: Daniel Vitor Morilha Assignee: Jon Sime Fix For: Docs Traffic Server provides different types of timeouts: - dns - connect - no activity - active I found no documentation about the timeouts, specially no activity and active. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2385) http.origin_max_connections is ignored when http.keep_alive_post_out is set
[ https://issues.apache.org/jira/browse/TS-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2385. --- Resolution: Invalid Fix Version/s: (was: 6.0.0) http.origin_max_connections is ignored when http.keep_alive_post_out is set Key: TS-2385 URL: https://issues.apache.org/jira/browse/TS-2385 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.5, 4.0.2 Reporter: Wilson Ho Assignee: Susan Hinrichs Using the following settings: CONFIG proxy.config.http.server_max_connections INT 0 CONFIG proxy.config.http.origin_max_connections INT 200 CONFIG proxy.config.http.keep_alive_post_out INT 1 The origin_max_connections is NOT honored and at some point TS would start creating much much more than 200 connections to each origin server. To repeat: 1) simulate 1000 clients and have each of them continuously send requests to TS. It doesn't matter if these are GET or POST requests. 2) monitor the number of TCP connection to the origin server. 3) The origin_max_connections might hold up for a few minutes, but after a while, it starts to break and you would see close to 1000 connections being created. If keep_alive_post_out is turned off, then using the same experiment, TS maintains the outgoing connection count pretty steadily at 200. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2394) We need a performance tuning document
[ https://issues.apache.org/jira/browse/TS-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2394: Assignee: Jon Sime We need a performance tuning document - Key: TS-2394 URL: https://issues.apache.org/jira/browse/TS-2394 Project: Traffic Server Issue Type: Bug Components: Documentation Reporter: Igor Galić Assignee: Jon Sime Fix For: Docs Traffic Server is a complex beast, we need a document that unifies and links-back to all the different options that have an affect on its performance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2403) Segfault when HostDB full
[
https://issues.apache.org/jira/browse/TS-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2403:
Fix Version/s: (was: 6.0.0)
sometime
Segfault when HostDB full
-
Key: TS-2403
URL: https://issues.apache.org/jira/browse/TS-2403
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 4.0.1
Reporter: David Carlin
Assignee: Alan M. Carroll
Labels: Crash
Fix For: sometime
diags.log leading up to crash:
{noformat}
[Nov 25 10:50:23.346] Server {0x2b06c4302700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.379] Server {0x2b06c4100700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.449] Server {0x2b06c4a09700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.462] Server {0x2b06c4403700} WARNING: out of room in hostdb
for round-robin DNS data
[Nov 25 10:50:23.494] Server {0x2b06bed1f540} WARNING: out of room in hostdb
for reverse DNS data
[Nov 25 10:54:46.919] {0x2baa2d65b540} STATUS: opened
/home/y/logs/trafficserver/diags.log
[Nov 25 10:54:46.927] {0x2baa2d65b540} NOTE: updated diags config
[Nov 25 10:54:46.961] Server {0x2baa2d65b540} NOTE: cache clustering disabled
[Nov 25 10:54:46.995] Server {0x2baa2d65b540} NOTE: ip_allow.config updated,
reloading
[Nov 25 10:54:47.059] Server {0x2baa2d65b540} NOTE: cache clustering disabled
[Nov 25 10:54:47.072] Server {0x2baa2d65b540} NOTE: logging initialized[15],
logging_mode = 3
[Nov 25 10:54:47.103] Server {0x2baa2d65b540} NOTE: loading plugin
'/home/y/libexec64/trafficserver/quick_filter.so'
[Nov 25 10:54:47.326] Server {0x2baa2d65b540} NOTE: loading plugin
'/home/y/libexec64/trafficserver/header_filter.so'
[Nov 25 10:54:49.395] Server {0x2baa2d65b540} NOTE: traffic server running
{noformat}
From traffic.out:
{noformat}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x3d07c0f500)[0x2b06be27a500]
/home/y/bin/traffic_server(_Z14ats_ip_addr_eqPK8sockaddrS1_+0x3)[0x5e0323]
/home/y/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x2389)[0x5df3b9]
/home/y/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5f9cd4]
/home/y/bin/traffic_server[0x5fbd17]
/home/y/bin/traffic_server(_ZN10DNSHandler8recv_dnsEiP5Event+0x8d0)[0x5fd5c0]
/home/y/bin/traffic_server(_ZN10DNSHandler9mainEventEiP5Event+0x12)[0x5fe642]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a321f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x4a3)[0x6a3c03]
/home/y/bin/traffic_server(main+0xb14)[0x4c5314]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3d0781ecdd]
/home/y/bin/traffic_server[0x485a19]
{noformat}
Backtrace:
{noformat}
#0 ats_ip_addr_cmp (lhs=0x7fffdf15e778, rhs=0x8) at
../../lib/ts/ink_inet.h:669
#1 ats_ip_addr_eq (lhs=0x7fffdf15e778, rhs=0x8) at
../../lib/ts/ink_inet.h:721
#2 0x005df3b9 in restore_info (this=value optimized out,
event=value optimized out, e=value optimized out) at HostDB.cc:1375
#3 HostDBContinuation::dnsEvent (this=value optimized out, event=value
optimized out, e=value optimized out) at HostDB.cc:1604
#4 0x005f9cd4 in handleEvent (this=0x2b06f40a2120) at
../../iocore/eventsystem/I_Continuation.h:146
#5 DNSEntry::postEvent (this=0x2b06f40a2120) at DNS.cc:1278
#6 0x005fbd17 in dns_result (h=0x1778380, e=0x2b06f40a2120,
ent=0x1913820, retry=value optimized out) at DNS.cc:1230
#7 0x005fd5c0 in dns_process (this=0x1778380) at DNS.cc:1599
#8 DNSHandler::recv_dns (this=0x1778380) at DNS.cc:790
#9 0x005fe642 in DNSHandler::mainEvent (this=0x1778380, event=value
optimized out, e=value optimized out) at DNS.cc:802
#10 0x006a321f in handleEvent (this=0x2b06bf2d0010, e=0x2b06d8092740,
calling_code=5) at I_Continuation.h:146
#11 EThread::process_event (this=0x2b06bf2d0010, e=0x2b06d8092740,
calling_code=5) at UnixEThread.cc:141
#12 0x006a3c03 in EThread::execute (this=0x2b06bf2d0010) at
UnixEThread.cc:265
#13 0x004c5314 in main (argv=value optimized out) at Main.cc:1690
{noformat}
HostDB settings:
CONFIG proxy.config.hostdb.size INT 20
CONFIG proxy.config.hostdb.storage_size INT 50331648
CONFIG proxy.config.hostdb.ttl_mode INT 0
CONFIG proxy.config.hostdb.timeout INT 1440
CONFIG proxy.config.hostdb.strict_round_robin INT 0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2150) Add Milestone log tags
[
https://issues.apache.org/jira/browse/TS-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2150:
Fix Version/s: (was: 6.0.0)
6.1.0
Add Milestone log tags
--
Key: TS-2150
URL: https://issues.apache.org/jira/browse/TS-2150
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Leif Hedstrom
Assignee: John
We have a notion of milestones in the core, and plugin APIs
(TSHttpTxnMilestoneGet() ). It'd be useful to expose these milestone timers
as a log tag, something like:
{code}
%{UA_BEGIN}mtms
{code}
mtms is just an example / suggestion, MilestoneTimeMilliSecond, we can make
it whatever we like.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1409) Add webdav methods to ip allow/quick filter
[ https://issues.apache.org/jira/browse/TS-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582499#comment-14582499 ] Bryan Call commented on TS-1409: TRACE is part of rfc2616 https://www.ietf.org/rfc/rfc2616.txt REPORT is part of rfc3253 https://www.ietf.org/rfc/rfc3253.txt Add webdav methods to ip allow/quick filter --- Key: TS-1409 URL: https://issues.apache.org/jira/browse/TS-1409 Project: Traffic Server Issue Type: Bug Components: Security Affects Versions: 3.2.0 Reporter: Bryan Call Assignee: Meera Mosale Nataraja Labels: newbie Fix For: 6.0.0 I know of PROPFIND and REPORT should be added. There might need to be more added. HTTP Extensions for Distributed Authoring -- WEBDAV http://www.ietf.org/rfc/rfc2518.txt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2284) Run with no configs
[ https://issues.apache.org/jira/browse/TS-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2284. --- Resolution: Won't Fix Fix Version/s: (was: 6.0.0) Run with no configs --- Key: TS-2284 URL: https://issues.apache.org/jira/browse/TS-2284 Project: Traffic Server Issue Type: Sub-task Components: Configuration Reporter: Phil Sorber Assignee: Leif Hedstrom In addition to running with empty configs (TS-2282), we should be able to run with no configs and not write them out (TS-2283). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-315) Add switch to disable config file generation/runtime behavior changing
[ https://issues.apache.org/jira/browse/TS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-315: --- Issue Type: Improvement (was: Sub-task) Parent: (was: TS-2281) Add switch to disable config file generation/runtime behavior changing -- Key: TS-315 URL: https://issues.apache.org/jira/browse/TS-315 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Miles Libbey Priority: Minor Labels: A Fix For: sometime (was yahoo bug 1863676) Original description by Michael S. Fischer 2 years ago at 2008-04-09 09:52 In production, in order to improve site stability, it is imperative that TS never accidentally overwrite its own configuration files. For this reason, we'd like to request a switch be added to TS, preferably via the command line, that disables all automatic configuration file generation or other runtime behavioral changes initiated by any form of IPC other than 'traffic_line -x' (including the web interface, etc.) Comment 1 by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17 A very crucial request, in my opinion. If TS needs to be able to read command-line config changes on the fly, these changes should be stored in another config file (for example remap.config.local instead of remap.config). We have a patch config package that overwrites 4 of the config files under /home/conf/ts/, and with all packages we'd like to think that the content of these files can't change outside our control. Comment 2 by Bryan Call 2 years ago at 2008-04-09 11:02:46 traffic_line -x doesn't modify the configuration, it reloads the configuration files. If we want to have an option for this it would be good to have it as an option configuration file (CONFIG proxy.config.write_protect INT 1). It would be an equivalent of write protecting floppies (ahh the memories)... Comment 3 by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09 I don't think it would be a good idea to have this in the configuration file, as it would introduce a chicken/egg problem. Comment 4 by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17 So I'm not 100% positive that this isn't just a bad interaction. Now, it's only triggered when trafficserver is running, but usually what ends up happening is that we get a records.config which looks like it's the default config that comes with the trafficserver package. It's possible it's all one and the same issue, or we might have two issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2299) ATS seg faults in MIMEScanner::mime_scanner_get
[
https://issues.apache.org/jira/browse/TS-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber reassigned TS-2299:
---
Assignee: Phil Sorber
ATS seg faults in MIMEScanner::mime_scanner_get
---
Key: TS-2299
URL: https://issues.apache.org/jira/browse/TS-2299
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP, MIME
Affects Versions: 4.0.1
Environment: RHEL 5.9
Reporter: John Paul Vasicek
Assignee: Phil Sorber
Labels: Crash
Fix For: sometime
I'm seeing segmentation faults in ATS 4.0.1, these seem to happen randomly:
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x2aafe810eca0]
/usr/local/bin/traffic_server(_Z16mime_scanner_getP11MIMEScannerPPKcS2_S3_S3_Pbbi+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(_Z21http_parser_parse_reqP10HTTPParserP7HdrHeapP11HTTPHdrImplPPKcS6_bb+0x113)[0x5c4e73]
/usr/local/bin/traffic_server(_ZN7HTTPHdr9parse_reqEP10HTTPParserP14IOBufferReaderPib+0x1a7)[0x5c11d7]
/usr/local/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x100)[0x5311c0]
/usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x425)[0x4d1535]
/usr/local/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x5ac)[0x4d1e6c]
/usr/local/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x46e)[0x4d389e]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x238)[0x6cb258]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x3a9)[0x6cb979]
/usr/local/bin/traffic_server[0x6cad1e]
/lib64/libpthread.so.0[0x2aafe810683d]
/lib64/libc.so.6(clone+0x6d)[0x313bad503d]
{code}
(demangled)
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x2aafe810eca0]
/usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
/lib64/libpthread.so.0[0x2ba86e67aca0]
/usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x100)[0x5311c0]
/usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
/usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
/usr/local/bin/traffic_server(PluginVC::process_read_side(bool)+0x425)[0x4d1535]
/usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x100)[0x5311c0]
/usr/local/bin/traffic_server(PluginVC::main_handler(int,
void*)+0x39f)[0x4d37cf]
/usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(_ZN8Plu
ginVC17process_read_sideEb+0x425)[0x4d1535]
/usr/local/bin/traffic_server(EThread::process_event(Event*,
int)+0x238)[0x6cb258]
/usr/local/bin/traffic_server(EThread::execute()+0x707)[0x6cbcd7]
/usr/local/bin/traffic_server[0x6cad1e]
/lib64/libpthread.so.0[0x2ba86e67283d]
/usr/local/bin/traffic_server(PluginVC::process_write_side(bool)+0x5ac)[0x4d1e6c]
/usr/local/bin/traffic_server(PluginVC::main_handler(int,
void*)+0x46e)[0x4d389e]
/lib64/libc.so.6(clone+0x6d)[0x313bad503d]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2299) ATS seg faults in MIMEScanner::mime_scanner_get
[
https://issues.apache.org/jira/browse/TS-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582536#comment-14582536
]
Phil Sorber commented on TS-2299:
-
Is this still an issue in ATS 5.3.x?
ATS seg faults in MIMEScanner::mime_scanner_get
---
Key: TS-2299
URL: https://issues.apache.org/jira/browse/TS-2299
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP, MIME
Affects Versions: 4.0.1
Environment: RHEL 5.9
Reporter: John Paul Vasicek
Labels: Crash
Fix For: sometime
I'm seeing segmentation faults in ATS 4.0.1, these seem to happen randomly:
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x2aafe810eca0]
/usr/local/bin/traffic_server(_Z16mime_scanner_getP11MIMEScannerPPKcS2_S3_S3_Pbbi+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(_Z21http_parser_parse_reqP10HTTPParserP7HdrHeapP11HTTPHdrImplPPKcS6_bb+0x113)[0x5c4e73]
/usr/local/bin/traffic_server(_ZN7HTTPHdr9parse_reqEP10HTTPParserP14IOBufferReaderPib+0x1a7)[0x5c11d7]
/usr/local/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x100)[0x5311c0]
/usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x425)[0x4d1535]
/usr/local/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x5ac)[0x4d1e6c]
/usr/local/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x46e)[0x4d389e]
/usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x238)[0x6cb258]
/usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x3a9)[0x6cb979]
/usr/local/bin/traffic_server[0x6cad1e]
/lib64/libpthread.so.0[0x2aafe810683d]
/lib64/libc.so.6(clone+0x6d)[0x313bad503d]
{code}
(demangled)
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x2aafe810eca0]
/usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/local/bin/traffic_server - STACK TRACE:
/usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
/lib64/libpthread.so.0[0x2ba86e67aca0]
/usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
/usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x100)[0x5311c0]
/usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
/usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
/usr/local/bin/traffic_server(PluginVC::process_read_side(bool)+0x425)[0x4d1535]
/usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x100)[0x5311c0]
/usr/local/bin/traffic_server(PluginVC::main_handler(int,
void*)+0x39f)[0x4d37cf]
/usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
/usr/local/bin/traffic_server(_ZN8Plu
ginVC17process_read_sideEb+0x425)[0x4d1535]
/usr/local/bin/traffic_server(EThread::process_event(Event*,
int)+0x238)[0x6cb258]
/usr/local/bin/traffic_server(EThread::execute()+0x707)[0x6cbcd7]
/usr/local/bin/traffic_server[0x6cad1e]
/lib64/libpthread.so.0[0x2ba86e67283d]
/usr/local/bin/traffic_server(PluginVC::process_write_side(bool)+0x5ac)[0x4d1e6c]
/usr/local/bin/traffic_server(PluginVC::main_handler(int,
void*)+0x46e)[0x4d389e]
/lib64/libc.so.6(clone+0x6d)[0x313bad503d]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2166) Response header to ua has two Content-Range field
[
https://issues.apache.org/jira/browse/TS-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2166:
Assignee: Alan M. Carroll
Response header to ua has two Content-Range field
---
Key: TS-2166
URL: https://issues.apache.org/jira/browse/TS-2166
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.2.4, 4.2.0
Reporter: portl4t
Assignee: Alan M. Carroll
Fix For: 6.0.0
Follow these steps to reproduce:
1. TrafficServer cache a document which has Etag field in response header
2. The document expires.
3. UA sends request with Range field to this document.
4. TrafficServer sends request with IMS field to origin server to revalidate
this document
5. Origin Server sends response which has 304 code and Content-Range field
to TrafficServer
6. TrafficServer will generate another Content-Range field in
RangeTransform.
{code}
HTTP/1.1 206 Partial Content
Date: Thu, 29 Aug 2013 03:09:05 GMT
Content-Type: application/octet-stream
Cache-Control: public
Content-Disposition: attachment;
Content-Encoding: utf-8
ETag: F68ADB16DB4F1EF87D93D665CC1FFF54
Expires: Tue,13 August 2013 07:04:10 GMT
Last-Modified: Tue, 13 Aug 2013 07:04:14 GMT
Server: ATS/3.2.0
x-oss-request-id: 521EBB51E369AA445D2F48B9
Accept-Ranges: bytes
Content-Range: bytes 0-4243537/4243538
Content-Range: bytes 0-4243537/4243538
Content-Length: 4243538
Age: 0
Via: http/1.1 l2cn202 (ATS [cSsNfU])
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2170) stats.config.xml is undocumented
[
https://issues.apache.org/jira/browse/TS-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2170:
Assignee: Jon Sime
stats.config.xml is undocumented
Key: TS-2170
URL: https://issues.apache.org/jira/browse/TS-2170
Project: Traffic Server
Issue Type: Bug
Components: Documentation
Reporter: Igor Galić
Assignee: Jon Sime
Fix For: Docs
Save for its DTD: {proxy/config/stats.config.dtd}, {stats.config.xml} is
undocumented.
We should change that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2182) Setting proxy.config.net.sock_recv_buffer_size_out seriously affects performance
[
https://issues.apache.org/jira/browse/TS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2182:
Fix Version/s: (was: 6.0.0)
6.1.0
Setting proxy.config.net.sock_recv_buffer_size_out seriously affects
performance
Key: TS-2182
URL: https://issues.apache.org/jira/browse/TS-2182
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Network
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 6.1.0
I still need to do some more testing, but setting
{code}
CONFIG proxy.config.net.sock_recv_buffer_size_out INT 256K
{code}
on my box reduces throughput to a (fast, local) Origin by about 1000x.
Throughput went from 18MB/sec to 15KB/sec. Removing this setting, restored
normal performance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2193) Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1
[ https://issues.apache.org/jira/browse/TS-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2193: Fix Version/s: (was: 6.0.0) 6.2.0 Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1 -- Key: TS-2193 URL: https://issues.apache.org/jira/browse/TS-2193 Project: Traffic Server Issue Type: Bug Components: DNS Affects Versions: 4.1.2 Reporter: Tommy Lee Assignee: Alan M. Carroll Labels: Crash Fix For: 6.2.0 Attachments: bt-01.txt Hi all, I've tried to enable DNS Thread without luck. When i set proxy.config.dns.dedicated_thread to 1, it crashes with the information below. The ATS is working in Forward Proxy mode. Thanks in advance. -- traffic.out NOTE: Traffic Server received Sig 11: Segmentation fault /usr/local/cache-4.1/bin/traffic_server - STACK TRACE: /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2af714875cb0] /usr/local/cache-4.1/bin/traffic_server(_Z16_acquire_sessionP13SessionBucketPK8sockaddrR7INK_MD5P6HttpSM+0x52)[0x51dac2] /usr/local/cache-4.1/bin/traffic_server(_ZN18HttpSessionManager15acquire_sessionEP12ContinuationPK8sockaddrPKcP17HttpClientSessionP6HttpSM+0x3d1)[0x51e0f1] /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM19do_http_server_openEb+0x30c)[0x53644c] /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x6a0)[0x537560] /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x57e)[0x53743e] /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x57e)[0x53743e] /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM27state_hostdb_reverse_lookupEiPv+0xb9)[0x526b99] /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x531be8] /usr/local/cache-4.1/bin/traffic_server[0x5d7c8a] /usr/local/cache-4.1/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x821)[0x5decd1] /usr/local/cache-4.1/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5f7a94] /usr/local/cache-4.1/bin/traffic_server[0x5fd382] /usr/local/cache-4.1/bin/traffic_server(_ZN10DNSHandler8recv_dnsEiP5Event+0x852)[0x5fee72] /usr/local/cache-4.1/bin/traffic_server(_ZN10DNSHandler9mainEventEiP5Event+0x14)[0x5ffd94] /usr/local/cache-4.1/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x91)[0x6b2a41] /usr/local/cache-4.1/bin/traffic_server(_ZN7EThread7executeEv+0x514)[0x6b3534] /usr/local/cache-4.1/bin/traffic_server[0x6b17ea] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x2af71486de9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2af71558dccd] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2205) AIO caused system hang
[
https://issues.apache.org/jira/browse/TS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber closed TS-2205.
---
Resolution: Duplicate
AIO caused system hang
--
Key: TS-2205
URL: https://issues.apache.org/jira/browse/TS-2205
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 4.0.1
Reporter: Zhao Yongming
the system may hang with AIO thread CPU usage rising:
{code}
top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2224) We leave an .../etc/trafficserver/snapshots directory behind, empty
[ https://issues.apache.org/jira/browse/TS-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2224: --- Fix Version/s: (was: 6.0.0) sometime We leave an .../etc/trafficserver/snapshots directory behind, empty --- Key: TS-2224 URL: https://issues.apache.org/jira/browse/TS-2224 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Leif Hedstrom Assignee: Phil Sorber Fix For: sometime Snapshots goes into the .../var/trafficserver directory, yet we still have make install create this writeable directory under etc/trafficserver. We should fix / remove this. At the same time, lets make sure the records.config configuration for snapshots dir actually works as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2240) traffic_ctl reload doesn't return result
[ https://issues.apache.org/jira/browse/TS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2240: --- Summary: traffic_ctl reload doesn't return result (was: traffic_line -x reload doesn't return result) traffic_ctl reload doesn't return result Key: TS-2240 URL: https://issues.apache.org/jira/browse/TS-2240 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Ask Bjørn Hansen Labels: A It'd be nice if there was a variation of traffic_line -x that waits for the result of the reload and returns an appropriate exit code (and error information if applicable). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2240) traffic_line -x reload doesn't return result
[ https://issues.apache.org/jira/browse/TS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2240: --- Assignee: (was: James Peach) traffic_line -x reload doesn't return result Key: TS-2240 URL: https://issues.apache.org/jira/browse/TS-2240 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Ask Bjørn Hansen Labels: A It'd be nice if there was a variation of traffic_line -x that waits for the result of the reload and returns an appropriate exit code (and error information if applicable). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2334) --with-tcmalloc does not test whether the found library actually exists
[
https://issues.apache.org/jira/browse/TS-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2334:
Assignee: Eric Sproul
--with-tcmalloc does not test whether the found library actually exists
-
Key: TS-2334
URL: https://issues.apache.org/jira/browse/TS-2334
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 4.1.2, 4.2.0
Reporter: Igor Galić
Assignee: Eric Sproul
Fix For: sometime
Our {{TS_CHECK_TCMALLOC}} does not work.
I found this when compiling --with-tcmalloc on Ubuntu, where the {{tcmalloc}}
library is called {{tcmalloc_minimal}}. (And its corresponding -dev package,
will, intuitively be named {{libgoogle-perftools-dev}}. )
But none of this actually matters. I don't need to have any tcmalloc
libraries installed for this to fail horribly: {{-ltcmalloc}} will be added
to the build simply because I specified {{--with-tcmalloc}} this causes
pretty much everything in the configure run to break, or at least run with
defaults. (e.g.: glibc2 is not recognized to have a reentrant
{{gethostbyname()}}, see TS-2331)
proposal: ACTUALLY check if {{tcmalloc}} can be found, abort {{configure}} if
it can't.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-2345) failed assert in Regression test SDK_API_HttpTxnTransform
[
https://issues.apache.org/jira/browse/TS-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2345.
---
Resolution: Cannot Reproduce
Fix Version/s: (was: sometime)
failed assert in Regression test SDK_API_HttpTxnTransform
-
Key: TS-2345
URL: https://issues.apache.org/jira/browse/TS-2345
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Thomas Berger
The regression test for SDK_API_HttpTxnTransform failes with an assertion
failure:
{noformat}
FATAL:
/var/tmp/paludis/net-proxy-trafficserver-4.1.1/work/trafficserver-4.1.1/proxy/InkAPITest.cc:7151:
failed assert `request_id != -1`
traffic_server - STACK TRACE:
/usr/lib64/libtsutil.so.4(+0x14aff)[0x7f4d7237caff]
/usr/lib64/libtsutil.so.4(+0x13e4f)[0x7f4d7237be4f]
traffic_server[0x4a7936]
traffic_server[0x4f299d]
traffic_server(HttpSM::state_api_callout(int, void*)+0x532)[0x508542]
traffic_server(HttpSM::set_next_state()+0xf0a)[0x5179ea]
traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x71c)[0x505e3c]
traffic_server(HttpSM::main_handler(int, void*)+0x99)[0x504979]
traffic_server(UnixNetVConnection::net_read_io(NetHandler*,
EThread*)+0x438)[0x6152e8]
traffic_server(NetHandler::mainNetEvent(int, Event*)+0x4ea)[0x60fb6a]
traffic_server(EThread::process_event(Event*, int)+0xc7)[0x62c257]
traffic_server(EThread::execute()+0x5a4)[0x62c9b4]
traffic_server[0x62b32e]
/lib64/libpthread.so.0(+0x8fe6)[0x7f4d70a18fe6]
/lib64/libc.so.6(clone+0x6d)[0x7f4d7001a8ad]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2383) Strange errors / warnings from make install related to man pages
[
https://issues.apache.org/jira/browse/TS-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2383:
Assignee: Jon Sime
Strange errors / warnings from make install related to man pages
Key: TS-2383
URL: https://issues.apache.org/jira/browse/TS-2383
Project: Traffic Server
Issue Type: Bug
Components: Build, Documentation
Reporter: Leif Hedstrom
Assignee: Jon Sime
Fix For: 6.0.0
I get
{code}
traffic_cop.8 { } None:None: WARNING: No definition found for configuration
variable 'proxy.config.cop.linux_min_memfree_kb'
None:None: WARNING: file reference target not found: /tmp/traffic_cop.trace
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1153) On Solaris, link with libumem by default
[ https://issues.apache.org/jira/browse/TS-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582559#comment-14582559 ] Eric Sproul commented on TS-1153: - libumem's malloc/free should be more performant on modern multi-core systems than traditional libc malloc, and you get all the other nice features along for the ride. I'll see if I can test LD_PRELOADing libumem on our instances just as a quick test. On Solaris, link with libumem by default Key: TS-1153 URL: https://issues.apache.org/jira/browse/TS-1153 Project: Traffic Server Issue Type: Improvement Components: Performance Environment: Solaris Reporter: Igor Galić Assignee: Eric Sproul Labels: memory Fix For: sometime http://www.oracle.com/technetwork/server-storage/solaris10/solaris-memory-135224.html We should make use of this and link to libumem by default on Solaris and Illumos. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2387) traffic_top should resize to the terminal window size
[ https://issues.apache.org/jira/browse/TS-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2387: Fix Version/s: (was: 6.0.0) 6.1.0 traffic_top should resize to the terminal window size - Key: TS-2387 URL: https://issues.apache.org/jira/browse/TS-2387 Project: Traffic Server Issue Type: Improvement Components: Console, Manager Reporter: James Peach Assignee: Bryan Call Fix For: 6.1.0 traffic_top is hard-coded to draw a 80x24 window. It would be much better if it queried the window size and drew itself with the actual window dimensions. Bonus points for resizing when the terminal window size changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2375) Error when using ascii logging format: There are more field markers than fields
[
https://issues.apache.org/jira/browse/TS-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2375:
Fix Version/s: (was: 6.0.0)
6.1.0
Error when using ascii logging format: There are more field markers than
fields
---
Key: TS-2375
URL: https://issues.apache.org/jira/browse/TS-2375
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 4.0.2, 4.1.2
Reporter: David Carlin
Assignee: Bryan Call
Fix For: 6.1.0
I noticed the following on an ats 4.0.2 host in diags.log:
{noformat}[Nov 20 15:08:29.627] Server {0x2b732fe9c700} NOTE: There are more
field markers than fields; cannot process log entry{noformat}
It only happens about every fifth time you start ATS. That message will fill
diags.log and nothing is written to squid.log
I then upgraded to 4.1.1 as a test, and the same thing happened except there
was additional error information:
{noformat}[Nov 20 15:40:53.656] Server {0x2b568aac8700} NOTE: There are more
field markers than fields; cannot process log entry
[Nov 20 15:40:53.656] Server {0x2b568aac8700} ERROR: Failed to convert
LogBuffer to ascii, have dropped (232) bytes.{noformat}
The convert to ascii message tipped me off that this could be the source of
the problem. Up until now we've been using the binary log format, so perhaps
this is why I didn't run into this in the past. I then changed the log
format back to binary, and I was unable to reproduce the issue - so it seems
related to ascii logging.
Here is our logs_xml.config:
{noformat}
LogFormat
Name = ats_generic_config/
Format = %cqtq %ttms %chi %crc %pssc %psql %cqhm %cquc
%caun %phr/%pqsn %psct %cquuc f1 f2 f3 f4/
/LogFormat
LogObject
Format = ats_generic_config/
Filename = squid/
Mode = ascii/
/LogObject
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2447) Cache fails to load / initialize, seems stuck on directory entry cleanup
[
https://issues.apache.org/jira/browse/TS-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-2447:
Fix Version/s: (was: 6.0.0)
sometime
Cache fails to load / initialize, seems stuck on directory entry cleanup
Key: TS-2447
URL: https://issues.apache.org/jira/browse/TS-2447
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Leif Hedstrom
Assignee: Alan M. Carroll
Fix For: sometime
We had an issue where a number of machines would not startup properly. They
get stuck on reading / initializing the cache. It initializes the caches with
{code}
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 0:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 1:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 2:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 3:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 4:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 5:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 6:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
0 Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) Cache::open
- proxy.config.cache.min_average_object_size = 65536
[Dec 20 16:45:40.198] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.201] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.204] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.208] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.213] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.219] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.224] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
{code}
After this, it enters a stage where it’s doing a *lot* of dir_clean events:
{code}
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f028 tag 0 boffset 0 b 0x7f3edcd6f028 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f050 tag 0 boffset 0 b 0x7f3edcd6f050 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f078 tag 0 boffset 0 b 0x7f3edcd6f078 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f0a0 tag 0 boffset 0 b 0x7f3edcd6f0a0 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f0c8 tag 0 boffset 0 b
[jira] [Closed] (TS-2514) Convert all length parameters from Int to off_t (or size_t or ssize_t)
[ https://issues.apache.org/jira/browse/TS-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2514. --- Resolution: Won't Fix Fix Version/s: (was: 7.0.0) Convert all length parameters from Int to off_t (or size_t or ssize_t) -- Key: TS-2514 URL: https://issues.apache.org/jira/browse/TS-2514 Project: Traffic Server Issue Type: Sub-task Components: Cleanup, TS API Reporter: Igor Galić Since this is an API breaking change we should do this with 7.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-667) Ability to keep traffic server from initializing the wrong disks when using RAW disk mode.
[ https://issues.apache.org/jira/browse/TS-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582586#comment-14582586 ] ASF GitHub Bot commented on TS-667: --- GitHub user cjqian opened a pull request: https://github.com/apache/trafficserver/pull/221 Issues/ts 667 Changed a proxy file and documentation file to encourage alternative symlinked names (with id, path). Note that only the Linux example was changed in the storage.config documentation; not familiar with syntax in FreeBSD and Solaris. This resolves #TS-667. You can merge this pull request into a Git repository by running: $ git pull https://github.com/cjqian/trafficserver issues/TS-667 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/221.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 #221 commit 80e5e0409429f33a4ebeaa00016c3dc8cc7e4f8f Author: Crystal Qian crystal_q...@cable.comcast.net Date: 2015-06-11T17:12:00Z TS-436 Added documentation for hardware sector size support commit 0a91592dc610bb007e44ff49c2228638e433fed8 Author: Crystal Qian crystal_q...@cable.comcast.net Date: 2015-06-11T22:01:44Z Changed disk device paths to include id/path. Ability to keep traffic server from initializing the wrong disks when using RAW disk mode. -- Key: TS-667 URL: https://issues.apache.org/jira/browse/TS-667 Project: Traffic Server Issue Type: Improvement Components: Cache, Configuration Reporter: David Robinson Assignee: Crystal Qian Priority: Minor Labels: A, features Fix For: 6.0.0 When disk devices are configured in storage.config for RAW mode they are automatically initialized when traffic server first starts up. If disk device names change later due to adding/removing disks or kernel changes trafficserver will overwrite disks that the user may not want to be cache disks. This leads to data loss on the affected disks. Maybe a feature could be added similar to squid's -z where cache disks must be explicitly initialized before they can be used. Or a configuration variable that changes trafficserver's initialization behavior. (6:49:06 PM) zwoop: so, maybe have a few settings for the config (6:49:06 PM) zwoop: 0 - Let it reinitialize cache as it likes (6:49:06 PM) zwoop: 1 - Only initialize cache explicitly (6:49:06 PM) zwoop: 2 - Only initialize cache explicitly, and refuse to start up if we detect a cache disk with bad header -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-2591) Cache does not invalidate variant/alternate content types on PUT or POST
[ https://issues.apache.org/jira/browse/TS-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2591. --- Resolution: Duplicate Fix Version/s: (was: 6.0.0) Cache does not invalidate variant/alternate content types on PUT or POST - Key: TS-2591 URL: https://issues.apache.org/jira/browse/TS-2591 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: Norm Paxton Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present). These methods are: PUT, DELETE, POST. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 (This doesn't explicitly address variant content types, I read it as implied.) The current caching implementation only invalidates the Request URI, and not variant/alternate URI's. Example: A REST service provides both xml and json documents. A client app requests in both content-types (perhaps two different components, one expects xml, the other json). Assume both documents (xml and json) are in the cache. If the app PUTs a modification to the object in XML (ie, changes a User object's email address), it should then be able to retrieve the correct object data via a GET in json. In order to do so, the json object in the cache would need to be invalidated, so that the cache server forwards the request on to the REST service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2597) QoS (Quality of Service) Support ZPH (Zero Penalty HIT)
[ https://issues.apache.org/jira/browse/TS-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2597: Assignee: (was: Jack Bates) QoS (Quality of Service) Support ZPH (Zero Penalty HIT) --- Key: TS-2597 URL: https://issues.apache.org/jira/browse/TS-2597 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Faysal Banna Fix For: sometime Hello there. I know it would be easy for someone in development team to create a module (plugin) that enables to set QoS markers on outgoing traffic. as such : Allows admin to set a TOS/Diffserv value to mark local hits. thus allowing missed (non locally cached )objects to have certain TOS/Diffserv and HITs (locally cached) objects to have different TOS/Diffserv. Much Regards Faysal Banna -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2596) Documentation for TS-1090 plugin support for SO_MARK
[ https://issues.apache.org/jira/browse/TS-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2596: Assignee: Jon Sime Documentation for TS-1090 plugin support for SO_MARK Key: TS-2596 URL: https://issues.apache.org/jira/browse/TS-2596 Project: Traffic Server Issue Type: Wish Components: Documentation Reporter: Faysal Banna Assignee: Jon Sime Fix For: Docs Hi there . would there be a documentation for SO_MARK TS-1090 much regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
