[jira] [Commented] (TS-2555) Move existing lua plugin to plugins/deprecated and rename ts_lua to lua
[ https://issues.apache.org/jira/browse/TS-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13970545#comment-13970545 ] ASF subversion and git services commented on TS-2555: - Commit 01be17ecd6ec47b493366feb755db9998bb9146e in trafficserver's branch refs/heads/master from [~kichan] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=01be17e ] TS-2555 adding example and documentation > Move existing lua plugin to plugins/deprecated and rename ts_lua to lua > --- > > Key: TS-2555 > URL: https://issues.apache.org/jira/browse/TS-2555 > Project: Traffic Server > Issue Type: Task > Components: Plugins >Reporter: Kit Chan >Assignee: Kit Chan > Fix For: 5.0.0 > > > As suggested by Igor Galic in TS-2335, "to avoid namespace pollution, we > could move move the old Lua plugin to plugins/deprecated, and name this one > lua again from the start. From what I gather, the consensus on the mailing > list was to replace the old plugin with this one. > Given that the old plugin was experimental, and we've decided that all bets > regarding compatibility and stability are off in experimental, I'm fairly > certain we can just do that. I'd move it, for easy reference into > plugins/deprecated, remove it from the build, and once the new plugin has > absorbed all of its features, remove it all together." -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2721) atscppapi: add support for CACHE_LOOKUP_COMPLETE hook
Kit Chan created TS-2721: Summary: atscppapi: add support for CACHE_LOOKUP_COMPLETE hook Key: TS-2721 URL: https://issues.apache.org/jira/browse/TS-2721 Project: Traffic Server Issue Type: Wish Components: TS API Reporter: Kit Chan I would like to see support for CACHE_LOOKUP_COMPLETE hook getting added to atscppapi. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2722) Authproxy: incorrect use of TSHttpConnect by passing destination ip as parameter
Kit Chan created TS-2722: Summary: Authproxy: incorrect use of TSHttpConnect by passing destination ip as parameter Key: TS-2722 URL: https://issues.apache.org/jira/browse/TS-2722 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Kit Chan We have previously discussed this in email thread with james. It seems the authproxy plugin is calling TSHttpConnect and passes the destination ip as parameter to this api instead of the connecting ip. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kit Chan reassigned TS-2723: Assignee: Kit Chan > Add new features for ts_lua. > > > Key: TS-2723 > URL: https://issues.apache.org/jira/browse/TS-2723 > Project: Traffic Server > Issue Type: Bug > Components: Lua, Plugins >Reporter: portl4t >Assignee: Kit Chan > > After TS-2555, Kit Chan and me will integrate new features from > https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2723) Add new features for ts_lua.
portl4t created TS-2723: --- Summary: Add new features for ts_lua. Key: TS-2723 URL: https://issues.apache.org/jira/browse/TS-2723 Project: Traffic Server Issue Type: Bug Components: Lua, Plugins Reporter: portl4t After TS-2555, Kit Chan and me will integrate new features from https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2723) Add new features for ts_lua.
[ https://issues.apache.org/jira/browse/TS-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13970606#comment-13970606 ] portl4t commented on TS-2723: - I will provide a patch next week. > Add new features for ts_lua. > > > Key: TS-2723 > URL: https://issues.apache.org/jira/browse/TS-2723 > Project: Traffic Server > Issue Type: Bug > Components: Lua, Plugins >Reporter: portl4t >Assignee: Kit Chan > > After TS-2555, Kit Chan and me will integrate new features from > https://github.com/portl4t/ts-lua into plugins/experimental/ts_lua. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2110) Cleanup ts/experimental.h
[ https://issues.apache.org/jira/browse/TS-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2110: -- Assignee: Kit Chan (was: Leif Hedstrom) > Cleanup ts/experimental.h > - > > Key: TS-2110 > URL: https://issues.apache.org/jira/browse/TS-2110 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Kit Chan > Labels: api-change > Fix For: 5.0.0 > > > We should go through the APIs in experimental.h, and do one of > 1. Remove > 2. Move to ts/ts.h.in > 3. Leave as is, assuming it's still considered experimental. > I know there are arguments for and against having an experimental.h include > file. I guess I don't have a strong opinion, another solution is to simply > keep everything in ts.h.in, but mark APIs that are experimental as such. I do > believe having APIs in an "experimental" state has benefits (such as we can > modify such APIs as we see fit, there is no ABI/API compatibility promise). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2716) Fix indentation for ts_lua plugin
[ https://issues.apache.org/jira/browse/TS-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2716: -- Assignee: Kit Chan (was: Leif Hedstrom) > Fix indentation for ts_lua plugin > - > > Key: TS-2716 > URL: https://issues.apache.org/jira/browse/TS-2716 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Kit Chan > Fix For: 5.0.0 > > > We should run all the C code through our normal "indent" command, to get the > code to align with our standards. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2120) stale_while_revalidate plugin does not build right now
[
https://issues.apache.org/jira/browse/TS-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2120:
--
Assignee: Kit Chan (was: Phil Sorber)
> stale_while_revalidate plugin does not build right now
> --
>
> Key: TS-2120
> URL: https://issues.apache.org/jira/browse/TS-2120
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Igor Galić
>Assignee: Kit Chan
> Fix For: 5.0.0
>
>
> but considering that it's still using the old {{INK*}} API, oh, well...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2604) Collapsed connection plugin
[ https://issues.apache.org/jira/browse/TS-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971547#comment-13971547 ] Leif Hedstrom commented on TS-2604: --- Bryan, lets get this in for v5.0.0, in experimental. > Collapsed connection plugin > --- > > Key: TS-2604 > URL: https://issues.apache.org/jira/browse/TS-2604 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Ethan Lai >Assignee: Bryan Call > Labels: review > Fix For: 5.0.0 > > > This plugin collapses connections with identical CacheUrl/EffectiveUrl. > Please find more detail from README and state.png (State Diagram) -- This message was sent by Atlassian JIRA (v6.2#6252)
[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-tabpanel&focusedCommentId=13971670#comment-13971670
]
Bryan Call commented on TS-1125:
[~ffcai],
Can you explain why the VC_EVENT_WRITE_COMPLETE event action had to change.
Section of the patch:
{code}
case VC_EVENT_WRITE_COMPLETE:
-// mark the vc as no longer in tunnel
-// so we don't get hosed if the ua abort before
-// real response header is received
-ua_entry->in_tunnel = false;
+if (t_state.txn_conf->send_100_continue_response == 0) {
+ // mark the vc as no longer in tunnel
+ // so we don't get hosed if the ua abort before
+ // real response header is received
+ ua_entry->in_tunnel = false;
+}
c->write_success = true;
{code}
> 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
> Labels: yahoo
> Fix For: 5.2.0
>
> Attachments: TS-1125.diff
>
>
> Sending a post like:
> POST / HTTP/1.1
> Host: www.example.com
> Content-Length: 10
> Expect: 100-continue
> directly to the web server immediately sends back:
> HTTP/1.1 100 Continue
> And then when the post data is sent, a status 200 response comes back.
> But when going through ATS the "HTTP/1.1 100 Continue" is not sent
> immediately, and instead is sent after the POST data has been received. This
> is legal, but it makes clients that are hoping for a 100 continue to wait a
> little while hoping to get that, ATS should forward that response through
> immediately.
> Note: I see curl using "Expect: 100-continue" with > 1024 bytes of post data,
> but web searching indicates that some Microsoft products also use it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2650) Redirect handling enhancements in ATS
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2650: --- Labels: review yahoo (was: review) > Redirect handling enhancements in ATS > - > > 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 > Labels: review, yahoo > Fix For: 5.0.0 > > Attachments: ts2650.diff > > > This Jira attempts to enhance/fix multiple issues found with ATS's support > for redirect follow. Below is a summary of issues: > 1. Support relative path in the location header in the 301/302/303 response. > Description: 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. > 2. Strip off default ports from Host header during redirect follow. > Description: ATS includes port in the host header as host:port during > redirect follow. It has been observed that some origins choke (and return 4xx > error) when the default port (80/http, 443/https) is included within the host > header. This enhancement is to strip off the default port (80/http, > 443/https) from the host header during redirect follow. This behavior is > controlled via a configuration parameter > "proxy.config.http.redirect_host_no_port". When enabled, ATS will strip off > the default port from the host header during redirect follow. Note that the > default setting for proxy.config.http.redirect_host_no_port is disabled, > which means, ATS will continue to include the port in the host header. > 3. Force DNS lookup during redirect follow > Description: It has been observed that, ATS doesn't perform a DNS lookup > during redirect follow. This may work when the host is unchanged during > redirect follow, but, will fail if the host is changed. This fix forces dns > lookup (either by way of hostdb lookup or an altogether new dns lookup) > during redirect follow > 4. Handle null path correctly during redirect follow > Description: It has been observed that, if a subsequent redirect follow > includes null path (e.g. /), ATS incorrectly uses the path received during a > previous redirect request. This fix resets the path during each redirect to > ensure that the path is correctly set to the newly received value. > 5. Cache not working during redirect > Description: It has been observed that ATS is not writing to cache the final > response at the end of a successful 3xx redirect follow. This fix is to force > ATS write to cache a valid non-3xx response received at the end of a redirect > follow. > 6. Support 303 status code to trigger redirect follow > Description: Currently, ATS supports only 301/302 based redirect follow. This > enhancement is to also handle 303 based redirect follow. Note that, in terms > of the response and redirect follow handling, 303 handling is identical to > 301/302, except for the status code. > 7. SEND_RESPONSE_HDR_HOOK plugin breaks redirect follow: > Description: Currently, when a plugin enables SEND_RESPONSE_HDR_HOOK, ATS has > a bug that breaks redirect handling. This fix is to allow redirect handling > to be completed (unto the configured max number of attempts) before invoking > the plugin with SEND_RESPONSE_HDR_HOOK. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (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:all-tabpanel ] Bryan Call updated TS-1125: --- Fix Version/s: (was: 5.2.0) 5.0.0 > 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 > Labels: yahoo > Fix For: 5.0.0 > > Attachments: TS-1125.diff > > > Sending a post like: > POST / HTTP/1.1 > Host: www.example.com > Content-Length: 10 > Expect: 100-continue > directly to the web server immediately sends back: > HTTP/1.1 100 Continue > And then when the post data is sent, a status 200 response comes back. > But when going through ATS the "HTTP/1.1 100 Continue" is not sent > immediately, and instead is sent after the POST data has been received. This > is legal, but it makes clients that are hoping for a 100 continue to wait a > little while hoping to get that, ATS should forward that response through > immediately. > Note: I see curl using "Expect: 100-continue" with > 1024 bytes of post data, > but web searching indicates that some Microsoft products also use it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2708) tcp_info plugin should use text logging API
[
https://issues.apache.org/jira/browse/TS-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971709#comment-13971709
]
ASF subversion and git services commented on TS-2708:
-
Commit d461c33e2050905bce86dc1eba59665ee879754b in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d461c33 ]
TS-2708: refactor and modernize the tcp_info plugin
Always build the tcp_info plugin, even if it doesn't end up doing
anything useful on the build platform. This is convenient for
development.
Only sample and log TCP metrics after it passes the sample threshold
to reduce unnecessary work.
Add IPv6 support. Use TS*Assert instead of assert. Remove the Config
global variable. Add a txn_close hook.
Use the text logging API rather than writing custom logs.
> tcp_info plugin should use text logging API
> ---
>
> Key: TS-2708
> URL: https://issues.apache.org/jira/browse/TS-2708
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging, Plugins
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 5.0.0
>
>
> The {{tcp_info}} plugin just writes its logs to a file itself. It should use
> the Traffic Server text logging API so that it gets log rotation for free and
> automatically locates logs in the correct logging directory (there's no API
> to get the Traffic Server log directory otherwise).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2714) promote the tcp_info plugin to stable
[
https://issues.apache.org/jira/browse/TS-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971710#comment-13971710
]
ASF subversion and git services commented on TS-2714:
-
Commit 86453b9930827d69e6647770b4073a74a71312ed in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=86453b9 ]
TS-2714: promote the tcp_info plugin to stable as 'tcpinfo'
> promote the tcp_info plugin to stable
> -
>
> Key: TS-2714
> URL: https://issues.apache.org/jira/browse/TS-2714
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 5.0.0
>
>
> The {{tcp_info}} plugin is trivial. Let's promote it to stable under the name
> {{tcpinfo}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2708) tcp_info plugin should use text logging API
[
https://issues.apache.org/jira/browse/TS-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2708.
-
Resolution: Fixed
> tcp_info plugin should use text logging API
> ---
>
> Key: TS-2708
> URL: https://issues.apache.org/jira/browse/TS-2708
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging, Plugins
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 5.0.0
>
>
> The {{tcp_info}} plugin just writes its logs to a file itself. It should use
> the Traffic Server text logging API so that it gets log rotation for free and
> automatically locates logs in the correct logging directory (there's no API
> to get the Traffic Server log directory otherwise).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2714) promote the tcp_info plugin to stable
[
https://issues.apache.org/jira/browse/TS-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2714.
-
Resolution: Fixed
> promote the tcp_info plugin to stable
> -
>
> Key: TS-2714
> URL: https://issues.apache.org/jira/browse/TS-2714
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 5.0.0
>
>
> The {{tcp_info}} plugin is trivial. Let's promote it to stable under the name
> {{tcpinfo}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2650) Redirect handling enhancements in ATS
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2650: --- Attachment: ts2650.diff Updated the patch: 1. cleaned up the logic for determining if the response will be redirected to another url 2. Fixed indentation (2 spaces) 3. Fixed misspelled words 4. Removed some casting that wasn't necessary if the type was changed to const char* > Redirect handling enhancements in ATS > - > > 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 > Labels: review, yahoo > Fix For: 5.0.0 > > Attachments: ts2650.diff, ts2650.diff > > > This Jira attempts to enhance/fix multiple issues found with ATS's support > for redirect follow. Below is a summary of issues: > 1. Support relative path in the location header in the 301/302/303 response. > Description: 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. > 2. Strip off default ports from Host header during redirect follow. > Description: ATS includes port in the host header as host:port during > redirect follow. It has been observed that some origins choke (and return 4xx > error) when the default port (80/http, 443/https) is included within the host > header. This enhancement is to strip off the default port (80/http, > 443/https) from the host header during redirect follow. This behavior is > controlled via a configuration parameter > "proxy.config.http.redirect_host_no_port". When enabled, ATS will strip off > the default port from the host header during redirect follow. Note that the > default setting for proxy.config.http.redirect_host_no_port is disabled, > which means, ATS will continue to include the port in the host header. > 3. Force DNS lookup during redirect follow > Description: It has been observed that, ATS doesn't perform a DNS lookup > during redirect follow. This may work when the host is unchanged during > redirect follow, but, will fail if the host is changed. This fix forces dns > lookup (either by way of hostdb lookup or an altogether new dns lookup) > during redirect follow > 4. Handle null path correctly during redirect follow > Description: It has been observed that, if a subsequent redirect follow > includes null path (e.g. /), ATS incorrectly uses the path received during a > previous redirect request. This fix resets the path during each redirect to > ensure that the path is correctly set to the newly received value. > 5. Cache not working during redirect > Description: It has been observed that ATS is not writing to cache the final > response at the end of a successful 3xx redirect follow. This fix is to force > ATS write to cache a valid non-3xx response received at the end of a redirect > follow. > 6. Support 303 status code to trigger redirect follow > Description: Currently, ATS supports only 301/302 based redirect follow. This > enhancement is to also handle 303 based redirect follow. Note that, in terms > of the response and redirect follow handling, 303 handling is identical to > 301/302, except for the status code. > 7. SEND_RESPONSE_HDR_HOOK plugin breaks redirect follow: > Description: Currently, when a plugin enables SEND_RESPONSE_HDR_HOOK, ATS has > a bug that breaks redirect handling. This fix is to allow redirect handling > to be completed (unto the configured max number of attempts) before invoking > the plugin with SEND_RESPONSE_HDR_HOOK. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2650) Redirect handling enhancements in ATS
[ https://issues.apache.org/jira/browse/TS-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2650: --- Attachment: ts2650.diff Fix a couple logic errors in is_redirect_required() > Redirect handling enhancements in ATS > - > > 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 > Labels: review, yahoo > Fix For: 5.0.0 > > Attachments: ts2650.diff, ts2650.diff, ts2650.diff > > > This Jira attempts to enhance/fix multiple issues found with ATS's support > for redirect follow. Below is a summary of issues: > 1. Support relative path in the location header in the 301/302/303 response. > Description: 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. > 2. Strip off default ports from Host header during redirect follow. > Description: ATS includes port in the host header as host:port during > redirect follow. It has been observed that some origins choke (and return 4xx > error) when the default port (80/http, 443/https) is included within the host > header. This enhancement is to strip off the default port (80/http, > 443/https) from the host header during redirect follow. This behavior is > controlled via a configuration parameter > "proxy.config.http.redirect_host_no_port". When enabled, ATS will strip off > the default port from the host header during redirect follow. Note that the > default setting for proxy.config.http.redirect_host_no_port is disabled, > which means, ATS will continue to include the port in the host header. > 3. Force DNS lookup during redirect follow > Description: It has been observed that, ATS doesn't perform a DNS lookup > during redirect follow. This may work when the host is unchanged during > redirect follow, but, will fail if the host is changed. This fix forces dns > lookup (either by way of hostdb lookup or an altogether new dns lookup) > during redirect follow > 4. Handle null path correctly during redirect follow > Description: It has been observed that, if a subsequent redirect follow > includes null path (e.g. /), ATS incorrectly uses the path received during a > previous redirect request. This fix resets the path during each redirect to > ensure that the path is correctly set to the newly received value. > 5. Cache not working during redirect > Description: It has been observed that ATS is not writing to cache the final > response at the end of a successful 3xx redirect follow. This fix is to force > ATS write to cache a valid non-3xx response received at the end of a redirect > follow. > 6. Support 303 status code to trigger redirect follow > Description: Currently, ATS supports only 301/302 based redirect follow. This > enhancement is to also handle 303 based redirect follow. Note that, in terms > of the response and redirect follow handling, 303 handling is identical to > 301/302, except for the status code. > 7. SEND_RESPONSE_HDR_HOOK plugin breaks redirect follow: > Description: Currently, when a plugin enables SEND_RESPONSE_HDR_HOOK, ATS has > a bug that breaks redirect handling. This fix is to allow redirect handling > to be completed (unto the configured max number of attempts) before invoking > the plugin with SEND_RESPONSE_HDR_HOOK. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2705) master Crashes frequently
[
https://issues.apache.org/jira/browse/TS-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971848#comment-13971848
]
Alan M. Carroll commented on TS-2705:
-
No, not TS-2564 - the first core dump is misleading.
The underlying problem seems is a setup where the transaction is reading from
cache and tries to do a background fill. It crashes because that assumes an
origin server (e.g. HttpSM::server_entry is valid). It seems to me the current
logic in HttpSM::is_bg_necessary assumes a cache read will only have 1 client
(the user agent) but in this case that is violated (the tunnel is doing a cache
read and write to the same object, but transforming to a different alternate).
I have a patch that changes the logic to explicit check for a valid origin
server rather than assuming it.
> master Crashes frequently
> --
>
> Key: TS-2705
> URL: https://issues.apache.org/jira/browse/TS-2705
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Core, Lua
>Reporter: Faysal Banna
>
> Hi Guys
> I enabled ts_lua plugin and did experiment on my local computer all worked
> fine
> when i moved to the big machine hosting traffic i noticed that the ATS
> crashes most often (each 5 minutes almost ).
> i don't know the cause of it and can not confirm if its from the ts_lua stuff
> plugins enabled are ts_lua, cacheurl, header_rewrite, collapsed_connection
> anyhow here is the code i get in traffic.out
> {code}
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x2b16fe4fcbb0]
> /usr/local/bin/traffic_server(HttpSM::tunnel_handler_ua(int,
> HttpTunnelConsumer*)+0x31d)[0x51b30d]
> /usr/local/bin/traffic_server(HttpTunnel::consumer_handler(int,
> HttpTunnelConsumer*)+0x74)[0x56b704]
> /usr/local/bin/traffic_server(HttpTunnel::main_handler(int,
> void*)+0x108)[0x56d048]
> /usr/local/bin/traffic_server(write_to_net_io(NetHandler*,
> UnixNetVConnection*, EThread*)+0xf67)[0x68c4f7]
> /usr/local/bin/traffic_server(NetHandler::mainNetEvent(int,
> Event*)+0x286)[0x681576]
> /usr/local/bin/traffic_server(EThread::execute()+0x9a3)[0x6af5a3]
> /usr/local/bin/traffic_server[0x6ae19a]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2b16fe4f4f6e]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b16ff2269cd]
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x2ab35816abb0]
> /usr/local/bin/traffic_server(mime_field_value_get(MIMEField*,
> int*)+0x0)[0x5c7fd0]
> /usr/local/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x112)[0x54f892]
> /usr/local/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
> HTTPWarningCode)+0x1e1)[0x55d7c1]
> /usr/local/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x147)[0x55ee67]
> /usr/local/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x56)[0x523466]
> /usr/local/bin/traffic_server(HttpSM::state_api_callout(int,
> void*)+0x2c8)[0x52d7a8]
> /usr/local/bin/traffic_server(HttpSM::state_api_callback(int,
> void*)+0x82)[0x531f92]
> /usr/local/bin/traffic_server(TSHttpTxnReenable+0x244)[0x4bea94]
> /usr/local/libexec/trafficserver/collapsed_connection.so(+0x3d05)[0x2ab361bc4d05]
> /usr/local/bin/traffic_server(HttpSM::state_api_callout(int,
> void*)+0x104)[0x52d5e4]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x5ab)[0x53263b]
> /usr/local/bin/traffic_server(HttpSM::state_api_callout(int,
> void*)+0x2c8)[0x52d7a8]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x5ab)[0x53263b]
> /usr/local/bin/traffic_server(HttpSM::state_cache_open_read(int,
> void*)+0x156)[0x52eda6]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xbd)[0x52e2fd]
> /usr/local/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
> void*)+0x1c2)[0x510912]
> /usr/local/bin/traffic_server(CacheVC::callcont(int)+0x5b)[0x5f508b]
> /usr/local/bin/traffic_server(CacheVC::openReadStartHead(int,
> Event*)+0xfba)[0x65cb3a]
> /usr/local/bin/traffic_server(CacheVC::handleReadDone(int,
> Event*)+0x1c8)[0x63ab78]
> /usr/local/bin/traffic_server(AIOCallbackInternal::io_complete(int,
> void*)+0x33)[0x5f3f83]
> /usr/local/bin/traffic_server(EThread::process_event(Event*,
> int)+0x150)[0x6b5de0]
> /usr/local/bin/traffic_server(EThread::execute()+0x6f3)[0x6b6873]
> /usr/local/bin/traffic_server[0x6b571a]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2ab358162f6e]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2ab358e949cd]
> {code}
> much regards
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2705) master Crashes frequently
[
https://issues.apache.org/jira/browse/TS-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2705:
Attachment: ts-2705.diff
> master Crashes frequently
> --
>
> Key: TS-2705
> URL: https://issues.apache.org/jira/browse/TS-2705
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Core, Lua
>Reporter: Faysal Banna
> Attachments: ts-2705.diff
>
>
> Hi Guys
> I enabled ts_lua plugin and did experiment on my local computer all worked
> fine
> when i moved to the big machine hosting traffic i noticed that the ATS
> crashes most often (each 5 minutes almost ).
> i don't know the cause of it and can not confirm if its from the ts_lua stuff
> plugins enabled are ts_lua, cacheurl, header_rewrite, collapsed_connection
> anyhow here is the code i get in traffic.out
> {code}
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x2b16fe4fcbb0]
> /usr/local/bin/traffic_server(HttpSM::tunnel_handler_ua(int,
> HttpTunnelConsumer*)+0x31d)[0x51b30d]
> /usr/local/bin/traffic_server(HttpTunnel::consumer_handler(int,
> HttpTunnelConsumer*)+0x74)[0x56b704]
> /usr/local/bin/traffic_server(HttpTunnel::main_handler(int,
> void*)+0x108)[0x56d048]
> /usr/local/bin/traffic_server(write_to_net_io(NetHandler*,
> UnixNetVConnection*, EThread*)+0xf67)[0x68c4f7]
> /usr/local/bin/traffic_server(NetHandler::mainNetEvent(int,
> Event*)+0x286)[0x681576]
> /usr/local/bin/traffic_server(EThread::execute()+0x9a3)[0x6af5a3]
> /usr/local/bin/traffic_server[0x6ae19a]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2b16fe4f4f6e]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b16ff2269cd]
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x2ab35816abb0]
> /usr/local/bin/traffic_server(mime_field_value_get(MIMEField*,
> int*)+0x0)[0x5c7fd0]
> /usr/local/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*,
> HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x112)[0x54f892]
> /usr/local/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
> HTTPWarningCode)+0x1e1)[0x55d7c1]
> /usr/local/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x147)[0x55ee67]
> /usr/local/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x56)[0x523466]
> /usr/local/bin/traffic_server(HttpSM::state_api_callout(int,
> void*)+0x2c8)[0x52d7a8]
> /usr/local/bin/traffic_server(HttpSM::state_api_callback(int,
> void*)+0x82)[0x531f92]
> /usr/local/bin/traffic_server(TSHttpTxnReenable+0x244)[0x4bea94]
> /usr/local/libexec/trafficserver/collapsed_connection.so(+0x3d05)[0x2ab361bc4d05]
> /usr/local/bin/traffic_server(HttpSM::state_api_callout(int,
> void*)+0x104)[0x52d5e4]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x5ab)[0x53263b]
> /usr/local/bin/traffic_server(HttpSM::state_api_callout(int,
> void*)+0x2c8)[0x52d7a8]
> /usr/local/bin/traffic_server(HttpSM::set_next_state()+0x5ab)[0x53263b]
> /usr/local/bin/traffic_server(HttpSM::state_cache_open_read(int,
> void*)+0x156)[0x52eda6]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xbd)[0x52e2fd]
> /usr/local/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
> void*)+0x1c2)[0x510912]
> /usr/local/bin/traffic_server(CacheVC::callcont(int)+0x5b)[0x5f508b]
> /usr/local/bin/traffic_server(CacheVC::openReadStartHead(int,
> Event*)+0xfba)[0x65cb3a]
> /usr/local/bin/traffic_server(CacheVC::handleReadDone(int,
> Event*)+0x1c8)[0x63ab78]
> /usr/local/bin/traffic_server(AIOCallbackInternal::io_complete(int,
> void*)+0x33)[0x5f3f83]
> /usr/local/bin/traffic_server(EThread::process_event(Event*,
> int)+0x150)[0x6b5de0]
> /usr/local/bin/traffic_server(EThread::execute()+0x6f3)[0x6b6873]
> /usr/local/bin/traffic_server[0x6b571a]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2ab358162f6e]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2ab358e949cd]
> {code}
> much regards
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2720) atscppapi: Request transformation doesn't work in streaming mode
[ https://issues.apache.org/jira/browse/TS-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971878#comment-13971878 ] ASF subversion and git services commented on TS-2720: - Commit a4860363a94e7bb51e5de651c5ea07a804915777 in trafficserver's branch refs/heads/master from [~briang] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a486036 ] [TS-2720] Fixing bug in C++ API Request Transformations > atscppapi: Request transformation doesn't work in streaming mode > > > Key: TS-2720 > URL: https://issues.apache.org/jira/browse/TS-2720 > Project: Traffic Server > Issue Type: Bug >Reporter: Manjesh Nilange >Assignee: Brian Geffon > > When a request xform produces data before input has been consumed, the core > is throwing a "no content length" error and ends up crashing the process. The > crash is a separate issue, but the api should handle streaming situation > correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2720) atscppapi: Request transformation doesn't work in streaming mode
[ https://issues.apache.org/jira/browse/TS-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon updated TS-2720: - Fix Version/s: 5.0.0 > atscppapi: Request transformation doesn't work in streaming mode > > > Key: TS-2720 > URL: https://issues.apache.org/jira/browse/TS-2720 > Project: Traffic Server > Issue Type: Bug >Reporter: Manjesh Nilange >Assignee: Brian Geffon > Fix For: 5.0.0 > > > When a request xform produces data before input has been consumed, the core > is throwing a "no content length" error and ends up crashing the process. The > crash is a separate issue, but the api should handle streaming situation > correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2720) atscppapi: Request transformation doesn't work in streaming mode
[ https://issues.apache.org/jira/browse/TS-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon resolved TS-2720. -- Resolution: Fixed > atscppapi: Request transformation doesn't work in streaming mode > > > Key: TS-2720 > URL: https://issues.apache.org/jira/browse/TS-2720 > Project: Traffic Server > Issue Type: Bug >Reporter: Manjesh Nilange >Assignee: Brian Geffon > Fix For: 5.0.0 > > > When a request xform produces data before input has been consumed, the core > is throwing a "no content length" error and ends up crashing the process. The > crash is a separate issue, but the api should handle streaming situation > correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2604) Collapsed connection plugin
[ https://issues.apache.org/jira/browse/TS-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971946#comment-13971946 ] ASF GitHub Bot commented on TS-2604: Github user Degreane commented on the pull request: https://github.com/apache/trafficserver/pull/53#issuecomment-40650993 Hi Previously the patch would just install with no problems but today i was trying to pull it in latest ATS git clone i got the stuff below would it be fixed so we may be able to use it again ? git pull https://github.com/yzlai/trafficserver TS-2604 remote: Counting objects: 24, done. remote: Compressing objects: 100% (21/21), done. remote: Total 24 (delta 7), reused 15 (delta 3) Unpacking objects: 100% (24/24), done. From https://github.com/yzlai/trafficserver * branchTS-2604-> FETCH_HEAD Auto-merging plugins/experimental/Makefile.am Auto-merging configure.ac CONFLICT (content): Merge conflict in configure.ac Automatic merge failed; fix conflicts and then commit the result. Much Regards > Collapsed connection plugin > --- > > Key: TS-2604 > URL: https://issues.apache.org/jira/browse/TS-2604 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Ethan Lai >Assignee: Bryan Call > Labels: review > Fix For: 5.0.0 > > > This plugin collapses connections with identical CacheUrl/EffectiveUrl. > Please find more detail from README and state.png (State Diagram) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2704) Core dump in state_raw_http_server_open
[ https://issues.apache.org/jira/browse/TS-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2704: --- Labels: review yahoo (was: review) > Core dump in state_raw_http_server_open > --- > > Key: TS-2704 > URL: https://issues.apache.org/jira/browse/TS-2704 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Sudheer Vinukonda >Assignee: Bryan Call > Labels: review, yahoo > Fix For: 5.0.0 > > Attachments: ts2704.diff > > > During production roll out of one of our properties, we observed ATS crashing > with the below backtrace. Upon some investigation, we found that > EVENT_INTERVAL was somehow unexpectedly being delivered to > state_raw_http_server_open and is falling into the default handler resulting > in a crash. While we are continuing to understand how the unexpected > EVENT_INTERVAL ended up in state_raw_http_server, this protection fix was > added to ignore the unexpected event. > #0 0x003021a328e5 in raise () from /lib64/libc.so.6 > #1 0x003021a340c5 in abort () from /lib64/libc.so.6 > #2 0x2b1ef4b9fcd9 in ink_die_die_die (retval=4878) at ink_error.cc:43 > #3 0x2b1ef4b9ff03 in ink_fatal_va(int, const char *, typedef > __va_list_tag > __va_list_tag *) (return_code=1, message_format=, > ap=0x2b1ef7fdbbb0) at ink_error.cc:65 > #4 0x2b1ef4ba0038 in ink_fatal (return_code=4878, message_format=0x1313 > ) at ink_error.cc:73 > #5 0x2b1ef4b9e51f in _ink_assert (expression=0x0, file=0x6 out of bounds>, line=-1) at ink_assert.cc:37 > #6 0x005206ef in HttpSM::state_raw_http_server_open > (this=0x2b1f19fbeeb0, event=2, data=0x2b1fa00066b0) at HttpSM.cc:1135 > #7 0x005342d8 in HttpSM::main_handler (this=0x2b1f19fbeeb0, event=2, > data=0x2b1fa00066b0) at HttpSM.cc:2516 > #8 0x006a6c8f in handleEvent (this=0x2b1ef67c5010, e=0x2b1fa00066b0, > calling_code=2) at I_Continuation.h:146 > #9 EThread::process_event (this=0x2b1ef67c5010, e=0x2b1fa00066b0, > calling_code=2) at UnixEThread.cc:141 > #10 0x006a7853 in EThread::execute (this=0x2b1ef67c5010) at > UnixEThread.cc:220 > #11 0x006a5b2a in spawn_thread_internal (a=0x1804b80) at Thread.cc:88 > #12 0x2b1ef5357851 in start_thread () from /lib64/libpthread.so.0 > #13 0x003021ae894d in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2704) Core dump in state_raw_http_server_open
[
https://issues.apache.org/jira/browse/TS-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13972143#comment-13972143
]
Bryan Call commented on TS-2704:
I think it would be better to change this to an error and try to figure out
more about why this is happening.
Error("HttpSM::state_raw_http_server_open, event: EVENT_INTERVAL state: %d
server_entry: %p", state, server_entry);
> Core dump in state_raw_http_server_open
> ---
>
> Key: TS-2704
> URL: https://issues.apache.org/jira/browse/TS-2704
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Bryan Call
> Labels: review, yahoo
> Fix For: 5.0.0
>
> Attachments: ts2704.diff
>
>
> During production roll out of one of our properties, we observed ATS crashing
> with the below backtrace. Upon some investigation, we found that
> EVENT_INTERVAL was somehow unexpectedly being delivered to
> state_raw_http_server_open and is falling into the default handler resulting
> in a crash. While we are continuing to understand how the unexpected
> EVENT_INTERVAL ended up in state_raw_http_server, this protection fix was
> added to ignore the unexpected event.
> #0 0x003021a328e5 in raise () from /lib64/libc.so.6
> #1 0x003021a340c5 in abort () from /lib64/libc.so.6
> #2 0x2b1ef4b9fcd9 in ink_die_die_die (retval=4878) at ink_error.cc:43
> #3 0x2b1ef4b9ff03 in ink_fatal_va(int, const char *, typedef
> __va_list_tag
> __va_list_tag *) (return_code=1, message_format=,
> ap=0x2b1ef7fdbbb0) at ink_error.cc:65
> #4 0x2b1ef4ba0038 in ink_fatal (return_code=4878, message_format=0x1313
> ) at ink_error.cc:73
> #5 0x2b1ef4b9e51f in _ink_assert (expression=0x0, file=0x6 out of bounds>, line=-1) at ink_assert.cc:37
> #6 0x005206ef in HttpSM::state_raw_http_server_open
> (this=0x2b1f19fbeeb0, event=2, data=0x2b1fa00066b0) at HttpSM.cc:1135
> #7 0x005342d8 in HttpSM::main_handler (this=0x2b1f19fbeeb0, event=2,
> data=0x2b1fa00066b0) at HttpSM.cc:2516
> #8 0x006a6c8f in handleEvent (this=0x2b1ef67c5010, e=0x2b1fa00066b0,
> calling_code=2) at I_Continuation.h:146
> #9 EThread::process_event (this=0x2b1ef67c5010, e=0x2b1fa00066b0,
> calling_code=2) at UnixEThread.cc:141
> #10 0x006a7853 in EThread::execute (this=0x2b1ef67c5010) at
> UnixEThread.cc:220
> #11 0x006a5b2a in spawn_thread_internal (a=0x1804b80) at Thread.cc:88
> #12 0x2b1ef5357851 in start_thread () from /lib64/libpthread.so.0
> #13 0x003021ae894d in clone () from /lib64/libc.so.6
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2710) ATS serves the wrong cert because it matches wildcard certs incorrectly
[ https://issues.apache.org/jira/browse/TS-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2710: --- Labels: yahoo (was: ) > ATS serves the wrong cert because it matches wildcard certs incorrectly > --- > > Key: TS-2710 > URL: https://issues.apache.org/jira/browse/TS-2710 > Project: Traffic Server > Issue Type: Bug > Components: SSL >Affects Versions: 5.0.0 >Reporter: manish thakrani > Labels: yahoo > Fix For: 5.0.0 > > Attachments: ts2710.diff > > > If one cert available has a SAN entry for *.a.b.com and another has > a SAN entry for *.b.com, a request for a.b.com will be given > the SAN with the *.a.b.com SAN entry, which will cause the browser > to show the "cert does not match" error. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2548) Add client IP to SSLError() calls in SSLNetVConnection
[ https://issues.apache.org/jira/browse/TS-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2548: --- Labels: review yahoo (was: review) > Add client IP to SSLError() calls in SSLNetVConnection > --- > > Key: TS-2548 > URL: https://issues.apache.org/jira/browse/TS-2548 > Project: Traffic Server > Issue Type: Improvement > Components: Logging, SSL >Reporter: David Carlin > Labels: review, yahoo > Fix For: 5.0.0 > > Attachments: ssl_log_enhancement.diff > > > I asked on IRC if we could put the Client IP in the SSL errors that appear in > diags.log and /var/log/messages - jpeach replied that it was a matter of > adding client IP to SSLError() calls in SSLNetVConnection. This would be > very helpful for troubleshooting. > Additionally, why are the errors sent to /var/log/messages - writing them to > only diags.log is preferable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2724) purge waste memory
bettydramit created TS-2724: --- Summary: purge waste memory Key: TS-2724 URL: https://issues.apache.org/jira/browse/TS-2724 Project: Traffic Server Issue Type: Bug Reporter: bettydramit I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M I set ats proxy.config.cache.target_fragment_size INT 1048576 I use curl to get them : for((i=0;i<100;i++)); do curl -v -o /dev/null http://www.test.com/testdir/$i.mp4; done very file just get once, i can see ats memory usage is 138M After i use curl to purge them : for((i=0;i<100;i++)); do curl -v -o /dev/null -X purge http://www.test.com/testdir/$i.mp4; done I can see ats memory usage is 246M very file removed from ats, why the memory usage enlarge about 100M -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2724) purge waste memory
[
https://issues.apache.org/jira/browse/TS-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bettydramit updated TS-2724:
Description:
I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M
records.config
{code}
proxy.config.cache.target_fragment_size INT 1048576
{code}
I use curl to get them :
{code}
for((i=0;i<100;i++)); do curl -v -o /dev/null
http://www.test.com/testdir/$i.mp4; done
{code}
every file just get once, i can see ats memory usage is 138M
After use curl to purge them :
{code}
for((i=0;i<100;i++)); do curl -v -o /dev/null -X purge
http://www.test.com/testdir/$i.mp4; done
{code}
I can see ats memory usage is 246M
every file removed from ats, why the memory usage enlarge about 100M
was:
I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M
records.config
{code}
proxy.config.cache.target_fragment_size INT 1048576
{code}
I use curl to get them :
{code}
for((i=0;i<100;i++)); do curl -v -o /dev/null
http://www.test.com/testdir/$i.mp4; done
{code}
every file just get once, i can see ats memory usage is 138M
After use curl to purge them :
{code}
for((i=0;i<100;i++)); do curl -v -o /dev/null -X purge
http://www.test.com/testdir/$i.mp4; done
{code}
I can see ats memory usage is 246M
every file removed from ats, why the memory usage enlarge about 100M
> purge waste memory
> --
>
> Key: TS-2724
> URL: https://issues.apache.org/jira/browse/TS-2724
> Project: Traffic Server
> Issue Type: Bug
>Reporter: bettydramit
>
> I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M
> records.config
> {code}
> proxy.config.cache.target_fragment_size INT 1048576
> {code}
> I use curl to get them :
> {code}
> for((i=0;i<100;i++)); do curl -v -o /dev/null
> http://www.test.com/testdir/$i.mp4; done
> {code}
> every file just get once, i can see ats memory usage is 138M
> After use curl to purge them :
> {code}
> for((i=0;i<100;i++)); do curl -v -o /dev/null -X purge
> http://www.test.com/testdir/$i.mp4; done
> {code}
> I can see ats memory usage is 246M
> every file removed from ats, why the memory usage enlarge about 100M
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2724) purge waste memory
[
https://issues.apache.org/jira/browse/TS-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bettydramit updated TS-2724:
Description:
I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M
records.config
{code}
proxy.config.cache.target_fragment_size INT 1048576
{code}
I use curl to get them :
{code}
for((i=0;i<100;i++)); do curl -v -o /dev/null
http://www.test.com/testdir/$i.mp4; done
{code}
every file just get once, i can see ats memory usage is 138M
After use curl to purge them :
{code}
for((i=0;i<100;i++)); do curl -v -o /dev/null -X purge
http://www.test.com/testdir/$i.mp4; done
{code}
I can see ats memory usage is 246M
every file removed from ats, why the memory usage enlarge about 100M
was:
I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M
I set ats proxy.config.cache.target_fragment_size INT 1048576
I use curl to get them :
for((i=0;i<100;i++)); do curl -v -o /dev/null
http://www.test.com/testdir/$i.mp4; done
very file just get once, i can see ats memory usage is 138M
After i use curl to purge them :
for((i=0;i<100;i++)); do curl -v -o /dev/null -X purge
http://www.test.com/testdir/$i.mp4; done
I can see ats memory usage is 246M
very file removed from ats, why the memory usage enlarge about 100M
> purge waste memory
> --
>
> Key: TS-2724
> URL: https://issues.apache.org/jira/browse/TS-2724
> Project: Traffic Server
> Issue Type: Bug
>Reporter: bettydramit
>
> I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M
> records.config
> {code}
> proxy.config.cache.target_fragment_size INT 1048576
> {code}
> I use curl to get them :
> {code}
> for((i=0;i<100;i++)); do curl -v -o /dev/null
> http://www.test.com/testdir/$i.mp4; done
> {code}
> every file just get once, i can see ats memory usage is 138M
> After use curl to purge them :
> {code}
> for((i=0;i<100;i++)); do curl -v -o /dev/null -X purge
> http://www.test.com/testdir/$i.mp4; done
> {code}
> I can see ats memory usage is 246M
> every file removed from ats, why the memory usage enlarge about 100M
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2724) purge waste memory
[
https://issues.apache.org/jira/browse/TS-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bettydramit updated TS-2724:
Affects Version/s: 4.2.0
> purge waste memory
> --
>
> Key: TS-2724
> URL: https://issues.apache.org/jira/browse/TS-2724
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 4.2.0
>Reporter: bettydramit
>
> I have 100 file, 0.mp4, 1.mp4 ... 99.mp4, every file`s size is 1M
> records.config
> {code}
> proxy.config.cache.target_fragment_size INT 1048576
> {code}
> I use curl to get them :
> {code}
> for((i=0;i<100;i++)); do curl -v -o /dev/null
> http://www.test.com/testdir/$i.mp4; done
> {code}
> every file just get once, i can see ats memory usage is 138M
> After use curl to purge them :
> {code}
> for((i=0;i<100;i++)); do curl -v -o /dev/null -X purge
> http://www.test.com/testdir/$i.mp4; done
> {code}
> I can see ats memory usage is 246M
> every file removed from ats, why the memory usage enlarge about 100M
--
This message was sent by Atlassian JIRA
(v6.2#6252)
