[jira] [Commented] (TS-3341) Add plugin APIs about server transaction status
[
https://issues.apache.org/jira/browse/TS-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15429561#comment-15429561
]
William Bardwell commented on TS-3341:
--
I have some code, it seems to occasionally claim that things were aborted that
don't look like they were...when I get some slack I would still like to deal
with this.
> Add plugin APIs about server transaction status
> ---
>
> Key: TS-3341
> URL: https://issues.apache.org/jira/browse/TS-3341
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: William Bardwell
>Assignee: William Bardwell
> Fix For: sometime
>
>
> {code}
> // Indicates if the connection to the client was aborted,
> // will not be true if the client closed cleanly at the end
> // of the transaction.
> int
> TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
> {
> sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
> HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
> return (s->client_info.abort == HttpTransact::ABORTED);
> }
> {code}
> {code}
> // Indicates if the transaction with the origin server is complete.
> // Will be true if the connection to the origin never started or
> // failed, as well as if it finished successfully. If this is checked
> // to early or for a cache hit, it will return true.
> int
> TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
> {
> sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
> HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
> return ((TSServerState)s->current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
> (s->current.server ? (s->current.server->state ==
> HttpTransact::TRANSACTION_COMPLETE):false);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
[ https://issues.apache.org/jira/browse/TS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-1807: - Fix Version/s: (was: 7.0.0) 8.0.0 > shutdown on a write VIO to TSHttpConnect() doesn't propogate > > > Key: TS-1807 > URL: https://issues.apache.org/jira/browse/TS-1807 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: William Bardwell >Assignee: William Bardwell > Labels: review > Fix For: 8.0.0 > > Attachments: TS-1807.diff > > > In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and > getting responses. But when I try to do TSVIONBytesSet() and > TSVConnShutdown() on the write vio (due to the client side being done sending > requests) the write vio just sits there and never wakes up the other side, > and the response side doesn't try to close up until an inactivity timeout > happens. > I think that PluginVC::do_io_shutdown() needs to do > other_side->read_state.vio.reenable(); when a shutdown for write shows up. > Then the otherside wakes up and sees the EOF due to the shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4506) Last-Modified and Expires headers are removed on 304 responses when they shouldn't
[
https://issues.apache.org/jira/browse/TS-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352234#comment-15352234
]
William Bardwell commented on TS-4506:
--
Your patch matches the description in the initial bug ticket, but not in the
comment and commit comment, and the patch seems backwards...(the later comments
seem right...don't delete Last-Modified unless there is an ETag that serves the
same purpose.)
I would argue that deleting the Last-Modified seems weird unless you are sure
that the client did a If-None-Match...otherwise (theoretically, although seems
pretty unlikely) they might not have an ETag to compare with...
Also isn't it removing Expires because it is hard coding Cache-Control to
no-store?
> Last-Modified and Expires headers are removed on 304 responses when they
> shouldn't
> --
>
> Key: TS-4506
> URL: https://issues.apache.org/jira/browse/TS-4506
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> Right now, when ATS generates a 304 response (Not Modified), we always remove
> the Last-Modified header. Reading the RFC, we should only remove the
> Last-Modified header if there is no ETag header. This is a simple fix, and we
> should just do it IMO.
> It also always removes the Expires headers, which is outright wrong.
> From https://tools.ietf.org/html/rfc7232#page-18:
> {code}
>The server generating a 304 response MUST generate any of the
>following header fields that would have been sent in a 200 (OK)
>response to the same request: Cache-Control, Content-Location, Date,
>ETag, Expires, and Vary.
>Since the goal of a 304 response is to minimize information transfer
>when the recipient already has one or more cached representations, a
>sender SHOULD NOT generate representation metadata other than the
>above listed fields unless said metadata exists for the purpose of
>guiding cache updates (e.g., Last-Modified might be useful if the
>response does not have an ETag field).
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3872) Enhance open_write_fail_action feature to support returning error on revalidation.
[ https://issues.apache.org/jira/browse/TS-3872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14724593#comment-14724593 ] William Bardwell commented on TS-3872: -- Do any of those options go ahead and do a conditional revalidate (even if they can't save the answer), just passing through the answer if they don't get a 304? Because that seems like a much better behavior than the old 'tunnel' case (aka 0), but I wasn't clear if one of the other options does that... > Enhance open_write_fail_action feature to support returning error on > revalidation. > -- > > Key: TS-3872 > URL: https://issues.apache.org/jira/browse/TS-3872 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 6.1.0 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 6.1.0 > > > Refer TS-3549. > The setting *proxy.config.http.cache.open_write_fail_action* currently > supports the below options: > On a cache write lock failure (multiple concurrent requests for the same > object): > (a) Return a 502 error on cache miss > (b) Return a stale copy on revalidation > (c) Both (a) and (b) > This jira is to add a new option to allow ATS to return a 502 error on both > cache miss as well as revalidation scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3426) Consolidate the multiple API for disabling cache
[
https://issues.apache.org/jira/browse/TS-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680896#comment-14680896
]
William Bardwell commented on TS-3426:
--
Aren't the Transformed vs Untransformed thing allowing you to choose where the
Cache is attached to the tunnel, which is nothing that the new 3 values would
not allow, it sounds like it needs more values or a bit-mask or to keep some
variation of those APIs.
Consolidate the multiple API for disabling cache
Key: TS-3426
URL: https://issues.apache.org/jira/browse/TS-3426
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Sudheer Vinukonda
Assignee: Alan M. Carroll
Labels: A
Fix For: 6.1.0
There are currently multiple API (see below) that can be used by a plugin to
disable cache for a given transaction.
{{TSHttpTxnServerRespNoStoreSet}}, {{TSHttpTxnReqCacheableSet}},
{{TSHttpTxnRespCacheableSet}}
Opening this jira to analyze whether these are redundant and consolidate if
necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3828) HEAD requests hang when origin returns Transfer-Encoding: Chunked
[ https://issues.apache.org/jira/browse/TS-3828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660580#comment-14660580 ] William Bardwell commented on TS-3828: -- Just to be clear, be careful that you do not delete/zero out the Content-Length header in the client response to a HEAD request. That would break lots of things. HEAD requests hang when origin returns Transfer-Encoding: Chunked - Key: TS-3828 URL: https://issues.apache.org/jira/browse/TS-3828 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 6.0.0 When a client makes a HEAD request and the origin returns a header containing Transfer-Encoding: chunked ATS for some reason adds a ChunkedConsumer to dechunk the body (which will never arrive) in some cases ATS will not return the headers to the client resulting in a 502, or in other cases it will send the headers and then close the connection later thinking the origin timed out. In both cases the behavior is incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3341) Add plugin APIs about server transaction status
[
https://issues.apache.org/jira/browse/TS-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Bardwell updated TS-3341:
-
Fix Version/s: (was: 6.0.0)
Add plugin APIs about server transaction status
---
Key: TS-3341
URL: https://issues.apache.org/jira/browse/TS-3341
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: William Bardwell
Assignee: William Bardwell
{code}
// Indicates if the connection to the client was aborted,
// will not be true if the client closed cleanly at the end
// of the transaction.
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return (s-client_info.abort == HttpTransact::ABORTED);
}
{code}
{code}
// Indicates if the transaction with the origin server is complete.
// Will be true if the connection to the origin never started or
// failed, as well as if it finished successfully. If this is checked
// to early or for a cache hit, it will return true.
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return ((TSServerState)s-current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s-current.server ? (s-current.server-state ==
HttpTransact::TRANSACTION_COMPLETE):false);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3348) read while write config and range issues
[ https://issues.apache.org/jira/browse/TS-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-3348: - Fix Version/s: (was: 6.0.0) sometime read while write config and range issues Key: TS-3348 URL: https://issues.apache.org/jira/browse/TS-3348 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Labels: review Fix For: sometime Attachments: TS-3348.diff We had a number of problems with the read-while-write logic. #1) you can't set background fill config options to keep background fill from behaving badly because they are shared too much with read-while-write #2) logic around filling range requests out of partial cache entries is too restrictive #3) issues around read_while_write not working if there is a transform anywhere #4) some related config is not overridable So we think that our patch fixes all of these issues...mostly. (The background fill timeout doesn't get re-instated if a download switches to read-while-write and then back. The Range is in cache code doesn't seem write for small things or possibly for seeing the current fragment that is only partially downloaded.) But we would like some review of this to see if we are doing anything dangerous/not right/not helpful. Might also help TS-2761 and issue around range handling. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
[ https://issues.apache.org/jira/browse/TS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-1807: - Fix Version/s: (was: 5.3.0) 6.0.0 shutdown on a write VIO to TSHttpConnect() doesn't propogate Key: TS-1807 URL: https://issues.apache.org/jira/browse/TS-1807 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Labels: review Fix For: 6.0.0 Attachments: TS-1807.diff In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and getting responses. But when I try to do TSVIONBytesSet() and TSVConnShutdown() on the write vio (due to the client side being done sending requests) the write vio just sits there and never wakes up the other side, and the response side doesn't try to close up until an inactivity timeout happens. I think that PluginVC::do_io_shutdown() needs to do other_side-read_state.vio.reenable(); when a shutdown for write shows up. Then the otherside wakes up and sees the EOF due to the shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
[ https://issues.apache.org/jira/browse/TS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14365213#comment-14365213 ] William Bardwell commented on TS-1807: -- Yeah until I can button-hole someone to look at that change and see if it is reasonable or an early sign of madness I don't want to check it in. shutdown on a write VIO to TSHttpConnect() doesn't propogate Key: TS-1807 URL: https://issues.apache.org/jira/browse/TS-1807 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Labels: review Fix For: 6.0.0 Attachments: TS-1807.diff In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and getting responses. But when I try to do TSVIONBytesSet() and TSVConnShutdown() on the write vio (due to the client side being done sending requests) the write vio just sits there and never wakes up the other side, and the response side doesn't try to close up until an inactivity timeout happens. I think that PluginVC::do_io_shutdown() needs to do other_side-read_state.vio.reenable(); when a shutdown for write shows up. Then the otherside wakes up and sees the EOF due to the shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2633) 406 negative responses being cached for too long
[ https://issues.apache.org/jira/browse/TS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358643#comment-14358643 ] William Bardwell commented on TS-2633: -- My fix to TS-3331 might have helped this one too... 406 negative responses being cached for too long Key: TS-2633 URL: https://issues.apache.org/jira/browse/TS-2633 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 4.0.2 Reporter: David Carlin Assignee: Sudheer Vinukonda Labels: yahoo Fix For: 6.0.0 Settings: proxy.config.http.negative_caching_enabled = 1 proxy.config.http.negative_caching_lifetime = 500 406 response is being cached, but lifetime isn't being adhered to. They are cached for much longer, perhaps indefinitely. I have seen Age: increase to several hours. With proxy.config.http.negative_caching_enabled = 0 then 406 responses are not cached. Bryan pointed out that the docs don't list 406 as one of the cached negative responses: http://trafficserver.readthedocs.org/en/latest/reference/configuration/records.config.en.html The value of proxy.config.http.cache.ignore_accept_mismatch has no bearing on this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3331) negative responses cached even when headers indicate otherwise
[
https://issues.apache.org/jira/browse/TS-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358775#comment-14358775
]
William Bardwell commented on TS-3331:
--
So...
{noformat}
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -198,10 +198,7 @@ is_negative_caching_appropriate(HttpTransact::State* s)
case HTTP_STATUS_BAD_GATEWAY:
case HTTP_STATUS_SERVICE_UNAVAILABLE:
case HTTP_STATUS_GATEWAY_TIMEOUT:
-return ((response_cacheable_indicated_by_cc(s-hdr_info.server_response)
= 0)
-
(HttpTransactHeaders::does_server_allow_response_to_be_stored(s-hdr_info.server_response)
||
-s-cache_control.ignore_server_no_cache ||
-(s-cache_control.ttl_in_cache 0)));
+return true;
default:
break;
}
@@ -4263,7 +4260,7 @@
HttpTransact::handle_cache_operation_on_forward_server_response(State* s)
client_response_code = server_response_code;
base_response = s-hdr_info.server_response;
-s-negative_caching = is_negative_caching_appropriate(s);
+s-negative_caching = is_negative_caching_appropriate(s) cacheable;
// determine the correct cache action given the original cache action,
// cacheability of server response, and request method
{noformat}
Hum, let me see if that works...
negative responses cached even when headers indicate otherwise
--
Key: TS-3331
URL: https://issues.apache.org/jira/browse/TS-3331
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: William Bardwell
Assignee: William Bardwell
Labels: review
Fix For: 5.3.0
Negative type status codes get cached even when there are Cache-Control:
no-store or the like headers and positive caching would be paying attention
to that. So the fix is to apply response headers (and general caching
config) to negative caching choices too.
My patch might fix [TS-2633] 406 negative responses being cached for too long
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3331) negative responses cached even when headers indicate otherwise
[ https://issues.apache.org/jira/browse/TS-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359187#comment-14359187 ] William Bardwell commented on TS-3331: -- Re-did it as suggested in https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=e5f2bb554eb33e9b29cf728d2bcb04ba4f1b0e8a negative responses cached even when headers indicate otherwise -- Key: TS-3331 URL: https://issues.apache.org/jira/browse/TS-3331 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Labels: review Fix For: 5.3.0 Negative type status codes get cached even when there are Cache-Control: no-store or the like headers and positive caching would be paying attention to that. So the fix is to apply response headers (and general caching config) to negative caching choices too. My patch might fix [TS-2633] 406 negative responses being cached for too long -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3331) negative responses cached even when headers indicate otherwise
[ https://issues.apache.org/jira/browse/TS-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14356129#comment-14356129 ] William Bardwell commented on TS-3331: -- Commit bd62e7006547e9fc174a764b2c219f774643a31a in trafficserver's branch refs/heads/master [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bd62e70 ] negative responses cached even when headers indicate otherwise -- Key: TS-3331 URL: https://issues.apache.org/jira/browse/TS-3331 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Labels: review Fix For: 5.3.0 Negative type status codes get cached even when there are Cache-Control: no-store or the like headers and positive caching would be paying attention to that. So the fix is to apply response headers (and general caching config) to negative caching choices too. My patch might fix [TS-2633] 406 negative responses being cached for too long -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3342) Non-standard method in bad request can cause crash
[
https://issues.apache.org/jira/browse/TS-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14356166#comment-14356166
]
William Bardwell commented on TS-3342:
--
Commit 66bdd406f92e61bd0fdc86afe308a7563093896f in trafficserver's branch
refs/heads/master
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=66bdd40 ]
Non-standard method in bad request can cause crash
--
Key: TS-3342
URL: https://issues.apache.org/jira/browse/TS-3342
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: William Bardwell
Assignee: William Bardwell
Labels: review
Fix For: 5.3.0
Attachments: TS-3342.diff
Fix is to check for a normal sort of method (that would actually need a cache
lookup) in HttpTransact::HandleCacheOpenReadMiss() to do
{code}
s-cache_info.action = CACHE_DO_NO_ACTION;
{code}
instead of
{code}
s-cache_info.action = CACHE_PREPARE_TO_WRITE;
{code}
for anything weird. But I am concerned that this might cause problems if
someone wants to add support for a weird method...but maybe that never works
right with the cache anyway...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3341) Add plugin APIs about server transaction status
[
https://issues.apache.org/jira/browse/TS-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Bardwell updated TS-3341:
-
Description:
{code}
// Indicates if the connection to the client was aborted,
// will not be true if the client closed cleanly at the end
// of the transaction.
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return (s-client_info.abort == HttpTransact::ABORTED);
}
{code}
{code}
// Indicates if the transaction with the origin server is complete.
// Will be true if the connection to the origin never started or
// failed, as well as if it finished successfully. If this is checked
// to early or for a cache hit, it will return true.
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return ((TSServerState)s-current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s-current.server ? (s-current.server-state ==
HttpTransact::TRANSACTION_COMPLETE):false);
}
{code}
was:
{code}
// Indicates if the connection to the client was aborted,
// will not be true if the client closed cleanly at the end
// of the transaction.
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return (s-client_info.abort == HttpTransact::ABORTED);
}
{code}
{code}
// Indicates if the transaction with the origin server is
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return ((TSServerState)s-current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s-current.server ? (s-current.server-state ==
HttpTransact::TRANSACTION_COMPLETE):false);
}
{code}
Add plugin APIs about server transaction status
---
Key: TS-3341
URL: https://issues.apache.org/jira/browse/TS-3341
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: William Bardwell
Assignee: William Bardwell
Fix For: 5.3.0
{code}
// Indicates if the connection to the client was aborted,
// will not be true if the client closed cleanly at the end
// of the transaction.
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return (s-client_info.abort == HttpTransact::ABORTED);
}
{code}
{code}
// Indicates if the transaction with the origin server is complete.
// Will be true if the connection to the origin never started or
// failed, as well as if it finished successfully. If this is checked
// to early or for a cache hit, it will return true.
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return ((TSServerState)s-current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s-current.server ? (s-current.server-state ==
HttpTransact::TRANSACTION_COMPLETE):false);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3341) Add plugin APIs about server transaction status
[
https://issues.apache.org/jira/browse/TS-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Bardwell updated TS-3341:
-
Description:
{code}
// Indicates if the connection to the client was aborted,
// will not be true if the client closed cleanly at the end
// of the transaction.
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return (s-client_info.abort == HttpTransact::ABORTED);
}
{code}
{code}
// Indicates if the transaction with the origin server is
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return ((TSServerState)s-current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s-current.server ? (s-current.server-state ==
HttpTransact::TRANSACTION_COMPLETE):false);
}
{code}
was:
{code}
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return (s-client_info.abort == HttpTransact::ABORTED);
}
{code}
{code}
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return ((TSServerState)s-current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s-current.server ? (s-current.server-state ==
HttpTransact::TRANSACTION_COMPLETE):false);
}
{code}
Add plugin APIs about server transaction status
---
Key: TS-3341
URL: https://issues.apache.org/jira/browse/TS-3341
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: William Bardwell
Assignee: William Bardwell
Fix For: 5.3.0
{code}
// Indicates if the connection to the client was aborted,
// will not be true if the client closed cleanly at the end
// of the transaction.
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return (s-client_info.abort == HttpTransact::ABORTED);
}
{code}
{code}
// Indicates if the transaction with the origin server is
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return ((TSServerState)s-current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s-current.server ? (s-current.server-state ==
HttpTransact::TRANSACTION_COMPLETE):false);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
[ https://issues.apache.org/jira/browse/TS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-1807: - Attachment: TS-1807.diff Patch to make PluginVC support shutdown properly and make it work right through the tunnel and such...and generally fix a few issues we had with closes not propagating quite right. I would appreciate review and comments on what makes sense here and what doesn't... shutdown on a write VIO to TSHttpConnect() doesn't propogate Key: TS-1807 URL: https://issues.apache.org/jira/browse/TS-1807 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Fix For: sometime Attachments: TS-1807.diff In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and getting responses. But when I try to do TSVIONBytesSet() and TSVConnShutdown() on the write vio (due to the client side being done sending requests) the write vio just sits there and never wakes up the other side, and the response side doesn't try to close up until an inactivity timeout happens. I think that PluginVC::do_io_shutdown() needs to do other_side-read_state.vio.reenable(); when a shutdown for write shows up. Then the otherside wakes up and sees the EOF due to the shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
[ https://issues.apache.org/jira/browse/TS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-1807: - Fix Version/s: (was: sometime) 5.3.0 shutdown on a write VIO to TSHttpConnect() doesn't propogate Key: TS-1807 URL: https://issues.apache.org/jira/browse/TS-1807 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Fix For: 5.3.0 Attachments: TS-1807.diff In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and getting responses. But when I try to do TSVIONBytesSet() and TSVConnShutdown() on the write vio (due to the client side being done sending requests) the write vio just sits there and never wakes up the other side, and the response side doesn't try to close up until an inactivity timeout happens. I think that PluginVC::do_io_shutdown() needs to do other_side-read_state.vio.reenable(); when a shutdown for write shows up. Then the otherside wakes up and sees the EOF due to the shutdown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-1435) return full content if client is a multi range request
[ https://issues.apache.org/jira/browse/TS-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell reassigned TS-1435: Assignee: William Bardwell (was: Alan M. Carroll) return full content if client is a multi range request -- Key: TS-1435 URL: https://issues.apache.org/jira/browse/TS-1435 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: weijin Assignee: William Bardwell Fix For: 5.3.0 Attachments: TS-1435.diff if client request is a muti range, and served from the cache, it returns the full content. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1435) return full content if client is a multi range request
[ https://issues.apache.org/jira/browse/TS-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell closed TS-1435. Resolution: Fixed return full content if client is a multi range request -- Key: TS-1435 URL: https://issues.apache.org/jira/browse/TS-1435 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: weijin Assignee: William Bardwell Fix For: 5.3.0 Attachments: TS-1435.diff if client request is a muti range, and served from the cache, it returns the full content. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1435) return full content if client is a multi range request
[ https://issues.apache.org/jira/browse/TS-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-1435: - Summary: return full content if client is a multi range request (was: return full content if client is a muti range request) return full content if client is a multi range request -- Key: TS-1435 URL: https://issues.apache.org/jira/browse/TS-1435 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: weijin Assignee: Alan M. Carroll Fix For: 5.3.0 Attachments: TS-1435.diff if client request is a muti range, and served from the cache, it returns the full content. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3343) outbound transparent can end up with Connection: keep-alive headers on failures
[ https://issues.apache.org/jira/browse/TS-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell closed TS-3343. Resolution: Fixed outbound transparent can end up with Connection: keep-alive headers on failures --- Key: TS-3343 URL: https://issues.apache.org/jira/browse/TS-3343 Project: Traffic Server Issue Type: Bug Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 502/504 responses generated by ATS can still end up with Connection: keep-alive headers even when outbound_transparent is on, and connection is doomed. Also for us not allowing setting that flag from the plugin with TSHttpTxnOutgoingTransparencySet() when not compiled with full TPROXY support is too mean, since that flag does change behavior in a few places in useful ways even when not doing tproxy stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3339) Multithread access to PluginVC can cause crash due to unprotected check of shutdown/close
[ https://issues.apache.org/jira/browse/TS-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell closed TS-3339. Resolution: Fixed Multithread access to PluginVC can cause crash due to unprotected check of shutdown/close - Key: TS-3339 URL: https://issues.apache.org/jira/browse/TS-3339 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 SEGV with: 1 0x006ffe7d in MIOBuffer::write () 2 0x004dc07e in PluginVC::transfer_bytes () 3 0x004df4dc in PluginVC::process_read_side () 4 0x004dffb5 in PluginVC::process_write_side () 5 0x004e0c00 in PluginVC::main_handler () 6 0x00701de8 in EThread::process_event () 7 0x00702847 in EThread::execute () Where IOBufferBlock had a _start and _end pointer which were both set to NULL. The IOBufferData it referred to was also NULL, and looking at the PluginVC it was actually shutdown by the time of the crash -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3342) Non-standard method in bad request can cause crash
[
https://issues.apache.org/jira/browse/TS-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Bardwell updated TS-3342:
-
Attachment: TS-3342.diff
Patch, but lists the 'methods that effect the cache' is that list totally known?
Non-standard method in bad request can cause crash
--
Key: TS-3342
URL: https://issues.apache.org/jira/browse/TS-3342
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: William Bardwell
Attachments: TS-3342.diff
Fix is to check for a normal sort of method (that would actually need a cache
lookup) in HttpTransact::HandleCacheOpenReadMiss() to do
{code}
s-cache_info.action = CACHE_DO_NO_ACTION;
{code}
instead of
{code}
s-cache_info.action = CACHE_PREPARE_TO_WRITE;
{code}
for anything weird. But I am concerned that this might cause problems if
someone wants to add support for a weird method...but maybe that never works
right with the cache anyway...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-3343) outbound transparent can end up with Connection: keep-alive headers on failures
[ https://issues.apache.org/jira/browse/TS-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell closed TS-3343. Resolution: Fixed outbound transparent can end up with Connection: keep-alive headers on failures --- Key: TS-3343 URL: https://issues.apache.org/jira/browse/TS-3343 Project: Traffic Server Issue Type: Bug Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 502/504 responses generated by ATS can still end up with Connection: keep-alive headers even when outbound_transparent is on, and connection is doomed. Also for us not allowing setting that flag from the plugin with TSHttpTxnOutgoingTransparencySet() when not compiled with full TPROXY support is too mean, since that flag does change behavior in a few places in useful ways even when not doing tproxy stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3348) read while write config and range issues
[ https://issues.apache.org/jira/browse/TS-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell reassigned TS-3348: Assignee: William Bardwell read while write config and range issues Key: TS-3348 URL: https://issues.apache.org/jira/browse/TS-3348 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Attachments: TS-3348.diff We had a number of problems with the read-while-write logic. #1) you can't set background fill config options to keep background fill from behaving badly because they are shared too much with read-while-write #2) logic around filling range requests out of partial cache entries is too restrictive #3) issues around read_while_write not working if there is a transform anywhere #4) some related config is not overridable So we think that our patch fixes all of these issues...mostly. (The background fill timeout doesn't get re-instated if a download switches to read-while-write and then back. The Range is in cache code doesn't seem write for small things or possibly for seeing the current fragment that is only partially downloaded.) But we would like some review of this to see if we are doing anything dangerous/not right/not helpful. Might also help TS-2761 and issue around range handling. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3348) read while write config and range issues
[ https://issues.apache.org/jira/browse/TS-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-3348: - Attachment: TS-3348.diff read while write config and range issues Key: TS-3348 URL: https://issues.apache.org/jira/browse/TS-3348 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Attachments: TS-3348.diff We had a number of problems with the read-while-write logic. #1) you can't set background fill config options to keep background fill from behaving badly because they are shared too much with read-while-write #2) logic around filling range requests out of partial cache entries is too restrictive #3) issues around read_while_write not working if there is a transform anywhere #4) some related config is not overridable So we think that our patch fixes all of these issues...mostly. (The background fill timeout doesn't get re-instated if a download switches to read-while-write and then back. The Range is in cache code doesn't seem write for small things or possibly for seeing the current fragment that is only partially downloaded.) But we would like some review of this to see if we are doing anything dangerous/not right/not helpful. Might also help TS-2761 and issue around range handling. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3348) read while write config and range issues
William Bardwell created TS-3348: Summary: read while write config and range issues Key: TS-3348 URL: https://issues.apache.org/jira/browse/TS-3348 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Attachments: TS-3348.diff We had a number of problems with the read-while-write logic. #1) you can't set background fill config options to keep background fill from behaving badly because they are shared too much with read-while-write #2) logic around filling range requests out of partial cache entries is too restrictive #3) issues around read_while_write not working if there is a transform anywhere #4) some related config is not overridable So we think that our patch fixes all of these issues...mostly. (The background fill timeout doesn't get re-instated if a download switches to read-while-write and then back. The Range is in cache code doesn't seem write for small things or possibly for seeing the current fragment that is only partially downloaded.) But we would like some review of this to see if we are doing anything dangerous/not right/not helpful. Might also help TS-2761 and issue around range handling. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3343) outbound transparent can end up with Connection: keep-alive headers on failures
[ https://issues.apache.org/jira/browse/TS-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-3343: - Fix Version/s: 5.3.0 outbound transparent can end up with Connection: keep-alive headers on failures --- Key: TS-3343 URL: https://issues.apache.org/jira/browse/TS-3343 Project: Traffic Server Issue Type: Bug Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 502/504 responses generated by ATS can still end up with Connection: keep-alive headers even when outbound_transparent is on, and connection is doomed. Also for us not allowing setting that flag from the plugin with TSHttpTxnOutgoingTransparencySet() when not compiled with full TPROXY support is too mean, since that flag does change behavior in a few places in useful ways even when not doing tproxy stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3343) outbound transparent can end up with Connection: keep-alive headers on failures
[ https://issues.apache.org/jira/browse/TS-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell reassigned TS-3343: Assignee: William Bardwell outbound transparent can end up with Connection: keep-alive headers on failures --- Key: TS-3343 URL: https://issues.apache.org/jira/browse/TS-3343 Project: Traffic Server Issue Type: Bug Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 502/504 responses generated by ATS can still end up with Connection: keep-alive headers even when outbound_transparent is on, and connection is doomed. Also for us not allowing setting that flag from the plugin with TSHttpTxnOutgoingTransparencySet() when not compiled with full TPROXY support is too mean, since that flag does change behavior in a few places in useful ways even when not doing tproxy stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3343) outbound transparent can end up with Connection: keep-alive headers on failures
William Bardwell created TS-3343: Summary: outbound transparent can end up with Connection: keep-alive headers on failures Key: TS-3343 URL: https://issues.apache.org/jira/browse/TS-3343 Project: Traffic Server Issue Type: Bug Reporter: William Bardwell 502/504 responses generated by ATS can still end up with Connection: keep-alive headers even when outbound_transparent is on, and connection is doomed. Also for us not allowing setting that flag from the plugin with TSHttpTxnOutgoingTransparencySet() when not compiled with full TPROXY support is too mean, since that flag does change behavior in a few places in useful ways even when not doing tproxy stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3344) 401 responses invalidate cache entry even if TSHttpTxnServerRespIgnore() used
William Bardwell created TS-3344: Summary: 401 responses invalidate cache entry even if TSHttpTxnServerRespIgnore() used Key: TS-3344 URL: https://issues.apache.org/jira/browse/TS-3344 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell It should be ignored... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3342) Non-standard method in bad request can cause crash
William Bardwell created TS-3342:
Summary: Non-standard method in bad request can cause crash
Key: TS-3342
URL: https://issues.apache.org/jira/browse/TS-3342
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: William Bardwell
Fix is to check for a normal sort of method (that would actually need a cache
lookup) in HttpTransact::HandleCacheOpenReadMiss() to do
{code}
s-cache_info.action = CACHE_DO_NO_ACTION;
{code}
instead of
{code}
s-cache_info.action = CACHE_PREPARE_TO_WRITE;
{code}
for anything weird. But I am concerned that this might cause problems if
someone wants to add support for a weird method...but maybe that never works
right with the cache anyway...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-2884) TSActionCancel() on TSNetAccept() causes spinning thread
[ https://issues.apache.org/jira/browse/TS-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell closed TS-2884. Resolution: Fixed TSActionCancel() on TSNetAccept() causes spinning thread Key: TS-2884 URL: https://issues.apache.org/jira/browse/TS-2884 Project: Traffic Server Issue Type: Bug Components: Network Reporter: William Bardwell Assignee: William Bardwell Priority: Minor Fix For: 5.3.0 It looks like the NetAccept::acceptLoopEvent() just loops calling do_blocking_accept() and doesn't check for an error return value... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3343) outbound transparent can end up with Connection: keep-alive headers on failures
[ https://issues.apache.org/jira/browse/TS-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295883#comment-14295883 ] William Bardwell commented on TS-3343: -- TS-3106 is related... outbound transparent can end up with Connection: keep-alive headers on failures --- Key: TS-3343 URL: https://issues.apache.org/jira/browse/TS-3343 Project: Traffic Server Issue Type: Bug Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 502/504 responses generated by ATS can still end up with Connection: keep-alive headers even when outbound_transparent is on, and connection is doomed. Also for us not allowing setting that flag from the plugin with TSHttpTxnOutgoingTransparencySet() when not compiled with full TPROXY support is too mean, since that flag does change behavior in a few places in useful ways even when not doing tproxy stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3344) 401 responses invalidate cache entry even if TSHttpTxnServerRespIgnore() used
[ https://issues.apache.org/jira/browse/TS-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-3344: - Fix Version/s: 5.3.0 401 responses invalidate cache entry even if TSHttpTxnServerRespIgnore() used - Key: TS-3344 URL: https://issues.apache.org/jira/browse/TS-3344 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 It should be ignored... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3344) 401 responses invalidate cache entry even if TSHttpTxnServerRespIgnore() used
[ https://issues.apache.org/jira/browse/TS-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell reassigned TS-3344: Assignee: William Bardwell 401 responses invalidate cache entry even if TSHttpTxnServerRespIgnore() used - Key: TS-3344 URL: https://issues.apache.org/jira/browse/TS-3344 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell It should be ignored... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3341) Add plugin APIs about server transaction status
William Bardwell created TS-3341:
Summary: Add plugin APIs about server transaction status
Key: TS-3341
URL: https://issues.apache.org/jira/browse/TS-3341
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: William Bardwell
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return (s-client_info.abort == HttpTransact::ABORTED);
}
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = (((HttpSM *) txnp)-t_state);
return ((TSServerState)s-current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s-current.server ? (s-current.server-state == HttpTransact::TRANSACTION
_COMPLETE):false);
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2884) TSActionCancel() on TSNetAccept() causes spinning thread
[ https://issues.apache.org/jira/browse/TS-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-2884: - Fix Version/s: (was: sometime) 5.3.0 TSActionCancel() on TSNetAccept() causes spinning thread Key: TS-2884 URL: https://issues.apache.org/jira/browse/TS-2884 Project: Traffic Server Issue Type: Bug Components: Network Reporter: William Bardwell Assignee: William Bardwell Priority: Minor Fix For: 5.3.0 It looks like the NetAccept::acceptLoopEvent() just loops calling do_blocking_accept() and doesn't check for an error return value... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-2884) TSActionCancel() on TSNetAccept() causes spinning thread
[ https://issues.apache.org/jira/browse/TS-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell reassigned TS-2884: Assignee: William Bardwell TSActionCancel() on TSNetAccept() causes spinning thread Key: TS-2884 URL: https://issues.apache.org/jira/browse/TS-2884 Project: Traffic Server Issue Type: Bug Components: Network Reporter: William Bardwell Assignee: William Bardwell Priority: Minor Fix For: 5.3.0 It looks like the NetAccept::acceptLoopEvent() just loops calling do_blocking_accept() and doesn't check for an error return value... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1435) return full content if client is a muti range request
[ https://issues.apache.org/jira/browse/TS-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14296355#comment-14296355 ] William Bardwell commented on TS-1435: -- The patch looks good, but you need to initialize num_chars_for_ct because it won't be cleared if there is no Content-Type header. return full content if client is a muti range request - Key: TS-1435 URL: https://issues.apache.org/jira/browse/TS-1435 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: weijin Assignee: Alan M. Carroll Fix For: 5.3.0 Attachments: TS-1435.diff if client request is a muti range, and served from the cache, it returns the full content. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3325) TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash
[ https://issues.apache.org/jira/browse/TS-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell closed TS-3325. Resolution: Fixed TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash -- Key: TS-3325 URL: https://issues.apache.org/jira/browse/TS-3325 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 It is possible to get a crash with a null url in the cache if you turn caching off in the middle of a transaction, but a trivial change fixes this... (This showed up because TSHttpTxnCacheLookupSkip() worked in those cases, but this replacement for it didn't.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3339) Multithread access to PluginVC can cause crash due to unprotected check of shutdown/close
William Bardwell created TS-3339: Summary: Multithread access to PluginVC can cause crash due to unprotected check of shutdown/close Key: TS-3339 URL: https://issues.apache.org/jira/browse/TS-3339 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell SEGV with: 1 0x006ffe7d in MIOBuffer::write () 2 0x004dc07e in PluginVC::transfer_bytes () 3 0x004df4dc in PluginVC::process_read_side () 4 0x004dffb5 in PluginVC::process_write_side () 5 0x004e0c00 in PluginVC::main_handler () 6 0x00701de8 in EThread::process_event () 7 0x00702847 in EThread::execute () Where IOBufferBlock had a _start and _end pointer which were both set to NULL. The IOBufferData it referred to was also NULL, and looking at the PluginVC it was actually shutdown by the time of the crash -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3339) Multithread access to PluginVC can cause crash due to unprotected check of shutdown/close
[ https://issues.apache.org/jira/browse/TS-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-3339: - Fix Version/s: 5.3.0 Multithread access to PluginVC can cause crash due to unprotected check of shutdown/close - Key: TS-3339 URL: https://issues.apache.org/jira/browse/TS-3339 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 SEGV with: 1 0x006ffe7d in MIOBuffer::write () 2 0x004dc07e in PluginVC::transfer_bytes () 3 0x004df4dc in PluginVC::process_read_side () 4 0x004dffb5 in PluginVC::process_write_side () 5 0x004e0c00 in PluginVC::main_handler () 6 0x00701de8 in EThread::process_event () 7 0x00702847 in EThread::execute () Where IOBufferBlock had a _start and _end pointer which were both set to NULL. The IOBufferData it referred to was also NULL, and looking at the PluginVC it was actually shutdown by the time of the crash -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3339) Multithread access to PluginVC can cause crash due to unprotected check of shutdown/close
[ https://issues.apache.org/jira/browse/TS-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell reassigned TS-3339: Assignee: William Bardwell Multithread access to PluginVC can cause crash due to unprotected check of shutdown/close - Key: TS-3339 URL: https://issues.apache.org/jira/browse/TS-3339 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 SEGV with: 1 0x006ffe7d in MIOBuffer::write () 2 0x004dc07e in PluginVC::transfer_bytes () 3 0x004df4dc in PluginVC::process_read_side () 4 0x004dffb5 in PluginVC::process_write_side () 5 0x004e0c00 in PluginVC::main_handler () 6 0x00701de8 in EThread::process_event () 7 0x00702847 in EThread::execute () Where IOBufferBlock had a _start and _end pointer which were both set to NULL. The IOBufferData it referred to was also NULL, and looking at the PluginVC it was actually shutdown by the time of the crash -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3331) negative responses cached even when headers indicate otherwise
William Bardwell created TS-3331: Summary: negative responses cached even when headers indicate otherwise Key: TS-3331 URL: https://issues.apache.org/jira/browse/TS-3331 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Negative type status codes get cached even when there are Cache-Control: no-store or the like headers and positive caching would be paying attention to that. So the fix is to apply response headers (and general caching config) to negative caching choices too. My patch might fix [TS-2633] 406 negative responses being cached for too long -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3331) negative responses cached even when headers indicate otherwise
[ https://issues.apache.org/jira/browse/TS-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-3331: - Fix Version/s: 5.3.0 negative responses cached even when headers indicate otherwise -- Key: TS-3331 URL: https://issues.apache.org/jira/browse/TS-3331 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 Negative type status codes get cached even when there are Cache-Control: no-store or the like headers and positive caching would be paying attention to that. So the fix is to apply response headers (and general caching config) to negative caching choices too. My patch might fix [TS-2633] 406 negative responses being cached for too long -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-3323) Cache scan will stop early if any empty volumes
[ https://issues.apache.org/jira/browse/TS-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell closed TS-3323. Resolution: Fixed Cache scan will stop early if any empty volumes --- Key: TS-3323 URL: https://issues.apache.org/jira/browse/TS-3323 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 Cache scans will stop early if there are any volumes with nothing in them (no directory entries.) It needs to just skip to the next volume. (Also the optimizations to the scanning are not strict enough about what is a valid directory entry.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3323) Cache scan will stop early if any empty volumes
William Bardwell created TS-3323: Summary: Cache scan will stop early if any empty volumes Key: TS-3323 URL: https://issues.apache.org/jira/browse/TS-3323 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: William Bardwell Cache scans will stop early if there are any volumes with nothing in them (no directory entries.) It needs to just skip to the next volume. (Also the optimizations to the scanning are not strict enough about what is a valid directory entry.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3324) If a chunked fetch from origin dies due to inactivity timeout, truncated cache entry can be created
William Bardwell created TS-3324: Summary: If a chunked fetch from origin dies due to inactivity timeout, truncated cache entry can be created Key: TS-3324 URL: https://issues.apache.org/jira/browse/TS-3324 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Several places that look for 'download complete' related events need to treat VC_EVENT_INACTIVITY_TIMEOUT as similar to EOS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Bardwell closed TS-1547.
Resolution: Fixed
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: William Bardwell
Labels: A, crash
Fix For: 5.3.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3324) If a chunked fetch from origin dies due to inactivity timeout, truncated cache entry can be created
[ https://issues.apache.org/jira/browse/TS-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-3324: - Fix Version/s: 5.3.0 If a chunked fetch from origin dies due to inactivity timeout, truncated cache entry can be created --- Key: TS-3324 URL: https://issues.apache.org/jira/browse/TS-3324 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 Several places that look for 'download complete' related events need to treat VC_EVENT_INACTIVITY_TIMEOUT as similar to EOS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3325) TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash
[ https://issues.apache.org/jira/browse/TS-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell reassigned TS-3325: Assignee: William Bardwell TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash -- Key: TS-3325 URL: https://issues.apache.org/jira/browse/TS-3325 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 It is possible to get a crash with a null url in the cache if you turn caching off in the middle of a transaction, but a trivial change fixes this... (This showed up because TSHttpTxnCacheLookupSkip() worked in those cases, but this replacement for it didn't.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3325) TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash
William Bardwell created TS-3325: Summary: TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash Key: TS-3325 URL: https://issues.apache.org/jira/browse/TS-3325 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell It is possible to get a crash with a null url in the cache if you turn caching off in the middle of a transaction, but a trivial change fixes this... (This showed up because TSHttpTxnCacheLookupSkip() worked in those cases, but this replacement for it didn't.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3325) TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash
[ https://issues.apache.org/jira/browse/TS-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292321#comment-14292321 ] William Bardwell commented on TS-3325: -- TS-2195 got rid of TSHttpTxnCacheLookupSkip().. TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash -- Key: TS-3325 URL: https://issues.apache.org/jira/browse/TS-3325 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 It is possible to get a crash with a null url in the cache if you turn caching off in the middle of a transaction, but a trivial change fixes this... (This showed up because TSHttpTxnCacheLookupSkip() worked in those cases, but this replacement for it didn't.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3325) TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash
[ https://issues.apache.org/jira/browse/TS-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-3325: - Fix Version/s: 5.3.0 TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0) can crash -- Key: TS-3325 URL: https://issues.apache.org/jira/browse/TS-3325 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.3.0 It is possible to get a crash with a null url in the cache if you turn caching off in the middle of a transaction, but a trivial change fixes this... (This showed up because TSHttpTxnCacheLookupSkip() worked in those cases, but this replacement for it didn't.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2314) New config to allow unsatifiable Range: request to go straight to Origin
[ https://issues.apache.org/jira/browse/TS-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14153401#comment-14153401 ] William Bardwell commented on TS-2314: -- In mode 2, shouldn't it stay attached to the existing download if the beginning of the range is in cache, and just wait for the download to finish? (Rather than insisting that the end is in cache.) New config to allow unsatifiable Range: request to go straight to Origin Key: TS-2314 URL: https://issues.apache.org/jira/browse/TS-2314 Project: Traffic Server Issue Type: Bug Components: Core Reporter: jaekyung oh Assignee: Sudheer Vinukonda Labels: range Attachments: TS-2314.diff Basically read_while_writer works fine when ATS handles normal file. In progressive download and playback of mp4 in which moov atom is placed at the end of the file, ATS makes and returns wrong response for range request from unfulfilled cache when read_while_writer is 1. In origin, apache has h264 streaming module. Everything is ok whether the moov atom is placed at the beginning of the file or not in origin except a range request happens with read_while_writer. Mostly our customer’s contents placed moov atom at the end of the file and in the case movie player stops playing when it seek somewhere in the movie. to check if read_while_writer works fine, 1. prepare a mp4 file whose moov atom is placed at the end of the file. 2. curl --range - http://www.test.com/mp4/test.mp4 1 no_cache_from_origin 3. wget http://www.test.com/mp4/test.mp4 4. right after wget, execute “curl --range - http://www.test.com/mp4/test.mp4 1 from_read_while_writer” on other terminal (the point is sending range request while ATS is still downloading) 5. after wget gets done, curl --range - http://www.test.com/mp4/test.mp4 1 from_cache 6. you can check compare those files by bindiff. The response from origin(no_cache_from_origin) for the range request is exactly same to from_cache resulted from #5's range request. but from_read_while_writer from #4 is totally different from others. i think a range request should be forwarded to origin server if it can’t find the content with the offset in cache even if the read_while_writer is on, instead ATS makes(from where?) and sends wrong response. (In squid.log it indicates TCP_HIT) That’s why a movie player stops when it seeks right after the movie starts. Well. we turned off read_while_writer and movie play is ok but the problems is read_while_writer is global options. we can’t set it differently for each remap entry by conf_remap. So the downloading of Big file(not mp4 file) gives overhead to origin server because read_while_writer is off. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2314) New config to allow unsatifiable Range: request to go straight to Origin
[ https://issues.apache.org/jira/browse/TS-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14153417#comment-14153417 ] William Bardwell commented on TS-2314: -- Mode 1 waits even if the start of the range is not present...which certainly is unfortunate behaviour much of the time...but if the start of the last range is in cache, then there is no performance benefit (assuming nothing weird) to tunneling the range request, just waiting would get it just as fast, if not faster. (arguably, to optimize further you would want one or more thresholds, since if you are one byte away from the start of the range it is almost the same as if you are one byte past the start...so you would want to say if the first byte of the highest range is read_while_write_range_close_limit away, just wait...) The degenerate case with mode 2 is that a range request for 0- will never use an in progress download, when clearly it should... New config to allow unsatifiable Range: request to go straight to Origin Key: TS-2314 URL: https://issues.apache.org/jira/browse/TS-2314 Project: Traffic Server Issue Type: Bug Components: Core Reporter: jaekyung oh Assignee: Sudheer Vinukonda Labels: range Attachments: TS-2314.diff Basically read_while_writer works fine when ATS handles normal file. In progressive download and playback of mp4 in which moov atom is placed at the end of the file, ATS makes and returns wrong response for range request from unfulfilled cache when read_while_writer is 1. In origin, apache has h264 streaming module. Everything is ok whether the moov atom is placed at the beginning of the file or not in origin except a range request happens with read_while_writer. Mostly our customer’s contents placed moov atom at the end of the file and in the case movie player stops playing when it seek somewhere in the movie. to check if read_while_writer works fine, 1. prepare a mp4 file whose moov atom is placed at the end of the file. 2. curl --range - http://www.test.com/mp4/test.mp4 1 no_cache_from_origin 3. wget http://www.test.com/mp4/test.mp4 4. right after wget, execute “curl --range - http://www.test.com/mp4/test.mp4 1 from_read_while_writer” on other terminal (the point is sending range request while ATS is still downloading) 5. after wget gets done, curl --range - http://www.test.com/mp4/test.mp4 1 from_cache 6. you can check compare those files by bindiff. The response from origin(no_cache_from_origin) for the range request is exactly same to from_cache resulted from #5's range request. but from_read_while_writer from #4 is totally different from others. i think a range request should be forwarded to origin server if it can’t find the content with the offset in cache even if the read_while_writer is on, instead ATS makes(from where?) and sends wrong response. (In squid.log it indicates TCP_HIT) That’s why a movie player stops when it seeks right after the movie starts. Well. we turned off read_while_writer and movie play is ok but the problems is read_while_writer is global options. we can’t set it differently for each remap entry by conf_remap. So the downloading of Big file(not mp4 file) gives overhead to origin server because read_while_writer is off. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1435) return full content if client is a muti range request
[ https://issues.apache.org/jira/browse/TS-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14151769#comment-14151769 ] William Bardwell commented on TS-1435: -- We are seeing this bug too, although it does not seem to send the whole response, rather it seems to send a reasonable looking body, but the full response Content-Length, which confuses the clients. return full content if client is a muti range request - Key: TS-1435 URL: https://issues.apache.org/jira/browse/TS-1435 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: weijin Assignee: Alan M. Carroll Fix For: 5.2.0 if client request is a muti range, and served from the cache, it returns the full content. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1435) return full content if client is a muti range request
[ https://issues.apache.org/jira/browse/TS-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14152227#comment-14152227 ] William Bardwell commented on TS-1435: -- It looks like HttpSM::calculate_output_cl() just needs to stop adding in the content_length when doing multiple ranges. return full content if client is a muti range request - Key: TS-1435 URL: https://issues.apache.org/jira/browse/TS-1435 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.3.0 Reporter: weijin Assignee: Alan M. Carroll Fix For: 5.2.0 if client request is a muti range, and served from the cache, it returns the full content. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3086) Range requests for stale cache entries never use If-Modified-Since/If-None-Match
William Bardwell created TS-3086: Summary: Range requests for stale cache entries never use If-Modified-Since/If-None-Match Key: TS-3086 URL: https://issues.apache.org/jira/browse/TS-3086 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Range requests against a stale cache entry always cause the Range request to be tunneled with no conditional. It would be nice if it used conditionals even if it couldn't update the cache entry just to cut down the traffic. (Not sure if updating the cache entry would be right, does If-Modified-Since refer only to the Range requested or to the whole object?) We could also have an option to use If-Range in these cases, but that might not make sense as a global decision... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2912) HEAD transaction on stale entry deletes cache entry
[ https://issues.apache.org/jira/browse/TS-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14110825#comment-14110825 ] William Bardwell commented on TS-2912: -- As I said are you sure that this really fixes things? And are you sure that you want conditional headers on a HEAD request, which the patch seems to do? HEAD transaction on stale entry deletes cache entry --- Key: TS-2912 URL: https://issues.apache.org/jira/browse/TS-2912 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Assignee: weijin Labels: review Fix For: 5.1.0 Attachments: ts-2912.try1.diff On a stale cache entry a HEAD gets tunneled to the origin, but when a 200 comes back HttpTransact::handle_cache_operation_on_forward_server_response(State* s) deletes the cache entry, it seems like it should just ignore it (or check ETag/Last-Modified and maybe delete if those don't match, but not unconditionally.) I am seeing this with 4.2.X with a plugin fiddling with stuff, but the code looks the same in trunk, line 4318 looks like the problem line. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2912) HEAD transaction on stale entry deletes cache entry
[ https://issues.apache.org/jira/browse/TS-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14083252#comment-14083252 ] William Bardwell commented on TS-2912: -- Why did you want it to add If-Modified-Since or If-None-Match if the request is a HEAD request? The chnge to request_conditional seems reasonable, but not sure that it will fix it, it seems like handle_cache_operation_on_forward_server_response() needs to not delete things... HEAD transaction on stale entry deletes cache entry --- Key: TS-2912 URL: https://issues.apache.org/jira/browse/TS-2912 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Assignee: weijin Labels: review Fix For: 5.1.0 Attachments: ts-2912.try1.diff On a stale cache entry a HEAD gets tunneled to the origin, but when a 200 comes back HttpTransact::handle_cache_operation_on_forward_server_response(State* s) deletes the cache entry, it seems like it should just ignore it (or check ETag/Last-Modified and maybe delete if those don't match, but not unconditionally.) I am seeing this with 4.2.X with a plugin fiddling with stuff, but the code looks the same in trunk, line 4318 looks like the problem line. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2912) HEAD transaction on stale entry deletes cache entry
William Bardwell created TS-2912: Summary: HEAD transaction on stale entry deletes cache entry Key: TS-2912 URL: https://issues.apache.org/jira/browse/TS-2912 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell On a stale cache entry a HEAD gets tunneled to the origin, but when a 200 comes back HttpTransact::handle_cache_operation_on_forward_server_response(State* s) deletes the cache entry, it seems like it should just ignore it (or check ETag/Last-Modified and maybe delete if those don't match, but not unconditionally.) I am seeing this with 4.2.X with a plugin fiddling with stuff, but the code looks the same in trunk, line 4318 looks like the problem line. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2884) TSActionCancel() on TSNetAccept() causes spinning thread
[ https://issues.apache.org/jira/browse/TS-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-2884: - Priority: Minor (was: Major) TSActionCancel() on TSNetAccept() causes spinning thread Key: TS-2884 URL: https://issues.apache.org/jira/browse/TS-2884 Project: Traffic Server Issue Type: Bug Components: Network Reporter: William Bardwell Priority: Minor It looks like the NetAccept::acceptLoopEvent() just loops calling do_blocking_accept() and doesn't check for an error return value... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2618) IOBufferBlock::realloc()'s bounds check is wrong
[
https://issues.apache.org/jira/browse/TS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14010540#comment-14010540
]
William Bardwell commented on TS-2618:
--
Must have gotten moved/renamed since that was a very confusing name:
./ink_defs.h:#define SIZE(x) (sizeof(x)/sizeof((x)[0]))
IOBufferBlock::realloc()'s bounds check is wrong
Key: TS-2618
URL: https://issues.apache.org/jira/browse/TS-2618
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: William Bardwell
Assignee: William Bardwell
Fix For: 5.1.0
Presumably this never fires, but:
{code}
if (i = (int64_t) sizeof(ioBufAllocator))
return;
{code}
looks wrong, it looks like i is an index into that array, so it should be
{code}
i = SIZE(ioBufAllocator))
{code}
(SIZE() from ink_defs.h)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2617) !TS_USE_FREELIST code allocates too much memory
[ https://issues.apache.org/jira/browse/TS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13976024#comment-13976024 ] William Bardwell commented on TS-2617: -- It is on my list...but it might be a little bit, feel free to do it. !TS_USE_FREELIST code allocates too much memory --- Key: TS-2617 URL: https://issues.apache.org/jira/browse/TS-2617 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.0.0 The code does: if (f-alignment) newp = ats_memalign(f-alignment, f-chunk_size * f-type_size); else newp = ats_malloc(f-chunk_size * f-type_size); But we are not making a freelist, just memory for a single item so it shouldn't be multiplying by f-chunk_size. Obviously this is really only for debugging, but it should still allocate the right amount of memory. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956615#comment-13956615 ] William Bardwell commented on TS-2632: -- I like the change... Range request will always lock object in cache, even thought it's rarely cacheable -- Key: TS-2632 URL: https://issues.apache.org/jira/browse/TS-2632 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 Attachments: range.diff Right now, if a client sends a Range: request, we still lock the URL in the cache, under the assumption that it will be written to. Since we don't support partial objects, in almost all cases, we'll not write the object and therefore release the object. I suggest we change this such that we never try to write lock a URL in the presence of a Range: header in the client request. This will allow other requests to go to origin faster, and better yet, it allows a request without a Range: header to properly lock the URL for writing. This turns out to be important for implementing e.g. background filling as a plugin. There is one use case where this might be useful; If the origin does not respond with a 206 (partial object), we can now cache the full object. However, this is a pretty rare case, and for someone to support this, all you have to do is to remove the Range: header on the request. I'm opening up this bug right now for discussion, if anyone have any concerns about this change, please let me know. It is an incompatible change, without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2632) Range request will always lock object in cache, even thought it's rarely cacheable
[ https://issues.apache.org/jira/browse/TS-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956011#comment-13956011 ] William Bardwell commented on TS-2632: -- It is not unusual for a server to return a full object to a range request if you are doing range requests on random stuff, especially on dynamically generated or assembled content. But those things are much less likely to be cached, although certainly not impossible. Obviously serving video, audio and PDFs that would normally get Range requests from a normal client/user-agent should support Range requests. But if you have something wacky trying to do partial object loads of everything, it could mess up your caching a bit with this change. Obviously if it is configurable, and configurable per-transaction then developers/deployers can decide which behavior they want. Range request will always lock object in cache, even thought it's rarely cacheable -- Key: TS-2632 URL: https://issues.apache.org/jira/browse/TS-2632 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 Right now, if a client sends a Range: request, we still lock the URL in the cache, under the assumption that it will be written to. Since we don't support partial objects, in almost all cases, we'll not write the object and therefore release the object. I suggest we change this such that we never try to write lock a URL in the presence of a Range: header in the client request. This will allow other requests to go to origin faster, and better yet, it allows a request without a Range: header to properly lock the URL for writing. This turns out to be important for implementing e.g. background filling as a plugin. There is one use case where this might be useful; If the origin does not respond with a 206 (partial object), we can now cache the full object. However, this is a pretty rare case, and for someone to support this, all you have to do is to remove the Range: header on the request. I'm opening up this bug right now for discussion, if anyone have any concerns about this change, please let me know. It is an incompatible change, without configuration options, but that should be ok for the v5.0.0 release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13935949#comment-13935949
]
William Bardwell commented on TS-2564:
--
Could this be the same as TS-1547?
(If so you would be able to see MIMEFieldBlockImpl::unmarshal() getting
entries from cache where field-m_readiness != MIME_FIELD_SLOT_READINESS_LIVE
(but where it has a pointer), which can cause problems later...maybe like that
stack, although it is quite a bit different than the one in TS-1547)
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Labels: crash
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (TS-866) Need way to clear contents of a cache entry
[ https://issues.apache.org/jira/browse/TS-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell closed TS-866. --- Resolution: Won't Fix We would still like this, but it is not critical to my current needs, and I agree that those changes make sense, but don't have the time to do it... Need way to clear contents of a cache entry --- Key: TS-866 URL: https://issues.apache.org/jira/browse/TS-866 Project: Traffic Server Issue Type: New Feature Components: Cache Affects Versions: 3.0.0 Reporter: William Bardwell Assignee: William Bardwell Priority: Minor Fix For: sometime Attachments: cache_erase.diff I needed a way to clear a cache entry off of disk, not just forget about it. The worry was about if you got content on a server that was illegal or a privacy violation of some sort, we wanted a way to be able to tell customers that after this step there was no way that TS could serve the content again. The normal cache remove just clears the directory entry, but theoretically a bug could allow that data out in some way. This was not intended to prevent forensic analysis of the hardware being able to recover the data. And bugs in low level drivers or the kernel could theoretically allow data to survive due to block remapping or mis-management of disk caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13922794#comment-13922794
]
William Bardwell commented on TS-1547:
--
I do not have permission yet, I will try to get permission in the next couple
of weeks for this and some of the other bugs that I recently filed.
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Labels: A, crash
Fix For: 5.2.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2617) !TS_USE_FREELIST code allocates too much memory
William Bardwell created TS-2617: Summary: !TS_USE_FREELIST code allocates too much memory Key: TS-2617 URL: https://issues.apache.org/jira/browse/TS-2617 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell The code does: if (f-alignment) newp = ats_memalign(f-alignment, f-chunk_size * f-type_size); else newp = ats_malloc(f-chunk_size * f-type_size); But we are not making a freelist, just memory for a single item so it shouldn't be multiplying by f-chunk_size. Obviously this is really only for debugging, but it should still allocate the right amount of memory. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2618) IOBufferBlock::realloc()'s bounds check is wrong
William Bardwell created TS-2618: Summary: IOBufferBlock::realloc()'s bounds check is wrong Key: TS-2618 URL: https://issues.apache.org/jira/browse/TS-2618 Project: Traffic Server Issue Type: Bug Components: Core Reporter: William Bardwell Presumably this never fires, but: if (i = (int64_t) sizeof(ioBufAllocator)) return; looks wrong, it looks like i is an index into that array, so it should be i = SIZE(ioBufAllocator)) (SIZE() from ink_defs.h) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2419) Don't close client connection when responding with a 204 and there is no body
[
https://issues.apache.org/jira/browse/TS-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878843#comment-13878843
]
William Bardwell commented on TS-2419:
--
Note: I tried to back port this to 3.2.4 and I am seeing crashes where
s-current.server can be NULL during that new check for transfer encoding. Not
sure if the same thing can happen in 4.X, but maybe...
Don't close client connection when responding with a 204 and there is no body
-
Key: TS-2419
URL: https://issues.apache.org/jira/browse/TS-2419
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 4.2.0
Currently ATS closes the client connection when returning a 204. In
production I saw a 2x the number of requests per connection when not closing
the connection on a 204 response. It the patch below I only close the
connection if it is chunked encoding or content length not equal to 0.
patch so far, untested:
{code}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 049e672..ad3bbfd 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -6756,9 +6756,10 @@
HttpTransact::handle_response_keep_alive_headers(State* s, HTTPVersion ver,
HTTP
} else if (HTTP_MAJOR(ver.m_version) == 0) { /* No K-A for 0.9 apps */
ka_action = KA_DISABLED;
}
- // some systems hang until the connection closes when receiving a 204
- // regardless of the K-A headers
- else if (heads-status_get() == HTTP_STATUS_NO_CONTENT) {
+ else if (heads-status_get() == HTTP_STATUS_NO_CONTENT
+ (s-current.server-transfer_encoding != NO_TRANSFER_ENCODING ||
s-hdr_info.request_content_length != 0)) {
+// some systems hang until the connection closes when receiving a 204
regardless of the K-A headers
+// close if there is any body response from the origin
ka_action = KA_CLOSE;
} else {
// Determine if we are going to send either a server-generated or
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (TS-1702) enable_read_while_writer on with simultaneous cache entry refreshes can leak 304's to client
[ https://issues.apache.org/jira/browse/TS-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell resolved TS-1702. -- Resolution: Fixed Fix Version/s: (was: 5.0.0) 4.1.2 The fix to TS-1086 seems to fix this, and is the same underlying issue. enable_read_while_writer on with simultaneous cache entry refreshes can leak 304's to client Key: TS-1702 URL: https://issues.apache.org/jira/browse/TS-1702 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.4, 3.2.0 Reporter: William Bardwell Labels: A Fix For: 4.1.2 enable_read_while_writer will sometimes fail to get the sort of locks that it wants, and will try to send a request forward that is not conditional, but if the cache entry content has an ETag and Last-Modified-Time header, then the code in HttpTransact::handle_cache_write_lock(State* s) to handle a failed write lock will remove the If-Modified-Since but not the If-None-Match. It should remove both. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874897#comment-13874897
]
William Bardwell commented on TS-1547:
--
The attachment is bettydramit's patch...I haven't gotten legal clearance to
send out my patch, but my textual description implies the couple lines needed
for my approach...
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Labels: A, crash
Fix For: 5.0.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1666) Plugins, clustering and core crashes when share_server_sessions=2
[
https://issues.apache.org/jira/browse/TS-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874899#comment-13874899
]
William Bardwell commented on TS-1666:
--
I haven't seen it in a while, but I think that is more a failure to do the
right sort of testing, because I have not updated or fixed anything related to
this.
Plugins, clustering and core crashes when share_server_sessions=2
-
Key: TS-1666
URL: https://issues.apache.org/jira/browse/TS-1666
Project: Traffic Server
Issue Type: Bug
Components: MIME, Plugins
Reporter: Otto van der Schaaf
Priority: Critical
Labels: Crash
Fix For: 4.2.0
ibrezac dumped this trace on irc:
{noformat}
[Jan 22 21:25:34.555] Server {0x2ac1f8a78300} NOTE: logging initialized[15],
logging_mode = 3
[Jan 22 21:25:34.610] Server {0x2ac1f8a78300} NOTE: loading plugin
'/usr/lib/trafficserver/modules/gzip.so'
[Jan 22 21:25:34.683] Server {0x2ac1f8a78300} NOTE: traffic server running
[Jan 22 21:25:34.705] Server {0x2ac1f8a78300} NOTE: cache enabled
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(_Z19mime_hdr_field_findP11MIMEHdrImplPKci+0x152)[0x5c27f2]
/usr/bin/traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0xe1)[0x545571]
/usr/bin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x122)[0x553112]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x526df8]
/usr/bin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x52ba2d]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x533888]
/usr/bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x272)[0x4e7402]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x90)[0x6ab490]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main+0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ac1f86da76d]
/usr/bin/traffic_server[0x4855fd]
[Jan 22 21:25:41.933] Manager {0x7fa2b126c740} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:42.946] Manager {0x7fa2b126c740} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr'
{noformat}
configuration used:
{noformat}
cache true
enabled true
remove-accept-encoding false
compressible-content-type text/*
compressible-content-type *javascript*
{noformat}
=== misc info
TS Version 3.2.4
Running at around 50 qps
crashes every 10 seconds
== c++filt stack trace
{noformat}
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0( 0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(mime_hdr_field_find(MIMEHdrImpl*, char const*, int)
0x152)[0x5c27f2]
/usr/bin/traffic_server(ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5
0xe1)[0x545571]
/usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)
0x122)[0x553112]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*)) 0x28)[0x526df8]
/usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
void*) 0xed)[0x52ba2d]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*) 0xe8)[0x533888]
/usr/bin/traffic_server(TransformTerminus::handle_event(int, void*)
0x272)[0x4e7402]
/usr/bin/traffic_server(EThread::process_event(Event*, int) 0x90)[0x6ab490]
/usr/bin/traffic_server(EThread::execute() 0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main 0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main 0xed)[0x2ac1f86da76d]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-1545) possible crash in records stat snap
[
https://issues.apache.org/jira/browse/TS-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13874904#comment-13874904
]
William Bardwell commented on TS-1545:
--
I think so, it can leave a machine in a loop where it won't work at all without
deleting those files. The current code would need a lot more validation of the
data that is being read in. Maybe it needs fancier marshalling out so you can
just tell that a file was partially written. (Magic number that is written
last, or something similar.)
possible crash in records stat snap
---
Key: TS-1545
URL: https://issues.apache.org/jira/browse/TS-1545
Project: Traffic Server
Issue Type: Bug
Components: Core, Stats
Affects Versions: 3.3.0
Environment: debug build, long time regression testing
Reporter: Zhao Yongming
Labels: Crash
Fix For: 4.2.0
Attachments: records.snap, stats.snap
when I running regression testing in the loop script, we come to fail to
start the server. well, the codes may handle the issue when we build without
--enable-debug, but that looks like we have something may break records snap.
open this issue in case someone need it.
{code}
[TrafficServer] using root directory '/opt/ats'
FATAL: RecMessage.cc:426: failed assert `eh-magic == REC_MESSAGE_ELE_MAGIC`
/opt/ats/bin/traffic_server - STACK TRACE:
/opt/ats/lib/libtsutil.so.3(ink_fatal_die+0x0)[0x77baeca1]
/opt/ats/lib/libtsutil.so.3(_Z12ink_get_randv+0x0)[0x77badbb8]
/opt/ats/bin/traffic_server(_Z23RecMessageUnmarshalNextP13RecMessageHdrP13RecMessageItrPP9RecRecord+0xbf)[0x6ed860]
/opt/ats/bin/traffic_server(_Z16RecReadStatsFilev+0xc1)[0x6e5e36]
/opt/ats/bin/traffic_server(_Z11RecCoreInit8RecModeTP5Diags+0xec)[0x6e254b]
/opt/ats/bin/traffic_server(_Z14RecProcessInit8RecModeTP5Diags+0x3b)[0x6e7769]
/opt/ats/bin/traffic_server[0x51d4a5]
/opt/ats/bin/traffic_server(main+0x1df)[0x51ee39]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7515b60d]
/opt/ats/bin/traffic_server[0x4d8f99]
Program received signal SIGABRT, Aborted.
0x7516ec15 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x7516ec15 in raise () from /lib64/libc.so.6
#1 0x7517008b in abort () from /lib64/libc.so.6
#2 0x77baeb2c in ink_die_die_die (retval=1) at ink_error.cc:43
#3 0x77baebfe in ink_fatal_va(int, const char *, typedef
__va_list_tag __va_list_tag *) (return_code=1,
message_format=0x77bca3e0 %s:%d: failed assert `%s`,
ap=0x7fffc8b8) at ink_error.cc:65
#4 0x77baeca1 in ink_fatal (return_code=1,
message_format=0x77bca3e0 %s:%d: failed assert `%s`) at ink_error.cc:73
#5 0x77badbb8 in _ink_assert (expression=0x76ffa0 eh-magic ==
REC_MESSAGE_ELE_MAGIC, file=0x76fe40 RecMessage.cc, line=426)
at ink_assert.cc:38
#6 0x006ed860 in RecMessageUnmarshalNext (msg=0xfe6110,
itr=0x7fffca00, record=0x7fffca10) at RecMessage.cc:426
#7 0x006e5e36 in RecReadStatsFile () at P_RecCore.i:569
#8 0x006e254b in RecCoreInit (mode_type=RECM_STAND_ALONE,
_diags=0xfe5f70) at RecCore.cc:209
#9 0x006e7769 in RecProcessInit (mode_type=RECM_STAND_ALONE,
_diags=0xfe5f70) at RecProcess.cc:313
#10 0x0051d4a5 in initialize_process_manager () at Main.cc:413
#11 0x0051ee39 in main (argc=1, argv=0x7fffdd08) at Main.cc:1409
(gdb) f 6
#6 0x006ed860 in RecMessageUnmarshalNext (msg=0xfe6110,
itr=0x7fffca00, record=0x7fffca10) at RecMessage.cc:426
426 ink_debug_assert(eh-magic == REC_MESSAGE_ELE_MAGIC);
(gdb) l
421 itr-ele_hdr = (RecMessageEleHdr *) ((char *) (msg) +
itr-ele_hdr-o_next);
422 itr-next += 1;
423 eh = itr-ele_hdr;
424 }
425
426 ink_debug_assert(eh-magic == REC_MESSAGE_ELE_MAGIC);
427
428 // If the file is corrupt, ignore the the rest of the file.
429 if (eh-magic != REC_MESSAGE_ELE_MAGIC) {
430 Warning(Persistent statistics file records.stat is corrupted.
Ignoring the rest of the file\n);
(gdb) p eh-magic
$1 = 0
(gdb) p REC_MESSAGE_ELE_MAGIC
$2 = 4027445261
(gdb) p eh
$3 = (RecMessageEleHdr *) 0xff4138
(gdb) p *eh
$4 = {magic = 0, o_next = 0}
(gdb) f 7
#7 0x006e5e36 in RecReadStatsFile () at P_RecCore.i:569
569 } while (RecMessageUnmarshalNext(m, itr, r) != REC_ERR_FAIL);
(gdb) l
564 if (RecMessageUnmarshalFirst(m, itr, r) != REC_ERR_FAIL) {
565 do {
566 if ((r-name == NULL) || (!strlen(r-name)))
567 continue;
568 RecSetRecord(r-rec_type, r-name, r-data_type, (r-data),
(r-stat_meta.data_raw), false);
569 } while (RecMessageUnmarshalNext(m, itr, r) != REC_ERR_FAIL);
570 }
571 }
[jira] [Commented] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859533#comment-13859533
]
William Bardwell commented on TS-1547:
--
Did you try my patch idea? I worry that your change may cause a problem with
DETACHED strings disappearing while someone is still using them. (Thus my idea
about only changing unmarshal, where we know that DETACHED things can't be used
by any thing else.)
BTW I assume that you are also running with a plugin that edits headers a lot,
since that is what seems to trigger this.
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Labels: A, crash
Fix For: 5.0.0
Attachments: move_string.patch
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2358) DNS does not fail-over promptly for DNS server returning SERVFAIL
[ https://issues.apache.org/jira/browse/TS-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831107#comment-13831107 ] William Bardwell commented on TS-2358: -- I am not working on this one for now. DNS does not fail-over promptly for DNS server returning SERVFAIL - Key: TS-2358 URL: https://issues.apache.org/jira/browse/TS-2358 Project: Traffic Server Issue Type: Bug Components: DNS Affects Versions: 3.2.5 Reporter: William Bardwell Attachments: ats.dns.txt If I have 2 dns servers listed in my resolv.conf and the first one is returning SERVFAIL for something that I try to lookup, ATS takes a long time to fail over, and won't do it for the first request to look something up. Using normal system commands (host, ping etc.) with the same resolv.conf work fine. I tried various config values with out much improvement. I could make it fail in 40sec instead of 60sec for the initial failure... debug logs will be attached, doing one DNS and then waiting a while and doing another. (Doing more before enough time has passed don't seem to help much.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2358) DNS does not fail-over promptly for DNS server returning SERVFAIL
[ https://issues.apache.org/jira/browse/TS-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-2358: - Affects Version/s: 3.2.5 DNS does not fail-over promptly for DNS server returning SERVFAIL - Key: TS-2358 URL: https://issues.apache.org/jira/browse/TS-2358 Project: Traffic Server Issue Type: Bug Components: DNS Affects Versions: 3.2.5 Reporter: William Bardwell If I have 2 dns servers listed in my resolv.conf and the first one is returning SERVFAIL for something that I try to lookup, ATS takes a long time to fail over, and won't do it for the first request to look something up. Using normal system commands (host, ping etc.) with the same resolv.conf work fine. I tried various config values with out much improvement. I could make it fail in 40sec instead of 60sec for the initial failure... debug logs will be attached, doing one DNS and then waiting a while and doing another. (Doing more before enough time has passed don't seem to help much.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2358) DNS does not fail-over promptly for DNS server returning SERVFAIL
William Bardwell created TS-2358: Summary: DNS does not fail-over promptly for DNS server returning SERVFAIL Key: TS-2358 URL: https://issues.apache.org/jira/browse/TS-2358 Project: Traffic Server Issue Type: Bug Components: DNS Reporter: William Bardwell If I have 2 dns servers listed in my resolv.conf and the first one is returning SERVFAIL for something that I try to lookup, ATS takes a long time to fail over, and won't do it for the first request to look something up. Using normal system commands (host, ping etc.) with the same resolv.conf work fine. I tried various config values with out much improvement. I could make it fail in 40sec instead of 60sec for the initial failure... debug logs will be attached, doing one DNS and then waiting a while and doing another. (Doing more before enough time has passed don't seem to help much.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-1666) Plugins, clustering and core crashes when share_server_sessions=2
[
https://issues.apache.org/jira/browse/TS-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811357#comment-13811357
]
William Bardwell commented on TS-1666:
--
I am not using any weird threads and proxy.config.http.share_server_sessions=1
and I still see this crash every once in a while.
Is the guess that this is a locking problem?
Plugins, clustering and core crashes when share_server_sessions=2
-
Key: TS-1666
URL: https://issues.apache.org/jira/browse/TS-1666
Project: Traffic Server
Issue Type: Bug
Components: MIME, Plugins
Reporter: Otto van der Schaaf
Priority: Critical
Labels: crash
Fix For: 4.2.0
ibrezac dumped this trace on irc:
{noformat}
[Jan 22 21:25:34.555] Server {0x2ac1f8a78300} NOTE: logging initialized[15],
logging_mode = 3
[Jan 22 21:25:34.610] Server {0x2ac1f8a78300} NOTE: loading plugin
'/usr/lib/trafficserver/modules/gzip.so'
[Jan 22 21:25:34.683] Server {0x2ac1f8a78300} NOTE: traffic server running
[Jan 22 21:25:34.705] Server {0x2ac1f8a78300} NOTE: cache enabled
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(_Z19mime_hdr_field_findP11MIMEHdrImplPKci+0x152)[0x5c27f2]
/usr/bin/traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0xe1)[0x545571]
/usr/bin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x122)[0x553112]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x526df8]
/usr/bin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x52ba2d]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x533888]
/usr/bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x272)[0x4e7402]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x90)[0x6ab490]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main+0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ac1f86da76d]
/usr/bin/traffic_server[0x4855fd]
[Jan 22 21:25:41.933] Manager {0x7fa2b126c740} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:42.946] Manager {0x7fa2b126c740} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr'
{noformat}
configuration used:
{noformat}
cache true
enabled true
remove-accept-encoding false
compressible-content-type text/*
compressible-content-type *javascript*
{noformat}
=== misc info
TS Version 3.2.4
Running at around 50 qps
crashes every 10 seconds
== c++filt stack trace
{noformat}
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0( 0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(mime_hdr_field_find(MIMEHdrImpl*, char const*, int)
0x152)[0x5c27f2]
/usr/bin/traffic_server(ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5
0xe1)[0x545571]
/usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)
0x122)[0x553112]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*)) 0x28)[0x526df8]
/usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
void*) 0xed)[0x52ba2d]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*) 0xe8)[0x533888]
/usr/bin/traffic_server(TransformTerminus::handle_event(int, void*)
0x272)[0x4e7402]
/usr/bin/traffic_server(EThread::process_event(Event*, int) 0x90)[0x6ab490]
/usr/bin/traffic_server(EThread::execute() 0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main 0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main 0xed)[0x2ac1f86da76d]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811012#comment-13811012 ] William Bardwell commented on TS-1776: -- Not sure if it would be the same or not...Like I said the fix for TS-1574 looked like it fixed most of the issues that I saw for (just wasn't ported back to 3.2.X) But I would be happy to look at the change and see if it helps at all... Range requests not working right in 3.2.4 - Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.4 Reporter: William Bardwell Assignee: Alan M. Carroll Priority: Blocker Fix For: 3.2.6 With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
[ https://issues.apache.org/jira/browse/TS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793530#comment-13793530 ] William Bardwell commented on TS-1807: -- I have some tentative fixes, not sure about a release...some time in the next couple months... shutdown on a write VIO to TSHttpConnect() doesn't propogate Key: TS-1807 URL: https://issues.apache.org/jira/browse/TS-1807 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.0.0 In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and getting responses. But when I try to do TSVIONBytesSet() and TSVConnShutdown() on the write vio (due to the client side being done sending requests) the write vio just sits there and never wakes up the other side, and the response side doesn't try to close up until an inactivity timeout happens. I think that PluginVC::do_io_shutdown() needs to do other_side-read_state.vio.reenable(); when a shutdown for write shows up. Then the otherside wakes up and sees the EOF due to the shutdown. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
[ https://issues.apache.org/jira/browse/TS-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell reassigned TS-1807: Assignee: William Bardwell shutdown on a write VIO to TSHttpConnect() doesn't propogate Key: TS-1807 URL: https://issues.apache.org/jira/browse/TS-1807 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Assignee: William Bardwell Fix For: 5.0.0 In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and getting responses. But when I try to do TSVIONBytesSet() and TSVConnShutdown() on the write vio (due to the client side being done sending requests) the write vio just sits there and never wakes up the other side, and the response side doesn't try to close up until an inactivity timeout happens. I think that PluginVC::do_io_shutdown() needs to do other_side-read_state.vio.reenable(); when a shutdown for write shows up. Then the otherside wakes up and sees the EOF due to the shutdown. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779527#comment-13779527
]
William Bardwell commented on TS-1547:
--
I am seeing promising behavior if I add code to MIMEFieldBlockImpl::unmarshal
to set field-m_readiness to MIME_FIELD_SLOT_READINESS_EMPTY whenever it is not
LIVE. The issue seems to be that marshal() writes out any readiness other than
LIVE without fixing up the pointers, but some code like move_strings() looks at
the pointer values of things that are _DETACHED. (So cache entries get written
out with pointers to old locations, and then they are read back in with the
same old pointer values. Maybe the real fix would be to try to fix the
pointers for _DETACHED in both marshal and unmarshal...I am not sure, anyone
out there who understands this code well enough to say?) Given that, I suspect
that this problem exists in the trunk version too, but must only be triggered
by specific patterns of plugin's adding and removing headers plus certain sizes
of headers and maybe some bad luck is required.
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Labels: A, crash
Fix For: 4.2.0
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in EThread::process_event (this=0x2b8244119010,
e=0x24af320, calling_code=5) at UnixEThread.cc:194
#19 0x006da27d in EThread::execute (this=0x2b8244119010) at
UnixEThread.cc:306
#20 0x006d8bd3 in spawn_thread_internal (a=0x2467970) at Thread.cc:88
#21 0x0032d38077f1 in start_thread () from /lib64/libpthread.so.0
#22 0x0032d34e570d in clone () from /lib64/libc.so.6
(gdb) f 0
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
/usr/src/debug/trafficserver-3.2.0/proxy/hdrs/HTTP.h:846:25127:beg:0x503695
(gdb) l
841
842 if (valid()) {
843 http_hdr_copy_onto(hdr-m_http, hdr-m_heap, m_http, m_heap,
(m_heap != hdr-m_heap) ? true : false);
844 } else {
845 m_heap = new_HdrHeap();
846 m_http = http_hdr_clone(hdr-m_http, hdr-m_heap, m_heap);
847 m_mime = m_http-m_fields_impl;
848 }
849 }
850
(gdb) p hdr
$3 = (const HTTPHdr *) 0x70
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
[jira] [Commented] (TS-1547) in HTTPHdr::copy hdr ptr is error
[
https://issues.apache.org/jira/browse/TS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13771974#comment-13771974
]
William Bardwell commented on TS-1547:
--
I am seeing similar crashes in 3.2 based code. I think that it is corrupted
cache entries, because clearing the cache lets the same requests work.
memcpy(): ip = 0x7f6ac294db3e offp = 0x000e sp = 0x7f6ac1289d48
MIMEFieldBlockImpl::move_strings(HdrStrHeap*)(): ip = 0x0067c105 offp = 0x
00b5 sp = 0x7f6ac1289d50
MIMEHdrImpl::move_strings(HdrStrHeap*)(): ip = 0x0067c4d3 offp = 0x002
7 sp = 0x7f6ac1289d90
HdrHeap::evacuate_from_str_heaps(HdrStrHeap*)(): ip = 0x0066a51e offp = 0x0
08e sp = 0x7f6ac1289db0
HdrHeap::coalesce_str_heaps(int)(): ip = 0x0066a372 offp = 0x00d0 sp = 0x7f
6ac1289df0
HdrHeap::allocate_str(int)(): ip = 0x0066a036 offp = 0x00fe sp = 0x7f6ac128
9e30
HdrHeap::duplicate_str(char const*, int)(): ip = 0x0066a10c offp = 0x003e
sp = 0x7f6a
c1289e70
mime_field_value_set(HdrHeap*, MIMEHdrImpl*, MIMEField*, char const*, int,
bool)(): ip = 0x00677efa offp = 0x006a sp = 0x7f6ac1289ec0
MIMEField::value_set(HdrHeap*, MIMEHdrImpl*, char const*, int)(): ip =
0x0057a020 offp = 0x0044 sp = 0x7f6ac1289f00
MIMEHdr::value_set(char const*, int, char const*, int)(): ip = 0x0057a3d7 offp
= 0x0069 sp = 0x7f6ac1289f50
HttpTransact::merge_response_header_with_cached_header(HTTPHdr*, HTTPHdr*)():
ip = 0x00601a41 offp = 0x01a5 sp = 0x7f6ac1289fb0
HttpTransact::merge_and_update_headers_for_cache_update(HttpTransact::State*)():
ip = 0x00600a55 offp = 0x01d5 sp = 0x7f6ac128a070
HttpTransact::handle_cache_operation_on_forward_server_response(HttpTransact::State*)():
ip = 0x005ffb95 offp = 0x1b25 sp = 0x7f6ac128a0c0
HttpTransact::handle_forward_server_connection_open(HttpTransact::State*)(): ip
= 0x005fda34 offp = 0x0824 sp = 0x7f6ac128b180
HttpTransact::handle_response_from_server(HttpTransact::State*)(): ip =
0x005faed1 offp = 0x028b sp = 0x7f6ac128b270
HttpTransact::HandleResponse(HttpTransact::State*)(): ip = 0x005f9810 offp =
0x07ac sp = 0x7f6ac128b2c0
HttpSM::call_transact_and_set_next_state(void (*)(HttpTransact::State*))(): ip
= 0x005dff02 offp = 0x006a sp = 0x7f6ac128c320
in HTTPHdr::copy hdr ptr is error
--
Key: TS-1547
URL: https://issues.apache.org/jira/browse/TS-1547
Project: Traffic Server
Issue Type: Bug
Components: Cache, HTTP
Affects Versions: 3.2.0
Reporter: Bin Chen
Labels: A, crash
Fix For: 4.2.0
{code}
(gdb) bt
#0 0x00503695 in HTTPHdr::copy (this=0x27e66b0, hdr=0x70) at
hdrs/HTTP.h:846
#1 0x00503a70 in HTTPInfo::response_set (this=0x2b827c5e8f80,
resp=0x70) at hdrs/HTTP.h:1343
#2 0x0059a2c5 in
HttpTransact::merge_and_update_headers_for_cache_update (s=0x2b827c5e8f08) at
HttpTransact.cc:4587
#3 0x00599542 in
HttpTransact::handle_cache_operation_on_forward_server_response
(s=0x2b827c5e8f08)
at HttpTransact.cc:4394
#4 0x0059765b in HttpTransact::handle_forward_server_connection_open
(s=0x2b827c5e8f08) at HttpTransact.cc:3896
#5 0x00594f11 in HttpTransact::handle_response_from_server
(s=0x2b827c5e8f08) at HttpTransact.cc:3450
#6 0x00593a82 in HttpTransact::HandleResponse (s=0x2b827c5e8f08) at
HttpTransact.cc:3140
#7 0x0057b066 in HttpSM::call_transact_and_set_next_state
(this=0x2b827c5e8ea0, f=0) at HttpSM.cc:6423
#8 0x0056ba10 in HttpSM::handle_api_return (this=0x2b827c5e8ea0) at
HttpSM.cc:1523
#9 0x00580db7 in HttpSM::do_api_callout (this=0x2b827c5e8ea0) at
HttpSM.cc:504
#10 0x0056c835 in HttpSM::state_read_server_response_header
(this=0x2b827c5e8ea0, event=100, data=0x2b8364007578)
at HttpSM.cc:1837
#11 0x0056eb47 in HttpSM::main_handler (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578) at HttpSM.cc:2462
#12 0x004e71f6 in Continuation::handleEvent (this=0x2b827c5e8ea0,
event=100, data=0x2b8364007578)
at ../iocore/eventsystem/I_Continuation.h:146
#13 0x006b80a8 in read_signal_and_update (event=100,
vc=0x2b8364007470) at UnixNetVConnection.cc:131
#14 0x006b88af in read_from_net (nh=0x2b824411c1e8,
vc=0x2b8364007470, thread=0x2b8244119010)
at UnixNetVConnection.cc:313
#15 0x006ba38d in UnixNetVConnection::net_read_io
(this=0x2b8364007470, nh=0x2b824411c1e8, lthread=0x2b8244119010)
at UnixNetVConnection.cc:813
#16 0x006b50cc in NetHandler::mainNetEvent (this=0x2b824411c1e8,
event=5, e=0x24af320) at UnixNet.cc:372
#17 0x004e71f6 in Continuation::handleEvent (this=0x2b824411c1e8,
event=5, data=0x24af320)
at ../iocore/eventsystem/I_Continuation.h:146
#18 0x006d9ddf in
[jira] [Commented] (TS-1666) gzip plugin crash report
[
https://issues.apache.org/jira/browse/TS-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688397#comment-13688397
]
William Bardwell commented on TS-1666:
--
Did anyone ever figure out what this was? I might be seeing something similar.
gzip plugin crash report
Key: TS-1666
URL: https://issues.apache.org/jira/browse/TS-1666
Project: Traffic Server
Issue Type: Bug
Components: MIME, Plugins
Reporter: Otto van der Schaaf
Assignee: Otto van der Schaaf
Labels: crash
Fix For: sometime
ibrezac dumped this trace on irc:
[Jan 22 21:25:34.555] Server {0x2ac1f8a78300} NOTE: logging initialized[15],
logging_mode = 3
[Jan 22 21:25:34.610] Server {0x2ac1f8a78300} NOTE: loading plugin
'/usr/lib/trafficserver/modules/gzip.so'
[Jan 22 21:25:34.683] Server {0x2ac1f8a78300} NOTE: traffic server running
[Jan 22 21:25:34.705] Server {0x2ac1f8a78300} NOTE: cache enabled
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(_Z19mime_hdr_field_findP11MIMEHdrImplPKci+0x152)[0x5c27f2]
/usr/bin/traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0xe1)[0x545571]
/usr/bin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x122)[0x553112]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x526df8]
/usr/bin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x52ba2d]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x533888]
/usr/bin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x272)[0x4e7402]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x90)[0x6ab490]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main+0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ac1f86da76d]
/usr/bin/traffic_server[0x4855fd]
[Jan 22 21:25:41.933] Manager {0x7fa2b126c740} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Jan 22 21:25:41.934] Manager {0x7fa2b126c740} ERROR: (last system error 2:
No such file or directory)
[Jan 22 21:25:42.946] Manager {0x7fa2b126c740} NOTE:
[LocalManager::startProxy] Launching ts process
[TrafficServer] using root directory '/usr'
configuration used:
cache true
enabled true
remove-accept-encoding false
compressible-content-type text/*
compressible-content-type *javascript*
=== misc info
TS Version 3.2.4
Running at around 50 qps
crashes every 10 seconds
== c++filt stack trace
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0( 0xfcb0)[0x2ac1f68bccb0]
/usr/bin/traffic_server(mime_hdr_field_find(MIMEHdrImpl*, char const*, int)
0x152)[0x5c27f2]
/usr/bin/traffic_server(ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5
0xe1)[0x545571]
/usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)
0x122)[0x553112]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*)) 0x28)[0x526df8]
/usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
void*) 0xed)[0x52ba2d]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*) 0xe8)[0x533888]
/usr/bin/traffic_server(TransformTerminus::handle_event(int, void*)
0x272)[0x4e7402]
/usr/bin/traffic_server(EThread::process_event(Event*, int) 0x90)[0x6ab490]
/usr/bin/traffic_server(EThread::execute() 0x5fe)[0x6ac05e]
/usr/bin/traffic_server(main 0x160f)[0x48022f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main 0xed)[0x2ac1f86da76d]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1807) shutdown on a write VIO to TSHttpConnect() doesn't propogate
William Bardwell created TS-1807: Summary: shutdown on a write VIO to TSHttpConnect() doesn't propogate Key: TS-1807 URL: https://issues.apache.org/jira/browse/TS-1807 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell In a plugin I am doing a TSHttpConnect() and then sending HTTP requests and getting responses. But when I try to do TSVIONBytesSet() and TSVConnShutdown() on the write vio (due to the client side being done sending requests) the write vio just sits there and never wakes up the other side, and the response side doesn't try to close up until an inactivity timeout happens. I think that PluginVC::do_io_shutdown() needs to do other_side-read_state.vio.reenable(); when a shutdown for write shows up. Then the otherside wakes up and sees the EOF due to the shutdown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1261) enable keepalive/chunking when transforming from cache
[ https://issues.apache.org/jira/browse/TS-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13625750#comment-13625750 ] William Bardwell commented on TS-1261: -- I would love for this to be back-ported to 3.2.X, because it breaks things in the 3.2.X line too. enable keepalive/chunking when transforming from cache -- Key: TS-1261 URL: https://issues.apache.org/jira/browse/TS-1261 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.3 Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Labels: patch Fix For: 3.3.1 Attachments: cache_transform_chunking.diff when transforming a document from cache, we will currently either close the connection, or send a content length header (probably when the full response is buffered). sending chunked responses could help lowering latencies and memory requirements in some use cases. the attached patch has only been lab tested, and has not got any production mileage yet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-974) TS should have a mode to hold partial objects in cache
[ https://issues.apache.org/jira/browse/TS-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13617449#comment-13617449 ] William Bardwell commented on TS-974: - #1 is certainly a reasonable step and not too hard, just needs some configuration about when to trigger it, and when to quit. (And also configuring, do you need to sometimes tunnel the range request while doing the background full load.) #2 is also reasonable, as you say the hard part is doing proper stitching together segments when the range request covers several of them, and ideally you could get at the new pread cache support to avoid reading too much data that you have no interest in. #2 does have some other benefits, like that it allows parts of files to be never cached, or expired if you have a video that is too boring to actually watch all of it, or I have heard that some pdf viewers look at the beginning and the end of a file with range requests (before they look at the middle), and that working without having to load the whole file first would be appealing. #3 would be awesome, but sounds hard. TS should have a mode to hold partial objects in cache -- Key: TS-974 URL: https://issues.apache.org/jira/browse/TS-974 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 3.0.1 Reporter: William Bardwell Fix For: sometime For ATS to do an excelent job caching large files like video it would need to be able to hold partial objects for a large file. This could be done in a plugin or in the core. This would need to be integrated with the Range handling code to serve requests out of the partial objects and to get more parts of a file to satisfy a Range request. An intermediate step (also do-able in the core or in a plugin) would be to have some settings to let the Range handling code be able to trigger a full file download either asynchronously when a Range response indicates that the file isn't larger than some threshold, or synchronously when a Range request could reasonably be answered quickly from a full request. (Right now Range requests are tunneled if there is not full cached content as far as I can tell.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1776) Range requests not working right in 3.2.4
William Bardwell created TS-1776: Summary: Range requests not working right in 3.2.4 Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13613377#comment-13613377 ] William Bardwell commented on TS-1776: -- It seems like the changes to try to add fancy range support left behind the old transform code, but missing the handling for calculating the proper content-length. And the full content length is used to start writing the data, and the change_response_headers() now unconditionally does multipart stuff. Also the code in HttpTunnel calculates read_start_pos and does a do_io_pread() to seek even when the fix has claimed that pread() shouldn't be used, and the RangeTransform code is going to try to do the seeking by skipping. (So now the start skip amount get skipped twice.) Range requests not working right in 3.2.4 - Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13613388#comment-13613388 ] William Bardwell commented on TS-1776: -- The fix for TS-1574 (commit 1199e991424d8495a80075718d8ec95a64f3a712) has most of the same fixes but done differently (based on the new range stuff being active in more cases, and a few changes in the 3.3.X code line.) (But it doesn't fix the content-length issues, although they may not happen in the read_while_writer cases since it doesn't have a known content-length anyway.) Range requests not working right in 3.2.4 - Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-1776: - Affects Version/s: 3.2.4 Range requests not working right in 3.2.4 - Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.4 Reporter: William Bardwell With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13613422#comment-13613422 ] William Bardwell commented on TS-1776: -- It should be pretty easy to add tests, just need to do a full load of a cachable object, and then a range load 1-10 or some such. Range requests not working right in 3.2.4 - Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.4 Reporter: William Bardwell With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[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=13609817#comment-13609817 ] William Bardwell commented on TS-1125: -- I haven't worked on this. 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 Priority: Minor Fix For: 3.3.3 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
