[jira] [Commented] (TS-2654) Range request crash in trafficserver 4.2.0
[
https://issues.apache.org/jira/browse/TS-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947462#comment-13947462
]
Leif Hedstrom commented on TS-2654:
---
Doh. Yeah, we really need the line and some of the state around that line...
Or, details on the request(s) that's causing it.
> Range request crash in trafficserver 4.2.0
> --
>
> Key: TS-2654
> URL: https://issues.apache.org/jira/browse/TS-2654
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Chaokovsky Lee
>Assignee: Leif Hedstrom
>Priority: Critical
> Fix For: 5.0.0
>
>
> I have updated trafficserver from 4.1.2 to 4.2.0, but the range request crash
> bug even appear.
> I use "read while writer" feature in my configuration, Maybe the feature
> cause crash ?
> CONFIG proxy.config.cache.enable_read_while_writer INT 1
> {code}
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x3a8300f4a0]
> /usr/bin/traffic_server(HttpTransact::change_response_header_because_of_range_request(HttpTransact::State*,
> HTTPHdr*)+0x255)[0x533295]
> /usr/bin/traffic_server(HttpTransact::handle_content_length_header(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*)+0x2c8)[0x533638]
> /usr/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x460)[0x533b40]
> /usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)+0x7d)[0x53a2dd]
> /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x28)[0x50b268]
> /usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
> void*)+0xed)[0x514b4d]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x70)[0x51feb0]
> /usr/bin/traffic_server(TransformTerminus::handle_event(int,
> void*)+0x1d6)[0x4df8d6]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x66d37f]
> /usr/bin/traffic_server(EThread::execute()+0x61b)[0x66deab]
> /usr/bin/traffic_server[0x66c89a]
> /lib64/libpthread.so.0[0x3a830077f1]
> /lib64/libc.so.6(clone+0x6d)[0x3a82ce570d]
> {code}
> Thank for your excellent work, the trafficserver is so great!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2654) Range request crash in trafficserver 4.2.0
[
https://issues.apache.org/jira/browse/TS-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947445#comment-13947445
]
Chaokovsky Lee commented on TS-2654:
Sorry for reply so late. The patch doesn't fix the problem, but I have not got
the core file because I used wrong kernel parameters.
> Range request crash in trafficserver 4.2.0
> --
>
> Key: TS-2654
> URL: https://issues.apache.org/jira/browse/TS-2654
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Chaokovsky Lee
>Assignee: Leif Hedstrom
>Priority: Critical
> Fix For: 5.0.0
>
>
> I have updated trafficserver from 4.1.2 to 4.2.0, but the range request crash
> bug even appear.
> I use "read while writer" feature in my configuration, Maybe the feature
> cause crash ?
> CONFIG proxy.config.cache.enable_read_while_writer INT 1
> {code}
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x3a8300f4a0]
> /usr/bin/traffic_server(HttpTransact::change_response_header_because_of_range_request(HttpTransact::State*,
> HTTPHdr*)+0x255)[0x533295]
> /usr/bin/traffic_server(HttpTransact::handle_content_length_header(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*)+0x2c8)[0x533638]
> /usr/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x460)[0x533b40]
> /usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)+0x7d)[0x53a2dd]
> /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x28)[0x50b268]
> /usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
> void*)+0xed)[0x514b4d]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x70)[0x51feb0]
> /usr/bin/traffic_server(TransformTerminus::handle_event(int,
> void*)+0x1d6)[0x4df8d6]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x66d37f]
> /usr/bin/traffic_server(EThread::execute()+0x61b)[0x66deab]
> /usr/bin/traffic_server[0x66c89a]
> /lib64/libpthread.so.0[0x3a830077f1]
> /lib64/libc.so.6(clone+0x6d)[0x3a82ce570d]
> {code}
> Thank for your excellent work, the trafficserver is so great!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2654) Range request crash in trafficserver 4.2.0
[
https://issues.apache.org/jira/browse/TS-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947377#comment-13947377
]
Leif Hedstrom commented on TS-2654:
---
Any updates on this? Did the patch fix the problem? Any more details on the
core ?
Thanks!
> Range request crash in trafficserver 4.2.0
> --
>
> Key: TS-2654
> URL: https://issues.apache.org/jira/browse/TS-2654
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Chaokovsky Lee
>Assignee: Leif Hedstrom
>Priority: Critical
> Fix For: 5.0.0
>
>
> I have updated trafficserver from 4.1.2 to 4.2.0, but the range request crash
> bug even appear.
> I use "read while writer" feature in my configuration, Maybe the feature
> cause crash ?
> CONFIG proxy.config.cache.enable_read_while_writer INT 1
> {code}
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x3a8300f4a0]
> /usr/bin/traffic_server(HttpTransact::change_response_header_because_of_range_request(HttpTransact::State*,
> HTTPHdr*)+0x255)[0x533295]
> /usr/bin/traffic_server(HttpTransact::handle_content_length_header(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*)+0x2c8)[0x533638]
> /usr/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x460)[0x533b40]
> /usr/bin/traffic_server(HttpTransact::handle_transform_ready(HttpTransact::State*)+0x7d)[0x53a2dd]
> /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x28)[0x50b268]
> /usr/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
> void*)+0xed)[0x514b4d]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x70)[0x51feb0]
> /usr/bin/traffic_server(TransformTerminus::handle_event(int,
> void*)+0x1d6)[0x4df8d6]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x66d37f]
> /usr/bin/traffic_server(EThread::execute()+0x61b)[0x66deab]
> /usr/bin/traffic_server[0x66c89a]
> /lib64/libpthread.so.0[0x3a830077f1]
> /lib64/libc.so.6(clone+0x6d)[0x3a82ce570d]
> {code}
> Thank for your excellent work, the trafficserver is so great!
--
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-tabpanel&focusedCommentId=13947349#comment-13947349
]
ASF subversion and git services commented on TS-2564:
-
Commit 8d7d25db897269988bcc1df662cd77d5707c34c4 in trafficserver's branch
refs/heads/master from [~amc]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8d7d25d ]
TS-2564 Revert field token ordering.
> 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=, detach_all_dups=false) at MIME.cc:469
> #1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=,
> detach_all_dups=false) at MIME.cc:1538
> #2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= 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] [Resolved] (TS-2664) atscppapi: remove initializable value code
[ https://issues.apache.org/jira/browse/TS-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon resolved TS-2664. -- Resolution: Fixed Fix Version/s: 5.0.0 > atscppapi: remove initializable value code > -- > > Key: TS-2664 > URL: https://issues.apache.org/jira/browse/TS-2664 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.0.0 > > > The initialization value concept was adding to add a layer of caching to > improve performance in the C++ api. This has proven to add more complications > than benefits, so let's just get it removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2664) atscppapi: remove initializable value code
[ https://issues.apache.org/jira/browse/TS-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947340#comment-13947340 ] ASF subversion and git services commented on TS-2664: - Commit 53431324ddc54ede890d3a7274648057b6cabfaf in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5343132 ] [TS-2664] Removing initializable value files > atscppapi: remove initializable value code > -- > > Key: TS-2664 > URL: https://issues.apache.org/jira/browse/TS-2664 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Brian Geffon >Assignee: Brian Geffon > > The initialization value concept was adding to add a layer of caching to > improve performance in the C++ api. This has proven to add more complications > than benefits, so let's just get it removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2664) atscppapi: remove initializable value code
[ https://issues.apache.org/jira/browse/TS-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947342#comment-13947342 ] ASF subversion and git services commented on TS-2664: - Commit 265ece127796842398ee3a00a26c1ff0761a6af4 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=265ece1 ] [TS-2664] atscppapi: Removing initializable value code > atscppapi: remove initializable value code > -- > > Key: TS-2664 > URL: https://issues.apache.org/jira/browse/TS-2664 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Brian Geffon >Assignee: Brian Geffon > > The initialization value concept was adding to add a layer of caching to > improve performance in the C++ api. This has proven to add more complications > than benefits, so let's just get it removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2664) atscppapi: remove initializable value code
[ https://issues.apache.org/jira/browse/TS-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947341#comment-13947341 ] ASF subversion and git services commented on TS-2664: - Commit 5622e8d43467a08fc03b921024b8c6a80851cd85 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5622e8d ] [TS-2664] Removing initializable value code > atscppapi: remove initializable value code > -- > > Key: TS-2664 > URL: https://issues.apache.org/jira/browse/TS-2664 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Brian Geffon >Assignee: Brian Geffon > > The initialization value concept was adding to add a layer of caching to > improve performance in the C++ api. This has proven to add more complications > than benefits, so let's just get it removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2253) PluginVC::process_close Segmentation fault
[ https://issues.apache.org/jira/browse/TS-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947267#comment-13947267 ] Bryan Call commented on TS-2253: There is a team here that was running into the same problem. We tried the TS-2253.wj.diff patch and that didn't work. The ts-2253.patch seems to have fixed the issue. A longer test will be done and I will comment on the results. > PluginVC::process_close Segmentation fault > --- > > Key: TS-2253 > URL: https://issues.apache.org/jira/browse/TS-2253 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 4.0.1 >Reporter: bettydramit >Assignee: weijin > Labels: crash, review > Fix For: 5.0.0 > > Attachments: 4.0.1.patch, TS-2253.wj.diff > > > Env: centos 6 x86_64 ats 4.0.1 > [E. Mgmt] log ==> [TrafficManager] using root directory '/usr' > [TrafficServer] using root directory '/usr' > NOTE: Traffic Server received Sig 11: Segmentation fault > /usr/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0xf500)[0x2b7b3a8a3500] > [0x2b7b3e825ac0] > gdb info > Reading symbols from /lib64/libnss_dns-2.12.so...Reading symbols from > /usr/lib/debug/lib64/libnss_dns-2.12.so.debug...done. > done. > Loaded symbols for /lib64/libnss_dns-2.12.so > Core was generated by `/usr/bin/traffic_server -M --httpport 80:fd=7'. > Program terminated with signal 11, Segmentation fault. > #0 0x2ac40034ed80 in ?? () > Missing separate debuginfos, use: debuginfo-install ts-4.0.1-9.el6.x86_64 > (gdb) where > #0 0x2ac40034ed80 in ?? () > #1 0x004d1ef2 in PluginVC::process_close() () > #2 0x004d2938 in PluginVC::main_handler(int, void*) () > #3 0x006a372f in EThread::process_event(Event*, int) () > #4 0x006a42ab in EThread::execute() () > #5 0x004c59b4 in main () -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2657) Eliminate TSHttpTxnSetHttpRetBody() and improve upon TSHttpTxnErrorBodySet()
[ https://issues.apache.org/jira/browse/TS-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2657: -- Labels: api-change (was: ) > Eliminate TSHttpTxnSetHttpRetBody() and improve upon TSHttpTxnErrorBodySet() > > > Key: TS-2657 > URL: https://issues.apache.org/jira/browse/TS-2657 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Labels: api-change > Fix For: 5.0.0 > > Attachments: TS-2657.diff > > > We currently have two APIs to set an “error” body. One was added at Yahoo > many years ago, and it was done for the wrong reasons (premature optimization > being one of them). I’ve made a patch that unifies these two APIs into one, > such that you can use TSHttpTxnErrorBodySet() anywhere you could use either > of those other two APIs. There are some subtle changes in how the APIs work, > which I’ll describe here. > 1. First, both TSHttpTxnSetHttpRetBody() and TSHttpTxnGetMaxHttpRetBodySize() > are removed. I’ve patched all “core” plugins to use the > TSHttpTxnErrorBodySet() API, but any non-Apache plugin would break. Hence, > this change is going in for v5.0.0, which allows breaking compatibility. > 2. More importantly, TSHttpTxnErrorBodySet() requires for the body to be heap > allocated, whereas TSHttpTxnSetHttpRetBody() used a fixed size (2KB) array on > the HttpSM. This was the primary reason why I started looking into this, > since this “simple” change reduces the size of the HttpSM by 25%. > 3. In order to make the TSHttpTxnErrorBodySet() API easier to use, I’ve > changed the content type argument to not transfer ownership. The common > (well, exclusive) pattern using this API used to be > TSHttpTxnErrorBodySet(txnp, body, body_len, TSstrdup(“plain/html”)); > This just seems like an overly generalized case, for a problem that doesn’t > exist (clearly we can all manage some static strings ;). The new API is > simply: > TSHttpTxnErrorBodySet(txnp, body, body_len, “plain/html”); > 4. The TSHttpTxnErrorBodySet() also imposes the body to be sent through the > body factory, for log field expansion. For starters, this is incredibly > inefficient , as well as imposing an 8KB size limit. This is something I > intend to ameliorate soon by improvements to the body factory. However, this > is an unnecessary inefficiency IMO; As part of the body factory improvements, > I also plan on exposing the body factory “log field” expansion as a generic > API. This would allow any plugin to decide if they want to go through the > pains of body factory expansions or not (and not limited to just error pages, > e.g. Header Rewrite would use this new API). > So, I’d like to open this up for discussions and concerns. I think 3) and 4) > are the primary candidates for concerns and objections. I’m willing to > compromise either or both if there are major concerns (for example, is it > worth the “cost” of changing the API in 3) ? I think it is, but I can easily > be persuaded otherwise). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2664) atscppapi: remove initializable value code
Brian Geffon created TS-2664: Summary: atscppapi: remove initializable value code Key: TS-2664 URL: https://issues.apache.org/jira/browse/TS-2664 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Brian Geffon The initialization value concept was adding to add a layer of caching to improve performance in the C++ api. This has proven to add more complications than benefits, so let's just get it removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2664) atscppapi: remove initializable value code
[ https://issues.apache.org/jira/browse/TS-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-2664: Assignee: Brian Geffon > atscppapi: remove initializable value code > -- > > Key: TS-2664 > URL: https://issues.apache.org/jira/browse/TS-2664 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Brian Geffon >Assignee: Brian Geffon > > The initialization value concept was adding to add a layer of caching to > improve performance in the C++ api. This has proven to add more complications > than benefits, so let's just get it removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2660) rename state machine action values
[
https://issues.apache.org/jira/browse/TS-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947046#comment-13947046
]
ASF subversion and git services commented on TS-2660:
-
Commit 70599abf90c5f67d9d6c4e320cba3289f1b3df5e in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=70599ab ]
TS-2660: rename StateMachineAction_t values with a consistent prefix
- All values are named SM_ACTION_XXX
- Redundant works, like HTTP and PROXY are removed.
- Where common tokens are use, these are grouped to the left, as
in SM_ACTION_DNS and SM_ACTION_CACHE.
- Removes unused actions SEND_QUERY_TO_INCOMING_ROUTER and
EXTENSION_METHOD_TUNNEL.
- Remove unused state HTTP_POST_REMAP_UPGRADE.
> rename state machine action values
> --
>
> Key: TS-2660
> URL: https://issues.apache.org/jira/browse/TS-2660
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Labels: Review
> Fix For: 5.0.0
>
>
> The values of {{StateMachineAction_t}} do not adhere to any naming
> convention, making them hard to recognize and find in code. We should apply a
> naming convention and remove unused values.
> The patch I have ends up with this set of values:
> {code}
> SM_ACTION_UNDEFINED = 0,
> // SM_ACTION_AUTH_LOOKUP,
> SM_ACTION_DNS_LOOKUP,
> SM_ACTION_DNS_REVERSE_LOOKUP,
> SM_ACTION_CACHE_LOOKUP,
> SM_ACTION_CACHE_ISSUE_WRITE,
> SM_ACTION_CACHE_ISSUE_WRITE_TRANSFORM,
> SM_ACTION_CACHE_PREPARE_UPDATE,
> SM_ACTION_CACHE_ISSUE_UPDATE,
> SM_ACTION_ICP_QUERY,
> SM_ACTION_ORIGIN_SERVER_OPEN,
> SM_ACTION_ORIGIN_SERVER_RAW_OPEN,
> SM_ACTION_ORIGIN_SERVER_RR_MARK_DOWN,
> SM_ACTION_READ_PUSH_HDR,
> SM_ACTION_STORE_PUSH_BODY,
> SM_ACTION_INTERNAL_CACHE_DELETE,
> SM_ACTION_INTERNAL_CACHE_NOOP,
> SM_ACTION_INTERNAL_CACHE_UPDATE_HEADERS,
> SM_ACTION_INTERNAL_CACHE_WRITE,
> SM_ACTION_INTERNAL_100_RESPONSE,
> SM_ACTION_INTERNAL_REQUEST,
> SM_ACTION_SEND_ERROR_CACHE_NOOP,
> #ifdef PROXY_DRAIN
> SM_ACTION_DRAIN_REQUEST_BODY,
> #endif /* PROXY_DRAIN */
> SM_ACTION_SERVE_FROM_CACHE,
> SM_ACTION_SERVER_READ,
> SM_ACTION_SERVER_PARSE_NEXT_HDR,
> SM_ACTION_TRANSFORM_READ,
> SM_ACTION_SSL_TUNNEL,
> SM_ACTION_CONTINUE,
> SM_ACTION_API_SM_START,
> SM_ACTION_API_READ_REQUEST_HDR,
> SM_ACTION_API_PRE_REMAP,
> SM_ACTION_API_POST_REMAP,
> SM_ACTION_API_OS_DNS,
> SM_ACTION_API_SEND_REQUEST_HDR,
> SM_ACTION_API_READ_CACHE_HDR,
> SM_ACTION_API_CACHE_LOOKUP_COMPLETE,
> SM_ACTION_API_READ_RESPONSE_HDR,
> SM_ACTION_API_SEND_RESPONSE_HDR,
> SM_ACTION_API_SM_SHUTDOWN,
> SM_ACTION_REMAP_REQUEST,
> SM_ACTION_POST_REMAP_SKIP,
> SM_ACTION_REDIRECT_READ
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2663) [HttpTransactHeaders.cc:622]: (style) Same expression on both sides of '||'.
David Binderman created TS-2663:
---
Summary: [HttpTransactHeaders.cc:622]: (style) Same expression on
both sides of '||'.
Key: TS-2663
URL: https://issues.apache.org/jira/browse/TS-2663
Project: Traffic Server
Issue Type: Bug
Reporter: David Binderman
Source code is
if (log_code == SQUID_LOG_TCP_MISS || log_code == SQUID_LOG_TCP_MISS) {
Judging by code a few lines further down, maybe the following
code was intended
if (log_code == SQUID_LOG_TCP_MISS || log_code == SQUID_LOG_TCP_IMS_MISS) {
I found this possible problem by using cppcheck, a static analysis checker.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946956#comment-13946956 ] ASF GitHub Bot commented on TS-2497: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/66 > Failed post results in tunnel buffers being returned to freelist prematurely > > > Key: TS-2497 > URL: https://issues.apache.org/jira/browse/TS-2497 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 4.1.3, 4.2.0 > > > When a post fails to an origin server either the server died or the server > returned a response without reading all of the post data, in either case, TS > will destroy buffers too early. This normally does not result in a crash > because the MIOBuffers are returned to the freelist and only with sufficient > load will the race happen causing a crash. Additionally, even if a crash > doesn't happen you might have data corruption across post requests from the > buffers being used after being returned to the freelist. > Thanks to Thomas Jackson for help reproducing and resolving this bug. > An example stack trace, while we've seen other crashes in write_avail too. > #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at > ../iocore/eventsystem/I_IOBuffer.h:362 > #1 0x0050d151 in MIOBuffer::append_block_internal > (this=0x2aab38001130, b=0x2aab0c037200) at > ../iocore/eventsystem/P_IOBuffer.h:946 > #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, > asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986 > #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:994 > #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:1002 > #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:1048 > #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208, > vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234 > #7 0x006c37bf in UnixNetVConnection::net_read_io > (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at > UnixNetVConnection.cc:816 > #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, > event=5, e=0x271d8e0) at UnixNet.cc:380 > #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, > event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146 > #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, > e=0x271d8e0, calling_code=5) at UnixEThread.cc:142 > #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at > UnixEThread.cc:264 > #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88 > #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0 > #14 0x0033728e68ed in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2662) Re-enable KEEP_ALIVE_POST_OUT by default
[ https://issues.apache.org/jira/browse/TS-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon resolved TS-2662. -- Resolution: Fixed Fix Version/s: 5.0.0 Assignee: Brian Geffon > Re-enable KEEP_ALIVE_POST_OUT by default > > > Key: TS-2662 > URL: https://issues.apache.org/jira/browse/TS-2662 > Project: Traffic Server > Issue Type: Task > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.0.0 > > > The reason this was disabled in the first place was because of a bug > (TS-2497) now that this has been fixed this can be re-enabled by default. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2662) Re-enable KEEP_ALIVE_POST_OUT by default
[ https://issues.apache.org/jira/browse/TS-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946857#comment-13946857 ] ASF subversion and git services commented on TS-2662: - Commit 7b82da6d48e42989426546be0b1ead0b05f1141d in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7b82da6 ] [TS-2662] Re-enable KEEP_ALIVE_POST_OUT by default. > Re-enable KEEP_ALIVE_POST_OUT by default > > > Key: TS-2662 > URL: https://issues.apache.org/jira/browse/TS-2662 > Project: Traffic Server > Issue Type: Task > Components: Core >Reporter: Brian Geffon > > The reason this was disabled in the first place was because of a bug > (TS-2497) now that this has been fixed this can be re-enabled by default. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2662) Re-enable KEEP_ALIVE_POST_OUT by default
[ https://issues.apache.org/jira/browse/TS-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946856#comment-13946856 ] ASF subversion and git services commented on TS-2662: - Commit f6a1cd7c3e04fa5e680a1731c1cb83c5ccaf5d23 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f6a1cd7 ] [TS-2662] Re-enable KEEP_ALIVE_POST_OUT by default. This closes #66 > Re-enable KEEP_ALIVE_POST_OUT by default > > > Key: TS-2662 > URL: https://issues.apache.org/jira/browse/TS-2662 > Project: Traffic Server > Issue Type: Task > Components: Core >Reporter: Brian Geffon > > The reason this was disabled in the first place was because of a bug > (TS-2497) now that this has been fixed this can be re-enabled by default. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2662) Re-enable KEEP_ALIVE_POST_OUT by default
Brian Geffon created TS-2662: Summary: Re-enable KEEP_ALIVE_POST_OUT by default Key: TS-2662 URL: https://issues.apache.org/jira/browse/TS-2662 Project: Traffic Server Issue Type: Task Components: Core Reporter: Brian Geffon The reason this was disabled in the first place was because of a bug (TS-2497) now that this has been fixed this can be re-enabled by default. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2661) Remove unused HttpSM method.
[ https://issues.apache.org/jira/browse/TS-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-2661. - Resolution: Fixed > Remove unused HttpSM method. > > > Key: TS-2661 > URL: https://issues.apache.org/jira/browse/TS-2661 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > > HttpSM::decide_cached_url is not used. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2661) Remove unused HttpSM method.
[ https://issues.apache.org/jira/browse/TS-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946735#comment-13946735 ] ASF subversion and git services commented on TS-2661: - Commit 059b9c8453073f7f8d9eaa529f9d803fd093c056 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=059b9c8 ] TS-2661: Remove unused HttpSM::decide_cached_url method. > Remove unused HttpSM method. > > > Key: TS-2661 > URL: https://issues.apache.org/jira/browse/TS-2661 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > > HttpSM::decide_cached_url is not used. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2661) Remove unused HttpSM method.
Alan M. Carroll created TS-2661: --- Summary: Remove unused HttpSM method. Key: TS-2661 URL: https://issues.apache.org/jira/browse/TS-2661 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: Alan M. Carroll HttpSM::decide_cached_url is not used. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2661) Remove unused HttpSM method.
[ https://issues.apache.org/jira/browse/TS-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-2661: --- Assignee: Alan M. Carroll > Remove unused HttpSM method. > > > Key: TS-2661 > URL: https://issues.apache.org/jira/browse/TS-2661 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > > HttpSM::decide_cached_url is not used. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2650) Support relative url in the location header in 302 redirection
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946622#comment-13946622 ] Leif Hedstrom commented on TS-2650: --- Ah, I thought you were referring to another bug. No, I think it's fine to do this in one Jira / patch. > Support relative url in the location header in 302 redirection > --- > > Key: TS-2650 > URL: https://issues.apache.org/jira/browse/TS-2650 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Fix For: 5.0.0 > > Attachments: ts2650.diff > > > Currently, if ATS receives a relative url path (with either the host or the > scheme missing) in the location header in the 302 redirect request, it > returns a "400 Host Header Required" error. This enhancement is to try the > redirection with the current origin connection's host/scheme when that > happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946607#comment-13946607
]
Yunkai Zhang commented on TS-2636:
--
How about SHADOW? In Linux, {{shadow}} is well known command used to encrypt
password:)
> Enhance ATS custom logging to support WIPE filter action
>
>
> Key: TS-2636
> URL: https://issues.apache.org/jira/browse/TS-2636
> Project: Traffic Server
> Issue Type: New Feature
> Components: Logging
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
> Labels: Review
> Fix For: 5.0.0
>
> Attachments: ts2636.diff
>
>
> Currently, ATS custom logging supports LogFilters with actions Accept,
> Reject. This feature request is to add a new filter action "WIPE". WIPE can
> be used in hiding sensitive parameters (e.g. userid, password) within the
> query part of a URL. Attached is a draft version of the patch. Kindly review
> and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946659#comment-13946659 ] Yunkai Zhang commented on TS-2636: -- Hi [~sudheerv]: With LogFilter, the code needs to compare all fields in LogFormat: 1) to check if the field satisfy the , 2) if Yes, to do WIPE. It'll slow down each HTTP response, especially when the number of filters become larger. But with field-function, the WIPE action will only affect certain fields that surrounding with % function in LogFormat. I can image that to implement a field-function would be more easier than adding a new filter-action(with few codes), so don't worry, just try it:) I'm pleasure to give you help if you need. > Enhance ATS custom logging to support WIPE filter action > > > Key: TS-2636 > URL: https://issues.apache.org/jira/browse/TS-2636 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Reporter: Sudheer Vinukonda >Assignee: Yunkai Zhang > Labels: Review > Fix For: 5.0.0 > > Attachments: ts2636.diff > > > Currently, ATS custom logging supports LogFilters with actions Accept, > Reject. This feature request is to add a new filter action "WIPE". WIPE can > be used in hiding sensitive parameters (e.g. userid, password) within the > query part of a URL. Attached is a draft version of the patch. Kindly review > and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2528) better bool handling in public APIs (ts / mgmt)
[
https://issues.apache.org/jira/browse/TS-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2528:
--
Summary: better bool handling in public APIs (ts / mgmt) (was: better bool
handling in mgmtapi.h)
> better bool handling in public APIs (ts / mgmt)
> ---
>
> Key: TS-2528
> URL: https://issues.apache.org/jira/browse/TS-2528
> Project: Traffic Server
> Issue Type: Bug
> Components: Management API
>Reporter: Zhao Yongming
> Labels: api-change
> Fix For: 5.0.0
>
>
> {code}
> tsapi bool TSListIsEmpty(TSList l);
> tsapi bool TSListIsValid(TSList l);
> tsapi bool TSIpAddrListIsEmpty(TSIpAddrList ip_addrl);
> tsapi bool TSIpAddrListIsValid(TSIpAddrList ip_addrl);
> tsapi bool TSPortListIsEmpty(TSPortList portl);
> tsapi bool TSPortListIsValid(TSPortList portl);
> tsapi bool TSStringListIsEmpty(TSStringList strl);
> tsapi bool TSStringListIsValid(TSStringList strl);
> tsapi bool TSIntListIsEmpty(TSIntList intl);
> tsapi bool TSIntListIsValid(TSIntList intl, int min, int max);
> tsapi bool TSDomainListIsEmpty(TSDomainList domainl);
> tsapi bool TSDomainListIsValid(TSDomainList domainl);
> tsapi TSError TSRestart(bool cluster);
> tsapi TSError TSBounce(bool cluster);
> tsapi TSError TSStatsReset(bool cluster, const char *name = NULL);
> tsapi TSError TSEventIsActive(char *event_name, bool * is_current);
> {code}
> and we have:
> {code}
> #if !defined(linux)
> #if defined (__SUNPRO_CC) || (defined (__GNUC__) || ! defined(__cplusplus))
> #if !defined (bool)
> #if !defined(darwin) && !defined(freebsd) && !defined(solaris)
> // XXX: What other platforms are there?
> #define bool int
> #endif
> #endif
> #if !defined (true)
> #define true 1
> #endif
> #if !defined (false)
> #define false 0
> #endif
> #endif
> #endif // not linux
> {code}
> I'd like we can make it a typedef or replace bool with int completely, to
> make things better to be parsed by SWIG tools etc.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946607#comment-13946607
]
Yunkai Zhang edited comment on TS-2636 at 3/25/14 2:32 PM:
---
How about SHADOW? In Linux, {{/etc/shadow}} is well known file used to contain
encrypted user account:)
was (Author: yunkai):
How about SHADOW? In Linux, {{shadow}} is well known command used to encrypt
password:)
> Enhance ATS custom logging to support WIPE filter action
>
>
> Key: TS-2636
> URL: https://issues.apache.org/jira/browse/TS-2636
> Project: Traffic Server
> Issue Type: New Feature
> Components: Logging
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
> Labels: Review
> Fix For: 5.0.0
>
> Attachments: ts2636.diff
>
>
> Currently, ATS custom logging supports LogFilters with actions Accept,
> Reject. This feature request is to add a new filter action "WIPE". WIPE can
> be used in hiding sensitive parameters (e.g. userid, password) within the
> query part of a URL. Attached is a draft version of the patch. Kindly review
> and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946624#comment-13946624 ] Sudheer Vinukonda commented on TS-2636: --- Thanks guys, but, would like to make a few points for your consideration: 1. The reason behind using the LogFilter for WIPE/clean/anon/shadow action is to reuse the existing framework as much as possible (this makes the implementation much simpler). 2. It is true that the WIPE action is applicable the most to URL fields, but, I am wondering if there's anything preventing for it to be more generic. Like Yunkai Zhang suggested, I should have also uploaded the logs_xml.config.default with examples on the intended usage of the WIPE param. Will do so shortly. But, in the meantime, below is one example: CONTAIN hpt"/> So, the WIPE param is specified as a CONDITION along with the field in which the WIPE is required. With this approach, % can be easily replaced with any other possible field. I do like the suggestion from Yunkai Zhang to use a field-function, but, I am wondering if it isn't just a different representation of the same behavior outlined with the Filter in the above example. Please let me know your opinion. Thank you! > Enhance ATS custom logging to support WIPE filter action > > > Key: TS-2636 > URL: https://issues.apache.org/jira/browse/TS-2636 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Reporter: Sudheer Vinukonda >Assignee: Yunkai Zhang > Labels: Review > Fix For: 5.0.0 > > Attachments: ts2636.diff > > > Currently, ATS custom logging supports LogFilters with actions Accept, > Reject. This feature request is to add a new filter action "WIPE". WIPE can > be used in hiding sensitive parameters (e.g. userid, password) within the > query part of a URL. Attached is a draft version of the patch. Kindly review > and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[ https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946587#comment-13946587 ] Leif Hedstrom commented on TS-2636: --- That seems good. Not sure I like the tag-name WIPE, but it's not that important. But maybe something more descriptive such as CLEAN or ANON or some such ? James is usually good at coming up with descriptive names. > Enhance ATS custom logging to support WIPE filter action > > > Key: TS-2636 > URL: https://issues.apache.org/jira/browse/TS-2636 > Project: Traffic Server > Issue Type: New Feature > Components: Logging >Reporter: Sudheer Vinukonda >Assignee: Yunkai Zhang > Labels: Review > Fix For: 5.0.0 > > Attachments: ts2636.diff > > > Currently, ATS custom logging supports LogFilters with actions Accept, > Reject. This feature request is to add a new filter action "WIPE". WIPE can > be used in hiding sensitive parameters (e.g. userid, password) within the > query part of a URL. Attached is a draft version of the patch. Kindly review > and comment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2636) Enhance ATS custom logging to support WIPE filter action
[
https://issues.apache.org/jira/browse/TS-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946133#comment-13946133
]
Yunkai Zhang edited comment on TS-2636 at 3/25/14 2:26 PM:
---
Hi [~sudheerv], [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since "WIPE" action only applys URL fields(eg. %), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new field-function(somewhat like aggregated
function): {{%}}
{code}
% // WIPE "token" parameter
% // WIPE "token"/"userid"/... parameters.
{code}
With this field-function, it's will be more efficient -- it will be only
executed on certain fields.
was (Author: yunkai):
Hi [~sudheerv] [~zwoop]:
With more deep thought, inspired by Leif, I got a better solution:
Since "WIPE" action only applys URL fileds(eg. %), strictly speaking,
it's not a *generic* filter ACTION, but a *special* filter FUNCTION that applys
certain fields. So, why not just create a new function to achieve this purpose?
For example, we can add a new filed-function(somewhat like aggregated
function): {{%}}
{code}
% // WIPE "token" parameter
% // WIPE "token"/"userid"/... parameters.
{code}
With this filed-function, it's will be more efficient -- it will be only
executed on certain fields.
> Enhance ATS custom logging to support WIPE filter action
>
>
> Key: TS-2636
> URL: https://issues.apache.org/jira/browse/TS-2636
> Project: Traffic Server
> Issue Type: New Feature
> Components: Logging
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
> Labels: Review
> Fix For: 5.0.0
>
> Attachments: ts2636.diff
>
>
> Currently, ATS custom logging supports LogFilters with actions Accept,
> Reject. This feature request is to add a new filter action "WIPE". WIPE can
> be used in hiding sensitive parameters (e.g. userid, password) within the
> query part of a URL. Attached is a draft version of the patch. Kindly review
> and comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
